* nf_conntrack_sip problem @ 2009-07-01 11:37 Joerg Dorchain 2009-07-01 12:03 ` Patrick McHardy 0 siblings, 1 reply; 12+ messages in thread From: Joerg Dorchain @ 2009-07-01 11:37 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 2353 bytes --] Hello, I have some problems understanding nf_conntrack_sip. I want to use it avoid having static entries for the rtp stream, as IMHO those should be catched by a RELATED rules when nf_conntrack_sip works properly. I have a machine with a pppoe interface connected to the internet, with asterisk running on it, and a small local network behind it on eth1, where I want to force sip traffic going through the local asterisk. Unfortunately it doesn't work as expected. I use vanilla kernel 2.6.30. My iptable rules that do not work look like this: # 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 -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Wed Jul 1 13:26:32 2009 # Generated by iptables-save v1.4.3.2 on Wed Jul 1 13:26:32 2009 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [32081:6020561] :blocknlog - [0:0] :checkblock - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i ppp0 -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT -A INPUT -i ppp0 -p tcp -m multiport --dports 22,25,53,80,443,993 -j ACCEPT -A INPUT -i ppp0 -p udp -m multiport --dports 53,123,5060 -j ACCEPT -A INPUT -s 212.88.128.10/32 -p udp -m udp --sport 53 -j ACCEPT -A INPUT -s 212.224.0.188/32 -i ppp0 -p ipv6 -j ACCEPT -A INPUT -s 192.88.99.1/32 -i ppp0 -p ipv6 -j ACCEPT -A INPUT -j checkblock -A INPUT -j ACCEPT -A FORWARD -j checkblock -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -j ACCEPT -A blocknlog -m limit --limit 1/sec -j LOG --log-prefix "Bad Packet: " --log-level 5 -A blocknlog -j REJECT --reject-with icmp-net-prohibited -A checkblock -m state --state RELATED,ESTABLISHED -j RETURN -A checkblock -m state --state INVALID -j LOG --log-prefix "Invalid match: " --log-level 5 -A checkblock ! -i ppp0 -j RETURN -A checkblock -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j RETURN -A checkblock -p udp -m limit --limit 1/min -m ttl --ttl-lt 3 -j blocknlog COMMIT # Completed on Wed Jul 1 13:26:32 2009 Maybe I am missing something obvious, but I'd appreciate a hint. (yes, nf_conntrack_sip is loaded) Bye, Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 11:37 nf_conntrack_sip problem Joerg Dorchain @ 2009-07-01 12:03 ` Patrick McHardy 2009-07-01 14:43 ` Joerg Dorchain 0 siblings, 1 reply; 12+ messages in thread From: Patrick McHardy @ 2009-07-01 12:03 UTC (permalink / raw) To: Joerg Dorchain; +Cc: netfilter Joerg Dorchain wrote: > Hello, > > I have some problems understanding nf_conntrack_sip. I want to > use it avoid having static entries for the rtp stream, as IMHO > those should be catched by a RELATED rules when nf_conntrack_sip > works properly. > > I have a machine with a pppoe interface connected to the > internet, with asterisk running on it, and a small local network > behind it on eth1, where I want to force sip traffic going > through the local asterisk. > > Unfortunately it doesn't work as expected. I use vanilla kernel > 2.6.30. My iptable rules that do not work look like this: > > Maybe I am missing something obvious, but I'd appreciate a hint. > (yes, nf_conntrack_sip is loaded) Depending on how your SIP provider works, you might need to set the sip_direct_signalling option to zero (in case signalling connections can arrive from different addresses than the one registered with), additionally you might need to set the sip_direct_media option to 0 in case the RTP streams arrive from different addresses than the signalling endpoint. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 12:03 ` Patrick McHardy @ 2009-07-01 14:43 ` Joerg Dorchain 2009-07-01 15:05 ` Patrick McHardy 0 siblings, 1 reply; 12+ messages in thread From: Joerg Dorchain @ 2009-07-01 14:43 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter [-- Attachment #1: Type: text/plain, Size: 7727 bytes --] On Wed, Jul 01, 2009 at 02:03:40PM +0200, Patrick McHardy wrote: >> I have some problems understanding nf_conntrack_sip. I want to >> use it avoid having static entries for the rtp stream, as IMHO >> those should be catched by a RELATED rules when nf_conntrack_sip >> works properly. >> >> I have a machine with a pppoe interface connected to the >> internet, with asterisk running on it, and a small local network >> behind it on eth1, where I want to force sip traffic going >> through the local asterisk. >> >> Unfortunately it doesn't work as expected. I use vanilla kernel >> 2.6.30. My iptable rules that do not work look like this: >> >> Maybe I am missing something obvious, but I'd appreciate a hint. >> (yes, nf_conntrack_sip is loaded) > > Depending on how your SIP provider works, you might need to set the > sip_direct_signalling option to zero (in case signalling connections > can arrive from different addresses than the one registered with), > additionally you might need to set the sip_direct_media option to > 0 in case the RTP streams arrive from different addresses than the > signalling endpoint. 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) 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 (packet dump from asterisk) *CLI> sip debug SIP Debugging enabled The 'sip debug' command is deprecated and will be removed in a future release. Please use 'sip set debug' instead. *CLI> <--- SIP read from 85.93.219.114:5060 ---> INVITE sip:s@212.88.133.153 SIP/2.0 Record-Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> Via: SIP/2.0/UDP 85.93.219.114;branch=z9hG4bKbcd7.7f0d18e6.0 Via: SIP/2.0/UDP 85.93.219.122:5060;branch=z9hG4bK13c75fc4;rport=5060 Max-Forwards: 16 From: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c To: <sip:20400371@tel.lu> Contact: <sip:Unknown@85.93.219.122> Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 INVITE User-Agent: Asterisk PBX 1.6.0.6 Date: Wed, 01 Jul 2009 14:23:10 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Content-Type: application/sdp Content-Length: 357 v=0 o=root 1551730590 1551730590 IN IP4 85.93.219.122 s=Asterisk PBX 1.6.0.6 c=IN IP4 85.93.219.122 t=0 0 m=audio 10316 RTP/AVP 8 0 97 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-------------> --- (16 headers 16 lines) --- Sending to 85.93.219.114 : 5060 (no NAT) Using INVITE request as basis request - 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 Found peer 'tel.lu' Found RTP audio format 8 Found RTP audio format 0 Found RTP audio format 97 Found RTP audio format 3 Found RTP audio format 101 Peer audio RTP is at port 85.93.219.122:10316 Found audio description format PCMA for ID 8 Found audio description format PCMU for ID 0 Found audio description format iLBC for ID 97 Found audio description format GSM for ID 3 Found audio description format telephone-event for ID 101 Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x40e (gsm|ulaw|alaw|ilbc)/video=0x0 (nothing), combined - 0xe (gsm|ulaw|alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 85.93.219.122:10316 Looking for s in from-tellu (domain 212.88.133.153) list_route: hop: <sip:85.93.219.114;ftag=as73ca530c;lr=on> <--- Transmitting (no NAT) to 85.93.219.114:5060 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP 85.93.219.114;branch=z9hG4bKbcd7.7f0d18e6.0;received=85.93.219.114 Via: SIP/2.0/UDP 85.93.219.122:5060;branch=z9hG4bK13c75fc4;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> From: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c To: <sip:20400371@tel.lu> Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:s@212.88.133.153> Content-Length: 0 <--- Reliably Transmitting (no NAT) to 85.93.219.114:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 85.93.219.114;branch=z9hG4bKbcd7.7f0d18e6.0;received=85.93.219.114 Via: SIP/2.0/UDP 85.93.219.122:5060;branch=z9hG4bK13c75fc4;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> From: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c To: <sip:20400371@tel.lu>;tag=as47e79d4b Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:s@212.88.133.153> Content-Type: application/sdp Content-Length: 234 v=0 o=root 20701 20701 IN IP4 212.88.133.153 s=session c=IN IP4 212.88.133.153 t=0 0 m=audio 7070 RTP/AVP 3 0 8 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv At this moment, I have a connection, but no sound. <--- SIP read from 85.93.219.114:5060 ---> ACK sip:s@212.88.133.153 SIP/2.0 Record-Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> Via: SIP/2.0/UDP 85.93.219.114;branch=0 Via: SIP/2.0/UDP 85.93.219.122:5060;branch=z9hG4bK31206d61;rport=5060 Max-Forwards: 16 From: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c To: <sip:20400371@tel.lu>;tag=as47e79d4b Contact: <sip:Unknown@85.93.219.122> Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 ACK User-Agent: Asterisk PBX 1.6.0.6 Content-Length: 0 <--- SIP read from 85.93.219.114:5060 ---> ACK sip:s@212.88.133.153 SIP/2.0 Record-Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> Via: SIP/2.0/UDP 85.93.219.114;branch=0 Via: SIP/2.0/UDP 85.93.219.122:5060;branch=z9hG4bK65d8099e;rport=5060 Max-Forwards: 16 From: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c To: <sip:20400371@tel.lu>;tag=as47e79d4b Contact: <sip:Unknown@85.93.219.122> Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 ACK User-Agent: Asterisk PBX 1.6.0.6 Content-Length: 0 Reliably Transmitting (no NAT) to 85.93.219.114:5060: BYE sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK44ee4aa2;rport Route: <sip:85.93.219.114;ftag=as73ca530c;lr=on> From: <sip:20400371@tel.lu>;tag=as47e79d4b To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK44ee4aa2;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as47e79d4b;lr=on> From: <sip:20400371@tel.lu>;tag=as47e79d4b To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as73ca530c Call-ID: 6b6bfb5c3eb6137532b36d216e8c9948@85.93.219.122 CSeq: 102 BYE User-Agent: Asterisk PBX 1.6.0.6 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Content-Length: 0 <-------------> --- (11 headers 0 lines) --- Bye, Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 14:43 ` Joerg Dorchain @ 2009-07-01 15:05 ` Patrick McHardy 2009-07-01 16:10 ` Joerg Dorchain 0 siblings, 1 reply; 12+ messages in thread From: Patrick McHardy @ 2009-07-01 15:05 UTC (permalink / raw) To: Joerg Dorchain; +Cc: netfilter Joerg Dorchain wrote: > On Wed, Jul 01, 2009 at 02:03:40PM +0200, Patrick McHardy wrote: >> Depending on how your SIP provider works, you might need to set the >> sip_direct_signalling option to zero (in case signalling connections >> can arrive from different addresses than the one registered with), >> additionally you might need to set the sip_direct_media option to >> 0 in case the RTP streams arrive from different addresses than the >> signalling endpoint. > > 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. Did you load the NAT module before the conntrack module? > 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 Besides the direct_media option, I assume you're accepting EXPECTED and RELATED packets? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 15:05 ` Patrick McHardy @ 2009-07-01 16:10 ` Joerg Dorchain 2009-07-01 16:16 ` Patrick McHardy 0 siblings, 1 reply; 12+ messages in thread From: Joerg Dorchain @ 2009-07-01 16:10 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter [-- Attachment #1: Type: text/plain, Size: 3607 bytes --] 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. > > 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. 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. > > 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 Man page says: RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error. As it works for ftp connection tracking, I'd assume it should also work for sip connection tracking. 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 # Completed on Wed Jul 1 13:26:32 2009 # Generated by iptables-save v1.4.3.2 on Wed Jul 1 13:26:32 2009 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [32081:6020561] :blocknlog - [0:0] :checkblock - [0:0] -A INPUT -i lo -j ACCEPT=20 -A INPUT -i ppp0 -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j AC= CEPT=20 -A INPUT -i ppp0 -p tcp -m multiport --dports 22,25,53,80,443,993 -j ACCEPT= =20 -A INPUT -i ppp0 -p udp -m multiport --dports 53,123,5060 -j ACCEPT=20 -A INPUT -s 212.88.128.10/32 -p udp -m udp --sport 53 -j ACCEPT=20 -A INPUT -s 212.224.0.188/32 -i ppp0 -p ipv6 -j ACCEPT=20 -A INPUT -s 192.88.99.1/32 -i ppp0 -p ipv6 -j ACCEPT=20 -A INPUT -j checkblock=20 -A INPUT -j ACCEPT=20 -A FORWARD -j checkblock=20 -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-= mss-to-pmtu=20 -A FORWARD -j ACCEPT=20 -A blocknlog -m limit --limit 1/sec -j LOG --log-prefix "Bad Packet: " --lo= g-level 5=20 -A blocknlog -j REJECT --reject-with icmp-net-prohibited=20 -A checkblock -m state --state RELATED,ESTABLISHED -j RETURN=20 -A checkblock -m state --state INVALID -j LOG --log-prefix "Invalid match: = " --log-level 5=20 -A checkblock ! -i ppp0 -j RETURN=20 -A checkblock -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j RETURN=20 -A checkblock -p udp -m limit --limit 1/min -m ttl --ttl-lt 3 -j blocknlog= =20 COMMIT # Completed on Wed Jul 1 13:26:32 2009 Bye, Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 16:10 ` Joerg Dorchain @ 2009-07-01 16:16 ` Patrick McHardy 2009-07-01 20:56 ` Joerg Dorchain 0 siblings, 1 reply; 12+ messages in thread From: Patrick McHardy @ 2009-07-01 16:16 UTC (permalink / raw) To: Joerg Dorchain; +Cc: netfilter 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 16:16 ` Patrick McHardy @ 2009-07-01 20:56 ` Joerg Dorchain 2009-07-02 8:17 ` Joerg Dorchain 0 siblings, 1 reply; 12+ messages in thread From: Joerg Dorchain @ 2009-07-01 20:56 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter [-- Attachment #1: Type: text/plain, Size: 2315 bytes --] On Wed, Jul 01, 2009 at 06:16:21PM +0200, Patrick McHardy wrote: > 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. Aehm, 85.93.219.122 is the address from the SDP payload for the RTP stream as attached. 85.93.219.114 is is address of where the SIP REGISTER is sent to. I will try again with only sip_direct_media=0. > >> *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. I intend to to so. Currently I am only talking about packet send and received from the host in question by local sockets, not about forwarded packets. I.e. the asterisks runs on the host intended to play SIP gateway, but also masqerading router for e.g. http and other protocols. Bye, Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-01 20:56 ` Joerg Dorchain @ 2009-07-02 8:17 ` Joerg Dorchain 2009-07-02 9:04 ` Joerg Dorchain 2009-07-03 9:44 ` Patrick McHardy 0 siblings, 2 replies; 12+ messages in thread From: Joerg Dorchain @ 2009-07-02 8:17 UTC (permalink / raw) To: Patrick McHardy, netfilter [-- Attachment #1: Type: text/plain, Size: 1036 bytes --] On Wed, Jul 01, 2009 at 10:56:16PM +0200, Joerg Dorchain wrote: > > Aehm, 85.93.219.122 is the address from the SDP payload for the > RTP stream as attached. 85.93.219.114 is is address of where the SIP REGISTER > is sent to. > > I will try again with only sip_direct_media=0. I works, but somewhat ugly. # conntrack -E expect 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077 All the places where the ip is 0.0.0.0 or the port is 0 could be filled more specifically. The necessary information is available in the same SIP/SDP flow as the used information. Besides the two RTP stream are unidirectional, so I'd like to have something like this: 180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080 180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077 Bye, Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-02 8:17 ` Joerg Dorchain @ 2009-07-02 9:04 ` Joerg Dorchain 2009-07-03 9:45 ` Patrick McHardy 2009-07-03 9:44 ` Patrick McHardy 1 sibling, 1 reply; 12+ messages in thread From: Joerg Dorchain @ 2009-07-02 9:04 UTC (permalink / raw) To: Patrick McHardy, netfilter [-- Attachment #1: Type: text/plain, Size: 1125 bytes --] On Thu, Jul 02, 2009 at 10:17:41AM +0200, Joerg Dorchain wrote: > > I works, but somewhat ugly. > # conntrack -E expect > 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080 > 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081 > 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076 > 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077 > > All the places where the ip is 0.0.0.0 or the port is 0 could be > filled more specifically. The necessary information is available > in the same SIP/SDP flow as the used information. Besides the two > RTP stream are unidirectional, so I'd like to have something like > this: > 180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080 > 180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077 Sorry for replying to often to myself, I have another addendum: In case of asterisk reinvites in order to have to RTP stream moved away from the machine, there are still connections expected despite that these invites are explicitly meant to stop rtp streams to the local machine. Joerg [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-02 9:04 ` Joerg Dorchain @ 2009-07-03 9:45 ` Patrick McHardy 2009-07-03 11:20 ` Joerg Dorchain 0 siblings, 1 reply; 12+ messages in thread From: Patrick McHardy @ 2009-07-03 9:45 UTC (permalink / raw) To: Joerg Dorchain; +Cc: netfilter Joerg Dorchain wrote: > On Thu, Jul 02, 2009 at 10:17:41AM +0200, Joerg Dorchain wrote: >> I works, but somewhat ugly. >> # conntrack -E expect >> 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080 >> 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081 >> 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076 >> 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077 >> >> All the places where the ip is 0.0.0.0 or the port is 0 could be >> filled more specifically. The necessary information is available >> in the same SIP/SDP flow as the used information. Besides the two >> RTP stream are unidirectional, so I'd like to have something like >> this: >> 180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080 >> 180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077 > > Sorry for replying to often to myself, I have another addendum: > In case of asterisk reinvites in order to have to RTP stream > moved away from the machine, there are still connections expected > despite that these invites are explicitly meant to stop rtp > streams to the local machine. Could you send a dump? Last time I tried asterisk reinvites, it didn't work at all because asterisk made some (don't recall the details) invalid assumptions. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-03 9:45 ` Patrick McHardy @ 2009-07-03 11:20 ` Joerg Dorchain 0 siblings, 0 replies; 12+ messages in thread From: Joerg Dorchain @ 2009-07-03 11:20 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter [-- Attachment #1: Type: text/plain, Size: 17574 bytes --] On Fri, Jul 03, 2009 at 11:45:51AM +0200, Patrick McHardy wrote: > > Joerg Dorchain wrote: >> On Thu, Jul 02, 2009 at 10:17:41AM +0200, Joerg Dorchain wrote: >>> I works, but somewhat ugly. >>> # conntrack -E expect >>> 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080 >>> 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081 >>> 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076 >>> 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077 >>> >>> All the places where the ip is 0.0.0.0 or the port is 0 could be >>> filled more specifically. The necessary information is available >>> in the same SIP/SDP flow as the used information. Besides the two >>> RTP stream are unidirectional, so I'd like to have something like >>> this: >>> 180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080 >>> 180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077 >> >> Sorry for replying to often to myself, I have another addendum: >> In case of asterisk reinvites in order to have to RTP stream >> moved away from the machine, there are still connections expected >> despite that these invites are explicitly meant to stop rtp >> streams to the local machine. > > Could you send a dump? Last time I tried asterisk reinvites, it didn't > work at all because asterisk made some (don't recall the details) > invalid assumptions. Here is the dump. The most interesting lines for you might be those with X-asterisk-Info: SIP re-invite (External RTP bridge) in between. My own asterisk is version 1:1.4.21.2~dfsg-3 from Debian. Bye, Joerg Here is some part missing for setting up the incoming call. The dump starts when asterisk tries the second sip call outgoing, and then directly connect the rtp streams. <-------------> --- (12 headers 0 lines) --- Reliably Transmitting (no NAT) to 217.10.79.9:5060: INVITE sip:10000@sipgate.de SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK7ae9f331;rport From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de> Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Date: Fri, 03 Jul 2009 10:55:17 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 290 v=0 o=root 29312 29312 IN IP4 212.88.133.153 s=session c=IN IP4 212.88.133.153 t=0 0 m=audio 7076 RTP/AVP 8 3 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- <--- SIP read from 217.10.79.9:5060 ---> SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK7ae9f331;rport=5060 From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=fe1721141f05bd30d4b50c70da3ae228.8296 Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 102 INVITE Proxy-Authenticate: Digest realm="sipgate.de", nonce="4a4de4c165713d8cf463b184d93833a2d3e9c869" Content-Length: 0 <-------------> --- (8 headers 0 lines) --- Transmitting (no NAT) to 217.10.79.9:5060: ACK sip:10000@sipgate.de SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK7ae9f331;rport From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=fe1721141f05bd30d4b50c70da3ae228.8296 Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- Reliably Transmitting (no NAT) to 217.10.79.9:5060: INVITE sip:10000@sipgate.de SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK17f9904c;rport From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de> Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 103 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Proxy-Authorization: Digest username="xxxxxxx", realm="sipgate.de", algorithm=MD5, uri="sip:10000@sipgate.de", nonce="xxxxxxxxxxxxx", response="xxxxxxxxxxxxxx" Date: Fri, 03 Jul 2009 10:55:17 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 290 v=0 o=root 29312 29313 IN IP4 212.88.133.153 s=session c=IN IP4 212.88.133.153 t=0 0 m=audio 7076 RTP/AVP 8 3 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- <--- SIP read from 217.10.79.9:5060 ---> SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK17f9904c;rport=5060 From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 103 INVITE Content-Length: 0 <-------------> --- (7 headers 0 lines) --- <--- SIP read from 217.10.79.9:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK17f9904c;rport=5060 Record-Route: <sip:172.20.40.3;lr=on> Record-Route: <sip:217.10.79.9;lr=on;ftag=as49b007bc> From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 103 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:10000@217.10.79.30> Content-Type: application/sdp Content-Length: 287 v=0 o=root 14076 14076 IN IP4 217.10.79.30 s=session c=IN IP4 217.10.79.30 t=0 0 m=audio 16236 RTP/AVP 8 0 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-------------> --- (13 headers 14 lines) --- Transmitting (no NAT) to 217.10.79.9:5060: ACK sip:10000@217.10.79.30 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK1cf1588f;rport Route: <sip:217.10.79.9;lr=on;ftag=as49b007bc>,<sip:172.20.40.3;lr=on> From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 103 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- Reliably Transmitting (no NAT) to 85.93.219.114:5060: INVITE sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK24a401b3;rport Route: <sip:85.93.219.114;ftag=as271217c9;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Contact: <sip:s@212.88.133.153> Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces X-asterisk-Info: SIP re-invite (External RTP bridge) Content-Type: application/sdp Content-Length: 287 v=0 o=root 29312 29313 IN IP4 217.10.79.30 s=session c=IN IP4 217.10.79.30 t=0 0 m=audio 16236 RTP/AVP 3 0 8 101 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- Reliably Transmitting (no NAT) to 217.10.79.9:5060: INVITE sip:10000@217.10.79.30 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK04dd2986;rport Route: <sip:217.10.79.9;lr=on;ftag=as49b007bc>,<sip:172.20.40.3;lr=on> From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 104 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces X-asterisk-Info: SIP re-invite (External RTP bridge) Content-Type: application/sdp Content-Length: 289 v=0 o=root 29312 29314 IN IP4 85.93.219.122 s=session c=IN IP4 85.93.219.122 t=0 0 m=audio 13006 RTP/AVP 8 3 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK24a401b3;rport=5060 From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 102 INVITE Server: Sip EXpress router (0.9.6 (x86_64/linux)) Content-Length: 0 Warning: 392 85.93.219.114:5060 "Noisy feedback tells: pid=31420 req_src_ip=212.88.133.153 req_src_port=5060 in_uri=sip:Unknown@85.93.219.122 out_uri=sip:Unknown@85.93.219.122 via_cnt==1" <-------------> --- (9 headers 0 lines) --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK24a401b3;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as67860b84;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 102 INVITE User-Agent: Asterisk PBX 1.6.0.6 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Contact: <sip:Unknown@85.93.219.122> Content-Type: application/sdp Content-Length: 312 v=0 o=root 1491947058 1491947059 IN IP4 85.93.219.122 s=Asterisk PBX 1.6.0.6 c=IN IP4 85.93.219.122 t=0 0 m=audio 13006 RTP/AVP 8 0 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-------------> --- (13 headers 14 lines) --- Transmitting (no NAT) to 85.93.219.114:5060: ACK sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK1f7a1716;rport Route: <sip:85.93.219.114;ftag=as271217c9;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Contact: <sip:s@212.88.133.153> Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- <--- SIP read from 217.10.79.9:5060 ---> SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK04dd2986;rport=5060 From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 104 INVITE Content-Length: 0 <-------------> --- (7 headers 0 lines) --- <--- SIP read from 217.10.79.9:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK04dd2986;rport=5060 From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 104 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:10000@217.10.79.30> Content-Type: application/sdp Content-Length: 287 v=0 o=root 14076 14077 IN IP4 217.10.79.30 s=session c=IN IP4 217.10.79.30 t=0 0 m=audio 16236 RTP/AVP 8 0 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-------------> --- (11 headers 14 lines) --- Transmitting (no NAT) to 217.10.79.9:5060: ACK sip:10000@217.10.79.30 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK3e4efa0c;rport Route: <sip:217.10.79.9;lr=on;ftag=as49b007bc>,<sip:172.20.40.3;lr=on> From: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc To: <sip:10000@sipgate.de>;tag=as069f42dc Contact: <sip:1738180@212.88.133.153> Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 104 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- <--- SIP read from 217.10.79.9:5060 ---> BYE sip:1738180@212.88.133.153 SIP/2.0 Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bKf4e9.3b548123.0 Via: SIP/2.0/UDP 172.20.40.3;branch=z9hG4bKf4e9.3b548123.0 Via: SIP/2.0/UDP 217.10.79.30:5060;branch=z9hG4bK15d17460;rport=5060 From: <sip:10000@sipgate.de>;tag=as069f42dc To: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 102 BYE Max-Forwards: 68 Content-Length: 0 X-hint: rr-enforced <-------------> --- (11 headers 0 lines) --- Sending to 217.10.79.9 : 5060 (no NAT) <--- Transmitting (no NAT) to 217.10.79.9:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bKf4e9.3b548123.0;received=217.10.79.9 Via: SIP/2.0/UDP 172.20.40.3;branch=z9hG4bKf4e9.3b548123.0 Via: SIP/2.0/UDP 217.10.79.30:5060;branch=z9hG4bK15d17460;rport=5060 From: <sip:10000@sipgate.de>;tag=as069f42dc To: "Unknown" <sip:1738180@sipgate.de>;tag=as49b007bc Call-ID: 62d694bd2314bbaa7e4ac9470a0a1dfe@sipgate.de CSeq: 102 BYE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:1738180@212.88.133.153> Content-Length: 0 <------------> Reliably Transmitting (no NAT) to 85.93.219.114:5060: INVITE sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK273424fd;rport Route: <sip:85.93.219.114;ftag=as271217c9;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Contact: <sip:s@212.88.133.153> Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 103 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces X-asterisk-Info: SIP re-invite (External RTP bridge) Content-Type: application/sdp Content-Length: 290 v=0 o=root 29312 29314 IN IP4 212.88.133.153 s=session c=IN IP4 212.88.133.153 t=0 0 m=audio 7074 RTP/AVP 3 0 8 101 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK273424fd;rport=5060 From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 103 INVITE Server: Sip EXpress router (0.9.6 (x86_64/linux)) Content-Length: 0 Warning: 392 85.93.219.114:5060 "Noisy feedback tells: pid=31389 req_src_ip=212.88.133.153 req_src_port=5060 in_uri=sip:Unknown@85.93.219.122 out_uri=sip:Unknown@85.93.219.122 via_cnt==1" <-------------> --- (9 headers 0 lines) --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK273424fd;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as67860b84;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 103 INVITE User-Agent: Asterisk PBX 1.6.0.6 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Contact: <sip:Unknown@85.93.219.122> Content-Type: application/sdp Content-Length: 312 v=0 o=root 1491947058 1491947060 IN IP4 85.93.219.122 s=Asterisk PBX 1.6.0.6 c=IN IP4 85.93.219.122 t=0 0 m=audio 13006 RTP/AVP 8 0 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-------------> --- (13 headers 14 lines) --- Transmitting (no NAT) to 85.93.219.114:5060: ACK sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK688e4031;rport Route: <sip:85.93.219.114;ftag=as271217c9;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Contact: <sip:s@212.88.133.153> Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 103 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- Reliably Transmitting (no NAT) to 85.93.219.114:5060: BYE sip:Unknown@85.93.219.122 SIP/2.0 Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK352dc0dd;rport Route: <sip:85.93.219.114;ftag=as271217c9;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 104 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- <--- SIP read from 85.93.219.114:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 212.88.133.153:5060;branch=z9hG4bK352dc0dd;rport=5060 Record-Route: <sip:85.93.219.114;ftag=as67860b84;lr=on> From: <sip:20400371@tel.lu>;tag=as67860b84 To: "Unknown" <sip:Unknown@85.93.219.122>;tag=as271217c9 Call-ID: 130aaf675f1c3e327fc3860c35001e11@85.93.219.122 CSeq: 104 BYE User-Agent: Asterisk PBX 1.6.0.6 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Content-Length: 0 <-------------> --- (11 headers 0 lines) --- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: nf_conntrack_sip problem 2009-07-02 8:17 ` Joerg Dorchain 2009-07-02 9:04 ` Joerg Dorchain @ 2009-07-03 9:44 ` Patrick McHardy 1 sibling, 0 replies; 12+ messages in thread From: Patrick McHardy @ 2009-07-03 9:44 UTC (permalink / raw) To: Joerg Dorchain; +Cc: netfilter Joerg Dorchain wrote: > On Wed, Jul 01, 2009 at 10:56:16PM +0200, Joerg Dorchain wrote: >> Aehm, 85.93.219.122 is the address from the SDP payload for the >> RTP stream as attached. 85.93.219.114 is is address of where the SIP REGISTER >> is sent to. >> >> I will try again with only sip_direct_media=0. > > I works, but somewhat ugly. > # conntrack -E expect > 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080 > 180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081 > 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076 > 180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077 > > All the places where the ip is 0.0.0.0 or the port is 0 could be > filled more specifically. The necessary information is available > in the same SIP/SDP flow as the used information. Besides the two > RTP stream are unidirectional, so I'd like to have something like > this: > 180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080 > 180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077 It depends on the setup. The remote address is not available at the time the expectation is created when using early media. As soon as the SDP payload is sent, one way audio might arrive, even from multiple source addresses in parallel. So this can't be made more specific for the generic case. When not using early media, we could wait for the SDP payload of the remote side, but I don't think many clients are not doing this. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-07-03 11:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-07-01 11:37 nf_conntrack_sip problem Joerg Dorchain 2009-07-01 12:03 ` Patrick McHardy 2009-07-01 14:43 ` Joerg Dorchain 2009-07-01 15:05 ` Patrick McHardy 2009-07-01 16:10 ` Joerg Dorchain 2009-07-01 16:16 ` Patrick McHardy 2009-07-01 20:56 ` Joerg Dorchain 2009-07-02 8:17 ` Joerg Dorchain 2009-07-02 9:04 ` Joerg Dorchain 2009-07-03 9:45 ` Patrick McHardy 2009-07-03 11:20 ` Joerg Dorchain 2009-07-03 9:44 ` Patrick McHardy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox