What is RTP pass-through mode in Asterisk?
The speech for VoIP calls uses RTP (Real Time Protocol) to get from one end to the other and it is compressed using one of the many speech compression codecs available. Commonly used codecs include G.711 and G.729. When you call someone through an Asterisk PBX, there will be two “legs” to that call. The first leg is from your phone to Asterisk and the second is from Asterisk to the person you called. Asterisk is usually able to translate codecs (so-called transcoding) if the two call legs want to use different codecs, but it is generally preferable to let it operate in pass-through mode – i.e. where both call legs use the same codec and Asterisk does not need to translate.
Codec choices – the benefits of G.729
G.729 is a popular codec because the compressed speech uses less bandwidth than the default G.711 codec and it is supported on most IP phones and by most VoIP services. Ok, there is a trade-off in so far as the speech quality is not quite as good, but if you need to deliver multiple simultaneous calls over an ADSL broadband link, then it has to be considered. On balance, G.729 is one of the better compressions in terms of achieving low bandwidth without losing too much speech audio quality.
So what’s the problem?
Well, no problem except that sometimes Asterisk needs to translate to or from G.729, yet the option may not be available. Take, for example, the Pika Appliance for Asterisk (also known as the Warp Appliance). It’s a great little device to use as a small office telephone system connecting to SIP trunks and conventional analogue or Basic Rate ISDN lines. It does, however, have one potentially annoying weakness – no support for transcoding to or from the G.729 codec. Even if you are using a different Asterisk PBX platform that does support the G.729 codec, you may need to purchase some G.729 licenses from Digium before the PBX will perform transcoding to or from G729.
How can you influence the choice of codec and the use of pass-through mode?
It would be great if you could configure Asterisk to use “pass-through” mode in all cases where transcoding is not possible (for whatever reason), but the reality is that codec negotiation is quite complex and Asterisk is not as clever as it could be. The complexity comes from the fact that one call involves 2 end points and 2 Asterisk connections – each end point has a list of preferred codecs, as does each Asterisk connection. That means four different sets of codec preferences have to somehow be resolved.
Suppose you want G.729 to be the preferred codec on a SIP trunk because it gives you a better balance between speech quality and number of simultaneous calls. However, for internal calls, extension to extension, the preferred codec is G.711. Your extension phones can work with both of these codecs. If the Asterisk PBX does not support G.729 transcoding, then you must ensure pass-through mode is used for any calls involving an extension phone and your SIP trunk.
The question is “Can Asterisk be configured to select pass-through mode for G.729 encoded calls from a SIP trunk to local extensions?”. The answer is yes, but setting up the list of allowed codecs in the sip.conf file is not altogether straightforward. Furthermore, in the example mentioned here it will only work for inbound calls – outbound calls would have to use G.711.
Codec negotiation – What are the rules?
Often, the only way to find out about the detailed workings of Asterisk is to read the source code or run some practical tests. I opted for the latter. My research showed that Asterisk is not very clever when it is matching up codecs on the inbound and outbound legs of a SIP-to-SIP call.
The rules seem to be this: First, Asterisk will negotiate with the calling device to select a codec for the inbound call leg – it uses the most preferred codec from its own list that is also supported by the calling peer device or service. Having decided on a codec for the inbound call leg, it now looks at the destination route and tries to select the same codec for the called peer. Provided the same codec is available on the outbound leg (it does not necessarily have to be the preferred codec on this leg), then pass-through mode is used. However, if the codec selected for the inbound leg is not supported at all by the destination device, then Asterisk attempts transcoding to the preferred codec of the destination peer. If it is unable to transcode (e.g. when G.729 is the 1st codec for one peer on the Pika Warp) then the call fails with a “not supported here” message.
This is quite unsophisticated because Asterisk never looks at the other options for pass-through using the lower preference codecs listed for the calling peer.
A cautionary note about Asterisk codec configuration
By the way, make sure that the list of codecs you set in Asterisk is correct for that peer device. For example, do not include GSM in Asterisk’s list for a device that does not support GSM. If you do, some calls will fail and it might be quite hard to figure out why!
Conclusion
Pass-through mode may provide a useful solution for direct peer to peer calling, but if you want Asterisk to play a pre-recorded sound file then you will be faced with new problems in transcoding from the compression mode used for the file to the mode required for the call. In theory you could record all the prompts in a G.729 encoded format thus avoiding the need for transcoding. If you have tried this or have any other comments, please post your comments below.