[Home]

Summary:ASTERISK-24624: Transfer to invalid extension results in hung channel.
Reporter:Zane Conkle (zconkle)Labels:
Date Opened:2014-12-16 11:01:34.000-0600Date Closed:2015-01-16 16:24:17.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:13.0.0 13.0.1 13.0.2 13.1.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ASTERISK-24624.patch
( 1) ASTERISK-24624-13.1.0.patch
Description:When attempting to blind transfer a call to an invalid extension or resource the channel will hang in the "Ring" state.

I was able to duplicate this by blind transferring a call to a mailbox that does not exist. Below is the CLI output along with the stuck channel.

{code}    -- Executing [s200-DEFAULT@default:1] Dial("SIP/carrier1-00000002", "PJSIP/200_default,10")
   -- Called PJSIP/200_default
   -- PJSIP/200_default-00000002 is ringing
   -- PJSIP/200_default-00000002 answered SIP/carrier1-00000002
   -- Channel SIP/carrier1-00000002 joined 'simple_bridge' basic-bridge <44f9110a-2508-4e62-acb4-75beca76ce31>
   -- Channel PJSIP/200_default-00000002 joined 'simple_bridge' basic-bridge <44f9110a-2508-4e62-acb4-75beca76ce31>
   -- Started music on hold, class 'default', on channel 'SIP/carrier1-00000002'
   -- Stopped music on hold on SIP/carrier1-00000002
   -- Channel SIP/carrier1-00000002 left 'simple_bridge' basic-bridge <44f9110a-2508-4e62-acb4-75beca76ce31>
   -- Channel PJSIP/200_default-00000002 left 'simple_bridge' basic-bridge <44f9110a-2508-4e62-acb4-75beca76ce31>
   -- Executing [1234@default:1] VoiceMail("SIP/carrier1-00000002", "5678@default") in new stack
[Dec 16 10:29:58] WARNING[3204][C-00000002]: app_voicemail.c:6467 leave_voicemail: No entry in voicemail config file for '5678'
   -- Auto fallthrough, channel 'SIP/carrier1-00000002' status is 'ANSWER'

[root@pbx ~]# asterisk -rx "core show channels verbose"
Channel              Context              Extension        Prio State   Application  Data                      CallerID        Duration Accountcode PeerAccount BridgeID            
PJSIP/200_default    default              s                   1 Ring    (None)       (Empty)                   200             00:27:57 default
{code}
Comments:By: Mark Michelson (mmichelson) 2015-01-13 18:28:57.781-0600

I tried to reproduce this and it was not working for me. I was using revision 430587 of the Asterisk 13 branch. My CLI output looks almost identical to yours except that I don't have a hung channel:

{noformat}
*CLI>     -- Executing [201@default:1] NoOp("PJSIP/202-00000003", "") in new stack
   -- Executing [201@default:2] Dial("PJSIP/202-00000003", "PJSIP/201,,tT") in new stack
   -- Called PJSIP/201
   -- PJSIP/201-00000004 is ringing
   -- PJSIP/201-00000004 answered PJSIP/202-00000003
   -- Channel PJSIP/201-00000004 joined 'simple_bridge' basic-bridge <4141887b-0eb9-41ad-9f77-7ad8b80dbf83>
   -- Channel PJSIP/202-00000003 joined 'simple_bridge' basic-bridge <4141887b-0eb9-41ad-9f77-7ad8b80dbf83>
   -- Started music on hold, class 'default', on channel 'PJSIP/202-00000003'
   -- Stopped music on hold on PJSIP/202-00000003
   -- Channel PJSIP/201-00000004 left 'simple_bridge' basic-bridge <4141887b-0eb9-41ad-9f77-7ad8b80dbf83>
   -- Channel PJSIP/202-00000003 left 'simple_bridge' basic-bridge <4141887b-0eb9-41ad-9f77-7ad8b80dbf83>
   -- Executing [310@default:1] VoiceMail("PJSIP/202-00000003", "NONEXISTENT_MAILBOX") in new stack
[2015-01-13 18:22:55.085] WARNING[18343][C-00000002]: app_voicemail.c:6467 leave_voicemail: No entry in voicemail config file for 'NONEXISTENT_MAILBOX'
   -- Auto fallthrough, channel 'PJSIP/202-00000003' status is 'ANSWER'

*CLI>
*CLI>
*CLI> core show channels
Channel              Location             State   Application(Data)            
0 active channels
0 active calls
3 calls processed
{noformat}

Out of curiosity, how are you performing your blind transfer? Are you using the transfer button on your SIP phone or are you pressing a DTMF sequence to do it? Does the hung channel happen every time or only sometimes?
By: Zane Conkle (zconkle) 2015-01-13 18:36:53.725-0600

I am using the "transfer" button on the phone itself and sending the call that way. FYI I tested this on branch yesterday to see if it happened to clear up and it did not.

The only thing I see different is that I am specifying a mailbox@context; I don't know if that matters or not. I believe Josh was able to reproduce this another way without the voicemail:

{quote}
[10:41am] file: a blind transfer how? from the phone itself, or features DTMF based?
[10:42am] ipengineer: file: From the phone itself by hitting xfer, dialing extension, pressing send
[10:43am] file: k
[10:45am] sgriepentrog: ipengineer: blind transfer feature code, or attended transfer feature code with a hangup when it's invalid?
[10:46am] file: yup
[10:46am] file: just reproduced it
[10:46am] file: you basically blind transfer to something that fails rapidly - like an extension that does a NoOp
{quote}
By: Joshua C. Colp (jcolp) 2015-01-13 18:43:13.894-0600

Yeah, blind transferring (from the phone) to an extension that simply does NoOp() will do it. I just did it on 13.1.0 and 13 branch. Both have a stuck channel.
By: Mark Michelson (mmichelson) 2015-01-14 09:21:47.854-0600

Excellent, thanks for the feedback. I'll modify my dialplan and try again.
By: Mark Michelson (mmichelson) 2015-01-14 13:54:00.957-0600

The reason I could not reproduce this was because it requires specific phone behavior in order to happen. As part of a transfer operation, Asterisk sends NOTIFY requests to the transferring party to let them know how the outbound call of the blind transfer is proceeding. When the blind transfer goes to an extension where things go badly, Asterisk sends a NOTIFY request that says things went badly. When a Digium phone receives this NOTIFY, it sends a BYE and is done.

When a Bria phone (and potentially others) receives this NOTIFY, it tries to reinvite itself back into the call. This reinvite is a bit confusing to Asterisk, because at the time the transfer was performed, we killed the channel of the transferring party. So when the reinvite arrives into chan_pjsip, chan_pjsip sees that there is no channel on the session and creates one. However, later code that is responsible for routing incoming channels sees that this is a reinvite and just takes no action. The result is a channel that gets created but then just sits there doing nothing.

Interestingly, sending a BYE on the dialog does not end up clearing the hung channel. This is likely because the channel reference that was created during the reinvite is leaked since the reference was never given to a channel thread. The resulting reference leak means that on session destruction, the corresponding channel is not freed.

I will work on a sensible solution to this and get back to you when I have a patch.
By: Mark Michelson (mmichelson) 2015-01-14 14:20:32.310-0600

I am attaching ASTERISK-24624.patch.

With this patch, the code that normally would create a new channel when receiving an INVITE now detects if the incoming INVITE is actually a reinvite and terminates the session if that is the case.

I could not reproduce the problem exactly as you had done, but I managed to do something similar with a Digium phone. The patch clears up the issue I had, but I want to double-check that it does for you as well. Please give the patch a try and let me know if it helps.
By: Zane Conkle (zconkle) 2015-01-14 14:39:38.801-0600

Tested and verified this fixed the issue
By: Mark Michelson (mmichelson) 2015-01-14 14:43:29.500-0600

At the request of the reporter, here is a 13.1.0 version of the patch.
By: Mark Michelson (mmichelson) 2015-01-14 15:13:58.153-0600

I have deleted the previous 13.1.0 version of the patch and added a new one here. I did not realize that ast_sip_session_terminate() was not defined in 13.1.0, so I have replaced the code with an in-line generation of the BYE request. This will behave differently than the 13 branch version. The 13 branch version will wait until the ACK is received to send the BYE since it has logic baked in to wait until INVITE transactions have cleared to send the BYE.

The 13.1.0 version of this patch will send the BYE immediately instead of waiting for an ACK. This may result in bad behavior on your devices, though it should be fine.
By: Zane Conkle (zconkle) 2015-01-14 16:24:28.920-0600

I verified the 13.1.0 patch worked