About Asterisk Codec Negotiation Patch

The purpose of this patch is to change the behaviour of the popular open-source PBX and IVR package Asterisk, so that when bridging two channels it tries as hard as possible to avoid doing any audio transcoding. This is necessary to avoid degrading the audio quality, which is unavoidable when converting from low-bitrate codec such as G.729 or GSM into signed linear (which is internal format used by the Asterisk) and then back to the same or different low-bitrate codec. It also allows using Asterisk in the cases when it has no support for decoding particular codec, such as for example G.729 or G.723.

Another important implication of the patch is that it helps to reduce administration efforts for maintaining Asterisk, as the administrator dosn't have to worry much about codecs anymore. The patch also typically redices the CPU usage and increases scalability, due to the fact that CPU-intensive transcoding is avoided for the most cases of call forwarding.

History

The patch was originally created around mid-2005. For various reasons outside of the control of the patch authors it has not been merged into the Asterisk yet, despite the fact that it has been properly submitted via Asterisk bug-tracking system back then and considerable attempts has been made to keep this patch up to date.

How it works

The patch introduces changes in two main areas of Asterisk's audio processing:

  1. The original Asterisk sends outgoing call independently of codec order of parent channel. With the patch the Asterisk tries to keep the order of codecs of the originating channel while sending another call out. This helps to avoid codec transcoding and this is extremely useful feature when commercial (G.729, G.723) codecs cannot be avoided in your UAs but those codecs aren't installed on your Asterisk.
  1. Another significant change introduced by this patch concerns the transcoding process. Original Asterisk behavior is to create fixed transcoding path at the very beginning of the call. If one of the parties decides to change codec on the fly without re-INVITE then the Asterisk simply drops such packets disregarding the fact that the Asterisk itself confirmed some non-preferred codecs at the negotiation stage. The patch makes the transcoding process dynamic - the Asterisk creates new transcoding paths upon receiving the RTP packet with the payload different from the preferred format.

Downloads

Current versions

Archive versions

Acknowelegments

The patch now is being actively developed and maintained by the Sippy Software, Inc.