Summary:ASTERISK-16348: [patch] STUN support not reliable
Reporter:philipp2 (philipp2)Labels:
Date Opened:2010-07-11 22:22:40Date Closed:2010-08-16 14:31:51
Versions:Frequency of
Environment:Attachments:( 0) new_stun_support.diff
Description:Up front: This is not my report, but I wanted to make sure this does get recorded. Having searched the bug tracker I found no entries on STUN, so I assume that the problem is also to be found in trunk.

Taken from:

thor: "more sniffing on the network explains why this problem happens. when sending stun request asterisk uses the sip socket as the source and the first packet after that, arriving on the sip socket, is assumed to be the stun reply. If it happens to be another sip message then asterisk throws an error because it does not verify if the packet is actually a stun reply and blindly tries to parse it. this makes stun unusable with asterisk."

Could be related to ASTERISK-15215


STUN problems - chan_sip.c: stun failed

Post by thor ยป Sat Jun 05, 2010 2:57 pm
My public IP changes less frequently than once a month but I decided to use STUN just in case it happens.
Unfortunately STUN support in asterisk is rather flaky at this point. I regularly get messages in my log:

Code: Select all
   [2010-06-05 13:44:55] WARNING[20697] chan_sip.c: stun failed
   [2010-06-05 13:44:55] WARNING[20697] chan_sip.c: stun failed
   [2010-06-05 13:44:56] WARNING[20697] chan_sip.c: stun failed
   [2010-06-05 13:44:56] WARNING[20697] chan_sip.c: stun failed

and then asterisk has no idea what my public IP is and I get one way audio.
sip show settings gives empty Externip in "Network Settings:"

I increased the log level to 99 and there are stun related messages when STUN packet is sent/received:

Code: Select all
   [2010-06-05 13:09:32] DEBUG[20697] rtp.c: Runt STUN packet (only 4, wanting at least 20)

the problem is the packet from the STUN server is 96 bytes, not 4, yet asterisk has problems reading it.

My version is

UPDATE: Some more STUN related entries:

Code: Select all
   [2010-06-05 13:44:55] DEBUG[20697] rtp.c: Scrambled STUN packet length (got 20527, expecting 396)
   [2010-06-05 13:50:55] DEBUG[20697] rtp.c: Scrambled STUN packet length (got 18249, expecting 438)
   [2010-06-05 14:00:57] DEBUG[20697] rtp.c: Scrambled STUN packet length (got 18249, expecting 638)

which does not make sense at all .....
Comments:By: philipp2 (philipp2) 2010-07-11 22:23:14

Some user complaints:

By: Paul Belanger (pabelanger) 2010-07-12 06:10:39

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch.

More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924

By: philipp2 (philipp2) 2010-07-12 06:28:08

"...so I assume that the problem is also to be found in trunk"

By: Leif Madsen (lmadsen) 2010-07-12 11:04:49

Acknowledging this issue per Russell.

By: David Vossel (dvossel) 2010-07-30 12:40:10

I uploaded a patch that reworks how sip does stun.  Now we have a dedicated socket for stun requests, which should prevent some of the weirdness that was occurring.  Please test the patch.  I also have this in a branch, so you could just it out instead.

svn co http://svn.digium.com/svn/asterisk/team/dvossel/sip_stun_support_improved


By: philipp2 (philipp2) 2010-07-30 12:54:22

This patch is for 1.6.2, or 1.8, or trunk?
Best testing feedback will be achieved with a 1.6.2 patch, I believe.

By: David Vossel (dvossel) 2010-07-30 13:15:15

The patch will apply to both 1.8 and trunk.  I don't want to make a 1.6.2 patch right now.  I'll consider that after testing with the current patch is complete.  A 1.6.2 patch can be done, but because of changes made to chan_sip.c between 1.6.2 and 1.8 the patch will have to be completely reworked for 1.6.2.

By: philipp2 (philipp2) 2010-07-30 13:34:02

Thanks for the patch and the clarification! :-)

By: Leif Madsen (lmadsen) 2010-07-31 08:36:38

I'm marking this as targeted for 1.8.0, but is dependent upon results from testing. Also marked as Ready for Testing.

By: philipp2 (philipp2) 2010-08-02 14:46:25

I tested the branch behind NAT with


(not sure if I spelled this correctly, citing by heart).

Unfortunately he registration from this branch to an Asterisk 1.4 on the Internet did not appear to involve any STUN: The receiving Asterisk still needed nat=yes to succeed, and then the Reg. Contact showed the private IP (192.168.x.x).

By: David Vossel (dvossel) 2010-08-02 15:05:14

Did stun ever work for you before this change?

This patch is not touching the Asterisk stun implementation, I'm just making stun use a dedicated port in chan_sip so it should be more reliable.  If stun never even remotely worked to begin with, then this change won't make any difference.

By: philipp2 (philipp2) 2010-08-02 15:48:17

Didn't use STUN before in this context. My first guess is that the udpbindaddress with the port added to it like this somehow prevents a STUN query. I can't test on 5060 because the DSL Router grabs that itself and cannot be taught not to do that.

BTW, in DEBUG mode I also saw a message that stated something like 'attempting to send "REGISTER si"' where the string was obviously cut off after "si". Not sure if that is the way it is supposed to be.

By: philipp2 (philipp2) 2010-08-04 07:35:32

Basic STUN functionality works with (localnet= must be set), but the same simple/reduced sip.conf does not work with the stun branch, the private address is used instead:

[Aug  4 14:27:58] DEBUG[1502]: acl.c:706 ast_ouraddrfor: For destination 'y.y.y.y', our source address is '192.168.x.x'.
[Aug  4 14:27:58] DEBUG[1502]: chan_sip.c:3227 ast_sip_ouraddrfor: Setting SIP_TRANSPORT_UDP with address 192.168.x.x:5064
chan_sip.c:3063 __sip_xmit: Trying to put 'REGISTER si' onto UDP socket destined for y.y.y.y

Network Settings:
 SIP address remapping:  Disabled
 Externhost:             <none>
 externaddr:               (null)
 Externrefresh:          15
 Internal IP:  
 STUN server:  

By: David Vossel (dvossel) 2010-08-04 09:53:24

thanks for the feedback.  I'll look into it.

By: David Vossel (dvossel) 2010-08-04 11:16:30

After reviewing further feedback I've discovered that just about every part of our current sip STUN implementation is done wrong architecturally.  This all needs to just be re-written.  I'll see what I can do.

By: Digium Subversion (svnbot) 2010-08-16 14:31:44

Repository: asterisk
Revision: 282302

U   branches/1.8/CHANGES
U   branches/1.8/UPGRADE.txt
U   branches/1.8/channels/chan_sip.c
U   branches/1.8/configs/sip.conf.sample

r282302 | dvossel | 2010-08-16 14:31:43 -0500 (Mon, 16 Aug 2010) | 10 lines

remove current STUN support from chan_sip.c

This patch removes the current broken/useless stun
support from chan_sip.

(closes issue ASTERISK-16348)
Reported by: philipp2

Review: https://reviewboard.asterisk.org/r/855/



By: Digium Subversion (svnbot) 2010-08-16 14:31:51

Repository: asterisk
Revision: 282304

_U  trunk/
U   trunk/CHANGES
U   trunk/UPGRADE-1.8.txt
U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

r282304 | dvossel | 2010-08-16 14:31:50 -0500 (Mon, 16 Aug 2010) | 17 lines

Merged revisions 282302 via svnmerge from

 r282302 | dvossel | 2010-08-13 17:23:38 -0500 (Fri, 13 Aug 2010) | 10 lines
 remove current STUN support from chan_sip.c
 This patch removes the current broken/useless stun
 support from chan_sip.
 (closes issue ASTERISK-16348)
 Reported by: philipp2
 Review: https://reviewboard.asterisk.org/r/855/