Summary:	ASTERISK-21923: Add the ability to app_bridgewait to specify various music and sound options
Reporter:	Matt Jordan (mjordan)	Labels:	Asterisk12
Date Opened:	2013-06-19 19:25:05	Date Closed:	2013-07-18 11:53:03
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_bridgewait
Versions:	12	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk 12 contains a new application, app_bridgewait, that puts channels into an infinite wait bridge. When a channel is added to an infinite wait bridge, it should specify how it should be handled within that bridge. If the bridge doesn't already exist, the bridge is created with those options; otherwise the options are ignored. The options should be: * s - send silence media frames while in the holding bridge * n - send no media to the channel while in the bridge (Channel should not be answered yet) * h(moh-class) - send a hold frame to the channel and specify the music class to play * m(moh-class) - play MoH * r - Answer() the channel if not already answered If nothing is specified, m with {{default}} MoH is assumed. Note that if an unanswered channel joins, we should probably reject any attempts by announcer channels to join. In addition to addressing the BUGBUG comments in app_bridgewait, this will also handle the BUGBUG comments in bridge_holding.c: {noformat} /* BUGBUG Add IDLE_MODE_HOLD option to put channel on hold using AST_CONTROL_HOLD/AST_CONTROL_UNHOLD while in bridge */ /* BUGBUG Add IDLE_MODE_SILENCE to send silence media frames to channel while in bridge (uses a silence generator) */ /* BUGBUG A channel without the holding_participant role will assume IDLE_MODE_MOH with the default music class. */ {noformat}
Comments:	By: Jonathan Rose (jrose) 2013-07-08 15:01:26.951-0500 So one thing worth noting here right of the bat is that the 'r' option is already occupied by ringing and either that or the answer option will need to be something other than 'r'.