[asterisk-bugs] [JIRA] (ASTERISK-22092) Gulp blond transfers result in channels not being hung up properly

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-22092:
-----------------------------------

    Status: Open  (was: Triage)
    
> 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
>              Labels: Asterisk12
>
> 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.

--
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