|Summary:||ASTERISK-04978: Asterisk fails to send to correct RTP IP address when double natted|
|Reporter:||David James (davidj)||Labels:|
|Date Opened:||2005-09-04 15:22:37||Date Closed:||2011-06-07 14:10:27|
|Environment:||Attachments:||( 0) code_notes.txt|
( 1) incorrect.txt
( 2) working.txt
Asterisk will fail to send RTP packets to the correct IP address when behind nat and to a IP-500 behind nat. However, about 1 out of 20 times Asterisk will successfully do the correct behavior. This maybe because of a bug in the way SIP handles NAT.
Asterisk is located at IP address behind nat 10.1.1.12
Asterisk externip address is set to xxx.xxx.xxx.xxx
IP-500 is located at internal address 192.168.1.102
IP-500 external address is set to yyy.yyy.yyy.yyy
hardware, just for reference: both WAN routers WRT54g with defaults.
****** ADDITIONAL INFORMATION ******
Sets to reproduce:
1. Setup Asterisk behind nat with [general] nat=yes (also tested also with nat=no)
2. Setup externip and localnet
3. Setup Polycom IP-500 or other behind nat with [polycomip500] nat=yes and qualify=yes.
4. Setup Asterisk's WAN router to forward ports UDP 5060 and 10000-20000. In this setup this is a WRT54G with a Sveasoft ROM and SIP connection tracking turned off.
5. Place calls and verify Asterisk will send to wrong IP address
Note: My setup uses Asterisk realtime
1. Verify that phone is registered correctly to asterisk with 'sip show peers'
354/354 yy.yyy.yyy.yyy D N 255.255.255.255 5060 OK (101 ms)
2. Place call from polycom phone and verify it answered:
*CLI> show channels
Channel Location State Application(Data)
SIP/354-fd31 *98@from-internal:3 Up VoiceMailMain(default)
1 active channel
1 active call
*CLI> sip show cha
*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message
192.168.1.102 354 e635f988-3b 00101/00001 ulaw No Rx: ACK
1 active SIP channel
3. Turn on 'RTP debug'
*CLI> rtp debug
RTP Debugging Enabled
Sent RTP packet to 192.168.1.102:2234 (type 0, seq 52311, ts 160, len 160)
Sent RTP packet to 192.168.1.102:2234 (type 0, seq 52312, ts 320, len 160)
Sent RTP packet to 192.168.1.102:2234 (type 0, seq 52313, ts 480, len 160)
Sent RTP packet to 192.168.1.102:2234 (type 0, seq 52314, ts 640, len 160)
Verify this by tcpdump
12:53:45.001908 10.1.1.12.26800 > 192.168.1.102.2250: udp 172 (DF) [tos 0x18] (ttl 64, id 5, len 200)
12:53:45.021913 10.1.1.12.26800 > 192.168.1.102.2250: udp 172 (DF) [tos 0x18] (ttl 64, id 6, len 200)
12:53:45.041907 10.1.1.12.26800 > 192.168.1.102.2250: udp 172 (DF) [tos 0x18] (ttl 64, id 7, len 200)
4. Dial asterisk 20 or more times and show rtp debug output for successful connection:
Got RTP packet from 220.127.116.11:2242 (type 0, seq 40814, ts 363420172, len 160)
Got RTP packet from 18.104.22.168:2242 (type 0, seq 40815, ts 363420332, len 160)
Got RTP packet from 22.214.171.124:2242 (type 0, seq 40816, ts 363420492, len 160)
Got RTP packet from 126.96.36.199:2242 (type 0, seq 40817, ts 363420652, len 160)
Got RTP packet from 188.8.131.52:2242 (type 0, seq 40818, ts 363420812, len 160)
Got RTP packet from 184.108.40.206:2242 (type 0, seq 40819, ts 363420972, len 160)
Got RTP packet from 220.127.116.11:2242 (type 0, seq 40820, ts 363421132, len 160)
Got RTP packet from 18.104.22.168:2242 (type 0, seq 40821, ts 363421292, len 160)
Got RTP packet from 22.214.171.124:2242 (type 0, seq 40822, ts 363421452, len 160)
Log files includes:
Note this is extension '354' dialing '*98'
working.txt : 'full' log, start to stop asterisk, with one call and correct behavior.
incorrect.txt : 'full' log, start to stop asterisk, with one call and incorrect behavior.
code-notes.txt : random notes from looking at the code including 'ngrep' cscope notes, chan_sip, and RTP debug searches in full
See RFC 3581 ?
|Comments:||By: Tilghman Lesher (tilghman) 2005-09-05 02:31:28|
Could you describe exactly what failure you're seeing in processing of the SIP call? Forget technical failure, because setting nat=yes causes Asterisk to technically violate the SIP spec. This is by design.
By: David James (davidj) 2005-09-05 03:35:45
No audio; please join irc #asterisk @ opus__ for detailed explaination.
By: David James (davidj) 2005-09-06 14:58:27
Sorry I haven't got a hold of you.. The only thing I can suggest is to reread the "Problem statement" and look at the tcpdump output. I'm absolutely dumbfounded that this couldn't be more concise, perhaps you can ask me a specific question in the context of this bug.
Regarding 'Asterisk technically violating the SIP spec': please elaborate what you are talking about in the context of this bug. Can you refer to where Asterisk breaks the SIP spec in RFC 3581? If the reason this is not a bug is because asterisk breaks the SIP spec, then why does it work 1 out of 20 times? Was there an attempt to correctly follow RFC 3581, and then later on became buggy? Thats my best guess.
By: David James (davidj) 2005-09-06 15:03:30
Can you please explain why this bug was changed from Major to Minor? This is a absolute show stopper -- I have people who can't use their phone at all until this is fixed.
By: Tilghman Lesher (tilghman) 2005-09-06 15:52:29
When you set nat=yes in sip.conf, Asterisk sends replies back to the address from which it receives SIP packets, rather than to the address specified within the SIP headers. This is a technical violation of the SIP spec, but it tends to work with natted hosts, since the NAT generally does the right thing and relays the packet back to the requested host.
The reason why this is not a major bug, is that it can easily be worked around by giving the Asterisk server a real IP.
By: David James (davidj) 2005-09-06 19:05:54
"When you set nat=yes in sip.conf, Asterisk sends replies back to the address from which it receives SIP packets"
Listen man, re-read my bug report. Rinse and repeat. I'll say it again,
re-read this bug report.
Asterisk is NOT sending replies back from which it receives SIP packets as you insist. Thats why I opened the bug. Thats why we're both here.
Just so that we don't have to play bug tag again, let me re-iterate it:
Asterisk is NOT sending replies back from which it recieves SIP packets when nat=yes; hense the title of this bug reads "Asterisk fails to send to correct RTP IP address ... ."
Look at the TCPDUMP if you don't believe me, sir. You've closed a few of my bugs _without actually reading them_ or because you're not that smart. And you've marked my karma down as well. I've spent a lot of time tracing these bug here, working with people on #asterisk making absolute sure it wasn't a problem on my end and I don't appreciate or understand how you are planning to contribue towards a solution here.
Because Asterisk is NOT sending replies back from which it receives SIP packets , I am still having major problems. Please either contribute here to the community or don't say anything at all. The only postivie suggestion you've made was to try HOST=<IPADDR>, which yielded the same behavior as posted above which is: Asterisk is NOT sending replies back from which it receives SIP packets.
What I was expecting was somebody who under stands the code, glance at it, tell me where I can fix the problem or post a fix: 5 minutes, done. I even included notes in code-notes.txt. Shesh!
By: Tilghman Lesher (tilghman) 2005-09-06 22:26:30
Please give your Asterisk server a real IP, out in front of any NATs. Do not put your Asterisk server and SIP behind two different NATs and expect it to work. There are no other SIP servers that will tolerate such a setup.
By: David James (davidj) 2005-09-07 01:52:38
a bug is a bug is a bug.
By: Olle Johansson (oej) 2005-09-07 03:13:31
Talked with submitter of this issue report and sorted out how it works in Asterisk. Making two devices behind NAT talk to each other can drive you crazy...
By: Olle Johansson (oej) 2005-09-07 03:26:46
---Finally closing this in agreement with submitter.
Symmetric RTP sends to RFC1918 address we got in SDP until we get the first incoming RTP packet from the other end, then we start sending to the public IP address we received the packet from. Silence suppression will give you problems here, as well as if both devices are inside a NAT waiting for that first audio packet... RTP deadlock :-)
So one device needs to send a public IP either with externIP= in sip.conf or a phone using STUN or other techniques (rport) to discover the outside address and tell the other end about it.