[asterisk-dev] [Code Review] RFC5389 (STUN), basic ICE, and Jingle support

[David Vossel]

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


I know very little about how STUN messages are constructed in RFC5389.  Is it possible with the changes you have made here to continue to use STUN with the old method described in rfc3489?  I just want to make sure all the changes here are backwards compatible with previous functionality as I believe some services require usage of the old method.

- David


On 2010-10-02 07:12:27, Philippe Sultan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/401/
> -----------------------------------------------------------
> 
> (Updated 2010-10-02 07:12:27)
> 
> 
> Review request for Asterisk Developers, Russell Bryant, Joshua Colp, Kevin Fleming, and Olle E Johansson.
> 
> 
> Summary
> -------
> 
> Add STUN (RFC5389) support to provide ICE, and Jingle support based on XEP-0166 (basic procedure) and XEP-0176 (ICE-UDP transport).
> 
> STUN changes :
> I modified the STUN stack in order to make it compatible with the latest spec (RFC5389 obsoleted RFC3489), and therefore provide the ability to any RTP based channel (SIP, Jingle, etc.) to handle ICE connectivity checks (described in : http://tools.ietf.org/html/draft-ietf-mmusic-ice-19). The stun_credentials structure that stores the username and password can be filled in during the signaling time and used by the RTP asterisk engine.
> 
> Jingle changes :
> Proper Jingle signaling has been implemented. Only incoming Jingle calls are handled for the moment.
> 
> Before moving any further, I'd like to have feedback from the community regarding these changes in the STUN stack. In particular, I'd like to point out that zlib and OpenSSL are now needed in stun.c to compute the fingerprint and message integrity attributes respectively.
> 
> 
> This addresses bug 15634.
>     https://issues.asterisk.org/view.php?id=15634
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_gtalk.c 290024 
>   /trunk/channels/chan_h323.c 290024 
>   /trunk/channels/chan_jingle.c 290024 
>   /trunk/channels/chan_mgcp.c 290024 
>   /trunk/channels/chan_sip.c 290024 
>   /trunk/channels/chan_skinny.c 290024 
>   /trunk/channels/chan_unistim.c 290024 
>   /trunk/include/asterisk/jingle.h 290024 
>   /trunk/include/asterisk/rtp_engine.h 290024 
>   /trunk/include/asterisk/stun.h 290024 
>   /trunk/main/rtp_engine.c 290024 
>   /trunk/main/stun.c 290024 
>   /trunk/res/res_jabber.c 290024 
>   /trunk/res/res_rtp_asterisk.c 290024 
>   /trunk/res/res_rtp_multicast.c 290024 
> 
> Diff: https://reviewboard.asterisk.org/r/401/diff
> 
> 
> Testing
> -------
> 
> All my testings were made with Psi (version 0.13 on Windows) :
> - incoming Jingle calls (from Psi to Asterisk) are properly set up ;
> - ICE connectivity checks are validated by Psi ;
> - sound quality is awful from ASterisk to Psi, possibly because of a misconfiguration of the codec (Speex at 16KHz).
> 
> 
> Thanks,
> 
> Philippe
> 
>