[asterisk-dev] [Code Review] Make sure that a declined media stream ends in '\r\n'

opticron reviewboard at asterisk.org
Mon Jan 28 13:43:03 CST 2013


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

Ship it!


Looks good to me.

- opticron


On Jan. 28, 2013, 1:37 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2297/
> -----------------------------------------------------------
> 
> (Updated Jan. 28, 2013, 1:37 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and kmoore.
> 
> 
> Summary
> -------
> 
> r369028 updated chan_sip's processing of media streams in an SDP to better handle multiple offered media streams. Part of that change modified how streams were declined. Previously, declined streams were not handled in an RFC compliant manner - in Asterisk 11, we now set the port number to 0 in the media stream definition and proceed on with the next media stream.
> 
> Unfortunately, the formatting of the declined media stream forgot to append a '\r\n' to the end of the media stream. This is normally added to the accepted media streams later on in the processing of the SDP. Since the declined media stream uses a different buffer than the accepted media streams (and is a malloc'd buffer as opposed to a struct ast_str), it's easier to just put the '\r\n' in the declined media stream buffer rather than attempt to append it later on.
> 
> 
> This addresses bug ASTERISK-20908.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20908
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/chan_sip.c 380249 
> 
> Diff: https://reviewboard.asterisk.org/r/2297/diff
> 
> 
> Testing
> -------
> 
> Patch fixed the problem for the issue reporter. Prior to the patch, X-Lite 3.0 would reject the call and log a "ParseException dereferenced ParseBuffer eof" in its debug log - post patch, it works.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130128/9f46fa89/attachment.htm>


More information about the asterisk-dev mailing list