Calculating Bandwidth for SIP Trunks

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:

http://www.erlang.com/calculator/

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.

Tags: SIP, Unified Communications, VoIP