res_stasis: Don't play MoH to channels by default when added to holding bridges

When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.

Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.

This patch does the following:
 * The Stasis bridge class now inspects channels as they are going into a
   bridge. If the bridge has a holding capability, and the channel has no
   roles, we give it a participant role and mark the default behaviour to have
   no entertainment. This allows addChannel operations to continue to set a
   participant role with an entertainment option if it felt like it (or could
   do it).
 * The music on hold channel is now Stasis approved (tm)

Review: https://reviewboard.asterisk.org/r/3929/

ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau 
........

Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3

res/res_stasis.c

@@ -513,6 +513,11 @@ static struct ast_channel *bridge_moh_create(struct ast_bridge *bridge)
 		return NULL;
 	}
 
+	if (stasis_app_channel_unreal_set_internal(chan)) {
+		ast_hangup(chan);
+		return NULL;
+	}
+
 	/* The after bridge callback assumes responsibility of the bridge_id. */
 	if (ast_bridge_set_after_callback(chan,
 		moh_after_bridge_cb, moh_after_bridge_cb_failed, bridge_id)) {

res/stasis/stasis_bridge.c

@@ -130,6 +130,24 @@ static int bridge_stasis_push(struct ast_bridge *self, struct ast_bridge_channel
 		return -1;
 	}
 
+	/*
+	 * If going into a holding bridge, default the role to participant, if
+	 * it has no compatible role currently
+	 */
+	if ((self->technology->capabilities & AST_BRIDGE_CAPABILITY_HOLDING)
+	    && !ast_channel_has_role(bridge_channel->chan, "announcer")
+	    && !ast_channel_has_role(bridge_channel->chan, "holding_participant")) {
+		if (ast_channel_add_bridge_role(bridge_channel->chan, "holding_participant")) {
+			ast_log(LOG_ERROR, "Failed to set holding participant on %s\n", ast_channel_name(bridge_channel->chan));
+			return -1;
+		}
+
+		if (ast_channel_set_bridge_role_option(bridge_channel->chan, "holding_participant", "idle_mode", "none")) {
+			ast_log(LOG_ERROR, "Failed to set holding participant mode on %s\n", ast_channel_name(bridge_channel->chan));
+			return -1;
+		}
+	}
+
 	ao2_cleanup(control);
 	if (self->allowed_capabilities & STASIS_BRIDGE_MIXING_CAPABILITIES) {
 		ast_bridge_channel_update_linkedids(bridge_channel, swap);
@@ -187,6 +205,10 @@ static void bridge_stasis_pull(struct ast_bridge *self, struct ast_bridge_channe
 		ast_bridge_channel_update_accountcodes(NULL, bridge_channel);
 	}
 
+	if (self->technology->capabilities & AST_BRIDGE_CAPABILITY_HOLDING) {
+		ast_channel_clear_bridge_roles(bridge_channel->chan);
+	}
+
 	ast_bridge_move_hook(bridge_channel->features, bridge_stasis_moving, NULL, NULL, 0);
 
 	ast_bridge_base_v_table.pull(self, bridge_channel);