Mark Michelson created ASTERISK-22092:
-----------------------------------------
Summary: Gulp blond transfers result in channels not being hung up properly
Key: ASTERISK-22092
URL: https://issues.asterisk.org/jira/browse/ASTERISK-22092
Project: Asterisk
Issue Type: Bug
Security Level: None
Components: Core/Bridging
Affects Versions: 12
Reporter: Mark Michelson
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:
{no-format}
*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
{no-format}
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira