Summary:	ASTERISK-26318: Dial with M(macro-name) needs an optional media bridge but don't answer
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2016-08-26 06:22:51	Date Closed:	2016-08-31 08:07:06
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:	13.10.0	Frequency of Occurrence
Related Issues:
Environment:	Linux	Attachments:
Description:	{noformat} [inbound] exten => _X.,1,Dial(PJSIP/outbound/sip:${EXTEN}@XX.XX.XX.XX,,M(nobill^${CHANNEL(name)})) [macro-nobill] exten=> s,1,Wait(30) same=n,MacroExit() {noformat} Inside the macro nobill, we should set a variable that would indicate if media bridging is OK. I need to let the parties talk and wait a certain amount of seconds before I relay back the 200 OK to the caller. This is not possible now. I tried using {{Bridge($\{ARG1\})}} inside the macro above, but the call does get bridged and answered at the same time. Bridge should not answer the call, nobody asked to do so.
Comments:	By: Asterisk Team (asteriskteam) 2016-08-26 06:22:52.309-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) 2016-08-30 19:19:38.709-0500 Just as a note, you should really be using GoSubs wherever possible now. Macros are still there for legacy support, but GoSub is preferred. Can you attach a full log and a full log with debug showing the undesired behavior? By: Private Name (falves11) 2016-08-30 21:04:44.821-0500 The gosub and the macro are both the same, when related to this problem. The issue is that in a postdial handler, like U() or M(), the media bridge is not there while either the gosub or the macro executes. It should left to the coder to decide if he needs the mediapath open or not. An there is a way to do it now, using the application Bridge(), it works, I tested it. But, but, it also answers the call, which it should not. Answering the is a business decision, not a technical one. The Bridge() command should not automatically answer the call. In this case, I want to delay XX seconds the 200 OK, but let them talk. So the solution would be to change the Bridge() command to do what it does and nothing more. Think there is no need for a trace, since we all know what the Bridge() command does by looking at the code. By: Matt Jordan (mjordan) 2016-08-31 08:11:21.732-0500 This is a feature request without a patch. As per project policy, this issue is closed pending someone wanting to provide said functionality. Bridge will always Answer a call. If two parties are talking with each other, a 200 OK *has* to be sent. Any other situation would result in only one direction of media, which means you aren't really bridged. If you want to Dial a party, have the outbound party Answer, but then manipulate both channels for some period of time before bridging them, you can use the {{MACRO_RESULT}} or {{GOSUB_RESULT}} to specify a dialplan location to send the channel(s) to. You can also use the option in Dial that specifies both parties should be immediately sent to a dialplan location. By: Private Name (falves11) 2016-08-31 08:17:38.539-0500 This statement is false "Bridge will always Answer a call. If two parties are talking with each other, a 200 OK has to be sent. Any other situation would result in only one direction of media, which means you aren't really bridged." The 183 has SDP and if early media is allowed in pjsip.conf, both parties are exchanging media, are fully bridged, long before a 200 Ok is sent. Bridge has no business sending a 200 OK. The 200 Ok initiates billing, which is not a technical decision, is a business one. By: Asterisk Team (asteriskteam) 2016-08-31 08:17:38.726-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Private Name (falves11) 2016-09-02 19:10:04.128-0500 This is really a bug. A client of mine declined buying calls from me because he placed test calls, and when he already was listening to the other side (the callee was saying "hello John"), suddenly, the audio was clipped for the 5 seconds I was executing the M() or U(). As by principle, never interrupt the parties once they can hear each other. It costed me already a customer and maybe hundreds of thousands in lost revenue. Asterisk should never, ever, create the possibility of dead air once the parties already hear each others voices. It is a simple change, on the M() or U() don't break the already established media channel. By: Asterisk Team (asteriskteam) 2016-09-02 19:10:04.387-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Matt Jordan (mjordan) 2016-09-03 16:33:01.330-0500 The functionality you are asking for has *never* been in Asterisk. Without a patch, it is a feature request. The fact that you think that functionality that has never existed is a bug does not make it so. Asterisk is behaving how it always has, and is behaving as it was designed. You've been told many times in the past what your options are for having new features put into Asterisk. This is the last time I will comment on this issue. Continuing to complain and/or argue about this point will result in this issue being deleted and/or your account being blocked.