[Home]

Summary:ASTERISK-22092: Gulp blond transfers result in channels not being hung up properly
Reporter:Mark Michelson (mmichelson)Labels:Asterisk12
Date Opened:2013-07-17 15:20:51Date Closed:2013-08-19 10:02:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/Bridging
Versions:12 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:Performing an external blond transfer results in channel refleaks.

Example:

GULP/alice-00000000 is bridged to GULP/bob-00000001
Bob presses transfer key and dials Carol's extension.
This results in an outbound call from GULP/bob-00000002 to GULP/carol-00000003.
Carol's phone rings.
Bob hangs up before Carol answers.
Channel destructor runs for GULP/bob-00000002<ZOMBIE>
Carol answers.
Carol and Alice talk.
Carol hangs up.
Channel destructor runs for GULP/carol-00000003.

I never see GULP/bob-00000001 destroyed and I never see GULP/alice-00000000 destroyed.

Issuing a "core show channels" command after the blond transfer gives the following:

{noformat}
*CLI> core show channels
Channel              Location             State   Application(Data)            
Gulp/alice-00000000  (None)               Up      NoOp(H EXTENSION)            
Gulp/bob-00000002    (None)               Ring    Dial(GULP/carol,,tT)          
Gulp/bob-00000001    (None)               Up      AppDial((Outgoing Line))      
0 active channels
0 active calls
2 calls processed
{noformat}

In an attempt to narrow things down a bit, I performed the same test using chan_sip instead of chan_gulp. The exact same problem occurred, so the problem is likely in the core attended transfer code.
Comments:By: Matt Jordan (mjordan) 2013-07-18 09:26:57.670-0500

As an aside, I thought we removed the renaming of the channel to {{GULP/bob-00000002<ZOMBIE>}}?
By: Mark Michelson (mmichelson) 2013-07-18 09:54:51.206-0500

The actual mechanics of channel masquerades have not changed, to my knowledge. The need for having to use masquerades has been reduced greatly though. It's pretty much limited at this point to blond transfers, call pickup, and bridge operations that have the MASQUERADE_ONLY flag set (used in ConfBridge).

The only reason I know about the ZOMBIE channel being destroyed is because I added some debug logging into ast_channel_destructor() so I could see what channels were being destroyed. I'm fairly certain that no one outside of Asterisk would have knowledge that channel existed.