In the last blog post covering changes to the Asterisk core, we discussed the new Stasis Message Bus and how it helped Asterisk facilitate new APIs. While the message bus was necessary for new APIs, by itself, it did not provide everything we needed. To reach the API goals set out by the Asterisk Developer Community, we needed to also provide a more consistent model of the lifetime of communication objects within Asterisk. This necessitated a new Bridging Framework.
Channels and Bridges
In Asterisk, a channel represents a path of communication between Asterisk and some device. Prior to Asterisk 12, a bridge was a loose association of two or more channels with an implied sharing of media. This model of bridging worked well back when Asterisk was first written — multi-core machines were rare, and being conservative in its bridging model made Asterisk efficient.
However, this model did not lend itself well to complex call scenarios, particularly since the bridge itself did not have state. To perform call transfers, external redirects, and other manipulations of the channels in a bridge, Asterisk would have to execute some rather complex channel operations. Sometimes, these operations would be exposed through the APIs, requiring more work on the part of the API consumer.
Fortunately, back in Asterisk 10, we updated the ConfBridge application to utilize a new multi-threaded Bridging Framework. While in Asterisk 10 the focus of the framework was on multi-party bridging, the overall Bridging Framework is highly flexible and adaptable, and is able to bridge any number of channels in a large variety of ways. In Asterisk 12, we took the proven Bridging Framework and applied it to all areas of Asterisk where bridges are created. This provides a large number of advantages over the previous model of bridging:
- Bridges are multi-threaded. This allows Asterisk to easily release channels from a bridge. This in turn gives Asterisk the ability to present its APIs with a clear, consistent model of the lifetime of a channel, even as channels moves in and out of bridges.
- Bridges are smart. Any bridge can change how it mixes media between channels as the situation in the bridge changes. This enables easy manipulation of channels and bridges via Asterisk APIs.
- Bridges can have state. As a first-class citizen in Asterisk, bridges can have more complex applications built on top of them. This provides some interesting new dialplan applications and capabilities for Asterisk users.
While multi-party bridges have often involved multiple threads, two-party bridges prior to Asterisk 12 were generally single threaded. To share the media in a two-party bridge, a single thread of execution would shuttle the media between the participating channels. While this is extremely efficient, it makes releasing either channel from the two-party bridge very difficult without complex channel operations.
As the new Bridging Framework is implicitly multi-threaded, either channel in a two-party bridge can — at any time — be released to the dialplan, moved to another bridge, or manipulated in some fashion. These actions can occur without any renaming or manipulation of the channel object, presenting a clear picture of the world for users of Asterisk’s APIs.
Using AMI as an example, channels are presented with a predictable lifetime — a Newchannel event indicates the creation of a channel; a Hangup event indicates its destruction. Like channels, bridges are also conveyed with a consistent lifetime, marked by BridgeCreate and BridgeDestroy events. When a channel enters a bridge, a BridgeEnter event is emitted; when a channel leaves a bridge, a BridgeLeave event is emitted. Names of channels, bridges, and other communications primitives are unaltered.
While we are excited about the capabilities in the new APIs in Asterisk 12 and 13, users of AMI and other existing APIs in Asterisk also greatly benefit from the new architecture.
In the new Asterisk architecture, bridges are smart. When a bridge is created, it is created with certain constraints that determine how it is allowed to mix media. At all times, the Bridging Framework will attempt to mix the media between channels in a bridge in the most efficient way possible, subject to those initial constraints. As channels move into and out of bridges, as external systems change the conditions within a bridge, the Bridging Framework notices the changes, and updates its mixing strategy accordingly.
For an example, let’s say Asterisk created a bridge that mixed media between all participants, and — at least initially — did not require the media to move through the Asterisk core. As channels enter this bridge, the mixing strategy choices made by the Bridging Framework would look like the following:
|Alice’s PJSIP channel is placed into a bridge, where Alice’s PJSIP endpoint is configured to allow direct media.||Because there is only a single participant, the Bridging Framework picks the core two-party mixing technology. At this time, it can’t pick anything more efficient, as it does not know who else might be joining the bridge later.|
|Bob’s PJSIP channel is placed into the bridge with Alice. Bob’s endpoint is also configured to allow direct media.||Because there are two RTP capable channels in the bridge, the Bridging Framework can pick a better mixing technology than what it is currently using. It switches from the core two-party mixing technology to a native RTP bridge. The native RTP bridge informs the PJSIP channel driver to re-direct the media to pass directly between the two endpoints.|
|Charlie, who also has a PJSIP channel, is placed into the same bridge as Alice and Bob. While Charlie’s endpoint is configured to allow direct media, Charlie has a MixMonitor placed on his channel so that Asterisk records all conversations he is in.||There are now three channels in the bridge! The Bridging Framework re-evaluates, and switches to a softmix mixing technology, which mixes the media between all three participants. In the process, it re-directs the media passing between Alice and Bob to instead go back to Asterisk.|
|Alice, Bob, and Charlie all talk for some time, then Bob hangs up. This leaves Alice and Charlie in the bridge together.||Since we are now back to two participants, we can pick a better mixing technology than softmix. However, because Charlie has a MixMonitor on his channel, Asterisk has to record the media. The Bridging Framework switch to a core two-party mixing technology, so that it can keep recording the call.|
One of the major impacts of the Bridging Framework is that the same bridge can be used regardless of the number of participants in the bridge. Users of Asterisk’s APIs do not have to redirect participants to a conferencing application just to add a third participant — all they have to do is add the participant to the existing bridge and Asterisk will take care of the rest.
New Bridging Capabilities
In addition to making the Asterisk APIs better, the Bridging Framework also provides several new capabilities for Asterisk users. Some of these include:
- The ability to add channels to a “holding bridge” via the BridgeWait dialplan application. This special bridge is an efficient way to entertain multiple channels for a period of time. Participants in the bridge receive media from Asterisk, but unlike normal “mixing bridges,” cannot interact with each other. It also includes some advanced options, like the ability to have announcement messages played to all waiting users.
- New attended transfer capabilities. While performing a features-based attended transfer, the initiator of the transfer can not only cancel or complete the transfer, but can also now also do either of the following:
- Toggle between the destination of the transfer and the transfer target using DTMF. This can be repeated as many times as desired.
- Converge the attended transfer into a multi-party call. The destination of the transfer, the target of the transfer, as well as the initiator of the transfer will all be placed into the same bridge.
Asterisk 12: The Bridge to Asterisk 13
All of the new capabilities in the Bridging Framework were introduced in Asterisk 12, and have been refined over the past year in preparation for the upcoming Asterisk 13 release. The new model of bridging in Asterisk represents a fundamental leap in the Asterisk architecture that enables new capabilities for Asterisk users and new APIs for business application developers.
In the next blog post, we’ll begin to explore the new API initially released in Asterisk 12: the Asterisk REST Interface (ARI).