Peter on project Asterisk SCF

In last Monday’s blog, I talked in general terms about my visit to Astricon 2011. One of the many things that interested me at the event was finding out that there’s a bunch of new documentation this year, and the main Digium resource is now on wiki.asterisk.org ; it contains all the developer and architecture documentation, plus auto-generated documentation from the source code. So, everything anyone would need to know should be there. Also interesting was that they have really upped their game in developer tools, as Digium has moved the project to using Jira and Confluence.

Secondly, asterisk now has a pretty comprehensive test suite (http://blogs.asterisk.org/2010/04/29/installing-the-asterisk-test-suite/). Every commit to asterisk source code is automatically built and the test suite is run against it. When custom patches are written, folks should therefore do the same – it tests for memory leaks, dead locks, etc.

Therefore, when developing patches against asterisk, the best practice would now be to to use a standard Digium packaged asterisk 10 and run the test suite against your patch. Secondly, it looks like there are some significant improvements in Asterisk10, especially with media handling, so I think we should all be aiming to use it as the default production install.

On to Asterisk SCF; last year at Astricon they announced a new project Asterisk SCF – scalable communications framework (https://wiki.asterisk.org/wiki/display/TOP/Asterisk+SCF+Home). This is designed to meet the needs of carriers and ITSPs like Gradwell and although it has a lot less functionality, it has a lot more scalability. First public beta release in November 2011, Production release expected in Jan 2012. It supports standard SIP connectivity, simple call routing, rtp and udptl media, bridging, etc.

The main features are:

  • Full support for ipv6
  • Nat traversal, stun, turn, Ice
  • Failover support in all components – including failover for rtp so media for phone calls can continue even if a server node dies.
  • Documented Apis for all interactions between Components.
  • Extension points: place to put in our own logic. Examples as python scripts.
  • Push configuration. Components cannot read config from any files etc. A tool has to connect to the components and pushes the configuration into the components. All changes made in real time.
  • Sip components are built on top of pjsip stack. Supports tcp, tls which is a good move and should make connecting to Microsoft Lync etc. much simpler.  http://www.pjsip.org/

 

2011-11-07T09:27:07+00:00

About the Author:

Leave A Comment

Request a quote