Hello,
could anybody take a look for this problem, please?
I'm totally despaired :(
Here are the problematic parts:
2004/03/22 22:37:45.622 3 RasSrv.cxx(197) RAS Send to <GK1ip>:1719
locationConfirm {
requestSeqNum = 589
callSignalAddress = ipAddress {
ip = 4 octets {
<GK2ip> ..g.
}
port = 1720
}
rasAddress = ipAddress {
ip = 4 octets {
<GK2ip> ..g.
}
port = 1719
}
cryptoTokens = 1 entries {
[0]=nestedcryptoToken cryptoHashedToken {
tokenOID = 0.0.8.235.0.2.5
hashedVals = {
tokenOID =
timeStamp = 1079991465
}
token = {
algorithmOID =
paramS = {
}
hash = Hex {
4c 6b 46 2b 50 67 75 72 43 50 6f 76 45 54 54 65
7a 72 72 55 43 41 3d 3d }
}
}
}
}
2004/03/22 22:37:45.622 5 RasSrv.cxx(211) RAS Sent Successful
2004/03/22 22:37:45.622 5 job.cxx(421) JOB Job LRQ deleted
2004/03/22 22:37:45.622 5 job.cxx(410) JOB Worker threads: 5 total - 4 busy, 1 idle
2004/03/22 22:37:47.437 5 yasocket.cxx(617) GkStatus 1 sockets selected from 1, total 1/0
2004/03/22 22:37:47.438 5 job.cxx(358) JOB Worker threads: 5 total - 5 busy, 0 idle
2004/03/22 22:37:47.438 5 yasocket.cxx(617) GkStatus 1 sockets selected from 1, total 1/0
2004/03/22 22:37:47.438 5 job.cxx(410) JOB Worker threads: 5 total - 4 busy, 1 idle
2004/03/22 22:37:48.960 5 yasocket.cxx(617) TCPServer 1 sockets selected from 8, total 8/0
2004/03/22 22:37:48.960 4 yasocket.cxx(716) TCP Accept request on <GK2ip>:1720
2004/03/22 22:37:48.960 5 job.cxx(358) JOB Worker threads: 5 total - 5 busy, 0 idle
2004/03/22 22:37:48.960 5 job.cxx(186) JOB Starting Job Acceptor at Worker thread 10247
2004/03/22 22:37:48.966 5 ProxyChannel.cxx(471) Q931s Reading from <GK1ip>:35297
2004/03/22 22:37:48.966 3 ProxyChannel.cxx(677) Q931s Received: Setup CRV=507 from <GK1ip>:35297
2004/03/22 22:37:48.969 4 ProxyChannel.cxx(633) Q931 Received: {
q931pdu = {
protocolDiscriminator = 8
callReference = 507
from = originator
messageType = Setup
IE: Bearer-Capability = {
80 90 a3 ...
}
IE: Calling-Party-Number = {
<a calling number>
}
IE: Called-Party-Number = {
<a called number>
}
IE: User-User = {
20 80 06 00 08 91 4a 00 04 28 00 b5 00 00 12 40 .....J..(.....@
01 3c 05 01 00 00 fd 84 80 2f 7b 7f 11 d8 96 a6 .<......./{.....
...
}
}
h225pdu = {
h323_uu_pdu = {
h323_message_body = setup {
protocolIdentifier = 0.0.8.2250.0.4
sourceInfo = {
vendor = {
vendor = {
t35CountryCode = 181
t35Extension = 0
manufacturerCode = 18
}
}
gateway = {
protocol = 1 entries {
[0]=voice {
supportedPrefixes = 0 entries {
}
}
}
}
mc = FALSE
undefinedNode = FALSE
}
activeMC = FALSE
conferenceID = 16 octets {
fd 84 80 2f 7b 7f 11 d8 96 a6 a0 96 83 a3 b6 69 .../{..........i
}
conferenceGoal = create <<null>>
callType = pointToPoint <<null>>
sourceCallSignalAddress = ipAddress {
ip = 4 octets {
<GK1ip> ....
}
port = 1720
}
callIdentifier = {
guid = 16 octets {
fd 85 1c 57 7b 7f 11 d8 96 a8 a0 96 83 a3 b6 69 ...W{..........i
}
}
fastStart = 12 entries {
[0]= 30 octets {
00 00 00 0c 10 b5 00 00 12 07 47 37 32 33 31 61 ..........G7231a
72 80 0b 05 00 01 00 d1 e3 a5 84 49 35 80 r..........I5.
}
[1]= 41 octets {
40 00 00 06 04 01 00 4c 10 b5 00 00 12 07 47 37 @......L......G7
32 33 31 61 72 80 12 15 00 01 00 d1 e3 a5 84 49 231ar..........I
34 00 d1 e3 a5 84 49 35 80 4.....I5.
}
[2]= 20 octets {
00 00 01 0d 00 01 c0 00 0b 05 00 01 00 d1 e3 a5 ................
84 49 35 80 .I5.
}
[3]= 31 octets {
40 00 01 06 04 01 00 4d 00 01 c0 00 12 15 00 01 @......M........
00 d1 e3 a5 84 49 34 00 d1 e3 a5 84 49 35 80 .....I4.....I5.
}
[4]= 20 octets {
00 00 02 0d 00 00 40 00 0b 05 00 01 00 d1 e3 a5 ......@.........
84 49 35 80 .I5.
}
[5]= 31 octets {
40 00 02 06 04 01 00 4d 00 00 40 00 12 15 00 01 @......M..@.....
00 d1 e3 a5 84 49 34 00 d1 e3 a5 84 49 35 80 .....I4.....I5.
}
[6]= 19 octets {
00 00 03 0d 40 03 80 0b 05 00 01 00 d1 e3 a5 84 ....@...........
49 35 80 I5.
}
[7]= 30 octets {
40 00 03 06 04 01 00 4d 40 03 80 12 15 00 01 00 @......M@.......
d1 e3 a5 84 49 34 00 d1 e3 a5 84 49 35 80 ....I4.....I5.
}
[8]= 20 octets {
00 00 04 0e 00 01 03 80 0b 05 00 01 00 d1 e3 a5 ................
84 49 35 80 .I5.
}
[9]= 31 octets {
40 00 04 06 04 01 00 4e 00 01 03 80 12 15 00 01 @......N........
00 d1 e3 a5 84 49 34 00 d1 e3 a5 84 49 35 80 .....I4.....I5.
}
[10]= 19 octets {
00 00 05 0c 60 13 80 0b 05 00 01 00 d1 e3 a5 84 ....`...........
49 35 80 I5.
}
[11]= 30 octets {
40 00 05 06 04 01 00 4c 60 13 80 12 15 00 01 00 @......L`.......
d1 e3 a5 84 49 34 00 d1 e3 a5 84 49 35 80 ....I4.....I5.
}
}
mediaWaitForConnect = FALSE
canOverlapSend = FALSE
multipleCalls = FALSE
maintainConnection = FALSE
}
h245Tunneling = TRUE
}
}
}
2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING Checking policy Explicit for request `e¸a.A. CRV=507
2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING Checking policy Internal for request `e¸a.A. CRV=507
2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING Checking policy Neighbor for request `e¸a.A. CRV=507
2004/03/22 22:37:48.970 3 ProxyChannel.cxx(1226) Q931 No destination for unregistered call fd 85 1c 57 7b
7f 11 d8 9...
Thanks in advance!
Kind regards,
Thomas
Wednesday, March 24, 2004, 2:33:35 PM, Thomas wrote:
T> Did you see the LCF/Setup message in previouse post of this thread?
T> What trace part would procide more help? It was a recompiled version.
T> The configuration should be OK, because I used the same configuration
T> for that gatekeeper as for another Gnugk GK. Let me explain:
I tryed: gnugk ->> gnugk
T> It worked fine, Setup was processed, call was established.
T> When I tryd: 3rd party gk (dont't have any info what kind) -> gnugk
T> I got Setup as it was post earlier (the 1st message in this thread).
T> The configuration was the same, just the gkid's and prefixes were
T> different, but the configuration was identical.
T> The main difference between gnugk Setup and that another GK:
T> gnugk has:
T> cryptoToken, destinationAddress
T> while 2nd GK didn't send these information.
T> As I looked for source codes, I found:
T> ProxyChannel.cxx
T> line 1220: if (H225_TransportAddress *dest = request.Process()) {
T> in this stage it got into else part.
T> Thank you in advance,
T> Thomas
T> Wednesday, March 24, 2004, 12:36:46 PM, Zygmuntowicz wrote:
ZM>> This is just a bad trace output (another question is why it is bad - maybe
ZM>> you need to make clean and recompile everything).
ZM>> I suspect the Setup message is correctly recognized and processed.
ZM>> The problem is rather with configuration- maybe Routing engine
ZM>> does not find a destination for the Setup message.
ZM>> Thomas <thomasj@xxxxxxxxx> wrote:
>>>Could somebody help me with this issue?
>>>Could somebody take a look for that Setup message?
>>>I discovered, that this problem appears also in situation when GK1
>>>sends call directly to GK2 (no LRQ/LCF, just Setup).
>>>
>>>Does GnuGk support H.225v4? (protocolIdentifier = 0.0.8.2250.0.4)
>>>
>>>I would be very happy to get some help.
>>>I already looked into source codes but I wasn\'t able to
>>>find/underestand the issue.
>>>
>>>Thanks in advance,
>>> Thomas
>>>
>>>Tuesday, March 23, 2004, 1:18:11 PM, Thomas wrote:
>>>T> Tuesday, March 23, 2004, 1:31:52 AM, ray wrote:
>>>r>> On Monday 22 March 2004 17:50, Thomas wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have this topology:
>>>>>> GK1-> GK2 -> GK3
>>>>>> Where GK2 is gnugk-2.2. GK1 and GK3\'s type is unknown.
>>>>>> GK2 runs in GK routed mode (and I have access only to it).
>>>>>> 1. GK1 is trying to make a call to GK2
>>>>>> 2. GK2 asks GK3
>>>>>> 3. GK3 responds with LCF
>>>>>> 4. GK2 sends LCF to GK1
>>>>>> 5. GK1 sends Q931 Setup
>>>>>> 6. GK2 rejects the call.
>>>
>>>
>>>r>> have you tried to set the hop count to 3 or 4 maybe.
>>>r>> also i have these settings enables.
>>>
>>>r>> ForwardHopCount=3
>>>r>> AcceptForwardedLRQ=1
>>>r>> ForwardResponse=1
>>>r>> ForwardLRQ=always
>>>r>> CiscoGKCompatible=1
>>>
>>>T> Yes, I have thos options (ForwardHopCount=2).
>>>
>>>T> This problem looks me strange:
>>>T> 2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING
>>>T> Checking policy Explicit for request `e¸a.A. CRV=507
>>>T> 2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING
>>>T> Checking policy Internal for request `e¸a.A. CRV=507
>>>T> 2004/03/22 22:37:48.970 5 Routing.h(140) ROUTING
>>>T> Checking policy Neighbor for request `e¸a.A. CRV=507
>>>T> From this I see that the message type was not recognised, on it\'s
>>>T> place are some symbols (`e¸a.A.). I checked the sources and found,
>>>T> that this is written in case the messageType variable doesn\'t match to
>>>T> any of specified (e.g. Setup). From the received Setup message is
>>>T> seen, that the Setup message was correct (in the meaning of the
>>>T> messageType). But later somehow it went to be wrong. My feeling is
>>>T> that the problem is in policy routing or before somewhere.
>>>
>>>T> Can anybody help me, please?
>>>
>>>T> Thanks in advance,
>>>T> Thomas
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/
