SIP Trunk BandWidth Calculation

9 Jun


Bandwidth as per Wikipedia is

A measurement of bit-rate of available or consumed data 
communication resources expressed in bits per second or 
multiples of it (bit/s, kbit/s, Mbit/s, Gbit/s, etc.). 
According to Hartley's law, the digital data rate limit 
(or channel capacity) of a physical communication link is 
proportional to its bandwidth in hertz.

Calculating the bandwidth requirement for a TDM network is easy. That is because they are based on either Multiplexing techniques like TDM,  Where each (Digital Signal) DS0 would correspond to one call, and depending on whether you are using T1 or E1 the number of simultaneous calls would be either 24 or 32 respectively. And at the end it boiled down to the number of connected circuits we have between two sites. However the same isn’t applicable for a SIP network when it comes to identifying Bandwidth, as there are no TDM or FDM techniques employed to send data. We’r going to use a century old telecom calculation technique called erlang. An erlang calculator can be found at Prior to determining the bandwidth requirement of a SIP network we’d need to

  1. Determine, maximum simultaneous calls we need to support at any given time.
  2. Busy Hour Traffic (BHT): BHT is the measure of the call traffic at the busiest operational hour. also known as erlang load the Calculation ofBHT = (Average Call Duration(s) * calls per hour )/ 3600
    For example if we have 4000 calls per hour, with an 
    average duration of 180 seconds then BHT would be 
    --> (360 x 180)/ 3600 = 200 Erlang
  3. Determining Blocking: Blocking is the measure of failure of call attempts due to insufficient available resources. (as per definition number of lines).
    For example, a Blocking of 0.05 indicates 5 calls 
    blocked per 100 calls attempted. These blocked 
    calls would hear a busy signal or re-order tone.

The resultant of feeding these numbers in the erlang calculator is the number of trunks required to support the number of calls we wanted at a certain desired Grade of Service. Now if we had been working with TDM, then our calculation would have been complete with this resultant number from the erlang calculator. But since we are dealing with IP telephony and SIP there are a few more steps to be taken. In the next steps we would be converting that number of trunks (which is also equal to the simultaneous calls had it been TDM) into bandwidth. Lets see how.. For doing that we need to identify what codecs we would use. Whether we would use g711, g729 etc. Each codec has its own set of characteristics, which could include the codec’s sampling size, payload type, tolerance etc.. A short comparative list of capabilities of various codecs Codec Bandwidth Sample period                     Frame size                   Frames/ packet                Ethernet Bandwidth G.711 (PCM)              64 kbps                         20 ms                                160 1 95.2 kbps G.723.1A (ACELP) 5.3 kbps                         30 ms                               20 1 26.1 kbps G.723.1A (MP-MLQ) 6.4 kbps                    30 ms                                24 1 27.2 kbps G.726 (ADPCM)      32 kbps                          20 ms                                80 1 63.2 kbps G.728 (LD-CELP)   16 kbps                           2.5 ms                               5 4 78.4 kbps G.729A (CS-CELP) 8 kbps                            10 ms                                10 2 39.2 kbps AMR (ACELP)          4.75 kbps                     20 ms                                12 1 36.0 kbps AMR (ACELP)          7.4 kbps                        20 ms                                19 1 38.8 kbps AMR (ACELP)          12.2 kbps                      20 ms                                31 1 43.6 kbps AMR-WB/G.722.2(ACELP)6.6 kbps       20 ms                                17 1 38.0 kbps Before moving ahead we would also need to know the following

Codec Bit Rate (Kbps) Based on the codec, this is the number of bits per second that need to be transmitted to deliver a voice call. (codec bit rate = codec sample size / codec sample interval).
Codec Sample Size (Bytes) Based on the codec, this is the number of bytes captured by the Digital Signal Processor (DSP) at each codec sample interval. For example, the G.729 coder operates on sample intervals of 10 ms, corresponding to 10 bytes (80 bits) per sample at a bit rate of 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
Codec Sample Interval (ms) sample interval at which the codec operates. For example, the G.729 coder operates on sample intervals of 10 ms, corresponding to 10 bytes (80 bits) per sample at a bit rate of 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
MOS MOS is a system of grading the voice quality of telephone connections. With MOS, a wide range of listeners judge the quality of a voice sample on a scale of one (bad) to five (excellent). The scores are averaged to provide the MOS for the codec.
Voice Payload Size (Bytes) The voice payload size represents the number of bytes (or bits) that are filled into a packet. The voice payload size must be a multiple of the codec sample size. For example, G.729 packets can use 10, 20, 30, 40, 50, or 60 bytes of voice payload size.
Voice Payload Size (ms) The voice payload size can also be represented in terms of the codec samples. For example,a G.729 voice payload size of 20 ms (two 10 ms codec samples) represents a voice payload of 20 bytes [ (20 bytes * 8) / (20 ms) = 8 Kbps ]
PPS PPS represents the number of packets that need to be transmitted every second in order to deliver the codec bit rate. For example, for a G.729 call with voice payload size per packet of 20 bytes (160 bits), 50 packets need to be transmitted every second [50 pps = (8 Kbps) / (160 bits per packet) ]

Ok, The theater is all set now. Let’s jump into some calculations Bandwidth Calculation Total packet size = (L2 header) + (IP/UDP/RTP header) + (voice payload size) PPS = (codec bit rate) / (voice payload size) Bandwidth = total packet size * PPS Sample Calculation For example, the required bandwidth for a G.729 call (8 Kbps codec bit rate) with the default 20 bytes of voice payload is: Total packet size (bytes) = (MP header of 6 bytes) + ( compressed IP/UDP/RTP header of 2 bytes) + (voice payload of 20 bytes) = 28 bytes Total packet size (bits) = (28 bytes) * 8 bits per byte = 224 bits PPS = (8 Kbps codec bit rate) / (160 bits) = 50 pps => Note: 160 bits = 20 bytes (default voice payload) * 8 bits per byte Bandwidth per call = voice packet size (224 bits) * 50 pps = 11.2 Kbps Now let’s say we would have received a number 200 From the the Erlang calculator, then the required bandwidth requirement scales up to (bandwidth per call * total number of trunks that are needed) = 11.2 * 200 = 2240 kbps. On top of that there would be some percentage of additional (in a factor of 20-25%) bandwidth would be considered to compensate for factors like network re-transmissions, variance and collision. Which would eventually lead us to a figure of 28000 Kbps = 2.8 MegaBytes per second. So the bandwidth requirement would be an approximate 3MBps. However since each codec offers an entirely different sampling size it would be possible to achieve the same call rate with the desired GOM. Hope I was able to do some justice to the topic. If there is any way in which this article can be improved, please let me know. Thanks for stopping by. References: the image was taken from Source:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: