- A TechNote on Unified Communications
- Gary Audin, Delphi, Inc.
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:
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:
See http://www.ansapoint.com/calculator/erlb/ 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:
The 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.
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 http://www.ansapoint.com/calculator/erlb/ 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)
The 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.
Comment:
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?