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

[kwemheuer]

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

(Updated Dec. 22, 2014, 9:39 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 429982


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 429824 

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/20141222/886388c2/attachment.html>