----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
