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

[vadim at mbdsys.com]

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



/trunk/main/stun.c
<https://reviewboard.asterisk.org/r/401/#comment2646>

    Is it safe?  What will happen if len < sizeof(struct stun_header)?



/trunk/main/stun.c
<https://reviewboard.asterisk.org/r/401/#comment2645>

    This looks as memory overflow...
    the size of the stun_pkt seems to be too short


- vadim


On 2009-10-09 11:15:30, Philippe Sultan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/401/
> -----------------------------------------------------------
> 
> (Updated 2009-10-09 11:15:30)
> 
> 
> 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 223055 
>   /trunk/channels/chan_h323.c 223055 
>   /trunk/channels/chan_jingle.c 223055 
>   /trunk/channels/chan_mgcp.c 223055 
>   /trunk/channels/chan_sip.c 223055 
>   /trunk/channels/chan_skinny.c 223055 
>   /trunk/channels/chan_unistim.c 223055 
>   /trunk/include/asterisk/jingle.h 223055 
>   /trunk/include/asterisk/rtp_engine.h 223055 
>   /trunk/include/asterisk/stun.h 223055 
>   /trunk/main/rtp_engine.c 223055 
>   /trunk/main/stun.c 223055 
>   /trunk/res/res_rtp_asterisk.c 223055 
>   /trunk/res/res_rtp_multicast.c 223055 
> 
> 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
> 
>