Tue, 14 May 2013 02:59:07 +1200
Hey all -
We have a new addition to the Asterisk development team here at Digium who will be working on tests for the Asterisk Test Suite, specifically to help support Asterisk 12 - John Bigelow! While relatively new on the Asterisk development team, John has been working with Asterisk and Digium for a long time, and brings a lot of knowledge to the test process on how Asterisk is used and deployed.
You will see some reviews to the Asterisk Test Suite by John already up on Review Board, and - in the very near future - commits as well. Please join me in welcoming John!
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
Wed, 08 May 2013 04:05:31 +1200
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
As Mark noted earlier, 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, call forwarding and diversion header support, SDES SRTP support, and out of call messaging support. 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! 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. If you don\'t vote, you can\'t complain about the results of the election!
API Work
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, and a new \'demo\' module, res_statsd, for showing how to use Stasis-Core has been added to Asterisk. (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
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.
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
--
Matthew Jordan
Digium, Inc. | Engineering Manager
Sat, 27 Apr 2013 03:43:09 +1200
Hi!
Those of you who watch the commits list have probably seen that the pimp_my_sip branch has been merged to trunk. The reason for this is that, with the exception of an API for handling incoming PUBLISH requests, the API for new SIP work has reached a stable point. There may still be forthcoming changes, but they will not be major.
So does this mean that SIP development for Asterisk 12 is complete? Not by a long shot!
For those of you brave enough to give what\'s in Asterisk trunk a whirl, here\'s a brief list of what you can do:
- Basic calls (inbound and outbound)
- Audio and video support
- DTMF support for RFC 4733, inband, and INFO
- Caller ID and limited Connected Line support
- Session timers
- PRACK
- RFC 3326 (Reason header) supportAuthentication (inbound and outbound)
- Direct media
- Audio and video support
- Registration (inbound and outbound)
- Call forwarding
- Sending OPTIONs outbound
- NAT traversal (including ICE support)
- MWI (Just NOTIFY support, no SUBSCRIBE support)
- SIP debugging
- Configuration for the following items:
- Endpoints (\"peers\" in chan_sip terminology)
- Addresses of record and their contacts
- Domains
- Authentication
- Transports (to include support for multiple transports)
- Endpoints (\"peers\" in chan_sip terminology)
MESSAGE support (both in-call and out-of-call)
A media negotiation dialplan function to explicitly set codecs on outbound calls
SDES SRTP support
Diversion header support
Other upcoming tasks can be found on the SIP project page\'s JIRA issues section.
Documentation for how to configure the new SIP work is slim for now. If you have questions or would like to improve documentation, please feel free to speak up. Currently, Brad Latus has a review up adding XML documentation for configuration items. It\'s a good first step towards making the new work more user-friendly.
This merge is a milestone, of sorts, mostly due to the API stability. Developers interested in adding new features should continue working either in the pimp_my_sip SVN branch or in a branch based off of pimp_my_sip. We\'re not sure yet when the next batch of code will make it into trunk, but the next batch will in all likelihood be much smaller.
Thanks for the support,
Mark Michelson
Thu, 25 Apr 2013 07:14:30 +1200
I’m having to whisper, because I’ve got all the details about AstriCon 2013 – and I’m spilling them just for you, before anyone else has them. The official release will happen later today – so you really are the first to know!
I can reveal that AstriCon, the only ‘must-attend’ Asterisk user event in the world, will be at the at the Renaissance Atlanta Waverly Hotel & Convention Center in Atlanta, GA (as its name suggests) from October 8-10 this year.
We’re expecting more Asterisk enthusiasts, telephony geeks, smart business types that are in the know and gifted developers than ever before.
Not only that, but Asterisk 12 *may* be released around that time, and we’ll have the Asterisk developers on hand to give you the lowdown on the most fundamental changes made to Asterisk for years.
Read More...
Tue, 23 Apr 2013 04:14:40 +1200
Friends,
I\'ve been working with a small piece of code that makes it possible for Asterisk to put a SIP phone on hold.
Previously, if one party in a call puts the other party on hold, Asterisk plays music. With this code enabled,
Asterisk will put the call on the other side of the bridge on hold too. This is beneficial if you have multiple
Asterisks or use Asterisk as an endpoint, a phone.
The code is ready for you to test. Provide feedback on this mailing list or any other channel.
http://svn.digium.com/svn/asterisk/team/oej/jasmin-remote-hold-1.8
Looking forward to your feedback!
/O
