H.323 behavior

H.323 behavior

[Greg Scott]

I was doing some h.323 testing a while ago and noticed some strange
behavior.  After thinking about it a while, I think I have an idea
what's going on.  
 
First test case:
 
Linux 2.6.17.2 on one site, 2.6.18.1 on the other side.  Both sides use
proxy ARP to Polycom V500 H.323 codecs with public IP Addresses.  So it
looks like this:
 
Polycom------Firewall with----Internet----Firewall with----Polycom
V500         2.6.18.1                     2.6.17.2         V500
Public IP   (Proxy ARP)                  (Proxy ARP)      Public IP

When either side hangs up a call and then immediately tries to call the
other side again, the call does not go through.  Tcpdump on the
firewalls shows a conversation with TCP port 1720, but the UDP packets
never start flying back and forth.  After a couple of minutes, the
problem seems to clear up and both sides can establish a call again.  

Other test cases use the Linux system on my side and generally just an
h.323 codec directly connected to the Internet on the other side.  So
far, I have not been able to reproduce this timeout behavior in the
other test cases.  I can hang up and call right back and the other side
always answers.  

I have a hunch this is what's going on:

The firewall on the side that hangs up the call shuts down all the
appropriate connection tracking info for the call.  But the firewall on
the other side does not shut down its connection tracking stuff.
Instead, it waits some period of time for a timeout and once this
timeout passes, then it resets its conntrack info as well.  This is just
a hunch to explain the behavior I see - I don't have proof.  

Can I do anything about this behavior?  

Thanks

- Greg Scott

Re: H.323 behavior

[Jing Min Zhao]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB18030", Size: 2173 bytes --]

Normally, when a call is hung up, the main TCP connection (Q.931) will be disconnected, all the derived RTP/RTCP connections on both boxes should be cleared as well. There is a easy way to verify your hunch, have you checked /proc/net/ip_conntrack?

----- Original Message ----- 
From: "Greg Scott" <GregScott@InfraSupportEtc.com>
To: <netfilter-devel@lists.netfilter.org>
Sent: April 13, 2007 7:45 AM
Subject: H.323 behavior


I was doing some h.323 testing a while ago and noticed some strange
behavior.  After thinking about it a while, I think I have an idea
what's going on.  
 
First test case:
 
Linux 2.6.17.2 on one site, 2.6.18.1 on the other side.  Both sides use
proxy ARP to Polycom V500 H.323 codecs with public IP Addresses.  So it
looks like this:
 
Polycom------Firewall with----Internet----Firewall with----Polycom
V500         2.6.18.1                     2.6.17.2         V500
Public IP   (Proxy ARP)                  (Proxy ARP)      Public IP

When either side hangs up a call and then immediately tries to call the
other side again, the call does not go through.  Tcpdump on the
firewalls shows a conversation with TCP port 1720, but the UDP packets
never start flying back and forth.  After a couple of minutes, the
problem seems to clear up and both sides can establish a call again.  

Other test cases use the Linux system on my side and generally just an
h.323 codec directly connected to the Internet on the other side.  So
far, I have not been able to reproduce this timeout behavior in the
other test cases.  I can hang up and call right back and the other side
always answers.  

I have a hunch this is what's going on:

The firewall on the side that hangs up the call shuts down all the
appropriate connection tracking info for the call.  But the firewall on
the other side does not shut down its connection tracking stuff.
Instead, it waits some period of time for a timeout and once this
timeout passes, then it resets its conntrack info as well.  This is just
a hunch to explain the behavior I see - I don't have proof.  

Can I do anything about this behavior?  

Thanks

- Greg Scott

RE: H.323 behavior

[Greg Scott]

Apologies - I never replied back to the list on how this turned out.
Jing Min Zhao was kind enough to reply privately and we developed a
theory. Jing was right.  The problem was, I had set up the Polycom codec
here to use fixed ports - a legacy from before Jing's H.323 module.  So
every time I hung up a call and tried again, the Polycom would try to
call using the same ports.  But the firewall hadn't cleared them yet and
that's why the strange behavior.  The cure - just get rid of fixed ports
on the Polycom codec and use it as delivered from the factory.

- Greg Scott



-----Original Message-----
From: netfilter-devel-bounces@lists.netfilter.org
[mailto:netfilter-devel-bounces@lists.netfilter.org] On Behalf Of Greg
Scott
Sent: Friday, April 13, 2007 6:46 AM
To: netfilter-devel@lists.netfilter.org
Subject: H.323 behavior

I was doing some h.323 testing a while ago and noticed some strange
behavior.  After thinking about it a while, I think I have an idea
what's going on.  
 
First test case:
 
Linux 2.6.17.2 on one site, 2.6.18.1 on the other side.  Both sides use
proxy ARP to Polycom V500 H.323 codecs with public IP Addresses.  So it
looks like this:
 
Polycom------Firewall with----Internet----Firewall with----Polycom
V500         2.6.18.1                     2.6.17.2         V500
Public IP   (Proxy ARP)                  (Proxy ARP)      Public IP

When either side hangs up a call and then immediately tries to call the
other side again, the call does not go through.  Tcpdump on the
firewalls shows a conversation with TCP port 1720, but the UDP packets
never start flying back and forth.  After a couple of minutes, the
problem seems to clear up and both sides can establish a call again.  

Other test cases use the Linux system on my side and generally just an
h.323 codec directly connected to the Internet on the other side.  So
far, I have not been able to reproduce this timeout behavior in the
other test cases.  I can hang up and call right back and the other side
always answers.  

I have a hunch this is what's going on:

The firewall on the side that hangs up the call shuts down all the
appropriate connection tracking info for the call.  But the firewall on
the other side does not shut down its connection tracking stuff.
Instead, it waits some period of time for a timeout and once this
timeout passes, then it resets its conntrack info as well.  This is just
a hunch to explain the behavior I see - I don't have proof.  

Can I do anything about this behavior?  

Thanks

- Greg Scott

Re: H.323 behavior

[Patrick McHardy]

Greg Scott wrote:
> Apologies - I never replied back to the list on how this turned out.
> Jing Min Zhao was kind enough to reply privately and we developed a
> theory. Jing was right.  The problem was, I had set up the Polycom codec
> here to use fixed ports - a legacy from before Jing's H.323 module.  So
> every time I hung up a call and tried again, the Polycom would try to
> call using the same ports.  But the firewall hadn't cleared them yet and
> that's why the strange behavior.  The cure - just get rid of fixed ports
> on the Polycom codec and use it as delivered from the factory.


It would probably make sense to destroy the connection when we seen
a CloseLogicalChannel or CloseLogicalChannelAck message to deal with
this kind of problem.

RE: H.323 behavior

[Greg Scott]

I'll be happy to test it...

- Greg
 

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Wednesday, May 30, 2007 11:35 PM
To: Greg Scott
Cc: netfilter-devel@lists.netfilter.org; Jing Min Zhao
Subject: Re: H.323 behavior

Greg Scott wrote:
> Apologies - I never replied back to the list on how this turned out.
> Jing Min Zhao was kind enough to reply privately and we developed a 
> theory. Jing was right.  The problem was, I had set up the Polycom 
> codec here to use fixed ports - a legacy from before Jing's H.323 
> module.  So every time I hung up a call and tried again, the Polycom 
> would try to call using the same ports.  But the firewall hadn't 
> cleared them yet and that's why the strange behavior.  The cure - just

> get rid of fixed ports on the Polycom codec and use it as delivered
from the factory.


It would probably make sense to destroy the connection when we seen a
CloseLogicalChannel or CloseLogicalChannelAck message to deal with this
kind of problem.

Re: H.323 behavior

[Jing Min Zhao]

----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Greg Scott" <GregScott@InfraSupportEtc.com>
Cc: <netfilter-devel@lists.netfilter.org>; "Jing Min Zhao" 
<zhaojingmin@users.sourceforge.net>
Sent: Thursday, May 31, 2007 12:34 AM
Subject: Re: H.323 behavior


> Greg Scott wrote:
>> Apologies - I never replied back to the list on how this turned out.
>> Jing Min Zhao was kind enough to reply privately and we developed a
>> theory. Jing was right.  The problem was, I had set up the Polycom codec
>> here to use fixed ports - a legacy from before Jing's H.323 module.  So
>> every time I hung up a call and tried again, the Polycom would try to
>> call using the same ports.  But the firewall hadn't cleared them yet and
>> that's why the strange behavior.  The cure - just get rid of fixed ports
>> on the Polycom codec and use it as delivered from the factory.
>
>
> It would probably make sense to destroy the connection when we seen
> a CloseLogicalChannel or CloseLogicalChannelAck message to deal with
> this kind of problem.
>

Sometimes when people change codec, for example, from voice to T.38 fax, 
they also close channels and open channels, but the H.245 connection doesn't 
diconnect. So better to wait for the connection disconnect itself or at 
least disconnect upon EndSessionCommand.

Re: H.323 behavior

[Patrick McHardy]

Jing Min Zhao wrote:
> 
>> It would probably make sense to destroy the connection when we seen
>> a CloseLogicalChannel or CloseLogicalChannelAck message to deal with
>> this kind of problem.
>>
> 
> Sometimes when people change codec, for example, from voice to T.38 fax,
> they also close channels and open channels, but the H.245 connection
> doesn't diconnect. So better to wait for the connection disconnect
> itself or at least disconnect upon EndSessionCommand.


CloseLogicalChannel might not be the right message (its been a while
since I last did something with H.323), but at least when we know for
sure the connection is closed we could kill it instead of waiting for
the timeout.