Bandwidth issues

One of the main criticisms of VoIP is the amount of bandwidth required for each
conversation, and the knockers are sometimes quite justified to pick on this poi
nt. Not only must there be adequate bandwidth, the quality of the link must be m
aintained throughout each call to ensure the users are not affected. At the end
of the day if a user is transferring a 3GB file from a workstation to a server,
they will not really notice if it takes eight seconds longer one time than the l
ast time due to network traffic impacting on the transfer time; it is all transp
arent and handled in the very nature of the TCP transmissions. However the same
problem with a VoIP call would definitely be noticeable and unacceptable to the
participants of that call because it is real-time. And real-time is the key. Whi
le VoIP may use TCP packets to set up and establish the call parameters, it most
ly uses UDP packets to send/receive the voice traffic. Ensure that your firewall
supports forwarding of UDP traffic. The two issues here are bandwidth and quali
ty of service (QOS).
While bandwidth is now abundant and cheap, particularly on a local area network
(LAN), moving what could potentially be large continuous amounts of data without
interruption from one point to another within a given period of time may not be
easy, especially over a wide area network (WAN) link. The average PSTN call run
s at 64Kbps. That 64Kbps channel needs to be open and unaffected for the duratio
n of the call. Naturally, not many VoIP installations could afford that type of
sustained traffic on the network, particularly large deployments; therefore the
dreaded technology C-word must be used: "compression".
Of course, with compression comes loss of audio quality, say the knockers. The m
ost commonly standard used with VoIP is H.323, which incorporates the G.723 code
c. This can take a 64Kbps stream of data and squash it down to a mere 5.5Kbps or
so. Before you get too excited, you also need to take into account the overhead
s that it takes to transmit that data, and in some situations these could be qui
te high. For VoIP to work effectively over WAN links, there needs to be low jitt
er, low packet loss, a relatively high-speed connection between the endpoints, a
nd less than 200ms delay.
Long pauses, unexpected dropouts, or any other strange phenomena not usually ass
ociated with land line telephone calls are unacceptable in a VoIP deployment. Th
e service has to be as good as normal landline telephone services. Jitter buffer
s in the technology help to reduce the effect that jitter can have on the connec
tion, but ultimately the connection is only as healthy as the network it is runn
ing over.
This takes us back to the compression protocols -- surely if something is remove
d through the compression then the quality can't be the same. Interestingly, whe
re the most savings come in the G.723.1 standard are in the pauses between words
. Believe it or not, up to 50 percent of a telephone conversation is silence. Pl
ease don't even mention music on hold; most vendors have some very interesting w
ays of dealing with it.
However, when the data is decompressed at the other end, if silence was inserted
between the gaps it would sound odd because usually there is some background no
ise or even the usual reassuring line noise. Various developers deal with the si
tuation in different ways. Some introduce a "generated" hiss or line noise, so t
hat the user of the system does not think that the line has dropped every time t
he speaker pauses for breath. Another solution is to randomly sample some backgr
ound noise from each end of the phone conversation link and inject that back int
o the blank gaps in the conversation.
One of the most important factors to consider when you build packet voice networ
ks is proper capacity planning. Within capacity planning, bandwidth calculation
is an important factor to consider when designing and troubleshooting packet voi
ce networks for good voice quality.
Voice Activity Detection
With circuit-switched voice networks, all voice calls use 64 Kbps fixed-bandwidt
h links regardless of how much of the conversation is speech and how much is sil
ence. With VoIP networks, all conversation and silence is packetized. Using Voic
e Activity Detection (VAD), packets of silence can be suppressed.
Over time and as an average on a volume of more than 24 calls, VAD may provide u
p to a 35 percent bandwidth savings. The savings are not realized on every indiv
idual voice call, or on any specific point measurement. For the purposes of netw
ork design and bandwidth engineering, VAD should not be taken into account, espe
cially on links that carry fewer than 24 voice calls simultaneously. Various fea
tures such as music on hold and fax render VAD ineffective. When the network is
engineered for the full voice call bandwidth, all savings provided by VAD are av
ailable to data applications.
VAD also provides Comfort Noise Generation (CNG). Because you can mistake silenc
e for a disconnected call, CNG provides locally generated white noise so the cal
l appears normally connected to both parties. G.729 Annex-B and G.723.1 Annex-A
include an integrated VAD function, but otherwise performs the same as G.729 and
G.723.1, respectively.
Audio CODECs
Voice channels occupy 64 Kbps using PCM (pulse code modulation) coding when carr
ied over T1/E1 links. Applications such as VoIP are not always used over links w
ith bandwidth of 64Kbps or higher. Thus, to allow for a smooth operation of VoIP
applications over links with low bandwidth, compression techniques were develop
ed allowing a reduction in the required bandwidth while preserving voice quality
. Such techniques are implemented as CODECs
Codecs are software drivers that are used to encode the speech in a compact enou
gh form that they can be sent in real time across the Internet using the bandwid
th available. Codecs are not something that Voip users normally need to worry ab
out, as the Voip clients at each end of the connection negotiate between them wh
ich one to use.
Voip software or hardware may give you the option to specify the codecs you pref
er to use. This allows you to make a choice between voice quality and network ba
ndwidth usage, which might be necessary if you want to allow multiple simultaneo
us calls to be held using an ordinary broadband connection. Your selection is un
likely to make any noticeable difference when talking to PSTN users, because the
lowest bandwidth part of the connection will always limit the quality achievabl
e, but Voip-to-Voip calls using a broadband Internet connection are capable of d
elivering much better quality than the plain old telephone system.
Different compression techniques can be compared using the following parameters:
Compressed voice rate - the CODEC compresses voice from 64 Kbps down to a certai
n bit rate. Some network designs have a big preference for low-bit-rate CODECs.
Most CODECs can accommodate different target compression rates such as 8, 6.4 an
d even 5.3 Kbps. Note that this bit rate is for audio only. When transmitting pa
cketized voice over the network, protocol overhead (such as RTP/UDP/IP/Ethernet)
is added on top of this bit rate, resulting in a higher actual data rate.
Complexity - the higher the complexity of implementing the CODEC, the more CPU r
esources are required.
Voice quality - compressing voice in some CODECs results in very good voice qual
ity, while others cause a significant degradation.
Digitizing delay - Each algorithm requires that different amounts of speech be b
uffered prior to the compression. This delay adds to the overall end-to-end dela
y. A network with excessive end-to-end delay, often causes people to revert to a
half-duplex conversation ("How are you today? over?") instead of the normal ful
l-duplex phone call.
The table below lists some commonly used codecs.
Codec Algorithm Bit rate
(Kbit/s) Bandwidth
(Kbit/s)
G.711 Pulse Code Modulation (PCM) 64 87.2
G.722 Adaptive Pulse Code Modulation (ADPCM) 48 66.8
G.726 Adaptive Differential Pulse Code Modulation (ADPCM) 32 55.2
G.728 Low-Delay Code Excited Linear Predication (LD-CELP) 16 31.5
iLBC Internet Low Bitrate Coded (ILBC) 15 27.7
GSM Regular Pulse Excited (RPE) 13 30.1
G.729a Conjugate Structure Algebraic-Code Excited Linear Prediction (CS-CELP)
8 31.2
G.723.1a MP-MLQ 6.4 21.9
G.723.1 ACELP 5.3 20.8

The following table compares popular CODECs according to above given parameters:
Compression scheme Compressed rate (Kbps) Required CPU resources Resultan
t Voice Quality Added Delay
G.711 PCM 64 (no compression) Non required Excellent N/A
G.723 MP-MLQ 6.4/5.3 Moderate Good (6.4)
Fair (5.3) High
G.726 ADPCM 40/32/24 Low Good (40)
Fair (24) Very low
G.728 LD-CELP 16 Very high Good Low
G.729 CS-ACELP 8 High Good Low
The bandwidth gives an indication of how much of the capacity of your broadband
Internet connection will be consumed by each Voip call. The bandwidth usage is n
ot directly proportional to the bit rate, and will depend on factors such as the
protocol used. Each chunk of voice data is contained within a UDP packet with h
eaders and other information. This adds a network overhead of some 15 - 25Kbit/s
, more than doubling the bandwidth used in some cases. However, most Voip implem
entations use silence detection, so that no data at all is transmitted when noth
ing is being said.
Insufficient bandwidth can result in interruptions to the audio if Voip uses the
same Internet connection as other users who may be downloading files or listeni
ng to music. For this reason, it is desirable to enable the Quality of Service "
QoS" option in the TCP/IP Properties of any computer running a software Voip cli
ent, and to use a router with QoS support for your Internet connection. This wil
l ensure that your Voip traffic will be guaranteed a slice of the available band
width so that call quality does not suffer due to other heavy Internet usage.
RTP Header-Compression or Compressed RTP (cRTP)
All VoIP packets are made up of two components: voice samples and IP/UDP/RTP hea
ders. Although the voice samples are compressed by the Digital Signal Processor
(DSP) and may vary in size based on the codec used, these headers are a constant
40 bytes in length. When compared to the 20 bytes of voice samples in a default
G.729 call, these headers make up a considerable amount of overhead. Using cRTP
, these headers can be compressed to two or four bytes. This compression offers
significant VoIP bandwidth savings. For example, a default G.729 VoIP call consu
mes 24 Kb without cRTP, but only 12 Kb with cRTP enabled.
Because cRTP compresses VoIP calls on a link-by-link basis, both ends of the IP
link need to be configured for cRTP.