Re: nf_conntrack_sip problem

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

 



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