[asterisk-bugs] [JIRA] (ASTERISK-26072) chan_sip: Asterisk 13 don't send INVITE with Replaces after accepted REFER
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Wed Jun 15 09:53:56 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231031#comment-231031 ]
Rusty Newton edited comment on ASTERISK-26072 at 6/15/16 9:52 AM:
------------------------------------------------------------------
Huh, this is strange.
I want to expand on Josh's previous request
{quote}
Can you please provide the complete console output as well as dialplan, and if possible the output from the previous version where it worked.
{quote}
Please provide a full debug log for both versions, the old where it works and the new where it doesn't.
Follow the instructions here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
Make sure that both of the debug logs contain the SIP trace as well so we can see the full SIP traffic for the complete call from beginning to end.
Verify the log has the DEBUG and VERBOSE messages plus the SIP trace before attaching it to the issue. Please attach the files to the issue with the .txt extension and do not paste them into a comment.
Thanks!
was (Author: rnewton):
Huh, this is strange.
I want to expand on Josh's previous request
{quote}
Can you please provide the complete console output as well as dialplan, and if possible the output from the previous version where it worked.
{quote}
Please provide a full debug log for both versions, the old where it works and the new where it doesn't.
Follow the instructions here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
Make sure that both of the debug logs contain the SIP trace as well so we can see the full SIP traffic for the complete call from beginning to end.
Thanks!
> chan_sip: 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
> Assignee: Jose Molina
> Severity: Minor
>
> 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
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list