Re: SIP conntrack defeating Asterisk canreinvite

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

 



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

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

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux