Panoramisk / The VoIP druid 

Voice transport should always balance between real time and bandwidth consumption. When interconnecting two PBX in order to exchange more than one communication, it could be interesting to limit bandwidth consumption by carrying more voice samples in the same IP frame. This is what the Asterisk Inter Exchange protocol (aka IAX) is doing and gains are real.

Usually codec’s output is carrying 20 ms of voice. This value is efficient enough to allow a low jitter and low delay during transport. Depending on the codec used those 20 ms of sound represent a variable size to transport in the IP frame (generally using UDP and RTP). Since we can potentially transport more than one voice sample in an IP frame we can make some savings.

On one hand, using a G.711 codec at 64Kbps, each 20 ms chunk represents 160 bytes of data. On the other hand, each standard voice frame using UDP and RTP is about 40 bytes long (IP + UDP + RTP) and with IAX it represents also a 40 bytes header. The waste ratio between transported interesting data (160 bytes) and the whole IP frame¹ (200 bytes) is around 20% which is high when repeated every 20 ms.

The more samples we can transport in the same IP frame, the less waste we have: 11% with 2 samples, 6% with 4 and 5% with 5 samples. But putting too much samples in the same IP frame increase the delay between each frames and can increase the jitter².

In IAX, that is mainly used to interconnect Asterisk PBX³ the approach is a bit different: each frame is sent at regular interval and carry the amount of data arriving from the codec during this delay. On our test platform, when using G.711 law A on the trunk, frames are sent every 100 ms (average) and frame size for one conversation is either 870 or 1034 bytes. When using GSM codec, frames are still sent every 100ms but size is between 230 and 270 bytes. The IAX trunk is obviously carrying more than one sample per IP frame, limiting the header impact down to the 5% stated previously.

But the main point is that IAX can multiplex inside the same IP frame multiple conversation. Asterisk still keep its delay between frames but, since more information are available, the IAX payload is bigger. For example, using G.711 with a second call on the same trunk the frame size is now bigger than my Ethernet MTU. Thus IP frames are fragmented on the network, which is not so good in some situation where fragments are not authorised. But the header loss ratio is becoming very good⁴: down to 3% with only 2 conversations on the same trunk.

IAX is really a good choice when dealing with Asterisk PBX interconnection, it is wasting less bandwidth, still limiting the delay and pass very easily firewalls. Why not using it more for multisite installation? The only issue is that IAX trunk is requiring an accurate clock (ie voice card or ztdummy), but this is not a big deal.

1. we don’t take into account the layer 2 part which exists anyway [↩]
2. each frame arriving late is impacting more samples [↩]
3. its main purpose [↩]
4. even with the IP fragmented part [↩]