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

Tue May 31 11:15:56 CDT 2016

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-26072:
---------------------------------------

    Description: 
Hi;

We use Asterisk as a gateway to connect PSTN with our SIP platform (an opensips proxy) 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.
{noformat}
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.
{noformat}

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 is performed.

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

  was:
Hi;