April 5, 2008, 2:54 p.m.
posted by nobody
Fundamentals of Packet Telephony NetworksThe increased efficiency of packet networks (for example, VoIP networks) and the ability to statistically multiplex voice traffic with data packets allows companies to maximize their return on investment (ROI) in data network infrastructures. Multiplexing voice traffic with data traffic reduces the number of costly circuits dedicated to servicing voice applications. As demand for voice services expands, it is important to understand the different requirements of voice and data traffic. Previously, voice and data networks were separate and could not impact each other. Today, it is necessary to determine the protocols available to control voice calls and ensure that data flows are not negatively impacted. This section delves into the benefits of packet telephony networks and provides an overview of basic packet telephony operations. Additionally, the fundamental components of packet networks are introduced. Finally, as a design consideration, this section considers the fragile nature of voice packets. Benefits of Packet Telephony NetworksTraditionally, the potential savings on long-distance costs was the driving force behind the migration to converged voice and data networks. However, as the cost of long-distance calls has dropped in recent years, other factors have come to the forefront as benefits of converged networks. The benefits of packet telephony versus circuit-switched telephony are as follows:
Although packet technology has clear benefits, you should carefully consider the following points before migrating to this technology:
Packet Telephony ComponentsThe basic components of a packet voice network, as shown in Figure, include the following:
Packet Telephony Network Components
Other components, such as software voice applications, interactive voice response (IVR) systems, and softphones, provide additional services to meet the needs of enterprise sites. Call ControlCall control allows users to establish, maintain, and disconnect a voice flow across a network, as shown in Figure. Call Control
Although different protocols address call control in different ways, they all provide a common set of services. The following are the basic components of call control:
From a design perspective, you can set up call control in either a distributed or centralized architecture. The following sections describe both types. Distributed Call ControlDistributed call control, an example of which is shown in Figure, offers an environment where call control is handled by multiple components in the network. This approach to call control is possible where the voice-capable device is configured to support call control directly. This is the case with a voice gateway when protocols, such as H.323 or SIP, are enabled on the device. In Figure, each location contains a Cisco Unified CallManager cluster. Each cluster is capable of handling call processing. Therefore, the topology shown demonstrates one example of distributed call control. Distributed Call Control
Distributed call control enables the gateway to perform the following procedure:
Centralized Call ControlCentralized call control, an example of which is illustrated in Figure, allows an external device (call agent) to handle the signaling and call processing, leaving the gateway to translate audio signals into voice packets after call setup. The call agent is responsible for all aspects of signaling, thus instructing the gateways to send specific signals at specific times. Also, the centralized call control model can leverage Cisco's Survivable Remote Site Telephony (SRST) feature to provide redundancy in the event of a WAN outage by having the voice-enabled router at the remote site perform basic call processing functions. In the figure, a Cisco Unified CallManager cluster located at the Headquarters location is in charge of call control. Therefore, the topology shown demonstrates an example of centralized call control. Centralized Call Control
When the call is set up, the following occur:
The use of centralized call control devices is beneficial in several ways:
MGCP is one example of a centralized call control model. Real-Time Versus Best-Effort TrafficVoice and data can share the same medium. However, their traffic characteristics differ widely: Voice is real-time traffic and data is typically sent as best-effort traffic. Traditional telephony networks were designed for real-time voice transmission, and therefore they cater to the need for a constant voice flow over the connection. Resources are reserved end to end on a per-call basis and are not released until the call is terminated. These resources guarantee that voice flows in an orderly manner. Good voice quality depends on the capacity of the network to deliver voice with guaranteed delay and timing. Traditional data networks were designed for best-effort packet transmission. Packet telephony networks transmit with no guarantee of delivery, delay, or timing. Data handling is effective in this scenario because upper-layer protocols, such as TCP, provide for reliable, although untimely, packet transmission. TCP trades delay for reliability. Data can typically tolerate a certain amount of delay and is not affected by interpacket jitter. A well-engineered, end-to-end network is required when converging delay-sensitive traffic, such as VoIP, with best-effort data traffic. Fine-tuning the network to adequately support VoIP involves a series of protocols and features to improve quality of service (QoS). Because the IP network is, by default, best effort, steps must be taken to ensure proper behavior of both the real-time and best-effort traffic. Packet telephony networks succeed, in large part, based on the QoS parameters that are implemented network-wide. |
- Comment