Summary:	ASTERISK-27228: bridging: Two party bridge where the first party was dialing a third party causes a variety of weird behavior
Reporter:	Thomas Sevestre (to)	Labels:
Date Opened:	2017-08-29 05:10:36	Date Closed:
Priority:	Major	Regression?	No
Status:	Open/New	Components:	Core/Bridging
Versions:	13.17.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Say - A dial B (we have channel_a and channel_b) - C bridge channel_a before channel_b is answered As a result : - channel_a is bridged with channel_c (OK) - channel_b is canceled (OK) - channel_b is canceled without an answered elsewhere reason (1st problem) - the initial dial does not returns until channel_a hangs up (2nd problem) The problem is in ast_bridge_add_channel implementation, when channel is not in a bridge but have a running pbx : - 1st problem is solved by setting AST_CAUSE_ANSWERED_ELSEWHERE hangupcause - I don't know how to fix the 2nd problem Edit (By bford): # Channel A calls Channel B # Channel C executes dialplan that calls Bridge(Channel A) before Channel B answers # Channel A and C and bridged, Channel B hangs up (reason is set to unknown) # When Channel A or C hang up, events are received involving Channel B, which can be seen via AMI
Comments:	By: Asterisk Team (asteriskteam) 2017-08-29 05:10:38.737-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-08-29 17:22:23.140-0500 Thomas, the issue was marked as regression. What version did the issue first occur in? That is, which version regressed the behavior? What specific versions did you test? Thanks, By: Thomas Sevestre (to) 2017-08-30 05:04:18.858-0500 Hello Rusty, I've hit regression by mistake, it won't help much. It works on asterisk 11 I've reproduced the bug on versions 13.16.0 and 13.17.0 By: Rusty Newton (rnewton) 2017-09-01 15:34:50.072-0500 [~to] Thanks for the information. No worries. bford was able to reproduce the issue as well, so I'm going to open this one up.