[asterisk-dev] [Code Review]: WebSocket SIP Support

[Joshua Colp]

> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, line 2560
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line2560>
> >
> >     Will this leak req.data?

Yes! Fixed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, line 2854
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line2854>
> >
> >     Is this necessary? The entire 'req' structure was memset() to zeroes above, unless I'm misreading the code.

Removed. Not required indeed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, lines 9445-9447
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line9445>
> >
> >     It would be better to explicitly check for AVPF and SAVPF, rather than accepting AVP42 or other bogus profiles.

Changed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, line 10768
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line10768>
> >
> >     Might as well use strlen(";transport=") here, as the compiler will compute it at compile time anyway.

Changed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/sip/include/sip.h, line 373
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29336#file29336line373>
> >
> >     'Support a minimal AVPF-compatible profile'... since we don't fully implement AVPF.

Changed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/configs/sip.conf.sample, line 979
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29339#file29339line979>
> >
> >     'with media streams using the AVPF RTP profile'

Changed.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, lines 3380-3389
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line3380>
> >
> >     Ugh... 32 possible combinations, and not all are covered here. This begs for a better solution, like maybe an array of 32 static strings and then treating 'transports' as an index into it.

Changed! This is now using a thread local storage buffer to construct the string.


> On July 5, 2012, 3:31 p.m., Kevin Fleming wrote:
> > /trunk/channels/chan_sip.c, lines 2531-2539
> > <https://reviewboard.asterisk.org/r/2008/diff/1/?file=29335#file29335line2531>
> >
> >     I suspect this is going to be pretty common, so it might be worth putting some mechanism into the WebSocket API itself for making the socket non-blocking.

I've added an API call people can use so that they don't have to reproduce this logic over and over.


- Joshua


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


On July 9, 2012, 10:59 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2008/
> -----------------------------------------------------------
> 
> (Updated July 9, 2012, 10:59 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> These changes add WebSocket transport support to chan_sip and fix some minor issues uncovered in the stack when used with WebSocket as a transport.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 369768 
>   /trunk/channels/sip/include/sip.h 369768 
>   /trunk/channels/sip/sdp_crypto.c 369768 
>   /trunk/channels/sip/security_events.c 369768 
>   /trunk/configs/sip.conf.sample 369768 
>   /trunk/include/asterisk/http_websocket.h 369768 
>   /trunk/res/res_http_websocket.c 369768 
> 
> Diff: https://reviewboard.asterisk.org/r/2008/diff
> 
> 
> Testing
> -------
> 
> Tested using sipml5 javascript SIP stack. Confirmed protocol traffic is correct, that connections are shutdown properly when they should be, that registration works, and that calling works.
> 
> 
> Thanks,
> 
> Joshua
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120709/315e831a/attachment-0001.htm>