Summary:ASTERISK-21689: AMI bridge continues to try and bridge even after reporting "Channel2" does not exist; and fails resulting in hangup of Channel1
Reporter:William luke (greenlightcrm)Labels:
Date Opened:2013-04-25 09:23:18Date Closed:2018-01-02 08:44:19.000-0600
Status:Closed/CompleteComponents:Core/Bridging Core/ManagerInterface Features
Versions:11.3.0 Frequency of
duplicatesASTERISK-21691 bridge cmd does not hangup if the bridged leg hangedup
Environment:CentOS 6Attachments:( 0) ami.txt
( 1) cli.txt
Description:Sometimes when executing an AMI Bridge on two channels one of the channels will have hungup and disappeared. Although the timing must be precise for this to occur (the hangup event and the bridge event "passing in transit" so to speak) we're seeing it a few hundred times a day on a busy system.

The AMI Bridge correctly response that Channel2 does not exist. It then continues to try and do the bridge anyway (!). This results in Channel1 being hungup.
It's worth noting that if Channel1 doesn't exist it gives the same error, but *does not* try and continue, which to me is the correct behavior.

This seems to happen regardless of the dialplan, however for our testing we had Channel1 sitting in a Wait loop, like so:

exten => _X.,1,Answer()
       same => n,Set(DiallingHub=${EXTEN})
       same => n,UserEvent(GLDiallingHubJoin,DiallingHub: ${DiallingHub},Channel: ${CHANNEL})
       same => n(agentinhub),NoOp(AGENT ${EXTEN} waiting in Dialling Hub)
       same => n,Wait(600)
       same => n,Goto(agentinhub)

I've included the AMI output and CLI outputs when this occurs.

If you need any further details please let me know.
Comments:By: Richard Mudgett (rmudgett) 2013-04-25 11:36:20.912-0500

Looks like the AMI bridge action code has always done this.  The code that handles the action is in features.c:action_bridge().  The routine needs to be reordered to call the do_bridge_masquerade()'s for each channel after the verification and preparation work for each channel.

By: Ido Kanner (ik_5) 2013-04-27 16:20:53.727-0500

here is a dialplan that also have the same result as the described bug:

By: Ido Kanner (ik_5) 2013-04-29 10:00:19.513-0500

In my case, I was able to figure out why it happens - When I use in dial the "G" option, it looses the track of the bridged call.

By: Joshua C. Colp (jcolp) 2017-12-19 04:48:04.999-0600

Are you also experiencing this under Asterisk 13?

By: Asterisk Team (asteriskteam) 2018-01-02 08:44:19.218-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines