From mboxrd@z Thu Jan  1 00:00:00 1970
From: Patrick McHardy <kaber@trash.net>
Subject: Re: nf_conntrack_sip problem
Date: Wed, 01 Jul 2009 18:16:21 +0200
Message-ID: <4A4B8BD5.6060907@trash.net>
References: <20090701113701.GZ9285@Redstar.dorchain.net> <4A4B509C.3080600@trash.net> <20090701144321.GB9285@Redstar.dorchain.net> <4A4B7B4D.5090900@trash.net> <20090701161029.GC9285@Redstar.dorchain.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <netfilter-owner@vger.kernel.org>
In-Reply-To: <20090701161029.GC9285@Redstar.dorchain.net>
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
To: Joerg Dorchain <joerg@dorchain.net>
Cc: netfilter@vger.kernel.org

Joerg Dorchain wrote:
> On Wed, Jul 01, 2009 at 05:05:49PM +0200, Patrick McHardy wrote:
>>> I tried this. Actually, it makes things worse. Now Asterisk
>>> complains: [Jul  1 16:17:46] WARNING[20516]: chan_sip.c:1787 
>>> __sip_xmit:
>>> sip_xmit of 0x86f8de0 (len 384) to 217.10.79.9:5060 returned -1:
>>> Operation not permitted
>>>
>>> (Trying to register with sipgate.de; registration in parallel
>>> with tel.lu seems to work)
>> sipgate needs sip_direct_media=0 since the RTP streams originate from
>> a seperate cluster.
> 
> I loaded the module with sip_direct_signalling=0 and
> sip_direct_media=0 to get these messages.

That should be fine. Possibly related to NAT without the helper,
see below.

>> Did you load the NAT module before the conntrack module?
> 
> I did not load the nat modules at all. As said, I am only
> interested in dynamically accepting the rtp streams.
>>> nf_conntrack_sip without options on a trial incoming call however gives:
>>>
>>> # conntrack -E expect
>>> 180 proto=17 src=85.93.219.114 dst=212.88.133.153 sport=0 dport=7070
>>> 180 proto=17 src=85.93.219.114 dst=212.88.133.153 sport=0 dport=7071
> 
> Also for tel.lu the expected IP should be 85.93.219.122.

It takes the addresses from the SDP payload. The gateway seems to be
handling RTP stream with a different server as well.

> BTW, it seems that combining an SER for the handling the sip part
> with an asterisk for the dial-in part seems to be common. Here it
> means the RTP stream is coming typically from a different IP than
> the register endpoint.

Thats what the sip_direct_media=0 option is meant for.

>> Besides the direct_media option, I assume you're accepting EXPECTED
>> and RELATED packets?
> 
> No, only RELATED. I repeat the line: -A checkblock -m state
> --state RELATED,ESTABLISHED -j RETURN

Sorry, my mistake :) That should be fine.

> For reference, again the complete iptables:
> # Generated by iptables-save v1.4.3.2 on Wed Jul  1 13:26:32 2009
> *nat
> :PREROUTING ACCEPT [1385:93589]
> :POSTROUTING ACCEPT [319:26979]
> :OUTPUT ACCEPT [5114:401834]
> -A PREROUTING ! -i ppp0 -p udp -m udp --dport 5060 -j REDIRECT=20
> -A POSTROUTING -o ppp0 -j MASQUERADE=20
> COMMIT

So you are using NAT? You *need* the NAT helper in that case for
remapping clashing ports.