[asterisk-bugs] [JIRA] (ASTERISK-26072) Asterisk 13 don't send INVITE with Replaces after accepted REFER

Mon May 30 01:31:57 CDT 2016

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

Asterisk Team commented on ASTERISK-26072:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> Asterisk 13 don't send INVITE with Replaces after accepted REFER
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-26072
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26072
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.9.1
>         Environment: Ubuntu 12.04
>            Reporter: Jose Molina
>
> Hi;
> We use Asterisk as a gateway to connect PSTN with our SIP platform with a SIP trunk. We upgraded our Asterisk gateway from version 11 to 13. After the migration, we have an issue with attended transfer with the chan_sip driver. This is the scenario:
> 1- PSTN number (user A) calls any extension of our SIP platform (user B). B answer the call
> 2- user B holds the incoming call and makes a second call to other SIP extension (user C) to initiate an attended transfer.
> 3- user B transfers the call for try to join A and C users but this transfer fails.
> Analyzing the signalling traffic, we can see that the REFER message arrives from B to the gateway Asterisk with the Replaces header. Asterisk accepts the REFER message with a 202 Accepted response but doesn't send the INVITE with the replaces message to do the transfer. Asterisk send a NOTIFY with a sipfrag reporting 503 Service Unavaiable.
> U 2016/05/30 08:20:02.3871052  1.1.1.2:5070 --> 1.1.1.1:5100
> REFER sip:37233 at 1.1.1.1:5100 SIP/2.0.
> Record-Route: <sip:xuser at 1.1.1.2;lr=on;ftag=4FC4B456-84A45F87>.
> Via: SIP/2.0/UDP 1.1.1.2:5070;branch=z9hG4bKa4e7.68946b95.0.
> Via: SIP/2.0/UDP 1.1.1.2:5070;branch=z9hG4bKa4e7.58946b95.0.
> Via: SIP/2.0/UDP 1.1.1.2;branch=z9hG4bKa4e7.5a17f5d2.0.
> Via: SIP/2.0/UDP 1.1.1.3;rport=5060;branch=z9hG4bK3b060ecd72DB1B2E.
> From: "userB" <sip:25988 at mydomain.com:5070>;tag=4FC4B456-84A45F87.
> To: "userA" <sip:37233 at mydomian.com:5100>;tag=as04e841f5.
> CSeq: 2 REFER.
> Call-ID: 26fc844416113667695f1f3f06d22826 at mydomain.com.
> Contact: <sip:u8-3 at 1.1.1.2>.
> Accept-Language: pl-pl,pl;q=0.9,en;q=0.8.
> Refer-To: <sip:u6-676 at 1.1.1.2?Replaces=4827f2a1-e2ca8142-5416e633%401.1.1.3%3Bto-tag%3D1422695821%3Bfrom-tag%3D107F133D-7BEB429E>.
> Referred-By: <sip:userB at mydomain.com>.
> Max-Forwards: 11.
> Content-Length: 0.
> .
> U 2016/05/30 08:20:02.387120 1.1.1.1:5100 -> 1.1.1.2:5070
> SIP/2.0 202 Accepted.
> Via: SIP/2.0/UDP 1.1.1.2:5070;branch=z9hG4bKa4e7.68946b95.0;received=1.1.1.2;rport=5070.
> Via: SIP/2.0/UDP 1.1.1.2:5070;branch=z9hG4bKa4e7.58946b95.0.
> Via: SIP/2.0/UDP 1.1.1.2;branch=z9hG4bKa4e7.5a17f5d2.0.
> Via: SIP/2.0/UDP 1.1.1.3;rport=5060;branch=z9hG4bK3b060ecd72DB1B2E.
> Record-Route: <sip:xuser at 1.1.1.2;lr=on;ftag=4FC4B456-84A45F87>.
> From: "userB" <sip:25988 at mydomain.com:5070>;tag=4FC4B456-84A45F87.
> To: "userA" <sip:37233 at mydomain.com:5100>;tag=as04e841f5.
> Call-ID: 26fc844416113667695f1f3f06d22826 at mydomain.com.
> CSeq: 2 REFER.
> Server: Asterisk PBX 13.9.1.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
> Supported: replaces, timer.
> Contact: <sip:37233 at 1.1.1.1:5100>.
> Content-Length: 0.
> .
> U 2016/05/30 08:20:02.387228 1.1.1.1:5100 -> 1.1.1.2:5070
> NOTIFY sip:u8-3 at 1.1.1.2 SIP/2.0.
> Via: SIP/2.0/UDP 1,1,1,1:5100;branch=z9hG4bK285dcfd6;rport.
> Route: <sip:1.1.1.2:5070;lr=on;ftag=as04e841f5>,<sip:1.1.1.2:5070;lr=on;ftag=as04e841f5>,<sip:xuser at 1.1.1.2;lr=on;ftag=as04e841f5>.
> Max-Forwards: 70.
> From: "userA" <sip:37233 at mydomain.com:5100>;tag=as04e841f5.
> To: "userB" <sip:25988 at mydomain.com:5070>;tag=4FC4B456-84A45F87.
> Contact: <sip:37233 at 1.1.1.1:5100>.
> Call-ID: 26fc844416113667695f1f3f06d22826 at mydomain.com.
> CSeq: 103 NOTIFY.
> User-Agent: Asterisk PBX 13.9.1.
> Event: refer;id=2.
> Subscription-state: terminated;reason=noresource.
> Content-Type: message/sipfrag;version=2.0.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
> Supported: replaces, timer.
> Content-Length: 33.
> .
> SIP/2.0 503 Service Unavailable.
> The TRANSFER_CONTEXT variable is defined but the call no execute any line of code defined in the dialplan from this context.
> This same scenario works fine with Asterisk 11 and with the same config files. Asterisk sends a NOTIFY with a sifrag 200 OK and sent and INVITE with Replaces and the trasnfer takes effect.
> Any idea why Asterisk 13 don't execute the TRASNFER_CONTEXT code and send the INVITE with Replaces? Is a possible bug in this release?
> Thanks for your help.
> Jose

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