- 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
|A bridge is created using ||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 |
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 ||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:
- 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.
- 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.
- If either channel hangs up, the other channel will also be hung up.
- Once the dialed channel exists the Stasis application, the mixing bridge will be destroyed.
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
- If the channel is
inbound, the endpoint to dial.
As an example, here is a dialplan that dials the
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:
The full source code for
bridge-dial.js is shown below:
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: