SIP conntrack defeating Asterisk canreinvite

SIP conntrack defeating Asterisk canreinvite

[John A. Sullivan III]

Hello, all.  Since implementing an iptables firewall between the
Asterisk PBX and several SIP phones, the Asterisk PBX ability to
"reinvite", i.e., to redirect the media stream from passing through the
PBX to be directly between the phones has been broken even when the
phones are on the same network (i.e., no firewall between the phones).
We've been beating our heads against the wall thinking it was the
complex rule set but it appears the issue is ip_conntrack_sip.

Before I drop another day into verifying this, may I ask if anyone else
has had a similar problem and found a solution?

The reinvite works by the Asterisk server sending a SIP invite after the
call has been set up. The new invite contains the address of the phone
in the SDP portion of the packet rather than the address of the PBX.
This should redirect the media stream to flow directly between the
phones.  However, it appears conntrack is rewriting the SDP so that the
address is reverted to the PBX address.

Here are the relevant SDP portion of a reinvite captured on the PBX
using tcpdump and displayed in Wireshark.  The PBX is at 172.x.x.8 and
the phone is at 10.x.x.193:

Owner/Creator, Session Id (o): root 1417450700 1417450701 IN IP4
10.68.6.183
Owner Address: 10.68.6.183
Connection Information (c): IN IP4 10.68.6.183
Connection Address: 10.68.6.183

Here is a similar sequence but captured from the phone itself:
Owner/Creator, Session Id (o): root 595629021 595629022 IN IP4
172.30.14.8
Owner Address: 172.30.14.8
Connection Information (c): IN IP4 172.30.14.8
Connection Address: 172.30.14.8

It would appear conntrack is incorrectly "fixed" the packet.

I noticed newer kernels have sip_direct_media and sip_direct_signalling
options.  I don't know if those apply but they do not seem to be present
in our CentOS 5.3 kernel.

I'll probably spend most of tomorrow confirming this hypothesis and
investigating solutions so I'd be deeply appreciative for any
time-saving advice.  Thanks - John

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

Re: SIP conntrack defeating Asterisk canreinvite

[Joerg Dorchain]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On Tue, Aug 25, 2009 at 09:04:28PM -0400, John A. Sullivan III wrote:
> The reinvite works by the Asterisk server sending a SIP invite after the
> call has been set up. The new invite contains the address of the phone
> in the SDP portion of the packet rather than the address of the PBX.
> This should redirect the media stream to flow directly between the
> phones.  However, it appears conntrack is rewriting the SDP so that the
> address is reverted to the PBX address.

Rewriting sounds like nat. I am using conntrack_sip to be able
to have the rtp connections accepted as related to a sip
connection. Are you sure that you aren't using the sip nat helper
by change?

To have reinvites working, I needed sip_direct_media=0 as option
to nf_conntrack_cip

Bye,

Joerg

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: SIP conntrack defeating Asterisk canreinvite

[John A. Sullivan III]

On Wed, 2009-08-26 at 09:15 +0200, Joerg Dorchain wrote:
> On Tue, Aug 25, 2009 at 09:04:28PM -0400, John A. Sullivan III wrote:
> > The reinvite works by the Asterisk server sending a SIP invite after the
> > call has been set up. The new invite contains the address of the phone
> > in the SDP portion of the packet rather than the address of the PBX.
> > This should redirect the media stream to flow directly between the
> > phones.  However, it appears conntrack is rewriting the SDP so that the
> > address is reverted to the PBX address.
> 
> Rewriting sounds like nat. I am using conntrack_sip to be able
> to have the rtp connections accepted as related to a sip
> connection. Are you sure that you aren't using the sip nat helper
> by change?
> 
> To have reinvites working, I needed sip_direct_media=0 as option
> to nf_conntrack_cip
> 
> Bye,
> 
> Joerg
Yes, as I was thinking after I wrote this, it is probably ip_nat_sip
since it is doing packet rewriting.  So it sounds like it is a problem
without sip_direct_media which sounds like it implies upgrading my
kernel :-(  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

Re: SIP conntrack defeating Asterisk canreinvite

[John A. Sullivan III]

On Wed, 2009-08-26 at 06:59 -0400, John A. Sullivan III wrote:
> On Wed, 2009-08-26 at 09:15 +0200, Joerg Dorchain wrote:
> > On Tue, Aug 25, 2009 at 09:04:28PM -0400, John A. Sullivan III wrote:
> > > The reinvite works by the Asterisk server sending a SIP invite after the
> > > call has been set up. The new invite contains the address of the phone
> > > in the SDP portion of the packet rather than the address of the PBX.
> > > This should redirect the media stream to flow directly between the
> > > phones.  However, it appears conntrack is rewriting the SDP so that the
> > > address is reverted to the PBX address.
> > 
> > Rewriting sounds like nat. I am using conntrack_sip to be able
> > to have the rtp connections accepted as related to a sip
> > connection. Are you sure that you aren't using the sip nat helper
> > by change?
> > 
> > To have reinvites working, I needed sip_direct_media=0 as option
> > to nf_conntrack_cip
> > 
> > Bye,
> > 
> > Joerg
> Yes, as I was thinking after I wrote this, it is probably ip_nat_sip
> since it is doing packet rewriting.  So it sounds like it is a problem
> without sip_direct_media which sounds like it implies upgrading my
> kernel :-(  Thanks - John
Hmm . . . on the other hand, these connections are NOT doing NAT.  If
they are separated by a VPN and using RFC 1918 addresses.  Why would
ip_nat_sip even come into play? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

Re: SIP conntrack defeating Asterisk canreinvite

[John A. Sullivan III]

On Thu, 2009-08-27 at 19:01 -0400, John A. Sullivan III wrote:
> On Wed, 2009-08-26 at 06:59 -0400, John A. Sullivan III wrote:
> > On Wed, 2009-08-26 at 09:15 +0200, Joerg Dorchain wrote:
> > > On Tue, Aug 25, 2009 at 09:04:28PM -0400, John A. Sullivan III wrote:
> > > > The reinvite works by the Asterisk server sending a SIP invite after the
> > > > call has been set up. The new invite contains the address of the phone
> > > > in the SDP portion of the packet rather than the address of the PBX.
> > > > This should redirect the media stream to flow directly between the
> > > > phones.  However, it appears conntrack is rewriting the SDP so that the
> > > > address is reverted to the PBX address.
> > > 
> > > Rewriting sounds like nat. I am using conntrack_sip to be able
> > > to have the rtp connections accepted as related to a sip
> > > connection. Are you sure that you aren't using the sip nat helper
> > > by change?
> > > 
> > > To have reinvites working, I needed sip_direct_media=0 as option
> > > to nf_conntrack_cip
> > > 
> > > Bye,
> > > 
> > > Joerg
> > Yes, as I was thinking after I wrote this, it is probably ip_nat_sip
> > since it is doing packet rewriting.  So it sounds like it is a problem
> > without sip_direct_media which sounds like it implies upgrading my
> > kernel :-(  Thanks - John
> Hmm . . . on the other hand, these connections are NOT doing NAT.  If
> they are separated by a VPN and using RFC 1918 addresses.  Why would
> ip_nat_sip even come into play? Thanks - John
Well . . . we've had mixed success.  We finally gave in and upgraded to
kernel 2.6.30.5 rather than stay with the stock CentOS 5.3 kernel.
Setting sip_direct_media=0 helped but there is still an issue.

Without changing that setting, the conversation would succeed until the
reinvite was issued and then audio would go dead.  Now, sometimes, the
audio starts off dead until the end points send a SIP packet to each
other.  Then the RDP stream jumps alive.  Until then, the RDP packets
are blocked.   It's as if conntrack did not pick up the changed end
point address in the SDP.  Once the end points sent an allowed SIP
packet, the RDP packets were appropriately associated with that
connection.

This seems to manifest itself in another way.  When a call is
transferred, we frequently have one way audio.  The culprit is again the
reinvite.  As soon as the PBX sends the end point address in the SDP,
the audio breaks.

Is this something we have misconfigured or is it a shortcoming in the
SIP conntrack module? Of course, I would imagine conntrack can only do
so much, e.g., what if the transfer made the call traverse a different
firewall - that would not be conntrack's fault!

On a related note, we also tried implementing sip_direct_signalling=0
but what exactly, in practical terms, does that do? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society