Commit Graph

5 Commits

Author SHA1 Message Date
Matthew Jordan
2d8c38cf9a 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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-01 14:14:40 +00:00
Jonathan Rose
712907eec6 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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-22 16:44:21 +00:00
Kinsey Moore
406dded64c 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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-11 18:37:14 +00:00
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
2014-08-07 15:30:19 +00:00
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
2014-07-09 16:34:51 +00:00