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

[Marc Blanchet]

The useful use case for STUN is for RTP trafic, isn't it?

Marc.

Le 10-08-03 17:33, David Vossel a écrit :
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/844/
> -----------------------------------------------------------
>
> 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
>
>


-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca