There’s been a lot of talk about the new SIP stack that is being worked on for Asterisk. The SIP stack is tightly connected to the RTP media subsystem and that’s a part of Asterisk I’ve spent a lot of time with lately. Here’s a few items I’ve been working on and hope to get into Asterisk 12:

Pinefool – Packet loss concealment and more

This branch improves audio handling. If configured  it adds packet loss concealment which improves recordings quite a lot
when there’s packet loss in the network. This is a very simple form of packet loss concealment, which I call the “Poor Man’s PLC”. If there is packet loss, Asterisk will just copy the previously received audio frame to conceal it. Asterisk already has a more advanced Packet Loss Concealment function, that’s hard to activate when you just forward packets in the RTP layer without any transcoding.

This patch also fixes some issues with packet reordering and loss. Previously Asterisk was masqing it, so two endpoints talking G.729 couldn’t fix the packet loss in their code. With Pinefool, Asterisk will keep the properties of the inbound stream on the outbound stream. A lost packet in the incoming stream will cause a lost packet in the outbound stream. Packets arriving out of order will still be out of order on the outbound stream, making it possible for the receiving end point, which in most cases has a jitter buffer with packet loss concealment, to sort out the mess and produce high-quality audio. I have to acknowledge a lot of help in brainstorms over a lot of chat sessions from Martin Festr Vit, the developer of

Benefit: Improved audio in lossy networks, better quality recordings

Pinefrog – Improved RTCP and call quality records (CQR)

The Pinefrog branch adds reporting of RTCP for streams that have it. By saving data about each call leg in database or outputting it on the manager port, a third-party application can monitor the health of SIP trunks and possibly calculate MOS score on calls. With an intelligent application, the data could also be used to disable trunks that doesn’t work as expected or select codecs based on network quality.

The CQR, Call Quality Records, are stored in any database supported by the ARA, Asterisk Realtime Architecture. This code has been in production in a large set of different sites, from carriers to call centers, for many years in the 1.4 branch.

Benefit: Being able to manage QoS and make automatic decisions based on this input in 3rd party apps

Pinequeue – background audio processing for queues

This patch implements a new audio backend for queues. Previously agents had to wait for a prompt to be played
for a caller in the queue before the phone gave a ring. With Pinequeue audio is handled in the background
and we will interrupt any prompts played as soon as an agent answers the call.

Benefit: No agents waiting to answer customers that in fact is waiting for a free agent.

Rana – Adjust the DTMF Duration and keep it under control

Fixes a lot of problems with DTMF passed through Asterisk. The duration wasn’t handled properly, which resulted in large differences between the incoming DTMF tone and the tone sent on the outbound call leg.

Benefit: 200 ms DTMF will not become 500 ms or even worse.

Roibus – Implements support of comfort noise (inbound only)

With this patch, Asterisk will negotiate and support comfort noise support on incoming media. Comfort noise goes hand in hand with silence suppression in a device. If a device recognizes silence, it stops sending audio frames and instead instructs the other end to generate replacement audio called “comfort noise”.

This patch is not yet complete. Asterisk will not send cng on the outbound stream yet. Regardless, the patch is already saving a lot of bandwidth and is a requirement for Microsoft Lync trunks too. Primarily it is a bandwidth saving issue. Previously Asterisk did not support it so for a 64 K codec we always send 64k plus over head. Coming work will add support for silence suppression in Asterisk, so that Asterisk can make a decision on whether to send actual audio or suppress it. This will add overhead in your Asterisk server, as a DSP will have to be applied to the audio stream to listen in for silence. In many cases this is worthwhile, as the bandwidth saving generates so many benefits.

Benefit: Some VoIP bandwidth calculation web sites estimates that full (two-way) silence suppression and CNG saves between 30-40% of the bandwidth for a call.

Current work: Implementing full DNS SRV-based failover and load balancing in Asterisk

Currently I’m working with improving the failover and load balancing when using DNS srv records. RFC 3263 describes how this should work in SIP. The Asterisk SIP stack has limited support – just grabbing the first alternative, not failing over. With the help of a set of dialplan functions, you can organize failover for the first INVITE in a call, but no failover during the call. This will have to be fixed.

The pinefrog, darjeeling, pinequeue, rana and roibus branches are in production in at least two large carriers and in some of our call centers. Pinefool is pretty new, we’re testing it in a few sites now. They are written for Asterisk 1.4 or Asterisk 1.8 with ports to many versions. Together with the Digium development team, I am working to make this code part of Asterisk 12.

The combination of pinefool, pinefrog, roibus and rana will improve your media handling vastly.

Check your bug tracker and sales records to see if you haven’t got requests for these kind of
features! If you have then download the branches from my subversion tree and try them out! 


PS. Every branch has a README file for the branch in the main directory. Don’t forget to read it. Thanks!