possible bug when sending FAX

[Julius-23]

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@...
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/

[Julius-23]

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@...
> 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/

------------------------------------------------------------------------------
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@...
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/

[Willamowius]

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

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

------------------------------------------------------------------------------
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@...
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/

[Julius-23]

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@...
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/

[Julius-23]

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
>>>
>>>
>>>      

------------------------------------------------------------------------------
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@...
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/

[Willamowius]

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@..., 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@...
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/