Tests of Asterisk Proxying Audio

Yesterday, we wrote an article about how to remove Asterisk from the media path if NAT was involved. Today's article focuses on why you would want to do such a thing. The answer depends on the specifications of your project. If your project requires Asterisk to listen for DTMF, record the call, transcode between codecs, or any other feature that involves audio processing, Asterisk will need to proxy the audio. If that doesn't apply, here are some reasons why you might not want Asterisk to handle the audio: 1) Bandwidth consumption. 2) Server resource consumption. 3) Latency. To be sure, the impact a single call has on an Asterisk server is fairly minimal, but if you have a busy server, it may be worthwhile to reduce its load when possible. There are three ways Asterisk can route audio to your phone. We decided to test them. (If anyone remembers at what version of Asterisk the terminology changed from Native/Packet2Packet to Remote/Local, let us know in the comments below. We're thinking it was around 1.6 but not totally sure.) Remote Bridge (Asterisk 11) / Native Bridge (older Asterisk versions) Media is sent directly between peers, and is not proxied by Asterisk. This results in the lowest latency and resource consumption, but requires experience to properly configure. Local Bridge (Asterisk 11) / Packet2Packet Bridge (older Asterisk versions) Media is proxied by Asterisk, but relatively efficiently. The RTP comes in to the RTP stack and goes directly out without manipulation. Here is an example of what RTP debug looks like:

Sent RTP P2P packet to 192.168.1.4:23276 (type 00, len 000160)
Sent RTP P2P packet to 192.168.1.5:10704 (type 00, len 000160)
Sent RTP P2P packet to 192.168.1.4:23276 (type 00, len 000160)
Sent RTP P2P packet to 192.168.1.5:10704 (type 00, len 000160)

With our specific equipment, this added 18ms of latency compared to a Remote Bridge. "Core" Media is proxied by Asterisk, and is processed in some way. Here is an example of what RTP debug looks like:

Sent RTP packet to      192.168.1.4:23276 (type 00, seq 017330, ts 4158583200, len 000160)
Got  RTP packet from    192.168.1.4:23276 (type 00, seq 055242, ts 3137014754, len 000160)
Sent RTP packet to      192.168.1.5:33884 (type 00, seq 059960, ts 3137014752, len 000160)
Got  RTP packet from    192.168.1.5:33884 (type 00, seq 017691, ts 4158583363, len 000160)

When we configured Asterisk to listen for RFC2833 DTMF, 40ms of latency was added when compared to a Remote Bridge. It is important to note that these types of bridges will not always add exactly 18ms and 40ms of latency. These results are based on our specific configuration with our specific equipment. The point of the tests is that in terms of latency, Remote Bridge < Local Bridge < Core. To reiterate, the relative difference between Remote Bridge and Core is relatively small, but if the requirements of your project make it possible for your audio to be routed efficiently, go for it.