Re: possible bug when sending FAX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

there is a fix in the CVS now so GnuGk will only look at the channels
an endpoint has created when closing logical channels.

GnuGk's previous behavior to look at both sides is only needed for
pretty buggy endpoints. If you need to retain the old behavior, you can
set

[Proxy]
SearchBothSidesOnCLC=1

Regards,
Jan


Julius wrote:
> 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, g729
> 
> 
> 2009/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)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
> >>>
> >>>
> >>>       
> 


-- 
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________________

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/

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux