[asterisk-dev] Asterisk 12 Update - Bridge Work
mjordan at digium.com
Tue Feb 12 15:31:31 CST 2013
Some folks have noticed that we've been doing a lot of work on the
bridging functionality in Asterisk. The motivation for this came out of
discussions at AstriDevCon, where many people noted the difficulties
external applications have when attempting to maintain the state of who
is talking to whom. These problems often start with Asterisk's
masquerade operation, which itself is a symptom of problems in the way
that Asterisk has historically bridged channels.
Luckily, Asterisk already has a solution to this (and has since 1.6
days) - Joshua Colp's Bridging API. The API is already used by
ConfBridge and Page, but hasn't been deployed outside of those
applications. Since we have a good layer of abstraction for bridging
already implemented, and since it provides a model of bridging that
lends itself well to the needs of external APIs (and Asterisk users!),
we started refactoring Asterisk to use the Bridging API for all of its
Up until now, the work for this has been tracked under the API project
, but the scope of the work being done really deserves its own page.
Thus, there is now a project page for this up on the wiki . This
provides a dedicated place to document project planning, design, tests,
and other useful information for people who want to participate and
contribute to the project.
So what's been done/being done?
If we're going to tear into the guts of such a fundamental concept, we
have to have some assurance that we can stitch it all back together! So
for some time, we've been working on a large set of tests that cover the
currently supported bridging features. You can find the current bridging
tests in the Asterisk Test Suite , and the test plan that they are
implementing on a sub page of the project page . There's more to be
done here, however, so expect additional tests to pop up (and more
reviews on Review Board for the tests).
In addition to testing, we've started the work on expanding usage of the
Bridge API to the various consumers that initiate bridging, starting
with the Bridge application. Richard has created an integration branch
for this work , and is currently working through the various ways in
which channels can be moved between bridges. That includes things like
transfers, but also Local channel optimization, merging bridges,
swapping between two party and multi-party bridge technologies, and a
whole host of other cases.
In parallel, Jonathan has been working on implementing timed features.
Previously, the Bridging API provided initial implementations of DTMF
triggered features, such as blind and attended transfers and hangup.
However, the Bridge application (as well as Dial) allows for features
that occur on a timed or periodic basis, such as hanging up a channel
after n seconds. Luckily, Joshua had already started on this work as
well, so Jonathan brought that up to trunk and has started to merge it
into Richard's work .
Some of the next steps on the bridging work are going to entail:
* Finish up the API cleanup and threading model changes
* Get the other consumers of bridging moved over to the new Bridging API
* Implement an API that allows external entities to initiate a transfer
operation on channels in a bridge
* Refactor the Park family of applications to use a new bridging technology
As always, if you're interested in any aspect of this work, feel free to
reply to this e-mail, start a new discussion, or talk about it in
#asterisk-dev. We also accept message via pigeon, but given how fast
things are moving, I'd recommend an electronic form of communication.
tl;dr: We're going to use the Bridging API for lots of stuff.
Collaboration is always welcome :-)
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
More information about the asterisk-dev