Skip to end of metadata
Go to start of metadata

Mixing Bridges

In a mixing bridge, Asterisk shares media between all the channels in the bridge. Depending on the attributes the bridge was created with and the types of channels in the bridge, a mixing bridge may attempt to share the media in a variety of ways. They are, in order of best performance to lowest performance:

  • Direct packet sharing between devices - when there are two channels in a mixing bridge of similar types, it may be possible to have the media bypass Asterisk completely. In this type of bridge, the channels will pass media directly between each other, and Asterisk will simply monitor the state of the channels. However, because the media is not going through Asterisk, most features - such as recording, speech detection, DTMF, etc. - are not available. The proxy_media attribute or the dtmf_events attribute will prevent this mixing type from being used.
  • Native packet sharing through Asterisk - when there are two channels in a mixing bridge of similar types, but the media cannot flow directly between the devices, Asterisk will attempt to mix the media between the channels by directly passing media from one channel to the other, and vice versa. The media itself is not decoded, and so - much like when the media is directly shared between the devices - Asterisk cannot use many features. The proxy_media attribute or the dtmf_events attribute will prevent this mixing type from being used.
On This Page

  • Two party mixing - when there are two channels in a mixing bridge, regardless of the channel type, Asterisk will decode the media from each channel and pass it to the other participant. This mixing technology allows for all the various features of Asterisk to be used on the channels while they are in the bridge, but does not necessarily incur any penalties from transcoding.
  • Multi-party mixing - when there are more than two channels in a mixing bridge, Asterisk will transcode the media from each participant into signed linear, mix the media from all participants together into a new media frame, then write the media back out to all participants.

At all times, the bridge will attempt to mix the media in the most performant manner possible. As the situation in the bridge changes, Asterisk will switch the mixing technology to the best mixing technology available.

What Can Happen in a Mixing Bridge

ActionBridge Response
A bridge is created using POST /bridges, and Alice's channel - which supports having media be directly sent to another device - is added to the bridge using POST /bridges/{bridge_id}/addChannel.Asterisk picks the basic two-party mixing technology. We don't know yet what other channel is going to join the bridge - it could be anything! - and so Asterisk picks the best one based on the information it currently has.
Bob's channel - which also supports having media be directly sent to another device - also joins the bridge via POST /bridges/{bridge_id}/addChannel.

We have two channels in the bridge now, so Asterisk re-evaluates how the media is mixed. Since both channels support having their media be sent directly to each other, and mixing media that way is more performant than the current mixing technology, Asterisk picks the direct media mixing technology and instructs the channels to tell their devices to send the media to each other.

Carol's channel - which is a DAHDI channel (poor Carol, calling from the PSTN) - is also added to the bridge via POST /bridges/{bridge_id}/addChannel.Since we now have three channels in the bridge, Asterisk switches the mixing technology to multi-mix. Alice and Bob's media is sent back to Asterisk, and Asterisk mixes the media from Alice, Bob, and Carol together and then sends the new media to each channel.
Eventually, Alice hangs up, leaving only Bob and Carol in the bridge.Since Alice left, Asterisk switches back to the basic two-party mixing technology. We can't use a native mixing technology, as Bob and Carol's channels are incompatible, but we can use a mixing technology that is less expensive than the multi-mix technology.

Example: Implementing a basic dial

Dialing can be implemented by using the POST - /channels operation and putting both the resulting channel and the original Stasis channel in a mixing bridge to allow media to flow between them. An endpoint should be specified along with the originate operation as well as a Stasis application name. This will cause the dialed channel to enter Stasis, where it can be added to a mixing bridge. It's also a good idea to use Stasis application arguments to flag that the dialed channel was dialed using originate in order to handle it differently from the original channel once it enters into the Stasis application.

This example ARI application will do the following:

  1. When a channel enters into the Stasis application, a call will be originated to the endpoint specified by the first command line argument to the script.
  2. When that channel enters into the Stasis application, a mixing bridge will be created and the two channels will be put in it so that media can flow between them.
  3. If either channel hangs up, the other channel will also be hung up.
  4. Once the dialed channel exists the Stasis application, the mixing bridge will be destroyed.

Dialplan

For this example, we'll use a Stasis application that species not only the application - bridge-dial - but also:

  • Whether or not the channel is inbound or a dialed channel.
  • If the channel is inbound, the endpoint to dial.

As an example, here is a dialplan that dials the PJSIP/bob endpoint:

extensions.conf

Python

As is typical for an ARI application, we'll start off by implementing a callback handler for the StasisStart event. In this particular case, our callback handler will be called in two conditions:

  1. When an inbound channel enters into the Stasis dialplan application. In that case, we'll want to initiate the outbound dial.
  2. When an outbound channel answers. In that case, we'll want to defer processing to a different callback handler and - in that handler - initiate the bridging of the two channels.

In our StasisStart callback handler, we can expect to have two pieces of information passed to the application:

  1. The "type" of channel entering the callback handler. In this case, we expect the type to be either inbound or dialed.
  2. If the "type" of channel is inbound, we expect the second argument to be the endpoint to dial.

The following code shows the StasisStart callback handler for the inbound channel. Note that if the "type" is not inbound, we defer processing to another callback handler. We also tell the inbound channel to start ringing via the ring operation, and initiate an outbound dial by creating a new channel to the endpoint specified. Finally, we subscribe to the StasisEnd event for both channels, and instruct them to call a safe_hangup function on the opposing channel. This ensures that if either party hangs up, we hang up the person they were talking to. We'll show the implementation of that function shortly.

Be careful of errors!

Icon

Note that we wrap the origination with a try / except block, in case the endpoint provided by the dialplan doesn't exist. When taking in input from a user or from the Asterisk dialplan, it is always good to be mindful of possible errors.

The safe_hangup function referenced above simply does a "safe" hangup on the channel provided. This is because it is entirely possible for both parties to hang up nearly simultaneously. Since our Python code is running in a separate process from Asterisk, we may be processing the hang up of the first party and instruct Asterisk to hang up the second party when they are already technically hung up! Again, it is always a good idea to view the processing of a communications application in an asynchronous fashion: we live in an asynchronous world, and a user can take an action at any moment in time.

We now have to handle the outbound channel when it answers. Currently, when it answers it will be immediately placed in our Stasis application, which will call the stasis_start_cb we previously defined. While we could have some additional if / else blocks in that handler, we can also just apply a StasisStart callback to the outbound channel after we create it, and handle its entrance separately.

When the outbound channel is answered, we need to do the following:

  1. Answer the inbound channel.
  2. Create a new mixing bridge.
  3. Put both channels into the mixing bridge.
  4. Ensure we destroy the mixing bridge when either channel leaves our application.

This is shown in the following code:

Note that the safe_bridge_destroy function is similar to the safe_hangup function, except that it attempts to safely destroy the mixing bridge, as opposed to hanging up the other party.

bridge-dial.py

The full source code for bridge-dial.py is shown below:

basic-dial.py

bridge-dial.py in action

The following shows the output of the bridge-dial.py script when a PJSIP channel for alice enters the application and dials a PJSIP channel for bob:

PJSIP/Alice-00000001 entered our application
Dialing PJSIP/Bob
PJSIP/Bob-00000002 answered; bridging with PJSIP/Alice-00000001
Hung up PJSIP/Bob-00000002

 

JavaScript (Node.js)

This example shows how to use anonymous functions to call functions with extra parameters that would otherwise require a closer. This can be done to reduce the number of nested callbacks required to implement the flow of an application. First, we look for an application argument in our StasisStart event callback to ensure that we will only originate a call if the channel entering Stasis is a channel that dialed our application extension we defined in the extensions.conf file above. We then play a sound on the channel asking the caller to wait while they are being connected and call the originate() function to process down the application flow:

We then prepare an object with a locally generate Id for the dialed channel and register event callbacks either channels hanging up and the dialed channel entering into the Stasis application. We then originate a call to the endpoint specified by the first command line argument to the script passing in a Stasis application argument of dialed so we can skip the dialed channel when the original StasisStart event callback fires for it:

We then handle either channel hanging up by hanging up the other channel. Note that we skip any errors that occur on hangup since it is possible that the channel we are attempting to hang up is the one that has already left and would result in an HTTP error as it is no longer a Statis channel:

We then handle the StasisStart event for the dialed channel by registered an event callback for the StasisEnd event on the dialed channel, answer that answer, creating a new mixing bridge, and finally calling a function to add the two channels to the new bridge:

We then handle the dialed channel exiting the Stasis application by destroying the mixing bridge:

Finally, the function that was called earlier by the callback handling the StasisStart event for the dialed channel adds the two channels to the mixing bridge which allows media to flow between the two channels:

bridge-dial.js

The full source code for bridge-dial.js is shown below:

bridge-dial.js

bridge-dial.js in action

The following shows the output of the bridge-dial.js script when a PJSIP channel for alice enters the application and dials a PJSIP channel for bob:

  • No labels