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

[David Vossel]

> On 2010-08-03 18:18:33, Simon Perreault wrote:
> > 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.

Thanks for your feedback.  As I stated, I know very little about how STUN is used so this is very helpful to me.

I am aware that it is easy to distinguish STUN from SIP traffic.  The reason I went about it this route is because of the way Asterisk's generic STUN api works.  The ast_stun_request() function both sends out a STUN request and blocks until it gets the response.  That means that any traffic coming in on that socket not STUN related while it is blocking for the STUN response is just thrown away.

Now, being aware of how STUN is used as a keep-alive mechanism I agree that the STUN requests need to be sent out the same UDP port as the SIP traffic.

I'm going to take down this review and make this all work right.


- David


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


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