[asterisk-dev] [Code Review]: Check for ANY to place calls on hold for SIP

[Olle E Johansson]

> On Oct. 10, 2011, 1:20 p.m., Matthew Nicholson wrote:
> > The code looks good. I don't know if it is standards compliant or not, but I guess if there are devices that expect this behavior and it fixes a regression, we should make this change.

In the old RFCs sending an SDP with IP address changed to 0.0.0.0 was used to put a call on hold. This actually STOPS all media streams, including RTCP, which is why later RFCs changed the procedure to indicate with a=recvonly etc. RTCP still runs, RTP keepalives still runs, but media is on hold.


- Olle E


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


On Oct. 10, 2011, 12:53 p.m., mjordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1504/
> -----------------------------------------------------------
> 
> (Updated Oct. 10, 2011, 12:53 p.m.)
> 
> 
> Review request for Asterisk Developers and Tzafrir Cohen.
> 
> 
> Summary
> -------
> 
> As reported, Asterisk (1.6.2 and prior) would previously place calls on hold if an INVITE was received with c=0.0.0.0.  This fails in 1.8 and later, as we only check to see if the various addresses are null.
> 
> This patch resolves this by checking if the addresses received are null or any.  This is done using the netsock2 library of functions, so it should be compatible with both IPv4 and IPv6.
> 
> 
> This addresses bug ASTERISK-18086.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18086
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 340135 
> 
> Diff: https://reviewboard.asterisk.org/r/1504/diff
> 
> 
> Testing
> -------
> 
> Tested using a cobbled together SIPp scenario, which appeared to behave as expected.  Tested also under the Asterisk TestSuite, which continued to work as expected.
> 
> 
> Thanks,
> 
> mjordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111010/99453a92/attachment.htm>