VoIP Blog

Mar 26

Written by: admin
3/26/2012 7:42 AM

Codec misunderstandings

I would like to share some of my thoughts about the "which is the best codec" topic.

We are receiving a lot of requests here at Mizutech regarding codec priority and low bandwidth usage.

As I see it, most  people have basic knowledge about codecs and they are aware about their raw payload, but most of them have little knowledge about the real bandwidth/quality and, overall, about how RTP really works. Most often people compare VoIP calls to regular phone calls and says. A more exact method is the MOS score where 5 means excellent, 4 means good (like a regular phone call), 3 means fair, 2 means poor and 1 means bad.

Let's see the most used codecs. Most people know something like the following:

  • G.723.1: 6.4 kbps MOS: 3.9 (Very good compression while keeping good call quality. Needs some CPU processing power)
  • G.729: 8 kbps MOS: 4.0    (Very good compression while keeping good call quality. Needs some CPU processing power)
  • GSM 06.10: 13 kbps MOS: 3.7 (Mediocre codec with low CPU requirement)
  • G711: 64 kbps MOS: 4.2 (PCMU and PCMA. Best quality narrow band codec –actually it is lossless, with highest bandwidth usage. Very low CPU processing required)
  • iLBC: 15.2 kbps MOS: 3.9 (Good compression, known as packet loss tolerant)
  • Wideband (Speex, Opus, G.722): 9 – 30 kbits, MOS above 4.3 (Audible better quality then the above narrow band codecs, but not supported to PSTN –landline/mobile- only for VoIP to VoIP calls)
  • Also there are some low quality codec’s that can fit into 1 kbits. (Rarely used because it is incompatible with all major network thus would require costly transcoding).
However, the above bandwidth usage listing is not relevant at all. You should always calculate with the real bandwidth usage.
These values were calculated only with the raw codec data in mind, but an RTP packet has the following components:
  • Ethernet header: 38 or 42 bytes
  • IP header: 20 bytes
  • UDP header: 12 bytes
  • RTP header: 8 bytes
  • codec payload: between 10 and 480 bytes (usually 20 byte for G729 with 2 frames/packet)
We also have to add RTCP which is around 2% of the total traffic.

The total overhead for one packet is around 83 bytes!
This is a very important factor many people seem to skip over.

Knowing this, it is obvious that the most important factor for the bandwidth usage is not the codec itself, but the packetization interval.

Let's see a real life example. I hear many times that "I would like to use G.723.1 instead of G.729 because it is a lower bandwidth codec".
Another important factor is that the most common (default) packetization for G.723.1 is 1 frame/packet and for G.729 is 2 frames/packet.
However, if we are using the same frame time for both (30 msec) then we get the following REAL bandwidth usage:
-G.723.1: 28.1 kbps
-G.729: 29.7 kbps

As you can see, the difference is only 5%.

Knowing the fact that G.729 has a little bit better quality (MOS: 4.0) than G.723.1 (MOS: 3.9) I think that there is not much reason for anybody to worry about this 5% bandwidth usage difference.
If you want to further lower the g.729 bandwidth usage, then just set the packet/frame to 6 which will result in 60 msec long packets (still unnoticeable, especially if your traffic is routed through the public internet). With this setting you will get 19.1 kbps for G.729 which means 67% lower bandwidth usage than it would be with G.723.1

Don't forget that in 99% of the cases the bandwidth size is not the true limitation, but the overall link quality (delay, jitter, packet loss).
This means that a user with a stable 100 kbps internet connection can have much better VoIP experience than a user with a 4000 kbps low quality internet (and unfortunately internet connections tend to have poor quality)

In this post I have analyzed only the bandwidth usage. For real word usage, you should always prioritize wideband codec (which can be used for IP to IP calls for the best call quality) and if wideband is not supported, the server or client should automatically failover to a narrowband codec.
For narrowband, if you have G.729, then I would recommend this codec for all conditions because it's high MOS score compared to good compression ratio. If you don't have G.729, then any other will do.

A perfect codec list configuration example (listed priority order):

  1. a wideband codec known to be supported by your peers (Opus, Speex or G.722 to get the best possible quality for IP to IP call)
  2. G.729 and/or G.723 (if you are using it over the internet to get a good quality/compression balance)
  3. G.711 (if you have a lot of bandwidth and also for compatibility reasons)
  4. GSM and/or iLBC (for compatibility reasons)

If you are building the  network/ VoIP infrastructure for an office then take special care for QoS. This is another confusing topic as there are a lot of marketing bullshit on the internet. The only most important thing here is your router ability to prioritize VoIP media (RTP) packets. This is very important if you share the same link between VoIP and other data (such as torrent and other heavy usage).  QoS mantra from your VoIP service provider doesn’t matter at all, nor your VoIP client setting. Just make sure to get a router that can do this job correctly by either automatically detecting RTP packets and increasing their priority or by manually specifying a higher priority port range that you will use for VoIP. The QoS scheduler is a tricky piece of software and rare routers does this correctly.

Conclusion:
-there is no such thing as "best" audio codec
-don't worry so much about the codec type
-if you are still worrying, then it is better if you play with the packetization rate instead of the codec type
-if you insist to have a single answer: use G.729 for PSTN and a wideband codec for IP to IP calls
-get a good quality QoS capable router for your office






Typical bandwidth requirements for VoIP?

Voice payload (G.729): 20 bytes
RTP header: 12 bytes
UDP header: 8 bytes
IP header: 20 bytes
Total bandwidth = 480 bits / 20 ms
Total bandwidth = 24,000 bps

If 80% of the calls are using g729 and the rest g711:

1 channel bandwidth: 40 kbits   = 13 GB / month
10 channel bandwidth: 400 kbits   = 130 GB / month
100 channel: 4 mbits = 1300 GB / month (1.3 TB)
1000 channel: 40 mbits = 13000 GB / month (13 TB)
10000 channel: 400 mbits = 130000 GB / month (130 TB)
If both the traffic sender and the termination devices are located on remote peers, then you have to multiply these values with 2X (especially if you are billed for both “in” and “out” traffic)

Note:
1.    These calculations are valid only if you have all the time X amount of traffic. This is usually not the case and you will also have off-peak times.
2.    These calculations are valid only if all your traffic needs RTP routing. Under normal circumstances you should be able to offload a lot of RTP routing from your server and enable the endpoints to communicate directly between them. This can be handled automatically by the Mizu VoIP server.

The bandwidth needed for g729 codec is around 32 kbits (this is the total bandwidth including RTP, UDP and Ethernet headers)
We assumed that not all calls will be handled by g729. Let's say around 20% is with g711. So let's calculate with 40 kbits in average.
This means 4 mbits/sec for 100 channels which is 0.5 MB/sec.
We have 60*60*24 seconds in a day and approximately 60*60*24*30 seconds in a months which is 2592000 seconds.
So we have 0.5 * 2592000 MB/month which is 1296000  MB which is 1296 GB/month for if you have 100 simultaneous calls in average.

Tags:

Your name:
Title:
Comment:
Add Comment    Cancel