[asterisk-dev] [Code Review] more reliable sip STUN support

Simon Perreault simon.perreault at viagenie.ca
Tue Aug 3 18:18:33 CDT 2010


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/844/#review2533
-----------------------------------------------------------


Another issue: we *want* STUN and SIP to be multiplexed on the same port. This is a feature. It ensures the same treatment by the NAT device. Splitting in different ports may result in a different binding on the NAT device. If this NAT device has a public IP address pool and assigns a different public address to the STUN flow, we're basically screwed. Even without an address pool, being bound to a different public port is definitely not a good situation.

Why not instead simply demultiplex STUN and SIP packets arriving on the same port? This is very easy. See RFC 5626 section 8. Excerpt:

      Note: It is easy to distinguish STUN and SIP packets sent over
      UDP, because the first octet of a STUN Binding method has a value
      of 0 or 1, while the first octet of a SIP message is never a 0 or
      1.

- Simon


On 2010-08-03 16:33:16, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/844/
> -----------------------------------------------------------
> 
> (Updated 2010-08-03 16:33:16)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Asterisk's support for STUN in chan_sip.c is very minimal.  In chan_sip STUN is currently unreliable because Asterisk uses the same UDP socket for sending STUN requests as it does for regular SIP traffic.  This is a problem because whenever a STUN request is sent, Asterisk's generic STUN implementation blocks expecting the next message on the socket to be the STUN response... since in chan_sip that socket is used for SIP traffic as well, this is not a reliable approach.  While it is technically possible to use the socket for both the SIP and STUN traffic, the current generic STUN support in Asterisk would have to be nearly completely re-written to support that.
> 
> The approach I am taking to make STUN support in chan_sip more reliable is to just give the STUN client its own dedicated socket for sending and receiving STUN requests on.  I have also added a new sip.conf option 'stunbindaddr' so the client's address/port binding can be configured.
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_sip.c 280617 
>   trunk/channels/sip/include/sipstun.h PRE-CREATION 
>   trunk/channels/sip/sipstun.c PRE-CREATION 
>   trunk/configs/sip.conf.sample 280617 
> 
> Diff: https://reviewboard.asterisk.org/r/844/diff
> 
> 
> Testing
> -------
> 
> This patch is essentially a wrapper for the previous implementation that uses a dedicated socket.  I verified that STUN requests are sent out on the configured port to the configured server's address.   I do not have a real STUN server to test on, so I did not test receiving the server's response, but since the code for sending/receiving the STUN messages is a separate API, I do not expect any of that to have changed.
> 
> I have requested additional testing on the dev-list for anyone who does currently use chan_sip's STUN support.
> 
> 
> Thanks,
> 
> David
> 
>




More information about the asterisk-dev mailing list