[Home]

Summary:ASTERISK-24628: [patch] chan_sip - CANCEL is sent to wrong destination when 'sendrpid=yes' (in proxy environment)
Reporter:Karsten Wemheuer (kwemheuer)Labels:
Date Opened:2014-12-17 05:12:24.000-0600Date Closed:2014-12-22 12:36:27.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General Channels/chan_sip/Transfers
Versions:11.15.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian Wheezy (7), OpenSIPsAttachments:( 0) issue.patch
( 1) issue-failure.log
( 2) issue-success.log
( 3) trace-failure-1.pcap
( 4) trace-success-1.pcap
Description:I have three phones communicating via OpenSIPs with asterisk. Phone A dials 100 and asterisk calls SIP/phone-b. Phone B accepts the call. The User on Phone B places the call on hold, dials 200 and, while hearing the dial tone of ringing phone C, places the handset on hook. Phone B sends a SIP REFER, so that phone A is connected with the ringing phone C. Asterisk sends an SIP UPDATE to phone C to update the connected line information. Now the user on phone B (or someone else) realized that user B is not available. B (or someone else) is doing a directed pickup to get the ringing call. A and B are now connected again. But phone C is still ringing.

Looking into the traces ,I found out, that asterisk sends the CANCEL request to stop the call to phone C directly to the phone and not to the proxy (where the INVITE comes from).  The phone ignores the CANCEL (481 Call/Transaction does not exist). You can see the scenario in the pcap file trace-failure-1.pcap (cancel is at packet #83) and the debug log of asterisk issue-failure.log. Asterisk is at 192.168.10.75:25060, OpenSIPs at 192.168.10.75:5060, the phones are at 192.168.10.201 (phone-a), 192.168.10.124 (phone-b) and 192.168.10.100 (phone-c).

If I disable updating of the connected line information (sendrpid=no) on phone C, the CANCEL will be sent to the proxy and all is well.
Comments:By: Karsten Wemheuer (kwemheuer) 2014-12-17 05:15:25.455-0600

Asterisk debug log of failure
By: Karsten Wemheuer (kwemheuer) 2014-12-17 05:15:58.526-0600

PCAP Trace of failure
By: Karsten Wemheuer (kwemheuer) 2014-12-17 05:25:53.400-0600

In function  reqprep there is a statement to call set_destination not for a CANCEL, so that a CANCEL will be sent the same way the corresponding INVITE was sent.
{noformat}
/*
* Use the learned route set unless this is a CANCEL on an ACK for a non-2xx
* final response. For a CANCEL or ACK, we have to send to the same destination
* as the original INVITE.
*/
if (p->route &&
   !(sipmethod == SIP_CANCEL ||
     (sipmethod == SIP_ACK && (p->invitestate == INV_COMPLETED || p->invitestate == INV_CANCELLED)))) {
       set_destination(p, p->route->hop);
       add_route(req, is_strict ? p->route->next : p->route);
}
add_max_forwards(p, req);
{noformat}
But the UPDATE, that  is sent to update calling line information calls set_destination some times earlier and so the information for the CANCEL gets overwritten (As far as I understand the code). Beside this, I think the UPDATE should be sent via the proxy too, because there could be some more endpoints to be updated (the call is in the ringing state).

I modified function  reqprep (see the patch issue.patch), so that the UPDATE in the ringing state takes the treatment like the CANCEL. With this patch all seem to work well. You can see the result in issue-success.log and trace-success-1.pcap.

I am not sure, that the handling of the issue does not lead to any regressions, so any comments or help is appreciated.
By: Karsten Wemheuer (kwemheuer) 2014-12-17 05:27:00.285-0600

Asterisk debug with patch attached
By: Karsten Wemheuer (kwemheuer) 2014-12-17 05:28:16.589-0600

PCAP trace of scenario with patched asterisk
By: Rusty Newton (rnewton) 2014-12-17 09:21:38.194-0600

[~kwemheuer] thanks for your debug and patch. The reported issue does look like a bug to me, but I'll have a developer take a closer look at the scenario and patch.


By: Rusty Newton (rnewton) 2014-12-17 09:39:06.220-0600

[~mmichelson] performed a quick review of the issue and patch (Thanks Mark!). Looks good so far, the next step is to get your code on Reviewboard (following the [Code Review process|https://wiki.asterisk.org/wiki/display/AST/Code+Review]). Thanks Karsten!
By: Rusty Newton (rnewton) 2014-12-17 09:46:16.849-0600

Oh, Remember to add a link here to the Reviewboard review ( you can edit the issue and use the Reviewboard field). Thanks.
By: Matt Jordan (mjordan) 2014-12-22 09:39:23.829-0600

Merged into 11+ - thanks for the contribution for this rather complex bug!