asterisk

Commit Graph

Author	SHA1	Message	Date
Matthew Jordan	df5dbbd878	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	11 years ago
Jonathan Rose	33835e17a0	ARI: Fix a crash caused by hanging during playback to a channel in a bridge ASTERISK-24147 #close Reported by: Edvin Vidmar Review: https://reviewboard.asterisk.org/r/3908/ ........ Merged revisions 421879 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421880 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421881 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	6f735288b0	Stasis: Allow internal channels directly into bridges The patch to catch channels being shoehorned into Stasis() via external mechanisms also happens to catch Announcer and Recorder channels because they aren't known to be stasis-controlled channels in the usual sense. This marks those channels as Stasis()-internal channels and allows them directly into bridges. Review: https://reviewboard.asterisk.org/r/3903/ ........ Merged revisions 420795 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 420796 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420797 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	0ac7f96057	Stasis: Convey transfer information to applications This fixes a class of issues where Stasis applications were not made aware that their channels were being manipulated or replaced by external entitiessuch as transfers, AMI commands, or dialplan applications such as Bridge(). Inconsistent information such as StasisEnd events with unknown channels as a result of masquerades has also been corrected. To accomplish these fixes, several new fields were added to blind and attended transfer messages as well as StasisStart and BridgeAttendedTransfer Stasis events. ASTERISK-23941 #close Review: https://reviewboard.asterisk.org/r/3865/ Review: https://reviewboard.asterisk.org/r/3857/ Review: https://reviewboard.asterisk.org/r/3852/ Review: https://reviewboard.asterisk.org/r/3816/ Review: https://reviewboard.asterisk.org/r/3731/ Review: https://reviewboard.asterisk.org/r/3729/ Review: https://reviewboard.asterisk.org/r/3728/ ........ Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	f962448eee	ARI: Make mixing bridges propagate linkedids and accountcodes. * Create a Stasis bridge sub-class to propagate linkedids and accountcodes. * Fixed the basic bridge sub-class to update peeraccount codes when the number of channels in the bridge drops back down to two parties. * Refactored ast_bridge_channel_update_accountcodes() to handle channels joining/leaving the bridge. * Fixed the basic bridge sub-class to not call the base bridge class pull method twice. AFS-105 #close ASTERISK-23852 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/3720/ ........ Merged revisions 418225 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418226 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago

5 Commits (b8c1130ed172e478d7eaccbf9ba2913aaf36b260)