While I will no longer be working with Asterisk full time, I still plan to participate in the open source community.  I am excited to watch both Asterisk and Asterisk SCF continue to evolve and grow.  The engineering team at Digium, as well as the global Asterisk development community are as strong as they have ever been and will continue to accomplish big things.

I have met many great people from all over the world in my time with Asterisk.  Thank you all for making the past seven years so memorable.

Best Regards,

–
Russell Bryant

Related Posts:

• blogs.digium.com
• Asterisk Daily News

Channel logging GoSub() routine.

• ARG1 – Log level.
• ARG2 – The log message.

Channel logging using this routine will be sent to the Asterisk console at verbose level 0, meaning that they will show up when you want them to regardless of the current “core set verbose” setting. This routine uses a different method, values in AstDB, to control what messages show up.

AstDB entries:

• Family: ChanLog/ Key: all
• If the log level is less than or equal to this value the message will be printed.
• Family: ChanLog/ Key: channels/
• This routine will also check for a channel specific debug setting. It will actually check for both the full channel name as well as just the part of the channel name before ‘-’. This allows setting a debug level for all calls from a particular device. For example, a SIP channel may be “SIP/myphone-0011223344″. This routine will check:
• Family: ChanLog/ Key: channels/SIP/myphone
• Family: ChanLog/ Key: channels/SIP/myphone-0011223344

Example Dialplan Usage:

exten => 7201,1,GoSub(chanlog,s,1(1,${CHANNEL} has called ${EXTEN}))

Example of enabling debugging for a device from the Asterisk CLI:

*CLI> database put ChanLog SIP/myphone 3

chanlog routine implementation:

[chanlog]

exten => s,1,GotoIf($[${DB_EXISTS(ChanLog/all)} = 0]?checkchan1)
    same => n,GotoIf($[${ARG1} <= ${DB(ChanLog/all)}]?log)
    same => n(checkchan1),Set(KEY=ChanLog/channel/${CHANNEL})
    same => n,GotoIf($[${DB_EXISTS(${KEY})} = 0]?checkchan2)
    same => n,GotoIf($[${ARG1} <= ${DB(${KEY})}]?log)
    same => n(checkchan2),Set(KEY=ChanLog/channel/${CUT(CHANNEL,-,1)})
    same => n,GotoIf($[${DB_EXISTS(${KEY})} = 0]?return)
    same => n,GotoIf($[${ARG1} <= ${DB(${KEY})}]?log)
    same => n(return),Return() ; Return without logging
    same => n(log),Verbose(0,${ARG2})
    same => n,Return()

Greetings,

Shortly after the release of Asterisk 1.8, we had a developer meeting
and discussed some of the projects that people would like to see in
Asterisk 1.10 [1]. We discussed the schedule there a bit, as well. Now
that Asterisk 1.8 has settled down and we are well into the development
cycle for Asterisk 1.10, it is a good time to revisit the plans for the
next release.

At Digium, the biggest thing we have been working on for 1.10 so far is
replacing the media infrastructure in Asterisk. Most of the critical
and invasive plumbing work is done and has been merged into trunk. Next
we’re looking at building up some features on top of that, such as
adding more codecs, enhancing ConfBridge() to support additional
sampling rates (HD conferencing), adding features that exist in
MeetMe() but not ConfBridge(), and enhancing codec negotiation.

Of course, many others have been working on new developments as well. I
would encourage you to respond if you’d like to provide an update on
some new things that you’re working on.

We would like to release Asterisk 1.10 roughly a year after Asterisk
1.8. This will be a standard release, not LTS [2]. To have the release
out in the October time frame, we need to branch off 1.10 (feature
freeze) at the end of June. At that point we will begin the beta and RC
process. If you’re working on new development projects that you would
like to get into Asterisk 1.10, please keep this timeline in mind.

As always, comments and questions are welcome.

Thanks,

[1] https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2010
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

–
Russell Bryant

Hey all!

We’re getting VERY close to having the first draft of the next Asterisk book, Asterisk: The Definitive Guide ready to be sent off to production. We’re very close to meeting our target dates, but our review timeline is very tight. Only about 2 weeks!

Each morning we’re continuing to work on the book, taking in your comments, reviewing chapters, testing dialplan and installation steps, and all that good stuff.

However, we’ve been looking at this book since May 2010 and our eyes are starting to get glazed We’d love for the community to have a look at the book and offer some constructive criticism.

It’s far too late to take requests for things to cover. What we have is what we’re going to get in for this edition. After we finish this book though we plan on continuing to update it, so there will be a chance to take suggestions again soon.

For now, head on over to http://ofps.oreilly.com and check out the book (updated this morning). There are a couple of bugs in the OFPS software which are causing comments to not be available after chapter 8, but we’re hoping to have those resolved by Friday. However, we do have this fancy mailing list that we can use.

Update: This issue has been resolved

Russell, Jim and myself will be monitoring this list for comments, and we’ll try and get all of them satisfied before publication. If there is a particular area we’re covering that you’re an expert in, we’d love to have you focus on that chapter. You can email me back directly for more information on what we might be looking for in that type of situation.

We do have editors to help with grammar and spelling, but pointing anything out is certainly useful. The best use of your time though is testing the dialplan snippets, the installation instructions for both Ubuntu and CentOS (we’re covering two Linux distributions this time around, which increases the testing load significantly), and making sure anything we’re explaining is concise, relates to what we’re talking about, and makes sense. The goal is to build an Asterisk system from scratch, so following through our dialplan via the chapters to make sure it all continues to build on itself would be ideal.

Additionally, if you see any sections which say, “see chapter XXX for more information” that are not links, please let us know, as those are meant to be placeholders until the chapters existed and we could link back to them. Now that all chapters are created, we should be linking to the appropriate locations. If you’re reading a section and notice a good spot to reference another part of the book (for example, lets say we’re talking about database functionality in one of the other chapters, and there is an appropriate spot in the Database Integration chapter to link to), then let us know!

Thanks for your interest! Books should be shipping sometime between March and April. Pre-orders are available now at http://oreilly.com/catalog/9780596517342. And yes, we’ll be releasing under a Creative Commons license like the last two books, so you’ll have access to the book at any time online.

This book has been pretty much written from the ground up, and is well over 600 pages of content. It’s been a lot of work, but we hope you like it!

Thanks!
Russell, Jim and Leif.

A while back, I posted a message about an effort to improve automated testing in the Asterisk project. I wanted to give an update on how that project has progressed for those that have not been following along very closely.

We started using Bamboo as a continuous integration tool, which you can find running at http://bamboo.asterisk.org/. Note that some of the pass/fail statistics on there are a bit skewed, as the Bamboo server was just rebuilt and things were failing as everything was put back together.

A lot of really good automated test cases have been developed, and more are constantly being added. There are currently 85 test cases that run against Asterisk trunk after every change to the code. While some tests are small in scope, many of them cover significant call scenarios, such as various methods of doing transfers and call parking.

I apologize for the previous flood of Bamboo emails to the -dev list. I now have a new mailing list created for those that would like to subscribe to those messages.

http://lists.digium.com/mailman/listinfo/test-results

Additionally, one of the latest updates to our Bamboo setup is automated testing code coverage analysis. It will tell us exactly what code ran as a result of our automated test cases. It provides a good metric to start using to help identify areas of Asterisk that are in need of more test cases. You can find the code coverage reports for the latest builds of Asterisk trunk and 1.8 on Linux in the artifacts tab when viewing the details of a build.

http://bamboo.asterisk.org/browse/AST-TRUNK/latest

I’m proud of the progress we have made so far and am excited to continue aggressive development of automated test cases for Asterisk. The tests we have are already catching problems on a regular basis. The resulting quality improvements make the job of the development team easier, as well as result in a better experience for end users.

If you’re looking for a way to contribute to Asterisk and you are more comfortable writing scripts instead of C code, then the external test suite is a great way to get involved and help out.

Thank you all for your continued support of Asterisk!

Best Regards,

–
Russell Bryant
Digium, Inc. | Engineering Manager, Open Source Software
445 Jan Davis Drive NW – Huntsville, AL 35806 – USA
jabber: rbryant@digium.com -=- skype: russell-bryant
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org

This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/

All interested users of Asterisk are encouraged to participate in the 1.8 testing process. Please report any issues found to the issue tracker, http://issues.asterisk.org/. It is also very useful to hear successful test reports. Please post those to the asterisk-dev mailing list.

Asterisk 1.8 is the next major release series of Asterisk. It will be a Long Term Support (LTS) release, similar to Asterisk 1.4. For more information about support time lines for Asterisk releases, see the Asterisk versions page.

http://www.asterisk.org/asterisk-versions

Asterisk 1.8 contains many new features over previous releases of Asterisk. A short list of included features includes:

• Secure RTP
• IPv6 Support
• Connected Party Identification Support
• Calendaring Integration
• A new call logging system, Channel Event Logging (CEL)
• Distributed Device State using Jabber/XMPP PubSub
• Call Completion Supplementary Services support
• Advice of Charge support
• Much, much more!

A full list of new features can be found in the CHANGES file.

http://svn.digium.com/view/asterisk/branches/1.8/CHANGES?view=checkout

For a full list of changes in the current release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.0-beta1

Thank you for your continued support of Asterisk!

There are many exciting features in Asterisk 1.8. Here are just a couple of the more recent changes that have been merged in:

• IPv6: Asterisk 1.8 will have IPv6 support for SIP and RTP.
• SRTP: Asterisk 1.8 will have support for secure RTP to allow the media to be encrypted for a SIP call.

The list of new features is quite long. Take a look for a list of what is in Asterisk trunk (which will soon become Asterisk 1.8).

When Asterisk 1.8 is available as a beta and release candidate, please help by testing things out to help make this the best release yet!

Greetings,

I think we can do a much better job at testing within the Asterisk project and I suspect you do, too. The vast install base and wide variety of uses gets us very good feedback. However, it is clear that we can do better within the development community at improving the quality of the code before it makes it out in any type of release (beta, RC, or full release).

I would like to propose that we adopt an automated testing approach as a part of our development process. There are 4 pieces to this:

1. Testing with our eyes
2. Bottom-Up testing using unit tests within Asterisk
3. Top-Down testing using an external test suite
4. Tests running constantly using a continuous integration framework

While this isn’t automated testing, it is too valuable not to mention. One of the most effective ways of finding bugs in code is by peer code review. We see this more and more as we continue to increase our usage of ReviewBoard for peer review before changes are merged. It’s rare that a change goes in as the first proposed patch that goes on ReviewBoard. While it has never been a hard rule, it is strongly encouraged that every committer to seek a sign-off from at least one other committer via ReviewBoard for _every_ non-trivial change.

https://reviewboard.asterisk.org/

For unit testing, we have a new API in Asterisk trunk for writing unit tests within the code. We’re up to 20 unit tests. Writing these tests has already found multiple bugs and running them continuously has caught one regression before it made it into a release.

See include/asterisk/test.h

The beginnings of an external test suite have been created. There is still design work to do, but hopefully it will begin to be populated with tests soon. In general, though, this will become a suite of tests that can use whatever external tools are necessary to verify Asterisk functionality. There is a README.txt that documents what is there so far.

$ svn co http://svn.digium.com/svn/testsuite/asterisk/trunk

On the continuous integration front, we have been using buildbot for a long time for doing compilation on various systems. It’s time that we extend our continuous integration approach to not only compile Asterisk, but also run regression tests. After evaluating some different options, Bamboo has been installed and configured for our use. So far, it is compiling all release branches of Asterisk. For Asterisk trunk, it is running all of the unit tests after every change to the code. The results of the tests are integrated into the application.

Bamboo – The Asterisk Project

The only build slave right now is Linux. This will be extended to other operating systems. If you would be interested in providing a build slave and assisting with its maintenance, please talk to me. We can configure up to 25 build slaves (“remote agents” in Bamboo terminology).

If you have commit access, you are strongly encouraged to sign up for an account on bamboo.asterisk.org and associate your account with your svn username. That way, bamboo can notify you by email and/or jabber if there any problems associated with changes that you make.

As you work on changes to the Asterisk code, you should consider this approach to testing along side your development. If there is a unit test you could write to help prove your code works or prevent a bug from showing up again, then please write one! If there is an external test you could write to help verify some piece of functionality you are using continues to work precisely as expected, then let’s figure out how to get that into the test suite. This kind of testing not only prevents regressions but it also guarantees that expected behavior will remain intact across releases.

I am excited about what this effort can do for the quality of Asterisk in the long term, and I hope you are, too. I look forward to your feedback on the approach as well as participation in the development of our testing infrastructure.

Thanks,

–
Russell Bryant
Digium, Inc. | Engineering Manager, Open Source Software
445 Jan Davis Drive NW – Huntsville, AL 35806 – USA
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org

Congratulations to all accepted students!