March 1, 2005
This should allow you to estimate the amount of network bandwidth required
between each location. Consider the following example:
- Scenario: A remote location has 50 users, and no more than 10 users are
expected to be on the phone at any one time. A gateway located on the central
site will be used for connection to the telephone network, and G.711 will
be used. The remote location is connected to the central site via IP VPN
and has a single T1 to access the IP network.
- Bandwidth requirements: 10xG.711 streams will require 10 x 96 kbits/s
of bandwidth or 960 kbits/s, with some extra overhead for signaling. If
the number of streams increases to 15 then the bandwidth needed would be
1.44 Mbits/s (almost the entire T1).
Figure 1:
Effective Network Bandwidth By CODEC Type For Different Voice Frame Sizes
| CODEC
Type |
CODEC
Bandwidth (kbits/s) |
Effective
Network Bandwidth (kbits/s) |
| 5mS
Frame |
10mS
Frame |
20mS
Frame |
30mS
Frame |
| G.711 |
64 |
131.2 |
97.6 |
80.8 |
75.1 |
| G.729A |
8 |
- |
41.6 |
24.8 |
19.1 |
| G.723.1 |
6.3 |
- |
- |
- |
17.4 |
| iLBC |
15.2 |
- |
- |
32 |
- |
Using low bandwidth CODECs helps reduce bandwidth requirements however due
to the overhead of IP, UDP and RTP protocols, such reduction is limited. The
table below shows the effective network bandwidth used by some common CODEC
types for different voice frame sizes. Note that using a longer frame can
have some impact on delay, hence it is common to use 10-20mS frames.
Low bit rate CODECs also introduce some voice distortion and may be unacceptable
for extended use.
Step 2
Map Existing Wide Area Network/VPN Capabilities
Many call quality-related problems occur in access links or on limited bandwidth
WAN or VPN links. If significant jitter or delay occurs on inter-site connections,
this is a strong indicator that similar problems will occur during VoIP deployment.
Budget bandwidth usage between sites and verify that routers can prioritize
RTP traffic.
- What is the bandwidth available between each site?
- How much data traffic is currently carried, (both average levels and peak
levels)?
- Is sufficient bandwidth available to support both the current data traffic
and the estimated bandwidth needed for voice?
- Is there any capacity for growth or for unexpected peaks in activity?
- Will the addition of voice traffic have an adverse effect on data application
performance, i.e. if there is significantly less bandwidth for data applications,
then how will they be affected?
Map VoIP bandwidth requirements onto available bandwidth.
10xG.711 streams will require 10 x 96 kbits/s of bandwidth or 960 kbits/s,
with some extra overhead for signaling. If the number of streams increases
to 15, then the bandwidth needed would be 1.44 Mbits/s (almost the entire
T1). This will leave approximately 500 kbits/s for data traffic. If more than
the expected 10 users are simultaneously on the phone, then problems may start
to occur with data applications due to insufficient bandwidth. And if more
than 15 users are on the phone, then voice quality will degrade very quickly.
Step 3
Verify LAN readiness
Use a switched 100BaseT Ethernet architecture, potentially using VLAN to
separate voice and data. Even with the use of switched Ethernet, problems
can still occur due to duplex mismatch, excessively long Ethernet segments
or bad cable connections.
- Are any hubs present in the LAN (don't forget remote sites)?
- Examine Ethernet switch statistics for evidence of packet errors or excessive
collisions and upgrade equipment accordingly.
If Wireless LANs are being used, be aware that these can introduce significant
impairments into the packet stream and should be checked carefully before
using them for Voice traffic.
Step 4
Verify Inter-Site Readiness
Pre-deployment testing is essential; however, you need to perform Steps 1
to 3 first. Many problems are predictable by simply verifying that sufficient
bandwidth is available to carry the expected traffic level.
When conducting a pre-deployment test, it is important that the test:
- is conducted over a sufficient period of time to assess network readiness
under a variety of "typical" network conditions. Conditions vary through
the day and through the week, and network problems are often transient in
nature. There is no substitute for a sufficient amount of testing time.
- is conducted under network load conditions that are similar to those expected
post-deployment. There is little point in testing a single VoIP call when
you expect that there will be twenty calls.
A number of vendors produce pre-deployment test tools or provide services.
And, there are also a number of open source tools available. Spending some
of your budget on pre-deployment testing is a worthwhile investment.
Add voipplanet.com to your browser search box
IE 7 | 
Firefox 2.0 | 
