nf_conntrack_sip problem

nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Patrick McHardy]

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.

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Patrick McHardy]

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?

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Patrick McHardy]

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.

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]

Re: nf_conntrack_sip problem

[Patrick McHardy]

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.

Re: nf_conntrack_sip problem

[Patrick McHardy]

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.

Re: nf_conntrack_sip problem

[Joerg Dorchain]

[-- 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 --]