Ever since the dawn of the PBX, businesses have had to calculate their estimated telephone usage in order to properly size the number of trunks coming into and out of the building. In the case of TDM, you ended up with the number of physical trunks. This would equate to the required number of analog circuits or digital T1’s.
With SIP you are more concerned with bandwidth. Of course, bandwidth has to be delivered on something, but VoIP gives you far more flexibility in that regard. When a T1 is used for TDM trunks, the maximum number of calls is limited to the number of DS0 circuits. Since one T1 has 24 DS0s then 24 is the maximum number of TDM calls on a T1. However, turn that T1 into data and those DS0s are not the deciding factor. Depending upon the codec used, 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.
Now, there are many people who 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 pre-packaged tool like the ones found here:
Now, if you clicked on any of the calculators in the link above (Erlang B being the most appropriate for this activity) you will have noticed two things that I haven’t talked about. 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 all duration (s) * Calls per hour / 3600
For example, if you know that 350 calls are made on a trunk group, and the average duration is 180 seconds, the BHT will be:
BHT = 180 * 350 / 3600 = 17.5 Erlangs
The second thing the Erlang B calculator wanted was Blocking. Blocking is the failure of calls due to an insufficient number of lines being available. For example, a Blocking of 0.03 indicates 3 calls blocked per 100 calls attempted. These blocked calls result in a busy signal or re-order tone.
The end result of 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 it one more step. We need to convert that number of trunks, or simultaneous calls, into bandwidth.
The first thing you need to consider when calculating bandwidth is what codec do you intend to use and what are the characteristics of that codec. When I say characteristics I am referring to things 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 will lead to voice payload sizes of 160 bytes, 240 bytes, and 320 bytes, respectively. That ultimately leads to RTP data rates of 88 Kbps, 80 Kbps, and 76 Kbps.
The next most common codec for SIP trunks would be G.729a and it has the same sorts of sample size and voice payload variants leading to data streams of 32 Kbps, 22 Kbps, and 20 Kbps.
However, for nearly everyone, 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 * 90 = 18,900 Kbps or an approximately 19 Meg data pipe. I’ve seen folks add an additional 20% on for traffic variation, traffic collisions, and Ethernet re-transmission. This will push our pipe up to about 22 Meg.
Using the same number of trunks plus the fudge factor, we come up with an 8 Meg pipe for G.729a. Clearly, switching to G.729a brings along a significant bandwidth savings.
There are a number of prepackaged bandwidth charts out there that greatly simplify the process. However, I wanted you to understand the reasoning behind their numbers. Some may be higher or lower than the numbers you come up with my values, but that’s fine. I err on the conservative side when it comes to traffic management while others are less so. Take a look at what you can find, though, and determine what’s best for you and your enterprise.
As a follow-up to this article, please see my thoughts on Calculating Bandwidth for Video Calls.
Great overview of the calculation process.
One thing I always warn my customers against when doing these calculations is QoS. Its great thinking wow look how much more I can squeeze down a trunk when I use G.729. But for a number of customers, especially those in the contact centre space, compressed codecs aren’t an option. BTW that’s also where Erlang C comes in, to make sure you’ve also accommodated the queued calls and the other consideration is conferencing and supervisor monitoring in a contact centre – all of which influence the calculation requirements.
Depending on the media requirements of course some bandwidth can be saved, as a Contact Centre solution could make use of the SIP Response code “182 Queued”, requiring no media to queue calls on the trunk, but requiring the device to provide some form of progress tones.
The other elements of the calculation – whilst much smaller on the bandwidth calculation – but all count when “squeezing every ounce out of your trunk” is the signalling components – SIP primarily and lets not forget RTCP. You may also need to take account of any “security” used such as TLS and SRTP overheads.
The other advice I always give it consider carefully the call profile before starting the calculation, as there may be calls you haven’t counted – like how many home/remote extensions and conference calls you need to accommodate.
Neill, you are absolutely right and I didn’t want to overwhelm folks with too much information. What I described was a non contact center setup. Contact centers come with a unique set of requirements. For instance, I generally engineer for simultaneous calls for all logged in agents. I also agree that G.729a may not be an option. However, when it comes to carrier SIP trunks I don’t account for TLS and SRTP since no carrier today supports them. Encryption is certainly a concern inside the network, but not between an enterprise and its SIP provider — at least not here in the United States.
Thank you again for reading my blog and adding your insightful comments! I hope you continue to stick around.
its nice to find some else thinking about the same problems!
[…] few weeks ago I wrote a blog on determining the bandwidth used by voice calls in Calculating Bandwidth for SIP Trunks. Now, while voice is an extremely important aspect of SIP communications, the beauty of SIP is […]
[…] lines to SIP Trunking. For more information on how to calculate the cost of a SIP trunk, see Andrew Prokop’s blog post on this […]