- Everything that is beautiful and noble is the product of reason and calculation.
-- Charles Baudelaire
Ever since the dawn of the PBX, businesses have had to calculate their estimated telephone usage in order to determine how many trunks they would need coming into and out of their buildings. In the case of TDM, these trunks were either analog circuits or digital T1s -- i.e., physical infrastructure.
With SIP, we are more concerned with bandwidth than physical trunks. Of course, bandwidth has to be delivered on something, but VoIP provides far more flexibility than traditional trunks. When using a T1 for a TDM trunk, the maximum number of calls is limited to the number of DS0 circuits within that T1. Since one T1 has 24 DS0s, then 24 is the maximum number of TDM calls on a T1. However, turn that T1 over to data, and the number of DS0s are no longer the deciding factor. Depending on the codec, you can have upwards of 40 VoIP calls on that same T1.
However, before you even think about bandwidth you need to determine how many simultaneous calls you need to support at any given point in time. This includes deciding how often you are willing to have a caller receive a busy signal or "all circuits are in use" tone. For that we turn to a 90-year-old telephony measurement called the Erlang -- named for the Danish mathematician Agner Krarup Erlang.
Do the Math
Some people thrive on calculating Erlangs by hand and, more specifically, running Erlang B and Erlang C calculations, but I am not one of them. I would much rather use a prepackaged tool like the ones found here.
If you clicked on any of the calculators in the above link (Erlang B being the most appropriate for this activity) you will have noticed two things that I haven't yet mentioned. The first is busy hour traffic (BHT). BHT is the call traffic during the busiest hour of operation. It's also called the Erlang load. BHT is calculated as follows:
BHT = average call duration(s) x calls per hour / 3600
For example, if you know that 350 calls are made on a trunk group in an hour, and the average call duration is 180 seconds, the BHT will be:
BHT = 180 x 350 / 3600 = 17.5 Erlangs
The second thing the Erlang B calculator asks for is blocking. Blocking is the failure of calls due to an insufficient number of available lines. For example, a blocking of 0.03 indicates three calls blocked per 100 calls attempted. These blocked calls result in a busy signal or re-order tone.
The result from the calculator is the number of trunks required to support your business at the particular grade of service (GoS) that you desire. If you are working with TDM, you can go out and order that number of analog or digital circuits and call it a day. However, with SIP we need to take one more step. We need to convert that number of trunks, or simultaneous calls, into bandwidth.
From Calls to Bandwidth
The first thing you need to consider when calculating bandwidth is the characteristics of the codec you intend to use. When I say "characteristics," I am referring to attributes such as sample size and voice payload.
For instance, G.711 may have sample sizes of 20 msec, 30 msec, or 40 msec. Those sample sizes lead to voice payload sizes of 160 bytes, 240 bytes, and 320 bytes, respectively. That ultimately leads to Real-Time Protocol data rates of 88 Kbps, 80 Kbps, and 76 Kbps.
The next most common codec for SIP trunks is G.729a, and it has the same sorts of sample size and voice payload variants. This leads us to data streams of 32 Kbps, 22 Kbps, and 20 Kbps.
For nearly every situation, it's safe to use 90 Kbps for G.711 and 32 Kbps for G.729a. Given that simplification, bandwidth calculations become fairly straightforward.
Let's say that we came up with 210 trunks from the Erlang B calculator, and you've chosen G.711 for your codec.
210 x 90 = 18,900 Kbps
This means you need a data pipe of approximately 19 Mbps to reliably support 210 simultaneous G.711 calls. I've commonly seen folks add an additional 20% of overhead (i.e., fudge factor) for traffic variation, traffic collisions, and Ethernet retransmission. This pushes our pipe up to about 22 Mbps.
Using the same number of trunks plus the fudge factor, we come up with an 8-Mbps pipe for G.729a. Clearly, switching to G.729a yields significant bandwidth savings.
Of course, factors such a voice quality come into play when choosing a codec, so you have to look at all the relevant pros and cons before committing to one codec over another. Saving money on bandwidth may not be worth customer complaints or speech recognition applications that no longer work. I have not factored in reliability and failover, which may necessitate two or more data pipes to ensure business continuity during a time of crisis.
Mischief Managed
You have your pick of a number of prepackaged bandwidth charts that can help greatly simplify the process. However, it's important to understand the reasoning behind their numbers. Some numbers may be slightly higher or lower than those you come up with using my calculations, but that's fine -- I err on the conservative side when it comes to traffic management. Take a look at what you can find, though, and determine what's best for you and your enterprise.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
Tags:
Articles You Might Like
