How Much SIP Bandwidth Should You Buy?

Along with the proliferation of Session Initiation Protocol (SIP) trunking has come the burden on IT organizations of doing bandwidth calculations for their SIP trunks. They buy too much capacity, and money is wasted. Too little, and calls are blocked or abandoned, call-center agents become less productive, and the enterprise's reputation for service is at risk.

There is a two-step process for determining the required trunk capacity for incoming calls. The first step is ascertaining the grade of service (GoS) - the probability that someone making a voice or interactive voice response (IVR) call will get a busy signal. This step uses an Erlang B formula and calculation. The second step is to calculate the bandwidth required to support the number of SIP trunks/lines needed to carry incoming calls, as determined by the Erlang B calculations.

Erlang B Calculations for Incoming Calls

The Erlang B formula assumes that an unsuccessful call (e.g., the call is blocked, the caller gets a busy signal) is not queued or retried, but lost forever. The formula further assumes that any new call arrives independently of the time since the previous call.

The formula can be used to calculate any one of the following three factors if the other two factors are known or can be predicted:
  • Busy hour traffic (BHT): the number of hours of call traffic during the busiest hour of operation, also called the "Erlang load."
  • Blocking (busy signal GoS): the percentage of calls blocked because not enough lines are available.
  • Lines: the number of lines in a trunk group, with each line carrying one call at a time.

Designing for the busy hour - the heaviest traffic period of the day, and the one with the worst GoS - allows callers to experience call blocking at the enterprise's desired rate. Performance will be better for each hour outside the busy hour, as will overall GoS.
The first determination is largely a business issue: how often is it acceptable for the caller to get a busy signal? Most calculations start with a GoS of .01 (1 percent busy), which means that 99 percent of calls are answered; a GoS of .001 means that 99.9 percent of calls are answered. The design for IVR systems should have a very high probability - 99.9 percent or better - that the call won't be blocked.

Next, the traffic load must be either measured or estimated in Erlangs/BHT, where one Erlang is equivalent to one line busy for one hour. To calculate the Erlang load, the trunk designer determines the average length of a call in minutes, plus the number of calls expected during the busiest hour of the day.

The Erlang load (BHT) = CAR X H/60, where:
  • CAR, the call arrival rate, is the number of calls during the busy hour
  • The average call length or holding (H) time is measured in minutes

See for a useful Erlang B calculator.

Outbound Trunks

The number of outbound voice calls is the same as the maximum number of agents on duty at one time. Assuming a predictive dialer is in use, total call length (including call setup, dialing and phone answering) is about 7 to 15 seconds longer than the conversation itself and should be taken into account. However, if outbound calls come from a "robo-calling" system, the enterprise needs to determine the number of simultaneous calls that must be completed. In neither case does the outbound channel calculation use the Erlang calculations. Per-call bandwidth requirements are the same for outbound and inbound calls.

VoIP Bandwidth

The amount of bandwidth to be allocated per call depends on:
  • Packet size for voice (20ms or 30ms of speech)
  • Codec/compression technique (G.711, G.729, G.723.1, etc.)
  • Header compression (Real-time Transport Protocol/RTP + User Datagram Protocol/UDP + IP), which is optional
  • Layer 2 protocol (Point-to-Point Protocol/PPP, Multiprotocol Label Switching/MPLS, frame relay)

UCTN-3-13-Table.jpgThe SIP trunk provider should provide customers with a table like the one shown for calculating the bandwidth requirements. (The provider's bandwidth requirements may be greater.) A good rule of thumb is to reserve at least 27Kbps of SIP trunk bandwidth per call for 8Kbps G.729 compressed voice. If G.711 is used, reserve at least 83Kbps of bandwidth per call. Many IP trunk providers recommend that 20 percent additional bandwidth be available to cover signaling, control and administrative traffic.

Designers are advised not to calculate the required number of trunks with the minimum number in mind, but rather to round up to a larger number of trunks. Traffic estimates are just that - estimates - and it's always better to increase bandwidth than cut corners and have dissatisfied callers.

Email and Social Media Links: Share securely via email |  |



As a person normally only half of the time during a voice call is speaking (and half the time is listening), the calculation would result in a reduced required bandwidth.
Does anybody has information about this effect?

This is true. About as much as 70% of a phone is silence. To reduce bandwidth, the SIP implementer COULD turn on silence suppression also called voice activity detection. It is generally not a good idea to use silence suppression. Cisco recommends that silence suppression should only be used when there are at least 24 or more channels implemented. Even then you can only expect about a 30% reduction in bandwidth. Silence suppression should not be used when the channels could be carrying music on hold, fax transmissions or modem transmissions. Most SIP trunk providers discourage the use of silence suppression as it can intermittently cause voice quality interference and a reduced MOS.


Voice Activity Detection (VAD) is an optional feature of some vocoders, including G.729a. It has the ability to save bandwidth under certain conditions, but with some side effects on overall voice quality.


"The ITU has defined a VAD standard, called G.729B, which only works with G.729 and G.729a (8k) compression. The ITU implementation is optimized for G.729 and G.729a and it also reduces the cumulative delay of G.729 and G.729a and VAD by doing the voice compression and VAD processing in parallel. According to a paper published in the IEEE Communications magazine, the Mean Opinion Score (MOS) scores of G.729B are comparable to the non-VAD G.729 and G.729a case. The G.729B also has the benefit of being an ITU standard.

"As with many bandwidth conservation mechanisms, VAD and comfort noise have trade-offs. In particular, artifacts such as clipping of soft voice segments, loud (or artificial) comfort noise (hissing) and additional delay might be experienced. If the device combination or the background noise characteristics for certain calls cause comfort noise to be annoying, then the only fool-proof way to currently avoid this problem is to disable it. Usually, disabling comfort noise also necessitates disabling VAD."

Join the Webtorials Community
Subscription Maintenance

Featured Sponsors

Recent Comments

Webtorials TechNotes

Featured Analysts

Gary Audin, Delphi, Inc.

Michael Finneran, dBrn Associates

William A. Flanagan, Flanagan Consulting

Douglas Jarrett, Keller and Heckman LLP

Jim Metzler, Ashton, Metzler & Associates

Lisa Phifer, Core Competence

Dave Powell, Independent Technical Writer

David Rohde, TechCaliber Consulting LLC

Steven Taylor, Distributed Networking Associates, Inc.

Joanie Wexler, Technology Analyst/Editor


Steven Taylor

TechNotes is a special program of Webtorials and Distributed Networking Associates, Inc.


Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Please encourage colleagues to download their own copy after registering at  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2013, Distributed Networking Associates, Inc.