Hi Jan, Thanks for suggestion, I've just tested ProxyForSameNAT=1 and sadly result is the same :( I think I'll try "debug trc 5" and will look for the clues in log files. Is there any other way to troubleshoot the issue? 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)PattonGW >>> >>> >>> gnugk 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 >>> >>> >>> I've taken packet traces of failed call on both interfaces (10.242.0.1 >>> and 10.242.1.10) (please see them attached). >>> I've tried to understand some of this, but of course I could be wrong: >>> 1. Call gets signaled (ARQ, ACF, all kinds of signaling and >>> negotiations). >>> 2. Two unidirectional g729 RTP streams opened (2 x openLogicalChannel >>> (g729), 2 x openLogicalChannelAck) >>> 3. Gateways detect fax and negotiate to tear down g729 RTP streams and >>> open new t.38 RTP streams. >>> 4. Two unidirectional t.38 RTP streams opened (2 x openLogicalChannel >>> (t.38), 2 x openLogicalChannelAck) >>> >>> By inspecting Cisco side packets from step 4 I've noticed weird thing >>> (cisco.pcap packet 221): >>> In openLogicalChannel message GNUGK correctly rewrites Pattons ip >>> address 10.242.1.11 with his own 10.242.1.10. But in >>> openLogicalChannelAck message GNUGK signals 10.242.1.11 and UDP ports >>> originally reported by Patton. As the result Cisco starts sending RTP >>> packets directly to Pattons ip 10.242.1.11 instead of sending them to >>> GNUGK's ip 10.242.1.10. >>> In cases when fax transmission is successful GNUGK rewrites ip address >>> and UDP ports correctly (I can send packet traces of good session if >>> needed). >>> Not sure if this only coincidence but in failed fax transmissions both >>> openLogicalChannel and openLogicalChannelAck gets packed in single IP >>> packet, in successful fax transmissions each message gets sent in >>> separate packet. >>> >>> Sadly I'm unable to locate the cause of a bug in source code, so I'm >>> addressing this forum in hope that someone more skilled than me could >>> look into this. >>> >>> Thanks. >>> >>> Julius >>> > > ------------------------------------------------------------------------------ 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/
