[asterisk-dev] Asterisk 12 Project Update

Tue May 7 01:47:41 CDT 2013

Hi,
Thanks for a good overview.

I have a couple of questions on what is included in current plans for 
Asterisk 12.

1. Real-time text.
Is the support for real-time text with presentation according to T.140 
and RTP transport according to RFC 4103 included in the plans.
It is in current versions 1.6, 1.8 etc, and described in 
http://www.voip-info.org/wiki/view/Real-time+text and works well for 
rapid smooth text communication.

2. Calls without audio.
A long time ago, Asterisk had problems with calls without audio. E.g. 
only video.
Many SIP implementations have the problem that they have audio-centric 
roots and are not verified for audio-less calls.
I did not see any use case for calls without audio among the video call 
cases and suggest that such cases are added and the case kept in mind 
during the development.

3. Complete SDP parameter handling for video.
Video calling through Asterisk requires good and comprehensive handling 
and conveyance of video parameters between the call legs to achieve 
interoperability and good video quality between the parties. Are there 
plans for that?

Thanks,

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
gunnar.hellstrom at omnitor.se
+46708204288
On 2013-05-07 01:58, Matthew Jordan wrote:
> 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/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130507/38ed2494/attachment-0001.htm>