Summary:	ASTERISK-27349: Failed to join Bridge when calling ConfBridge from applicationmap
Reporter:	Vasilis Agg (vagg)	Labels:
Date Opened:	2017-10-16 09:14:29	Date Closed:	2017-10-24 15:40:29
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_confbridge Core/Bridging
Versions:	13.17.2	Frequency of Occurrence
Related Issues:	is duplicated by ASTERISK-27855 Dial from macro-context N-way conference
Environment:		Attachments:	( 0) debug_log_2 ( 1) extensions.conf ( 2) features_applicationmap.conf
Description:	In Asterisk 11 it was possible to use a macro to  join a conference by calling the ConfBridge application. In Asterisk 13, it is no longer possible. When ConfBridge app is executed i get the following error {noformat} [Oct 16 10:16:05] DEBUG[26114][C-00000003] bridge_channel.c: Bridge 66a5a549-5e4b-469a-8b18-54845fc65c98: 0xaa474d80(SIP/100-00000006) failed to join Bridge {noformat} I have find out that bridge_channel_internal_join detects that the channel is in a bridge and returns without joining the bridge. To reproduce the problem first start a call and then the caller has to press *0 to start the macro.The caller fails to join the conference. The above error can be found in the debug log.
Comments:	By: Asterisk Team (asteriskteam) 2017-10-16 09:14:30.048-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: Joshua C. Colp (jcolp) 2017-10-16 09:41:46.855-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Joshua C. Colp (jcolp) 2017-10-20 12:12:02.543-0500 This specific behavior has always been undefined at best. Calling something like ConfBridge inside of a DTMF feature like that is not the best thing to do. Instead of trying to be in a bridge while in a bridge can the ChannelRedirect[1] dialplan application be used to redirect the channel out of the current bridge and into the dialplan where it can then enter the ConfBridge? [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_ChannelRedirect By: Vasilis Agg (vagg) 2017-10-23 09:37:04.669-0500 Thank you for your response. Using ChannelRedirect from a DTMF feature seems to work. However after using the feature it is not possible to retrieve previous channel variables (for example ${BRIDGEPEER}). I think that this is the expected behavior of the ChannelRedirect application. In some cases may be necessary to preserve the channel variables.  For example in a more complex scenario where we need to redirect the other party to the conference, this workaround doesn't work. By: Joshua C. Colp (jcolp) 2017-10-23 09:40:22.280-0500 The channel variable you are referring to is only set when a channel is in a bridge, and since it is redirected out then it is not set. What further complex scenario are you referring to? As well due to the fundamental changes to Asterisk it is unlikely this would be resolved such that you could use ConfBridge like before, other ways have to be used instead. By: Vasilis Agg (vagg) 2017-10-23 10:16:27.068-0500 I was referring to  n-way call. In this scenario you need to redirect the callee to the conference. This is not possible because we are not in the bridge. As far as i understand  ConfBridge can not be used  when we are in a bridge. So is it possible to use the ConfBridge application only when the channel is not into a bridge? By: Joshua C. Colp (jcolp) 2017-10-23 10:20:37.777-0500 Correct, ConfBridge can only be used when you aren't already in a bridge. You can't be in two bridges at the same time. By: Kevin Harwell (kharwell) 2017-10-24 15:30:41.228-0500 [~vagg], this currently sounds like a possible scenario specific configuration problem. Meaning there may be a way to solve this through dialplan and/or using redirects. For now I'd suggest querying the Asterisk community about it. Either on the mailing list (can subscribe [here|http://lists.digium.com/mailman/listinfo/asterisk-users] if not already), and/or the [community forums|https://community.asterisk.org/]. By: Kevin Harwell (kharwell) 2017-10-24 15:40:29.724-0500 Closing this out as this was not a supportable behavior of doing a bridge within a bridge as the new architecture does not allow it. At best before it was undefined behavior.  Asterisk post 11 has closed the misapplication of that behavior. By: Richard Mudgett (rmudgett) 2017-10-24 15:43:26.570-0500 The DTMF features (features.conf) supports ad-hock multi-party bridging as an option for attended transfers.  See the features.conf.sample file.  Or you could initially redirect the two parties to a confbridge and then originate other parties into the confbridge conference. By: Joseph Hayhoe (jhayhoe) 2018-11-12 16:34:37.511-0600 In response to Richard Mudgett above I can confirm this does work in 12+: I was able to setup basic 3-way calling using in-built features designed for asterisk 12+. I did this simply by adding the following to /etc/asterisk/features.conf: atxfer = *2 atxferthreeway = *42 atxferabort = #42 You initiate by starting a transfer via *2. The callee is placed on hold and you are presented with a dial tone. Dial the new number to bring into the 3-way call. Then once you are ready to bridge dial *42 (or whatever you defined above for atxferthreeway). To cancel the 3-way call and go back to the original call dial #42 (or whatever you defined above for atxferabort).