[asterisk-dev] [Code Review] 4279: chan_sip: Send CANCEL via proxy if CANCEL is to be sent after an UPDATE

[Scott Griepentrog]

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

Ship it!


Other than a few non-code issues, I ship thee.  Did not trigger any SIP tagged test failures.


http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/4279/#comment24525>

    I would recommend appending to the comment block something like this:
    
    ASTERISK-24628: Send UPDATE to the same destination as CANCEL



http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/4279/#comment24526>

    Purely for readability, the sipmethod == SIP_UPDATE condition should be indented to the same level as SIP_ACK, since it is similarly nested under the same negation started on the line containing SIP_CANCEL.


- Scott Griepentrog


On Dec. 17, 2014, 12:11 p.m., kwemheuer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4279/
> -----------------------------------------------------------
> 
> (Updated Dec. 17, 2014, 12:11 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24628
>     https://issues.asterisk.org/jira/browse/ASTERISK-24628
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Given three SIP phones (A, B, C), all communicating via a proxy (in this case OpenSIPs) with asterisk. A call is established between A and B. B sets the call on hold (A is hearing MOH) and dials the extension of C. While phone C is ringing, B transfers the call (A is hearing ringing of phone C, B is idle). On SIP there is a REFER to transfer the call. In case "sendrpid=yes" asterisk sends an UPDATE to phone C. This update is sent directly (not through the proxy). If someone (e.g. B) is trying to get the call back (through a directed pickup), asterisk sends a CANCEL to C. But this CANCEL is sent directly to C not through the proxy. The phone ignores this CANCEL according to the RFC3261 (Section 9.1).
> 
> In other situations asterisk ensures, that a CANCEL is sent the same way the INVITE has been sent. In this case the previously sent UPDATE overwrites the address used later for the CANCEL. On the other hand the UPDATE has to be sent via the proxy too (IMHO). The call is in the ringing state and other endpoints maybe have to been updated too.
> 
> The patch solves the issue. In function reqprep the UPDATE is handled the same way the CANCEL was (in case the state is in ringing state).
> 
> 
> Diffs
> -----
> 
>   http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 429698 
> 
> Diff: https://reviewboard.asterisk.org/r/4279/diff/
> 
> 
> Testing
> -------
> 
> Patch is tested in the described scenario and solves the issue. Patched against 11.15.0.
> 
> 
> Thanks,
> 
> kwemheuer
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141219/f354b401/attachment.html>