Hi,I've been looking into level 5 debug logs (attached) and I think I might have found the source of the problem.
There is trimmed version of the log with my comments:2009/10/02 14:07:53.822 4 Cisco -> GnuGK openLogicalChannel forwardLogicalChannelNumber=2 dataType=audioData g729 sessionID=1 2009/10/02 14:07:53.822 5 GnuGK -> Patton openLogicalChannel forwardLogicalChannelNumber=2 dataType=audioData g729 sessionID=1 2009/10/02 14:07:53.830 4 Patton -> GnuGK openLogicalChannelAck forwardLogicalChannelNumber=2 sessionID=1 2009/10/02 14:07:53.830 5 GnuGK -> Cisco openLogicalChannelAck forwardLogicalChannelNumber=2 sessionID=1 2009/10/02 14:07:53.833 4 Patton -> GnuGK openLogicalChannel forwardLogicalChannelNumber=3 dataType=audioData g729 sessionID=1 2009/10/02 14:07:53.833 5 GnuGK -> Cisco openLogicalChannel forwardLogicalChannelNumber=3 dataType=audioData g729 sessionID=1 2009/10/02 14:07:54.030 4 Cisco -> GnuGK openLogicalChannelAck forwardLogicalChannelNumber=3 2009/10/02 14:07:54.030 5 GnuGK -> Patton openLogicalChannelAck forwardLogicalChannelNumber=3
At this point there is 2 RTP g729 media streams established: Cisco->GnuGK->Patton channel=2, id=1, g729 Patton->GnuGK->Cisco channel=3, id=1, g7292009/10/02 14:07:56.319 4 Cisco -> GnuGK openLogicalChannel forwardLogicalChannelNumber=3 application=t38fax sessionID=3 2009/10/02 14:07:56.319 5 GnuGK -> Patton openLogicalChannel forwardLogicalChannelNumber=3 application=t38fax sessionID=3
2009/10/02 14:07:56.326 4 Patton -> GnuGK closeLogicalChannel forwardLogicalChannelNumber=3 2009/10/02 14:07:56.326 4 ProxyChannel.cxx(4378) RTP Delete logical channel 3
Patton signals closing of LogicalChannel 3, but it seems that instead of closing old g729 channel originated by Patton gnugk is also closing new t38 LogicalChannel originated by Cisco (both channels share the same number 3)
2009/10/02 14:07:56.327 4 Cisco -> GnuGK closeLogicalChannelAck forwardLogicalChannelNumber=3 2009/10/02 14:07:56.332 4 Patton -> GnuGK requestChannelClose forwardLogicalChannelNumber=2 2009/10/02 14:07:56.333 4 Cisco -> GnuGK requestChannelCloseAck forwardLogicalChannelNumber=2 2009/10/02 14:07:56.342 4 Patton -> GnuGK closeLogicalChannelAck forwardLogicalChannelNumber=2
2009/10/02 14:07:56.350 4 Patton -> GnuGK openLogicalChannelAck forwardLogicalChannelNumber=3 sessionID=3 2009/10/02 14:07:56.350 2 ProxyChannel.cxx(4736) Proxy Warning: logical channel 3 not found
I think this warning message confirms my theory - Patton tries to ACK new t38 channel, but it's already deleted by gnugk.
2009/10/02 14:07:56.355 4 Patton -> GnuGK openLogicalChannel forwardLogicalChannelNumber=5 application=t38fax sessionID=3 2009/10/02 14:07:56.355 5 GnuGK -> Cisco openLogicalChannel forwardLogicalChannelNumber=5 application=t38fax sessionID=3 2009/10/02 14:07:56.545 4 Cisco -> GnuGK openLogicalChannelAck forwardLogicalChannelNumber=5 2009/10/02 14:07:56.545 5 GnuGK -> Patton openLogicalChannelAck forwardLogicalChannelNumber = 5
Looking at debug it seems that openLogicalChannelAck from Patton was never forwarded to Cisco. Looking at the packet trace I can see that openLogicalChannelAck was forwarded but it it wasn't properly proxyed - IP address and UDP ports were not properly rewritten. So my suggestion is that choosing logical channel to close only channel number is matched, but not IP address of gateway originating the channel (it seems that only originating gateway can signal to close logical channel). Not sure if any of this makes sense - I've tried to look into RTPLogicalChannel class myself, but for someone with experience limited to writing of few basic shell scripts the source code looks like rocket science :(
Julius Jan Willamowius wrote:
Hi Julius, in 2.2.8 and 2.3.0 ProxyForSameNAT defaults to 0 (that will change in 2.3.1). In your situation some calls might not get proxied. Try setting ProxyForSameNAT=1. In 2.3.0 you could also set ProxyAlways=1. Does that fix our problem ? Regards, Jan Julius wrote:Hi,Just forget to mention that I'm running Red Hat Enterprise 5.4. I've tested both gnugk 2.2.8 with OpenH323 1.18.0, PWLib 1.10.3 and gnugk 2.3.0 with H323Plus 1.21.0, PTLib 2.4.5.Julius Julius wrote:Hello,I've recently tried to send fax using t.38 via CiscoGW->gnugkProxy->PattonGW. Success rate was only ~50%. Before addressing mailing list I've tried my best to troubleshoot the problem myself. So:Connectivity scheme is pretty simple:CiscoGw(ip:10.242.0.101)-----(ip:10.242.0.1)gnugkProxy(ip:10.242.1.10)-----(ip:10.242.1.11)PattonGWgnugk config: [Gatekeeper::Main] Fourtytwo=42 Name=gk1 Home=10.242.1.10 UseBroadcastListener=0 TimeToLive=300 TraceLevel=0 [GkStatus::Auth] rule=password admin=YZ943Tg7NsY= [RoutedMode] GKRouted=1 H245Routed=1 CallSignalPort=1720 [CallTable] DefaultCallDurationLimit=3600 [Proxy] Enable=1 InternalNetwork=10.242.0.0/24 [RasSrv::RRQFeatures] AcceptEndpointIdentifier=1 AcceptGatewayPrefixes=1
<<attachment: debugLog.zip>>
------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf
_______________________________________________________ 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/
