[asterisk-dev] Asterisk 12 Project Update

Mon May 6 18:58:56 CDT 2013

Hey everyone!

It's been awhile since the last project update, and since we're heading
into the home stretch on Asterisk 12, it felt like it was time for
another project update. As a general overview of the state of things,
all of the work for Asterisk 12 is now in the issue tracker and
represented on the various projects' wiki pages. There's still a lot of
things to get done, and lots of opportunities for participation and
collaboration. If you're interested in any of the work, don't hesitate
to ask in #asterisk-dev or on the asterisk-dev mailing list for ideas.

We have tasks for every kind of participation, many of which require
different levels of effort - so if you're wondering if there's something
you could contribute towards, don't worry - there probably is!

New SIP Channel Driver [1]

As Mark noted earlier [2], the new SIP channel driver is now in trunk.
There's still a ways to go however, and new work is being merged into
the team/group/pimp_my_sip branch as it is being completed. Recently,
this included some work on being able to negotiate media in a fine
grained fashion [3], call forwarding and diversion header support [4],
SDES SRTP support [5], and out of call messaging support [6]. WebSocket
support is well on it's way, as is initial support for device state.
snuffy has also started configuration documentation - a hugely needed
effort to make all of this usable! [7] You may note that the
configuration documentation is actually in source as opposed to in a
.conf file - due to some recent patches in trunk (work originally done
by Terry Wilson aka otherwiseguy), configuration for some modules can be
defined as XML documentation. That means the documentation will be up to
date on the wiki, and the sample configuration files can actually be
used for sample configuration - as opposed to just documentation.

I'd be remiss if I didn't point out that we're currently having a
discussion on what to name the new SIP channel driver - pop over to that
thread and vote if you haven't already [8]. If you don't vote, you can't
complain about the results of the election!

API Work [9]

Stasis-Core has now been in Asterisk trunk for awhile, and we continue
to refactor AMI, CDRs, CEL (and whatever else we can get our hands on)
on top of it. There's a lot of power in Stasis-Core: not only is the
vast majority of Asterisk state now available in a pub/sub architecture,
but you can aggregate this state into your own topic and route only the
messages you care about to your module. David Lee has written design
documentation for Stasis-Core on the wiki [10], and a new 'demo' module,
res_statsd, for showing how to use Stasis-Core has been added to
Asterisk [11]. (Unfortunately, refactoring res_snmp over to Stasis-Core
is a bit larger than a 'demo' task!)

An initial cut of CDRs using Stasis-Core is up on Review Board, and
we're working through a lot of the various AMI events now to get them
onto Stasis-Core. CEL is coming up next!

Stasis-HTTP continues to develop as the infrastructure in Asterisk
expands to support the concepts it needs. This includes having the
ability to treat endpoints as first class citizens within Asterisk, such
that endpoints can have state associated with them that can be queried
from resource modules. We're also currently hard at work on getting
media playback up and running - expect a "Hello World" Stasis-HTTP
sample in the relatively near future.

Bridging Framework [12]

The bridging core continues to be developed in the
team/group/bridge_construction branch and is starting to reach a point
where it's incorporating more consumers of bridging within Asterisk.
This includes:
* Local channel optimization - this now occurs completely within the
bridging framework (and appears to be just a tad bit faster!)
* Transfers - initial support for externally initiated blind transfers
is starting to go in. This includes chan_iax2, but also chan_sip [13].
Expect chan_gulp and the other channel drivers to start getting some
attention real soon!

There's a lot to say about the power of the new bridging framework, and
a lot of it is difficult to explain in just a single e-mail. Let's just
say the white boards here are filled with diagrams trying to cover all
the interesting corner cases that a dialplan writer may create (how do
you park a multi-party bridge?) There's a lot of fun things to play
with, now that channels can move between two-party and multi-party
bridges seamlessly.

Speaking of channels, if you're a maintainer of one of Asterisk's
channel drivers, you may get an e-mail from me soon asking for some help
converting your channel driver over to the new bridging framework. Not
to fear - it's far less painful than you might think, and you'll like
the number of lines of code you get to delete!

Phew. I'm sure I'm forgetting things, and as you can see there's a lot
of work going on and a lot left to do. As I mentioned previously,
collaboration and help is always appreciated - whether you're testing,
developing, documenting, or just providing input. It's coming along
well, but we've still got a ways to go, and the more collaboration we
get, the better Asterisk 12 will be.

Thanks!

Matt

[1] https://wiki.asterisk.org/wiki/display/AST/New+SIP+channel+driver
[2] http://lists.digium.com/pipermail/asterisk-dev/2013-April/059639.html
[3] http://lists.digium.com/pipermail/asterisk-commits/2013-May/061388.html
[4] http://lists.digium.com/pipermail/asterisk-commits/2013-May/061390.html
[5] http://lists.digium.com/pipermail/asterisk-commits/2013-May/061286.html
[6] http://lists.digium.com/pipermail/asterisk-commits/2013-May/061384.html
[7] https://reviewboard.asterisk.org/r/2471/
[8] http://lists.digium.com/pipermail/asterisk-dev/2013-April/059669.html
[9] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+API+Improvements
[10] https://wiki.asterisk.org/wiki/display/AST/Stasis+Message+Bus
[11] http://svn.asterisk.org/svn/asterisk/trunk/res/res_statsd.c
[12] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project
[13] https://reviewboard.asterisk.org/r/2495/

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org