Mikael Be careful, Just cause it works for PVX it's not the problem. The reason is that there are 2 control channels for H.323 calls H.225 and H.245. Sometimes H.245 is tunneled in H.225 so only 1 TCP connection however in other cases there are 2 TCP connections. 1 for both. But I think you did actual find the problem. Your gatekeeper settings have GKRouted=1 (H.225) H245Routed=0 (H.245) so you are intentionally separating them. Also the PIX firewall looks like the one causing the issue. So I suggest you make these changes to the INI [RoutedMode] H245Routed=1 But I think it's the PIX firewall that is causing the problem. Not GnuGk or Mirial. Simon -----Original Message----- From: Mikael Grehn [mailto:mikael.grehn@xxxxxxxx] Sent: 30 November 2011 07:48 To: GNU Gatekeeper Users Subject: Re: Question about disengageRequest Hi Simon! That's a really good guess. I tested to make the identical call but to the first customer (primary gnugk) from the same H323 device (Polycom PVX) behind the same (second) customer (Cisco 5510) firewall. This should really result in the same dropped call after about 25 seconds if it was caused by some firewall that is dropping connections...but it isn't!! The call is working perfectly. So this means that the firewall is not dropping the call (H225 transport). And the disengageRequest is coming from the primary gnugk so it cant be a Mirial thing either. I hope I am not spamming the forum to much this this single issue. Please forgive me if you think so. :-) Best Regards, Mikael -----Ursprungligt meddelande----- Från: Simon Horne [mailto:s.horne@xxxxxxxxxxxxxx] Skickat: den 29 november 2011 22:34 Till: 'GNU Gatekeeper Users' Ämne: Re: Question about disengageRequest Mikael My guess is that the H.225 TCP connection is being dropped forcing the DRQ from GnuGk (shutdown the call). Hence the forceDrop reason Generally firewalls will drop TCP connections after about 20 sec of inactivity. The H.225 channel gets very little activity if not H.245 tunneled. Make sure there is nothing between the devices that could do that. The only other reason is the Mirial side is deciding to drop the TCP connection due to a timeout or something. You will need to check the config and logs as well. You might need to consult mirial. Either case the error is coming from outside GnuGk control. Simon -----Original Message----- From: Mikael Grehn [mailto:mikael.grehn@xxxxxxxx] Sent: 30 November 2011 07:17 To: GNU Gatekeeper Users Subject: Re: Question about disengageRequest Thank you Jan! My main skill is unfortunately SIP but on that side I can see the SIP Invite, SIP OK and later SIP Ack which should mean that H323 has connected the call? I have tried to go through the Gnugk traces but have difficulties detecting the source of the error. I see: maintainConnection = false supportsAltGK = <<null>> in the registration that looks bad. In the sudden disengageRequest (from primary gnugk directly to Mirial) I see a forceDrop as disengageReason. Without getting anything from the H323 client? ------------- 2011/11/29 16:12:56.201 3 RasSrv.cxx(235) RAS Send to 207.183.235.149:1719 disengageRequest { requestSeqNum = 2 endpointIdentifier = 9 characters { 0036 0039 0035 0037 005f 0065 006e 0064 6957_end 0070 p } conferenceID = 16 octets { 02 35 81 4e 9a 4b 71 12 36 b9 e2 73 30 a9 2e cf .5.N.Kq.6..s0... } callReferenceValue = 51151 disengageReason = forcedDrop <<null>> callIdentifier = { guid = 16 octets { 02 35 81 4e 9a 4b 71 12 36 b8 e2 73 30 a9 2e cf .5.N.Kq.6..s0... } } gatekeeperIdentifier = 6 characters { 0047 0047 006e 0075 0047 006b GGnuGk } answeredCall = false } ------------- If it is OK with you I'd like to send you the gnugk traces directly (not exposing real IP's), both the primary and alternative one together with my gatekeeper configuration? Only if that is OK of course! :) Best Regards, Mikael -----Ursprungligt meddelande----- Från: Jan Willamowius [mailto:jan@xxxxxxxxxxxxxx] Skickat: den 29 november 2011 20:55 Till: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Ämne: Re: Question about disengageRequest Again, audio and video is no indication that the call has connected (and would be past most of the message timeouts). You have to check for the Connect message and check if the H.245 connection negotiated properly. Regards, Jan Mikael Grehn wrote: > Hi Jan and thanks for the rapid response. > > The calls are perfectly connected and they run with audio and video > for about 25 seconds (perhaps 20 seconds after fully being connected). Then the primary gatekeeper is sending this disengageRequest to Mirial and Mirial disconnects both sides. Primary gatekeeper has been "quiet" for about 20 seconds before this so something is absolutely happening! > > If I make a call to the other customer (directly to primary Gk) the > call is not disconnected at all and are working perfectly. :) > > Any ideas what can trigger this? > > Thanks for you kind help! > > Best Regards, > Mikael > > > -----Ursprungligt meddelande----- > Från: Jan Willamowius [mailto:jan@xxxxxxxxxxxxxx] > Skickat: den 29 november 2011 20:21 > Till: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Ämne: Re: Question about disengageRequest > > Hi Mikael, > > are your calls being terminated before or after they connect ? > (Hearing voice may just mean that the call was using FastStart.) > > If GnuGk actively terminates a call it usually detected ran into a > timeout (it tries to detect stale calls). When you have multiple gatekeepers involved, make sure each gatekeeper that handles the call sees all messages for that call. > > Regards, > Jan > > > Mikael Grehn wrote: > > Hi! > > > > I have a question about why a primary gatekeeper(out of 2 > > gatekeepers) is disconnecting calls after 25 seconds that first > > reaches the alternative gatekeeper on another machine. The H323 > > endpoint that is receiving the call is a Mirial gateway. :) > > > > We have two customers that use incoming H323 and SIP for their service. > > > > For the H323 we are using a H323 Gnugk for each customer (on two different IP's) that I have tried to setup as primary and alternative gatekeeper. > > To translate from H323 to SIP (which is the protocol mainly > > supported by our service) we have a Mirial H323 2 SIP in between. > > The H323 side of Mirial is registered in the primary gatekeeper at > > customer 1. We cant register it in the alternative as well. :) > > > > > > Customer 1: GnuGk(primary) IP1 <--registered Mirial IP3 > > |reg > > Customer 2: GnuGk(alternative) IP2 > > > > > > Calls from H323 clients to the first (primary) customer is working perfectly. > > Calls from H323 to the second customer (with the alternative > > gatekeeper gets the call to work for about 25 seconds. After this the primary gatekeepers decides to send disengageRequest directly to Mirial gateway, that is later disconnecting the calls. > > > > This is the log from the primary gatekeeper (207.183.111.122) when > > it is disconnecting a working call: > > > > (. . . about 20 seconds with no logs since the call was setup OK . . > > .) disengageRequest { > > requestSeqNum = 104 > > endpointIdentifier = 9 characters { > > 0031 0034 0030 0038 005f 0065 006e 0064 1408_end > > 0070 p > > } > > conferenceID = 16 octets { > > 02 35 81 01 a4 43 d0 10 36 b3 e2 73 30 a9 2e cf .5...C..6..s0... > > } > > callReferenceValue = 51145 > > disengageReason = forcedDrop <<null>> > > callIdentifier = { > > guid = 16 octets { > > 02 35 81 01 a4 43 d0 10 36 b2 e2 73 30 a9 2e cf .5...C..6..s0... > > } > > } > > gatekeeperIdentifier = 6 characters { > > 0047 0047 006e 0075 0047 006b GGnuGk > > } > > answeredCall = false > > } > > 2011/11/29 12:55:55.689 2 RasTbl.cxx(2642) Gk Disconnect Call No. 26 > > 2011/11/29 12:55:55.689 2 RasTbl.cxx(4076) CDR ignore not connected call > > 2011/11/29 12:55:55.689 2 gkacct.cxx(955) GKACCT Successfully logged event 2 for call no. 26 > > 2011/11/29 12:55:55.690 2 RasSrv.cxx(173) RAS Read from 207.183.111.224:1719 > > 2011/11/29 12:55:55.690 3 RasSrv.cxx(223) RAS > > disengageConfirm { > > requestSeqNum = 104 > > usageInformation = { > > nonStandardUsageFields = 0 entries { > > } > > alertingTime = 1322592922 > > connectTime = 1322592926 > > } > > } > > 2011/11/29 12:55:55.690 1 RasSrv.cxx(355) RAS DCF Received from 207.183.111.224:1719 > > 2011/11/29 12:55:56.689 3 RasTbl.cxx(2130) Gk Delete Call No. 26 > > 2011/11/29 12:55:57.278 2 RasSrv.cxx(173) RAS Read from 207.183.111.224:1719 > > 2011/11/29 12:55:57.278 3 RasSrv.cxx(223) RAS > > disengageRequest { > > requestSeqNum = 60528 > > endpointIdentifier = 9 characters { > > 0031 0034 0030 0038 005f 0065 006e 0064 1408_end > > 0070 p > > } > > conferenceID = 16 octets { > > 02 35 81 01 a4 43 d0 10 36 b3 e2 73 30 a9 2e cf .5...C..6..s0... > > } > > callReferenceValue = 18377 > > disengageReason = normalDrop <<null>> > > callIdentifier = { > > guid = 16 octets { > > 02 35 81 01 a4 43 d0 10 36 b2 e2 73 30 a9 2e cf .5...C..6..s0... > > } > > } > > gatekeeperIdentifier = 6 characters { > > 0047 0047 006e 0075 0047 006b GGnuGk > > } > > answeredCall = true > > usageInformation = { > > nonStandardUsageFields = 0 entries { > > } > > alertingTime = 1322592922 > > connectTime = 1322592926 > > endTime = 1322592952 > > } > > terminationCause = releaseCompleteReason gatekeeperResources <<null>> > > } > > 2011/11/29 12:55:57.279 1 RasSrv.cxx(355) RAS DRQ Received from 207.183.111.224:1719 > > 2011/11/29 12:55:57.279 2 RasSrv.cxx(395) DCF|207.183.111.224|1408_endp|18377|normalDrop|02-35-81-01-a4-43-d0-10-3 DCF|6-b2 -e2-73-30-a9-2e-cf; > > 2011/11/29 12:55:57.279 3 RasSrv.cxx(235) RAS Send to 207.183.111.224:1719 > > disengageConfirm { > > requestSeqNum = 60528 > > } > > > > Any ideas why it does this and how I can configure it away? > > I am adding the gnugk.ini file from primary gatekeeper. It is very > > similar on the alternative one. :) > > > > Primary Gk: 207.183.111.222 > > Alternativ Gk: 207.183.111.223 > > Mirial h323 2 SIP gw: 207.183.111.224 > > > > [Gatekeeper::Main] > > FortyTwo=42 > > Name=GGnuGk > > TimeToLive=600 > > StatusTraceLevel=2 > > AlternateGKs=207.183.111.223:1719:false:120:CGnuGk > > SendTo=207.183.111.223:1719 > > SkipForwards=207.183.111.223 > > CompareAliasCase=0 > > CompareAliasType=0 > > ExternalIP=207.183.111.222 > > [GkStatus::Auth] > > rule=allow > > 127.0.0.1=allow > > default=allow > > Shutdown=allow > > > > [RoutedMode] > > GKRouted=1 > > H245Routed=0 > > CallSignalPort=1720 > > AcceptUnregisteredCalls=1 > > DropCallsByReleaseComplete=1 > > SupportNATedEndpoints=1 > > > > [Proxy] > > Enable=0 > > ProxyForNAT=1 > > ProxyForSameNAT=0 > > > > [RoutingPolicy] > > default=explicit,internal,parent,neighbor,catchall,vqueue > > > > [RasSrv::RewriteAlias] > > customerdomain.com=0099999999 > > > > [Routing::CatchAll] > > CatchAllAlias=PSEGateway > > > > [EP::PSEGateway] > > Capacity=30 > > AddNumbers=0099999999 > > AdditionalDestinationAlias=0099999999 > > > > I have tried to change the real IP's into fictional ones, might have missed some! > > Any help is very appreciated! :) > > > > Best Regards, > > Mikael -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
