VoIP

Posted on Friday 19 January 2007

The migration of voice traffic from the traditional public switched telephone network (PSTN) to IP networks has been gaining momentum in recent years. Protocols supporting Voice over IP (VoIP) have matured and market acceptance continues to grow.



Large enterprises led the move to a converged network supporting both data and voice, closely followed by mid-sized business. Although a significant capital outlay was required up-front, the business case was compelling. Cost is reduced for network management and support and eliminated for long-distance and overseas calls. In addition, productivity can be increased through features such as unified messaging, advanced call routing and application integration.

Acceptance of VoIP has reached the small business and consumer market, with systems available at electronics retailers and integrated services offered by telcos and cable companies. The term VoIP can even be heard in radio and television commercials.

A successful VoIP solution must provide quality of experience for the user by compensating for negative conditions that occur in IP networks. Anue Network Emulators allow test engineers to introduce those conditions in a controlled and repeatable fashion to predict quality of experience in actual networks.

In addition to the Internet Protocol (IP), there are a number of other protocols that make VoIP possible. They can be divided into call setup/signaling and transport of the call itself.

Transport Control Protocol (TCP) is the reliable-transport partner in the TCP/IP protocol suite. As a result, it is used to encapsulate call signaling protocols to verify that the call is established. However, TCP has too much overhead to efficiently transport the actual call. User Datagram Protocol (UDP), a connectionless transport protocol, is used to carry the voice packets.

During call setup, a TCP connection between the two endpoints is established. This can involve the use of proxy, registration and redirect servers to locate the IP address of the called party. Once the TCP session is in place, the ring (called party) and ring back (calling party) tones are triggered and the parameters governing the call are negotiated. These can include master/slave settings for controlling the session, choice of codec (coder-decoder) and compression scheme, the type of call (voice/video conference) and security settings, such as encryption. Call setup/signaling protocols include H.225/Q.913, H.245, H.323, SIP, SDP, MGCP and MEGACO.

Once the call is established, the conversation is encoded or digitized (converted from analog signals to bits), compressed, and split into groups of bytes to be encapsulated into payloads for transport across the network. It may also be encrypted. Real-time Transport Protocol (RTP) is used to maintain packet sequence, since UDP doesn’t have the sequencing support provided by TCP. Real-time Transport Control Protocol (RTCP) is the companion protocol that provides out-of-band control information for an RTP flow. RTCP can provide feedback on quality of service (QoS) for the flow to a VoIP application, which can adjust differentiated services (DiffServ) parameters for the flow.

VoIP requires the seamless operation of many protocols and functions. The conversation must be sampled, coded and decoded, compressed and decompressed, packetized and depacketized, encrypted and decrypted. The transport must have the capability of delivering the required bandwidth at the appropriate service level. Signaling is required to establish the connection and negotiate settings. Most importantly, the system must be able to deliver high voice quality over the deployed infrastructure. And all of this must be delivered in the presence of data traffic.

In a Perfect Word: The Performance Baseline:The first step in testing VoIP is to evaluate it in a test lab under optimum conditions. The infrastructure of the test lab should provide an environment with no packet loss, no packet reorder and minimal delay. As all aspects of the solution are tested, such as signaling capacity, voice capacity and voice quality (PESQ/PSQM MOS scores), the maximum performance limits of the system are determined. These limits establish the baseline, which will be used for comparison against the results of tests in a more realistic environment.

Real-World Testing: The Reality Check: VoIP is not delivered on an ideal network. It travels in combination with other traffic through multiple devices and across infrastructure that spans significant distances. The result is an environment that presents some level of delay, impairment, and bandwidth limitation, the severity of which depends on how well the network is engineered.

To deliver VoIP with confidence, test and debugging iterations must be performed under the conditions in which the solution will actually be deployed, and also under worse conditions to account for equipment failure and disaster conditions. Rather than test on a live network, which is expensive and impractical, real-world testing is achieved by using network emulation in the test lab.

Each of the tests performed during baselining are performed again with a network emulator creating impairments such as packet loss, delay, bit errors, sequence errors or duplication in a controlled fashion. The emulator can also model the effects of high traffic load by constraining available bandwidth. The actual delay, impairment and bandwidth values used are determined by various methods.

Before and After: Features that are susceptible to specific im
pairments should be baselined and then tested in the presence of the impairments known to affect them. As issues are revealed, troubleshooting uncovers root causes and facilitates the debugging of applications or tuning of network parameters. This iterative process is required to assure robust solutions and minimize support costs.

Quality of Service: VoIP is sensitive to packet loss. While packet loss concealment (PLC) algorithms can help mask the effect of missing packets, there is a threshold beyond which PLC is ineffective. QoS is employed to guarantee delivery of VoIP with minimum latency. Different schemes may be used depending on the implementation. VoIP queues must be able to deliver packets with minimum loss, even in the presence of other, lower priority traffic. Bandwidth oversubscription should be tested to verify that lower priority traffic is dropped to accommodate VoIP. Impairment profiles can be configured based on where the QoS is implemented, such as in the experimental bits in the MPLS header (core network traffic engineering), the DSCP/ToS bits in the IP header (aggregation-level QoS) or the 802.1p-bits in the VLAN tag (DSLAM or PON QoS).

Voice quality: Voice quality can be affected by network jitter, sequence errors, jitter discards (frames discarded due to arriving too late) and packet loss. Implementations are tested against multiple loss profiles, from periodic and random loss rates to burst loss events associated with traffic congestion, route failure and route flapping. Acceptable quality thresholds are established for each loss profile.
Buffer size: Buffers are targeted specifically to address issues of mis-ordered packets and jitter. Quality or performance scores from the baseline tests should be compared to results as re-order and jitter are applied in a controlled fashion. As breaking points are established, adjustments to buffering can be tested to known values to discover optimum buffer design and configuration.

PLC Algorithms: PLC is targeted at packet loss. Implementations are tested against multiple loss profiles, from periodic and random loss rates to burst loss events associated with traffic congestion, route failure and route flapping. Performance thresholds are established for each loss profile.

Performance Thresholds: When baselining performance, packet loss and sequence errors caused by the system under test may increase as thresholds are reached. When testing with impairments, the amount of impairment injected should be compared to the impairment measured by the analyzer to compare performance thresholds to the baseline thresholds.

In addition, performance thresholds under realistic conditions are used to determine the service level parameters required when deploying VoIP over an existing enterprise network. If additional bandwidth or a service level increase is required, it must be known before deployment to avoid loss of productivity and possibly revenue.

In conclusion, a successful VoIP solution requires testing under real-world conditions to guarantee that it can provide capacity and quality by compensating for conditions that occur in IP networks. Using Anue Network Emulators enables engineers to predict application performance, thereby reducing risk, accelerating time to market, and allowing deployment with fewer problems and more confidence.



Since 1997, Gillaspy Associates has built a solid reputation for developing strong relationships with our customers by providing quality solutions and ongoing support.

Network Emulation Blog

Blog Home
Satellite Testing
Server Migration
VoIP
Circuit Emulation
Network Impairments
Network Emulation

GEM/XGEM Related Pages

Overview

GEM (10/100/1G Ethernet)

XGEM (10G Ethernet)

Ethernet Product Brief


Delay Emulation Products

GEM/XGME

SD Signal Delay

PD Path Delay

FC SAN Delay & Impairment

Combo Units


Delay Solutions

Networked Applications

Server/Data Center Migration

Video & Voice

Wireless/Mobile

Network QoS

Circuit Emulation

PON

Disaster Recovery/Business Continuity

Satellite Communications

Proof of Concept & Interoperability

Next Gen Sonet/SDH

iWARP

Network Planning & Readiness

SAN Extension

CPRI

TCP/WAN Acceleration

Anue Systems


Training Courses

Gillaspy currently offers the following training courses:

SAS

ML270 - Serial Attached SCSI Architecture & Instrumentation

Fibre Channel

ML250 - Fibre Channel Systems Architecture & Instrumentation

ML350 - In-depth Fibre Channel Analysis

iSCSI

ML280 - iSCSI Architecture and Instrumentation

FCIP

ML240 - Introduction to Fibre Channel Over IP (FCIP)

MCE: Medusa Certified Engineer

MC100 - Xgig Analyzer
MC125 - NetWisdom SAN Performance Monitoring System

SATA

Serial ATA Architecture

IO Bus

PCI™ Architecture
PCI™ Overview
PCI-X™ Architecture
PCI-X™ Overview
PCI Express ™ Architecture
PCI-Express™ Overview
Intel Pentium 4/m/Xeon
USB Architecture (Core Topics)
USB Architecture (LS/FS Only)
USB Architecture (HS Only)

Contact Gillaspy Assocates at 805-987-1959 to schedule an on-site class.