Summary:	ASTERISK-23280: Failed bridge when running ParkAndAnnounce from macro initiated from applicationmap
Reporter:	Anders Larsson (anders.larsson)	Labels:
Date Opened:	2014-02-12 03:45:26.000-0600	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Applications/app_parkandannounce Core/Bridging Features/Parking
Versions:	12.0.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	In Asterisk 11.6 you can park a call from a macro by calling the ParkAndAnnounce application. In 12.0.0 it's not longer possible. When trying to do so, you get this error and the ParkAndAnnounce application ends. {noformat} DEBUG[7118][C-00000000]: bridge_channel.c:1994 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) failed to join Bridge {noformat}
Comments:	By: Matt Jordan (mjordan) 2014-02-12 08:16:31.036-0600 The key here is that the macro execution is occurring as a result of an execution from an {{applicationmap}} in {{features.conf}} - that is, when the channel is in the Macro (or GoSub), it is actually already in an existing bridge. ParkAndAnnounce is calling {{ast_bridge_join}} to join the holding bridge. However, since that is occurring while a channel is in the bridge, {{bridge_channel_internal_join}} detects that the channel is in a bridge and bails. Basically, any application that wants to join a bridge should also check to see if the channel is already in a bridge. If we are in a bridge, we should simply get moved from our existing bridge to the new one. By: Anders Larsson (anders.larsson) 2014-02-18 04:33:04.969-0600 As an option to running the ParkAndAnnounce application from a Macro/GoSub, would it work to run it from an AGI-script, or will the call be in a bridge also at that point? By: Richard Mudgett (rmudgett) 2014-02-18 11:20:30.952-0600 If the channel is talking to another channel then it is in a bridge.  In that case, it would not matter how you executed the ParkAndAnnounce application. From the description, I take it that the ParkAndAnnounce is being run on the peer of the channel that activated the application map. By: Anders Larsson (anders.larsson) 2014-02-18 12:33:26.960-0600 Ok, so when is it possible to use the ParkAndAnnounce application? When there is only an incoming call without an outgoing call leg? This is the application map in features.conf: {noformat} parkswitchout => *#,peer/caller,Macro(parkswitch) {noformat} And this is the Macro(s) in extensions.conf: {noformat} [macro-parkswitch] ; this Macro is called when pressing *# during a connected call (defined in features.conf and available if __DYNAMIC_FEATURES is set for extension) exten => s,1,ExecIf($["${SHARED(PARKEDCALL,${DYNAMIC_PEERNAME})}" = "Y"]?Macro(parkswitchback)) ; if *# is pressed and there is already a parked call, run macro "parkswitchback" exten => s,n,Set(SHARED(PARKEDCALL,${DYNAMIC_PEERNAME})=Y) ; Will be used above and in the AGI script to know that a call has been parked exten => s,n,ParkAndAnnounce(,900,SIP/100) ; Park call for 15 min. SIP/100 will generate a warning instead of an announcement being played [macro-parkswitchback] ; this Macro is called by Macro "parkswitch" if *# is pressed and there is already a parked call exten => s,1,Set(SHARED(SWITCHBACKTOPARKEDCALL,${DYNAMIC_PEERNAME})=Y) ; Will be used in the AGI script to know that it should switch back to the parked call (run ParkedCall) exten => s,n,Hangup() ; Hangup the second call, so the parked call can be active {noformat} By: Richard Mudgett (rmudgett) 2014-02-18 13:54:02.628-0600 {quote} Ok, so when is it possible to use the ParkAndAnnounce application? When there is only an incoming call without an outgoing call leg? {quote} You are correct. Your use case is a legitimate use for ParkAndAnnounce.  Unfortunately, when ParkAndAnnounce and Park were reworked for Asterisk v12 that use case was not considered.  Currently, you can only use ParkAndAnnounce on an incoming call before it is put into a bridge.  e.g., before you Dial a destination. By: Anders Larsson (anders.larsson) 2014-02-18 14:04:52.974-0600 Thanks for your replies! I guess there is no simple patch I can do in the code to achive what Matt describes above, before this is fixed in a release? {quote} Basically, any application that wants to join a bridge should also check to see if the channel is already in a bridge. If we are in a bridge, we should simply get moved from our existing bridge to the new one. {quote} By: Richard Mudgett (rmudgett) 2014-02-18 14:37:12.093-0600 Without looking at the code, I cannot say how difficult it would be to accomplish. Could you use the one-touch-parking feature instead?  This is the use case and activation method for that feature. By: Anders Larsson (anders.larsson) 2014-02-18 14:49:10.633-0600 I have looked at the "one step parking" feature and it seems to work the way I want, except that I need a channel variable to be set when the call is parked (which I can retrieve in an AGI-script to know that a call has been parked) and also I don't want any announcement to be played. Maybe I can patch this in the code, but I'm not sure exactly where in the code I can find that. Also I need to be able to switch back to a parked call by pressing a DTMF sequence, preferably the same sequence as parks the call, but if it's not possible, I can use another sequence for that and then maybe achieve that the same way as I do now (by defining an application map running the "parkswitchback" macro which sets a variable and hangup the current leg)? By: Anders Larsson (anders.larsson) 2014-02-19 04:32:24.597-0600 I have now successfully configured my solution based on "one step parking" instead. I couldn't use the same DTMF sequence to switch back to a parked call as I use for parking the call, but that's ok. And when not using the same DTMF sequence for it I don't need the channel variable in the AGI-script anymore. I disabled the announcement message by changing the code as below: {noformat} res/parking/parking_bridge_features.c 117c117 <               snprintf(saynum_buf, sizeof(saynum_buf), "%u %u", 1, message->parkingspace); --- >               snprintf(saynum_buf, sizeof(saynum_buf), "", 1, ""); {noformat} Thanks for all your help. However, looking forward to see the issue fixed in a coming release.