[asterisk-bugs] [JIRA] (ASTERISK-24628) CANCEL is sent to wrong destination (Proxy environment)

[Karsten Wemheuer (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224057#comment-224057 ] 

Karsten Wemheuer commented on ASTERISK-24628:
---------------------------------------------

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.

> CANCEL is sent to wrong destination (Proxy environment)
> -------------------------------------------------------
>
>                 Key: ASTERISK-24628
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24628
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Channels/chan_sip/Transfers
>    Affects Versions: 11.15.0
>         Environment: Debian Wheezy (7), OpenSIPs
>            Reporter: Karsten Wemheuer
>         Attachments: issue-failure.log, trace-failure-1.pcap
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)