Transcript
This guide provides technical background information about the voice and video over IP technologies that are monitored by CA Unified Communications Monitor (UC Monitor). This guide helps you understand the challenges of delivering a high-quality experience to the users who access your unified communications system.
The definition of unified communications is evolving. For UC Monitor, the term refers to integrated applications that enable communications that use existing IP network infrastructure and extend beyond telephone service. Unified communications represent the convergence of multiple modes of communication within applications and infrastructure to allow people, teams, and organizations to communicate more effectively. The IP network provides the unifying factor for unified communications. Unified communications rely on a converged network, often with multiple and diverse applications vying for the same network resources. Therefore, network performance is a critical enabler for all unified communications applications. Assessing user quality of experience when interacting with unified communications system components is the key to the delivery of these services. UC Monitor monitors unified communications applications and devices, and measures their performance from a user perspective.
Many businesses lose sales opportunities when the phones go down for even a few minutes each month. VoIP traffic requires premium handling for the following reasons: ■
Network users are accustomed to excellent performance from their telephone service, which has been excellent since they first picked up a telephone in their homes. They notice, and probably complain, when the quality of their VoIP calls dips even slightly.
■
VoIP is a real-time application. As such, it is sensitive to latency, jitter, and packet loss. The network infrastructure is not designed to carry real-time application traffic.
VoIP still behaves like an emerging technology. Standards are still adopted and challenged. Multiple vendors still sell components that do not work together. These factors can create major application performance issues on converged networks. As a result, even a limited VoIP deployment requires ongoing, VoIP-specific monitoring, frequent call quality evaluation, trending, and troubleshooting.
VoIP traffic has several unique characteristics: ■
VoIP is a significant consumer of bandwidth. Application performance deteriorates when VoIP traffic runs on the same network because VoIP sends data at a fixed rate, with no throttling mechanism.
■
VoIP has a fair amount of header overhead and sends data continuously in two directions. Depending on several factors, such as the codecs you use and the levels of phone usage, VoIP traffic can really fill up your network. Your TCP applications gracefully back down under conditions of congestion. VoIP can starve them out.
■
VoIP uses the Real-time Transport Protocol (RTP), which rides on top of the User Datagram Protocol (UDP). RTP applications typically send packets at a fixed rate, and because UDP is a connectionless protocol, there is no retransmission or reordering of data. When a packet is dropped, it is gone. The signal cannot be retransmitted. If a whole group of packets is dropped at once, entire portions of a conversation between two IP phones are lost.
Think of VoIP as an application that is highly delay-intolerant, and whose quality depends on delivery with minimal latency, jitter, and packet loss.
Maintaining user Quality of Experience (QoE) is immensely challenging for video applications because it is difficult to measure success in delivering high-quality video. Video applications do not have a widely accepted video quality standard equivalent to the MOS for audio. Video quality is more subjective than audio quality, and it is more complicated to implement. Video is finicky. Like VoIP, it has stringent performance requirements. Its real-time, streaming behavior resembles VoIP, but some of the performance metrics that affect VoIP call quality have a more powerful effect on video. For example, packet loss causes a syllable or two to drop out of a call. For a viewer of a video, packet loss causes pixelation and probably slow or frozen images. Jitter on a call makes the audio sound scratchy or garbled. Jitter during a video conference both distorts the image and scrambles the speech. The effects are both more noticeable and more annoying. Video requires a network that is expertly tuned, adequately or even over-provisioned, and carefully monitored. Video applications have a much greater throughput requirement than VoIP. Video packets are large to begin with, and a key point to remember is that a video conference also has an audio component. One video stream takes from 300 to 400 kbps in each direction. Add the audio, and you have more than 800 kbps for combined video and audio streams. On the LAN, video performs well. However, a desktop video deployment means that some video streams are sent point-to-point, between a pair of users. Others are multicast, for a video conference or webcast, for example. A slow link or busy interface presents a potential issue for these users. Using desktop video conferencing enables cross-site collaboration, which usually means video calls must travel across WAN links to reach remote offices. When they compete for bandwidth with other application traffic, these data streams can create bottlenecks on WAN links and WAN-LAN interfaces.
The primary challenge in maintaining a unified communications system is minimizing network delay. Delay is the latency from infrastructure components such as: ■
packet queues
■
QoS queues
■
firewalls
■
NAT
■
encryption
Properly configured QoS policies ensure that other data applications do not contend with voice-allocated bandwidth, but they can add delay. Encryption technologies introduce more latency by ignoring priority flags (ToS) and adding additional header information, such as IPsec headers. Non-uniform packet delays, or jitter, are often more detrimental to VoIP and video call quality than latency. When it is not affecting every voice packet in a stream, delay creates jitter. Jitter affects call quality as the signal starts to sound or look garbled. Jitter can also cause packets to arrive out of order, which introduces additional latency at the application layer when reassembly of the signal occurs. VoIP-endpoint buffers, network devices that support QoS, and RTP header compression can minimize jitter. But there is always a tradeoff. RTP header compression, for example, adds latency due to the extra processing that is required on the routers. Packet loss can also result from excess latency or jitter. VoIP and video are also more sensitive to packet loss than other network applications. Loss rates greater than three percent are considered intolerable when compared to plain old telephone service (POTS) calls. Finally, specialized VoIP equipment presents its own monitoring and maintenance challenge. Test and monitor your call servers to ensure they can handle voice traffic and can route it properly.
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the “Documentation”) is for your informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed by you or used for any purpose other than as may be permitted in (i) a separate agreement between you and CA governing your use of the CA software to which the Documentation relates; or (ii) a separate confidentiality agreement between you and CA. Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice. The manufacturer of this Documentation is CA. Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors. Copyright © 2012 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
