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 2×10 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:


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


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):


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


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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

10 Responses to “Computing VoIP traffic bandwidth consumption”

  1. Ouajih OUAJA says:

    hello everyone

    The maestro is back !

  2. [...] Here is the original post: Computing VoIP traffic bandwidth consumption [...]

  3. Ali says:

    Hi Petr,

    Strange this article comes on a morning on which I am grappling with a LAN QoS implementation for VOIP.

    We have been marking G711 packets as EF on the network access, and then across all of the WAN [made up of ethernet circuits] we have simply made sure [all Cisco 3750's] that ethernet WAN interfaces are configured with priority queue out.

    I had a tough time first understanding myself and then explaining to others that we cannot police the priority queue on a 3750. Queue 1 is simply removed from any SRR [shaped or shared] calculations, and the priority queue will be emptied BEFORE any other queue regardless of how much bandwidth is being is demanded/hogged by queue 1.

    Dont know if that is what you meant by “Usually you don’t use CBWFQ/LLQ on fast connections to guarantee bandwidth to VoIP traffic.”

  4. To: Ali

    I should have been more specific in my text and mention that i’m talking about LLQ implemented on small to mid. routers suchs as 38xx, 28xx etc. Commonly, these have hard time feeling a 100Mbps up to the link capacity without exhausting their CPU limits first.

    Catalyst switches is different story though. Switches can easily pump gigabits of traffic thanks to their distributed ASIC based switching architecture. This is why you care for configuring Priority Queue for VoIP traffic on Ethernet ports.

  5. Jeff says:


    Should we fail to remember these numbers during the lab exam, is there anywhere in the Cisco online documentation to reference the varying Layer 2 overhead figures?


  6. Scott Mc says:

    Just wanted to thank you for the info.
    Great write a blog.

  7. Bilbo says:

    It’s still unclear for me. What does the green color really mean.

    Why do you add full 7 bytes if IOS counts only 4 (as I understand it 67 byte fram-relay frame is seen by the scheduler as 64 byte one) ?

    The task is to provide enough priority bandwidth in LLQ for one call – who cares how much bandwidth is left for other queues.

  8. Imran Malik says:

    Impressive piece of information, let me elaborate more on VoIP. Voice over Internet Protocol has been around since many years. But due to lack of sufficient and affordable bandwidth it was not possible to carry carrier grade voice over Internet Protocol. But since the arrival of low cost internet bandwidth and new speech codecs such as G.729, G.723 which utilizes very low payload to carry carrier class voice it has recently been possible to leverage the true benefits of VoIP. G.723 codec utilizes only 6 Kbps (Kilo Bytes/sec) which is capable of maintaining a constant stream of data between peers and deliver carrier grade voice quality. Lets put this way if you have 8 Mbps internet connection, by using G.723 codec you can run upto 100 telephone lines with crystal clear and carrier grade voice quality. I am also a user of VoIP and have setup a small PBX at home. Since I have discovered VoIP I have never used traditional PSTN service.

    Dear readers, if you have not yet tried VoIP I suggest that you try VoIP technology and I bet you will never want to use the traditional PSTN phone service ever again. VoIP has far more superior features to offer which traditional PSTN sadly cannot offer.

    Also It has recently been possile to carry Video alongwith VoIP by using low payload video codecs. I cannot resist to tell you that by using T.38 passthrough and disabling VAD VoIP can carry FAX transmission, but beaware FAX T.38 passthrough will only work when using wide band protocols such as G.711, a-Law and u-Law.

    By using ATA (Analog Telephone Adapter) which converts VoIP signals into traditional PSTN you can also using Dial-up modems to connect to various dialup services. I wont go in to the details what VoIP can offer, to cut my story short VoIP is a must to have product for every business and individual.

    How VoIP Works

    When we make a VoIP call, a communication channel is established between caller and called party over IP (Internet Protocol) which runs on top of computer data networks. A telephony conversation that takes place over VoIP are converted into binary data packets streams in real time and transmitted over data network, when these data packets arrive at the destination these are again converted into standard telephony conversation. This whole process of voice conversion into data, transmission and data conversion into back voice conversation takes place within less than few milliseconds. That is how a VoIP is call is transmitted over data networks. I hope that now you understand basics of how a VoIP call takes place.

    What are speech codec’s and what role codec plays in VoIP?

    Speech codec play a vital role in VoIP and codec determines the quality and cost of the call. Let me explain you what exactly VoIP codec’s are and how they work. You may have heard about data compression, or probably you have heard about air compressor which compresses a volume of air in enclosed container, VoIP codec’s are no different than a air compressor. Speech codec’s compresses voice into data packets and decompresses it upon arrival at destination. Some VoIP codec’s can compress huge amount of voice while maintaining QoS which means use this type of codec will cost less because it will consume just a fraction of data network. Some codec’s are just not capable of encoding huge amount of voice they simply consume huge amount of data networks bandwidth hence the cost goes up.

    Following is a list of VoIP codec’s along with how much data network bandwidth they consume.

    * AMR Codec
    * BroadVoice Codec 16Kbps narrowband, and 32Kbps wideband
    * GIPS Family – 13.3 Kbps and up
    * GSM – 13 Kbps (full rate), 20ms frame size
    * iLBC – 15Kbps,20ms frame size: 13.3 Kbps, 30ms frame size
    * ITU G.711 – 64 Kbps, sample-based Also known as alaw/ulaw
    * ITU G.722 – 48/56/64 Kbps ADPCM 7Khz audio bandwidth
    * ITU G.722.1 – 24/32 Kbps 7Khz audio bandwidth (based on Polycom’s SIREN codec)
    * ITU G.722.1C – 32 Kbps, a Polycom extension, 14Khz audio bandwidth
    * ITU G.722.2 – 6.6Kbps to 23.85Kbps. Also known as AMR-WB. CELP 7Khz audio bandwidth
    * ITU G.723.1 – 5.3/6.3 Kbps, 30ms frame size
    * ITU G.726 – 16/24/32/40 Kbps
    * ITU G.728 – 16 Kbps
    * ITU G.729 – 8 Kbps, 10ms frame size
    * Speex – 2.15 to 44.2 Kbps
    * LPC10 – 2.5 Kbps
    * DoD CELP – 4.8 Kbps

    Switch to VoIP Today and you will never want to use traditional PSTN ever again.



  9. [...] Brassil, J.; McGeer, R.; Sharma, P.; Yalagandula, P.; Mark, B.L.; Zhang, S.; Schwab, S. [3] Voice Bandwidth Consumption, INE Blog [4] Circuit Switching in the Internet, Pablo Molinero Fernandez [5] RFC 3945 Tags: bandwidth, [...]

  10. [...] quality VOIP call ,which used to be the measuring stick for decent Internet service runs about 54kbs.  A quality  HD video  stream  can easily consume about 40 times that [...]


Leave a Reply


CCIE Bloggers