If you’re preparing for a your CCIE Written or Lab exams, or (far more importantly) if you need to perform bandwidth sizing for a VoIP design or implementation, it’s critical to be able to accurately calculate the amount of bandwidth that your precious voice streams are going to need as they traverses your network.
Vik Mahli makes an excellent overview of what this means in terms of a QoS configuration here, but skips the calculation part altogether in order to focus on the LAN QoS config that he wished to cover in his post. Naturally, this created some confusion which was carried over into the comments section!
I encourage you to read the comments, specifically Mark Holloway’s length post on this topic. Mark makes an excellent reference here to the QoS SRND, and is well worth a read! Please see this link and refer to where Mark and Vik use a 93bkps base for G.711 calls from.
Building on some of the discussions there, I’d like to provide some additional detail on how these calculations can be performed in this post.
Finally, please take note that this does not account for signalling bandwidth requirements. This is a different discussion – ping me and I’ll blog about this too! 🙂
Performing VoIP Bandwidth Calculations
Calculation Assumptions
Firstly, we will have to make some protocol-related assumptions for sizing purposes:
- IP – 20 bytes
- User Datagram Protocol (UDP) – 8 bytes
- Real-Time Transport Protocol (RTP) – 12 bytes
- Compressed Real-Time Protocol (cRTP) reduces the IP/UDP/RTP headers to 2 or 4 bytes
- Multilink Point-to-Point Protocol (MP) – 6 bytes
- Frame Relay Forum (FRF).12 Layer 2 (L2)– 6 bytes
- End-of-frame flag on MP and Frame Relay frames – 1 byte
- Ethernet L2 headers– 18 bytes
Codec-Specific Information
Secondly, we need to know some values that are codec-specific:
- Voice Payload Size
- Codec Bitrate
Some values worth keeping in mind here are:
- G711
- Bit Rate – 64 kbps
- Default Payload size – 160 bytes
- G729
- Bit Rate – 8 kbps
- Default Payload size – 20 bytes
- iLBC 20ms
- Bit Rate – 15.2 kbps
- Default Payload size – 38 bytes
- iLBC 30ms
- Bit Rate – 13.33 kbps
- Default Payload size – 50 bytes
There is a detailed discussion of these values and their explanations here. I won’t go into more detail in this post. Please refer to the above document for clarity.
NOTE:
For differing Millesecond Packet Sizes (e.g. G.729 20ms/30ms), the codec bitrate is always constant. Therefore the payload size can always be scaled as a ratio using the formula of:
codec bit rate = codec sample size / codec sample interval
More on this later in a worked example…
Bandwidth Calculation Formulas
From the TAC Online Help, we’re presented with a fairly simple calculation:
Total Packet Size = (Media Access Header - Layer 2) + (IP/UDP/RTP Header) + (voice payload) Voice Packets Per Second (PPS) = codec bit rate / voice payload size Bandwidth = [ (voice packet size) + 1 byte (frame flag) ] * PPS
Finally, it is best practice to allow for a 5.0% overhead in all calculations.
Some Worked Examples
This seems simple enough, so let’s put it into practice in some worked examples!
Example 1 : 3 Concurrent G.711 Calls over Ethernet
Total Packet Size = [ (18) + (40) + (160) ] = 218 bytes
Packets per Second = [ 64 kbps * 1000 bits per kilobit ] / [ 160 bytes (default voice payload) * 8 bits per byte ] = 50 pps
Bandwidth = [ ( 218 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 87.2 kbps
5.0% Overhead = 87.2 kbps * 1.05 = 91.560 kbps
Concurrent Calls = 3 * 91.560 kbps = 274.68 kbps
Example 2 : 5 Concurrent G.729 Calls over PPP with Compressed RTP
Total Packet Size = [ (6) + (2) + (20) ] = 28 bytes
Packets per Second = [ 8 kbps * 1000 bits per kilobit ] / [ 20 bytes (default voice payload) * 8 bits per byte ] = 50 pps
Bandwidth = [ ( 28 bytes ) + (1 byte) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 11.6 kbps
5.0% Overhead = 11.6 kbps * 1.05 = 12.18 kbps
Concurrent Calls = 5 * 12.18 kbps = 60.9 kbps
Example 3 : 10 Concurrent iLBC Calls over Ethernet using a 20ms bitrate
Total Packet Size = [ (18) + (40) + (38) ] = 96 bytes
Packets per Second =[ 15.2 kbps * 1000 bits per kilobit ] / [ 38 bytes (default voice payload) * 8 bits per byte ] = 50 pps
Bandwidth = [ ( 96 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 38400 bits/sec = 38.4 kbps
5.0% Overhead = 38.4 kbps * 1.05 = 40.32 kbps
Concurrent Calls = 10 * 40.32 kbps = 403.20 kbps
The TAC Tool does not cover iLBC calculations, but we can see that there’s nothing special going on here. We just needed to know the bitrate values for the codec and the calculations are effectively the same.
Example 4 : 5 Concurrent iLBC Calls over Ethernet using a 30ms bitrate
Total Packet Size = [ (18) + (40) + (50) ] = 108 bytes
Packets per Second =[ 13.3 kbps * 1000 bits per kilobit ] / [ 50 bytes (default voice payload) * 8 bits per byte ] = 33.3 pps
Bandwidth = [ ( 108 bytes ) + (0 bytes ) ] * 33.3 pps * 8 bites/byte = 28800 bits/sec = 28.8 kbps
5.0% Overhead = 28.8 kbps * 1.05 = 30.24 kbps
Concurrent Calls = 5 * 30.24 kbps = 151.20 kbps
Example 5 : 2 Concurrent G.729 Calls over Ethernet using a 40ms bitrate
OK, let’s end it off with a challenge 🙂
As I said above, the bitrate is always a constant for any codec:
codec bit rate = codec sample size / codec sample interval
Therefore, we will need to calculate our new Payload Sample Size for 40ms instead of 20ms:
Codec Sample Size = 8 kbps * 40ms / (8bits/byte) = 40 bytes
See? Not so hard! If you’re following, you can actually see that you could have just used a ratio of:
New Payload Size = Old Payload Size * (New Sampling Interval / Old Sampling Interval)
OK, I digress. Now, carrying on as before:
Total Packet Size = [ (18) + (40) + (40) ] = 98 bytes
Packets per Second =[ 8 kbps * 1000 bits per kilobit ] / [ 40 bytes (default voice payload) * 8 bits per byte ] = 25 pps
Bandwidth = [ ( 98 bytes ) + (0 bytes ) ] * 25 pps * 8 bites/byte = 19600 bits/sec = 19.60 kbps
5.0% Overhead =19.60 kbps * 1.05 = 20.58 kbps
Concurrent Calls = 2 * 40.32 kbps = 41.16 kbps
As you can see, the payload size may have doubled, but the packet throughput has halved!
Example 6 : 8 Concurrent G.722 Calls over Ethernet using a 10ms bitrate
Building on the ideas presented in the previous example:
New Payload Size = 160 kbps * (10/20) = 80 kbps
Total Packet Size = [ (18) + (40) + (80) ] = 138 bytes
Packets per Second =[ 64 kbps * 1000 bits per kilobit ] / [ 80 bytes (default voice payload) * 8 bits per byte ] = 100 pps
Bandwidth = [ ( 138 bytes ) + (0 bytes ) ] * 100 pps * 8 bites/byte = 110400 bits/sec = 110,4 kbps
5.0% Overhead =110.40 kbp * 1.05 = 115.92 kbps
Concurrent Calls = 8 *115.92 kbps = 927,36 kbps
OK, at this point not much more to cover! 🙂
A Final Note on Sampling Rates…
I highlighted the PPS value in Example 5 in red to make a final point on this topic.
As you can see, the payload size may have doubled, but the packet throughput has halved.
Where does all of this come into play? Well, there are two competing considerations here:
- Longer Durations (i.e. a lower PPS value) reduces Network Overheads
- Increased Packet Sizes decreases the resiliency to Network Errors (such as packet loss)
Considerations such as physical hardware capabilities, link stability, available bandwidth, PBX feature sets (and don’t forget that of your Peering Partners!) etc. can all be considered when deciding on a preferred sampling rate for your VoIP network – a lot for the VoIP designer to think about when making decisions on what codecs (and respective capabilities) to support!
Online References
I have managed to find a number of excellent documents to help you.
For a detailed breakdown of how to perform these calculations:
A TAC tool, and simply the best out there with a nice GUI:
Configuring Bandwidth-based CAC for CUBE:
For quick and dirty calculations that don’t take into account network overheads:
Additional links to various sites that offer similar tools:
Hope this helps all you CCIE aspirants and VoIP network designers!
#dontcalltac
afterthenumber 
Nice blog thanks to shared this http://www.ipmomentum.com
LikeLiked by 1 person
Example 6 seems to have a “little” mistake:
in line 5.0% Overhead =19.60 kbps * 1.05 = 115.92 kbps – > should be 5.0% Overhead =110.40 kbps * 1.05 = 115.92 kbps
LikeLiked by 1 person
Thanks, fixed! Hope this was helpful.
LikeLike