Part one of Bulletproof IP telephony deployment by Christian Stegh, IP Telephony Practice Leader with Avaya, Inc., provides solutions to performance issues in Layer 1 – the physical layer.
It is well understood that voice applications require proper bandwidth engineering,
Quality of Service (QoS) and highly reliable networking components. However, these concepts merely scratch the surface of the optimizations necessary for a bulletproof IP telephony deployment. In fact, many more fundamental networking issues can cause the most annoying IP telephony problems. Often, poorly performing voice calls expose an underlying network issue that has gone unnoticed by data applications. While data networks are more tolerant of errors, and users may not notice a slightly longer hourglass, voice has much more stringent performance requirements. If a network has even a subtle problem, IP telephony will find it.
Similar to the way in which some network troubleshooters approach strange, nagging
performance issues, this article is broken down in sections corresponding to the layers
within the seven-layer OSI model. Beginning at the physical layer up to the application
layer, converged applications have been known to encounter network issues all along the
way. Within each layer, issues that have been known to impact IP telephony quality are
discussed, varying from commonly occurring issues to extremely rare ones. Figure 1 can
be used as a reference throughout the article.
Layer 1 – The physical layer
Cabling:
In the past, Category 3 cable was typically used to terminate digital phones. It effectively
met the needs of both two and four-wire digital sets and was more cost-efficient than
Category 5. Category 3 hasn't been generally used for LAN data applications, and
therefore, for a consistently reliable and clean IP telephony connection, Category 5
cabling or above is preferred. While Cat 3 can support Power over Ethernet, and its bandwidth capability can easily support a single voice call, performance will vary when running Cat 3, especially when a PC is plugged into an IP phone sharing the same uplink cable to the LAN switch. At that point, Cat 3's 10Mbps limitation can be easily exceeded. Phone chipsets and network interfaces are vigorously tested using Cat 5 and higher, but rarely tested using lower-grade cabling. If anything out of the ordinary is occurring on a phone connected to Cat 3 cable, switching to Category 5 or higher is the recommended first step.
Poorly terminated fiber optic cables have been known to cause intermittent packet loss.
The rapid rate of transmission of voice (around 50 packets per second in each direction),
exposes such links to much more constant traffic than a bursty data session. The packet
loss won't show up in an SNMP statistic on a router or switch interface, since the device
itself is not dropping the packet. Two methods of finding this issue have proven effective. Proactively, cable testing can be randomly or thoroughly done on each fiber uplink. Reactively, systematically tracing the path (via MAC/CAM tables) of calls that are having issues and isolating the common link will accomplish the job after some handwringing. Figure 2 illustrates how to narrow in a poorly performing cable.
Power:
There are two main ways to provide power to IP phones:
- From the desktop, with individual power supplies plugged into desktop outlets
- From the closet, using either 802.3af:
- LAN switch ports
- Powered patch panels
or
- Mid-span power injectors
Since power to each desktop infers supplying individual circuits and more opportunity for
error, IP phones are more susceptible to power surges and level inconsistencies when
plugged into wall circuits. Depending on its transformer and the phone itself, anomalies
vary. The screen may not provide full brightness, or in some cases, phones may reset due
to a brief loss of power. Since this can occur randomly, troubleshooting and isolating the
issue can be time consuming and expensive, eventually requiring a power meter to isolate
the issue. The best practice is to provide power from the closet, where the circuit can be more accurately managed and ideally, backed up and treated by a UPS.
On a financial note, if IP phones are to be powered from the closet, there may be extra costs involved. In the past, closets were equipped with circuits to power LAN switches for data machines. If IP phones are to connect into the LAN switches, the power draw of the LAN switch will increase, often exceeding the supplied load. Consider the extra costs of running an extra circuit to provide the additional power needed. Whether or not UPS is required is a business decision. To match the five 9' s reliability of the TDM world, where digital sets are powered by a PBX that is on UPS, each LAN switch would need to have backup power.
Echo:
Echo can be more of an issue with IP telephony systems than with TDM systems, but
the IP network is not solely to blame for echo problems. Echo occurs when the
speaker's voice is reflected back towards them, because some of the transmitted signal
appears on the receive path. A main cause of echo is impedance mismatching, where 2
to 4-wire conversions take place, at a central office tandem switch. Echo becomes
annoying when the intensity and delay increase. It is the increased delay in an IP
network that may make echo an issue. Keeping delay below the ITU' s recommended limit for one-way audio transmission time of 150ms (mouth-to-ear) will adequately control echo, but this requires one-way delays on the IP network to be much less. If IP network delay cannot be low enough so as to approach the delay of a digital phone signal, echo cancellers on T1 boards interfacing the PSTN will reduce some of the reflected signal before it reaches the IP network, improving results.
Environment:
Finally, environmental issues like overhead airplanes, HVAC noise, and EMI fields
from nearby mechanical equipment, fall into the category of too rare to characterize.
While they're not common enough to detail solutions, they have been known to occur.
Such oddities are typically due to interference with power supplies that would affect
any type of electrical equipment, not just IP phones.
Read Bulletproof IP telephony deployment, Part 2.
Read Bulletproof IP telephony deployment, Part 3.
About the author:
Christian Stegh is currently Avaya's IP Telephony Practice Leader for the North American Region. Among other responsibilities, he acts as a liaison between Avaya's customers/sales teams and Avaya's development teams, influencing direction of Avaya solutions based on customer input. Prior, he was a Managing Consultant within Avaya Global Services, designing, optimizing, and implementing hundreds of converged networks for customers. He began his IT career as a network engineer for a Fortune 200 manufacturing firm, where he managed worldwide L2/L3 networks. His interests not only include multimedia network performance, but also SIP, converged security, and business continuity. Feel free to provide your feedback to him.
