Computing VoIP traffic bandwidth consumption

Computing voice bandwidth is usually required for scenarios where you provision LLQ queue based on the number of calls and VoIP codec used. You need to account for codec rate, Layer 3 overhead (IP, RTP and UDP headers) and Layer 2 overhead (Frame-Relay, Ethernet, HDLC etc. headers). Accounting for Layer 2 overhead is important, since the LLQ policer takes this overhead in account when enforcing maximum rate.

We are going to consider two codecs for bandwidth computation: G.729 and G.711. By default, both codecs generate 50 VoIP packets per second. However, the codec framing rate is 10ms (100 packets per second). Therefore, each VoIP packet carries two frames with VoIP samples. The frame sizes are 10 bytes and 80 bytes for G.729 and G.711 codecs respectively.

Based on this, G.729 generates [10*2]*50*8=8000bps and G.711 generates [80*2]*50*8=64000bps of “payload” rate – no Layer 3 or Layer 2 overheads.

RTP header size is 12 bytes and UDP header size is 8 bytes. Typical IP header (no options) is 20 bytes in lenght. Therefore, the Layer 3 overhead is 40 bytes, if we don’t use header compression.

The following are the formats for WAN frames commonly used to transport voice. Note that these formats remain the same with or without FRF.12/MLP fragmentation schemes, since voice packets are never fragmented with good design.

Highlighted in green are the portions of Layer 2 frames that Cisco IOS queue scheduler accounts for when computing actual frame size. Note that the scheduler does not account for full Layer 2 overhead, but you need to provision more bandwidth for LLQ so that other class may not be configured with too much bandwidth. As we can see, both Cisco and IETF Frame-Relay encapsulations add 7 bytes of Layer 2 overhead to VoIP packets. The same holds true for HDLC encapsulation (which is not very common but added here for sake of completeness). PPP over Frame-Relay adds 9 bytes of overhead – the maximum overhead of all presented encapsulation types.

Using the information above, you can compute bandwidth usage for uncompressed voice traffic flow across any WAN connection. For example, let’s compute bandwidth consumption for a G.729 call across Frame-Relay link with FRF.12 fragmentation. First, FRF.12 does not fragment voice packets if configured properly. Next, the size of payload + Layer 3 overhead is 2x10 bytes + 40 bytes = 60 bytes. Based on the 50 pps rate and adding the 7 bytes overhead we end up with the bandwidth value of:

(20+40+7)*50*8=26800bps.

If you want to use G.711 codec, then replace the 20 bytes payload with 160 bytes. The result is:

(160+40+7)*50*8=82800bps.

Another thing to consider is IP/RTP/UDP headers compression. Cisco’s implementation reduces the total overhead of 40 bytes (12+8+20) down to 2 bytes (no UDP checksum). This limits the Layer 3 overhead to just 2 bytes. Let’s compute the bandwidth usage for G.729 call over MLPoFR with UDP header compression (9 bytes of Layer 2 overhead):

(20+2+9)*50*8=12400bps.

The same computations for compressed G.729 over Frame-Relay with or without FRF.12 bring the following result:

(20+2+7)*50*8=11600bps.

Now a few words about running VoIP traffic across Ethernet. Usually you don’t use CBWFQ/LLQ on fast connections on small to mid.range routers to guarantee bandwidth to VoIP traffic. Most of these routers are not capable of sending traffic at such rate that they oversubscribe 100Mbs interface. However, you may occasionally use Ethernet as "WAN" connection using Class-Based Shaping for sub-rate access. So just in case, Layer 2 overhead for typical Ethernet frame is 18 bytes – 14 bytes for Ethernet header and 4 bytes for FCS (32 bits). If the frame carries VLAN tag, add another 4 bytes here for 22 bytes of total overhead. Note that you will typically see G.711 codec used over LAN links.