| Summary: | ASTERISK-24264: ARI: Adding a channel to a holding bridge automatically starts MOH | ||
| Reporter: | Samuel Galarneau (sgalarneau) | Labels: | |
| Date Opened: | 2014-08-22 22:21:41 | Date Closed: | 2014-09-01 09:09:10 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_ari Resources/res_ari_bridges |
| Versions: | 12.5.0 13.0.0-beta1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Ubuntu 12.04 | Attachments: | |
| Description: | With Asterisk installed from svn trunk, when adding a channel to a holding bridge using ARI, the MOH starts automatically. A Call to stop MOH returns with an error that the bridge is currently not playing MOH. Removing the channel from the bridge then stops MOH.
MOH should not start until startMoh has been called manually. | ||
| Comments: | By: Matt Jordan (mjordan) 2014-08-22 22:24:45.956-0500 There's actually a few problems here: # A channel that doesn't specify a participant role when joining a bridge is automatically assigned MoH. That's not terrible, but it is probably unexpected. We should probably create a role of "holding_participant" with no sound/options unless the user specifies it. # Starting MoH on a holding bridge has several problems: ## MoH channels are not currently recognized as being allowed in Stasis and get bounced out ## When they aren't bounced out (which was an easy fix), they also get added as a participant in a holding bridge, and they have MoH started on them. Whoops. ## Looking more carefully, playback channels in a holding bridge also aren't announcers Generally, if a channel gets put into a Stasis bridge, and that bridge happens to be a holding bridge, we should handle it correctly based on its intended purpose. By: Richard Mudgett (rmudgett) 2014-08-23 14:04:15.438-0500 The holding technology has several options for the entertainment: none, MOH, ringing, and silence. It defaults to MOH if the participant entertainment is not specified. By: Matt Jordan (mjordan) 2014-08-23 17:33:10.332-0500 I'm well aware of that - that's not in question :-) The problem is: *that isn't what a user of ARI would expect*. | ||