This chapter discusses how to design the transport of voice within a network, and includes the following sections:
This chapter describes how voice can be transported along with other data within a network.
We first introduce why it would be advantageous to include voice in your network design. The mechanics of voice transport, including digitization, packetization, and call processing are explained. Quality of service (QoS) for voice is reviewed. The components required in a Voice over IP (VoIP) network and those in an IP telephony network are described. The standards for how voice calls are coded and compressed are introduced, and the bandwidth requirements for voice traffic are explored. IP telephony design scenarios are examined. We conclude with an introduction to security considerations for voice.
Note
Appendix B, “Network Fundamentals,” includes material that we assume you understand before reading the rest of the book. Thus, we encourage you to review any of the material in Appendix B that you are not familiar with before reading the rest of this chapter.
While those in the networking world have been hearing about Voice over IP for quite a while now, over the past couple of years (at least within North America), the mainstream press has been introducing the term VoIP to the ordinary consumer. Although the residential market is currently small, it is growing quickly, as prices are slashed for VoIP packages that include such features as unlimited calls within the continent, low-cost international calling, voice mail, selection of your own area code, call forwarding, and call display.
An enterprise might also want to implement VoIP, in other words, to use its data network to also carry its voice traffic. Referring to the discussion in Chapter 1, “Network Design,” a new technology shouldn’t be implemented just because it can be, but rather because it meets the network’s requirements. The goal for converging an organization’s voice and data networks is to positively “impact key initiatives, business processes and business results.”[1] This can be accomplished in many ways, including the following:
Direct cost savings, which is typically the initial reason that a company considers converging its voice and data networks. These savings include the following items:
Toll bypass—. Long-distance voice calls go over the data network instead of the public switched telephone network (PSTN), thus saving the associated charges. For example, calls between branch offices and headquarters can go on the same network as data. Calls to customers can go as far as possible over the converged network, and then onto the PSTN for the last segment.
Having only one network to implement, maintain, manage, and operate—. Cost reductions can include those for equipment purchases, equipment space, maintenance contracts, and so forth.
Reduced add/move/change costs—. Employees can take their extension number with them when they move offices, and new employees can be added easily.
Reduced cabling costs—. Because voice travels over the data network, no additional cabling is required.
Possible reduced capital expenditures costs—. For example, the company might not have to buy a new private branch exchange (PBX) switch to manage the corporate phone system.
Increased end-user productivity, because more applications are available through the Internet or from an IP phone. Two examples are a video telephony application that allows video conference calls between any locations, and unified messaging that allows employees to pick up voice-mail messages on the Internet, thus avoiding costly long-distance charges when they are traveling.
Revenue-generation opportunities, which can also be a competitive advantage. For example, a call center could be set up to take sales orders and provide customer service.
Improved customer service and response, because more information can be made available to customers themselves or to the customer-service agents.
Improved employee empowerment and satisfaction, for example, by providing employees that do not currently have a workstation access to the Internet and applicable applications through an IP phone.
A converged network is one in which data, voice, and video traffic coexist on a single network. Transporting voice and video across the network means that they become applications, just like file transfers, to the network. It also means that the capabilities of the network can be used to provide even more functionality and features than were previously available.
Key Point
To transport voice across the network, it must first be digitized—converted from analog to digital signals—and then packetized, that is, put into IP packets. These voice IP packets can then be sent over the data network, just like any other IP packets.
Figure 7-1 illustrates the digitization process for analog speech, as described in this section.
Analog speech contains components at many different frequencies, representing the range of sounds that we hear. Most analog speech components are in the frequency range of 300 hertz (Hz) to 3400 Hz. The first step in the digitization process is to filter out anything higher than 4000 Hz, thus isolating the speech component.
This filtered signal is then sampled by a process called pulse amplitude modulation (PAM), which uses the original analog signal to change the amplitude of a pulse signal. The rate at which the sampling is done is driven by the Nyquist theorem, which states that the sampling rate must be at least twice the highest frequency, so it is possible to reconstruct the analog signal from the digital signal. If too few samples are taken, not enough information would be available to re-create the original speech. Thus, for speech filtered at 4000 Hz, sampling must be done at 8000 Hz, or 8000 times per second.
Using a pulse code modulation (PCM) process, each of these samples is then quantized, which means that it is assigned a discrete binary value and then digitized. Eight bits are used for each sample, resulting in 28 = 256 possible values.
The packetization of voice is implemented in the following two ways, as illustrated in Figure 7-2:
Using traditional phones and a PBX (or digital phones attached to a PBX) to digitize the voice, and then connecting the PBX to a voice-enabled router to perform the packetization. The result is voice encapsulated inside IP packets, or VoIP. These packets are carried across the converged network, therefore replacing the traditional tie trunks between PBXs. This scenario is illustrated at the top of Figure 7-2, and the devices required are detailed in the “VoIP Components” section, later in this chapter.
Using IP phones to digitize and packetize the voice. The call-processing function previously performed by the PBX is now handled by a call-processing manager—for example, Cisco CallManager (CCM) is a software-based system that provides functions such as setting up and terminating calls, routing to voice mail, and so forth. Similar to the previous scenario, this results in VoIP packets traversing the network. VoIP, together with the enhanced features provided by CCM and other applications that are now possible, are collectively known as IP telephony. This scenario is illustrated in the lower portion of Figure 7-2. IP telephony also supports devices other than IP phones, to provide even more flexibility and functionality within the converged network. The devices used in IP telephony are described in the “IP Telephony Components” section, later in this chapter.
Note
Figure 7-2 does not show connectivity to the PSTN. IP telephony scenarios with PSTN connections are described in the “IP Telephony Design” section, later in this chapter.
Two categories of voice traffic exist: conversation traffic (the audio, also called bearer traffic) and control (or signaling) traffic.
Key Point
Within VoIP, conversation packets are sent using the User Datagram Protocol (UDP), which provides connectionless transmission.
Because it does not have the overhead that the sequencing, acknowledging, and error-checking features of the Transmission Control Protocol (TCP) require, UDP provides a more efficient, lower-delay service. Voice conversation is susceptible to delay—if a voice packet is delayed too much, it could lose its relevance. On the other hand, the loss of a single voice packet is not detrimental to the quality of voice at the receiving end because it can be interpolated from other voice samples.
Conversation packets are sent using the Real-Time Transport Protocol (RTP), which runs on top of UDP. RTP was designed to be used for real-time traffic such as voice. RTP adds another header to the UDP segment that includes some sequencing information and time-stamping information to ensure that the received data is processed in the correct order and that the variation in the delay is within acceptable limits.
Call control traffic is sent using TCP, because the signals must be received in the order in which they were sent, and loss of these packets cannot be tolerated.
Earlier we described how residential VoIP is becoming popular. These calls are being sent over the Internet, not over a private corporate wide-area network (WAN). You saw in Chapter 6, “Quality of Service Design,” how important QoS is to voice calls, to ensure that the delay and variation in delay (jitter) remain within acceptable levels. However, the Internet is known as a best-effort service: in general it has no QoS support. Thus, the quality of these voice calls over the Internet is not guaranteed. For residential and small-business needs, the quality might be acceptable, especially when weighed against the cost savings. For organizations that require enterprise-class voice-enabled network services and quality, though, Cisco does not recommend using best-effort WAN connections such as the Internet. For these networks, dedicated WAN connections with QoS support should be used for voice traffic between sites.[2]
Note
It is interesting to consider the quality of service provided by the best-effort Internet. For example, when we send an e-mail to someone, it usually arrives almost immediately. While we have probably all experienced a few instances of e-mails never arriving at their destination, in general, we think of the Internet as providing good service.
Voice traffic is sensitive to delays, jitter, and extensive packet loss. Recall from Chapter 6 that the guidelines for ensuring acceptable voice quality are as follows:
The one-way delay should be no more than 150 milliseconds (ms).
The jitter should be no more than 30 ms.
No more than 1 percent of the packets should be lost.
Note
While 150 ms is the standard for acceptable voice delay, tests have shown that a negligible quality difference exists with a 200-ms delay.
Chapter 6 also identifies the tools that are available to implement the QoS required by voice traffic, including classification and marking, policing and shaping, congestion avoidance, congestion management, and link-specific tools.
Key Point
When implementing VoIP using traditional phones, components include the phones, a PBX, and a voice-enabled router, as illustrated earlier in the VoIP portion of Figure 7-2.
Traditional phones and PBXs have been installed in businesses for many years. The addition of a voice-enabled router, also called a voice gateway, can be the first step toward a fully converged voice and data network. The voice-enabled router contains digital signal processors (DSPs) to perform its functions in hardware, which is much faster than doing it in software.
To support VoIP, an underlying IP infrastructure must be functioning and robust—in other words, don’t even think of adding voice to a network that is experiencing other problems, such as congestion or network failures.
Voice-specific recommendations for the IP infrastructure are as follows:
QoS, as described earlier and detailed in Chapter 6, should be implemented within the network. Queuing should be deployed on any link (WAN or LAN) that could potentially experience congestion, to meet delay and jitter requirements for the voice traffic.
WANs for voice networks should use a hub-and-spoke topology, with a central hub site and multiple remote spoke sites connected to the central hub site.[3] Each remote site is then one WAN link hop away from the central site and two WAN link hops away from all other spoke sites. This ensures that call admission control—limiting the number of calls allowed over the network so that the quality of all calls is within acceptable limits—at the central site can keep track of the bandwidth available between any two sites.
Redundancy should be implemented within the network. For example, WAN links should be redundant to ensure the availability of the voice traffic between sites, and redundant devices and links should be deployed within the campus where necessary to ensure the availability within each site.
Compression of voice traffic over WANs should be implemented to reduce the required bandwidth. The various compression techniques are described later in the “Voice Coding and Compression Techniques” section—G.729 compression is recommended for WAN links.
Key Point
IP telephony components include a robust IP infrastructure, IP phones, a video telephony option, a call-processing engine, applications, and optionally a voice gateway to the PSTN.
Note
More information on Cisco IP telephony is available at http://www.cisco.com/go/ipc.
The IP infrastructure requirements noted in the previous section apply equally to an IP telephony implementation. However, additional items must be considered in this environment because of the other components, including the following:
The LAN access switches to which IP phones and users’ PCs are connected should define two separate virtual LANs (VLANs) each, one for data and one for voice, allowing easier implementation of QoS tools. (VLANs are described in Chapter 2, “Switching Design.”) Recall from Chapter 1 that the LAN access switches are interconnected by distribution Layer 3 switches (routers) to provide communication between the workgroups.
As discussed in Chapter 6, while the network administrator might not want to trust end users to classify and set QoS markings consistent with the organization’s policy, the access switches to which they are connected could perform this task.
Access switches can provide in-line power for the IP phones.
Consideration should be given to deploying resources over WANs in a distributed design, rather than a centralized design. For example, the CCM application should be distributed when possible so that the voice network remains available if the WAN fails.
Key Point
IP phones digitize and packetize voice. They connect to the network through an Ethernet cable (or through a wireless network), just as a PC does. Many different types of IP phones are available, including both hardware-and software-based.
The following are some of the features available on Cisco IP phones:
Support for power over Ethernet (PoE), to allow the phone to be powered from the switch to which it is connected (if it supports in-line power) rather than from a power outlet.
Extensible markup language (XML) support enables access to applications; new features and applications can be added easily. The IP phone contains a micro-browser that enables limited web-browsing capability. Higher-end phones have web-client capabilities, while lower-end phones support text-based XML applications.
Display and audio features include liquid crystal displays (LCDs), speakerphones, and audible and visual alerts.
Some models have integrated Ethernet switches, with speeds up to 1 gigabit per second (Gbps).
Some models support multiple phone lines.
The Cisco portfolio also includes IP Communicator, a software-based IP phone, and a wireless IP phone (which is discussed in Chapter 5, “Wireless LAN Design”). IP Communicator runs on a PC to give users the flexibility of having their IP phone wherever they can access the network.
Cisco also has analog telephone adapters and gateways, allowing analog phones to be connected to a network as though they were IP phones.
Note
More information about Cisco IP phones is available at http://www.cisco.com/en/US/products/hw/phones/ps379/index.html.
The Cisco VT Advantage product provides Cisco IP phone users with the ability to add video telephony to their phone calls. VT Advantage includes the Cisco VT Advantage software application and a video telephony Universal Serial Bus (USB) camera. With the camera attached to a PC that is colocated with a Cisco IP phone, a user can place and receive video calls on his enterprise IP telephony network using the phone interface.
CCM is a software-based call-processing system that provides enterprise telephony features to an IP network. CCM can be installed on a Cisco Media Convergence Server (MCS) and selected third-party servers. The software also provides a suite of integrated voice applications and utilities, including a software-only manual attendant console and an auto-attendant; a software-only conferencing application; tools for detailed reporting and analysis of calls, adding and deleting users, and configuring phones; and tools for monitoring the CCM components. Multiple CCM servers can be clustered to support up to 30,000 IP phones per cluster; multiple clusters can also be integrated to support up to 1 million users. In networks with up to 2500 phones, two servers are typically deployed: One acts as a publisher (to store the master copy of the configuration database), and the other acts as a subscriber (the device with which phones register).[4] The subscriber also acts as a backup to the publisher in this scenario.
CCM can be configured to route calls in various ways, using a dial plan. For example, some phones might be allowed to only reach certain destinations within a building and local PSTN calls, while others might have unlimited access. As another example, different paths, such as the PSTN or the WAN, can be selected to reach the same destination, depending on which device is placing the call.
Voice applications are independent from the call-processing and voice-processing infrastructure, and can reside anywhere within the network. The main applications available from Cisco include the following:
Cisco IP Contact Center (IPCC) (available in Enterprise and Express editions)—. For managing customer voice contacts and deploying a distributed contact center infrastructure. For example, IPCC Enterprise provides intelligent contact routing, call treatment, network-to-desktop computer telephony integration (CTI), and multichannel automatic call distributor (ACD) functionality.
Cisco MeetingPlace—. A rich-media conferencing solution that integrates voice, video, and web-conferencing capabilities. This application uses existing corporate voice (IP and circuit-switched) and data networks to reduce or eliminate toll charges and conferencing charges.
Cisco Unity—. This unified messaging solution delivers e-mail, voice mail, and fax messages to a single inbox so that users can, for example, listen to their e-mail over the telephone, check voice messages from the Internet, and forward faxes to wherever they might be.
Cisco Personal Assistant—. A personal productivity application that helps users manage how and where they want to be reached. For example, it provides speech-enabled access to Cisco Unity voice messages, a corporate directory, and personal contact lists, from any telephone. The web-based and telephone user administration interfaces help prevent missed calls or interruptions by allowing calls to be forwarded or screened, in advance or in real time.
A voice gateway to the PSTN can be implemented with a variety of devices. For example, the Cisco 3700 Series multiservice access routers communicate directly with CCM and support a range of interfaces and signaling protocols. Voice gateway modules can also be installed in Cisco switches, including the Catalyst 4000 and 6000 Series.
These gateways could communicate with CCM using the H.323 protocol, the Session Initiation Protocol (SIP), or the Media Gateway Control Protocol (MGCP). H.323 is a standard protocol for packet-based audio, video, and data communications over IP. SIP is a standard application layer protocol for multimedia conferencing over IP. MGCP is a standard protocol that allows call agents, such as CCM, to control specific ports on a gateway.
Recall that voice digitized with PCM is sent at 64 kbps. You can reduce the bandwidth required by voice in many ways, as detailed in the following sections.
Voice compression reduces the size of the voice payload while still maintaining the quality at an acceptable level. As a result of technology advances, a variety of International Telecommunications Union (ITU) standards exist for voice coding/decoding and compression; these standards are known as codecs. Some of these standards and the bandwidth they use for one voice channel are summarized in Table 7-1. The quality of the resulting voice is represented by the average of the results of a wide variety of listeners’ opinions, on a scale of 1 (bad) to 5 (excellent), known as the mean opinion score (MOS), which is also shown in Table 7-1. Notice the variety of bandwidth and MOSs; both should be considered when choosing a codec.
Table 7-1. Voice Coding and Compression Standards[5]
ITU Standard Codec | Bandwidth (kbps) | MOS |
|---|---|---|
G.711 | 64 | 4.1 |
G.723 | 6.3/5.3 | 3.9/3.65 |
G.726 | 16/24/32 | 3.85 |
G.728 | 16 | 3.61 |
G.729 | 8 | 3.92 |
Key Point
In general, G.729 is the recommended voice compression technique over most WAN networks because of its combination of low bandwidth and high MOS.
Note
Using a single codec in WANs is recommended; this can also simplify the bandwidth-requirement calculations.
A DSP is a hardware component within a voice-enabled router that digitizes, compresses, and packetizes voice. Some of the codecs require more processing resources than others, so the number of voice calls that can be supported by one DSP depends on the codec implemented. The codecs are divided into two categories, known as medium complexity and high complexity, for this purpose. A single DSP can process up to four voice calls for medium-complexity codecs or up to two calls for high-complexity codecs. The two categories are summarized in Table 7-2.
Table 7-2. Medium-and High-Complexity Codecs[6]
Medium-Complexity Codecs | High-Complexity Codecs |
|---|---|
G.711 | G.723 |
G.726 | G.728 |
G.729a | G.729 |
G.729ab | G.729b |
Another way to reduce the bandwidth required by voice calls is to use voice activity detection (VAD). On average, about 35 percent of a call is in fact silence; when VoIP is used, this silence is packetized along with the conversation. VAD suppresses the silence, so instead of sending IP packets of silence, only IP packets of conversation are sent. The network bandwidth is therefore being used more efficiently and effectively.
Note
In some cases, Cisco recommends disabling VAD, for example, when faxes are to be sent through the network. VAD can also degrade the perceived quality of the call, because when VAD is enabled, the silence is replaced by comfort noise played to the listener (by the device at the listener’s end of the network). If this is causing problems, VAD can be disabled.
Recall that voice conversation packets are sent using RTP, which runs on top of UDP. Thus, VoIP packets consist of two parts: the voice and the headers (IP/UDP/RTP). The voice samples can be compressed, and therefore their size can vary depending on the codec used—for example, a typical G.729 call has 20 bytes of voice samples. The headers, though, are always 40 bytes, which can be a significant amount of overhead.
RTP header compression, called cRTP, compresses this 40-byte header to 2–4 bytes. The cRTP compression can be configured on an interface and is recommended on low-bandwidth WANs (up to 2 megabits per second [Mbps]). The cRTP compression is not recommended on higher-speed interfaces, though, because it is CPU intensive; the use of CPU resources outweighs the benefits on these faster links.
The bandwidth requirements for voice traffic depend on many factors, including the number of simultaneous voice calls, grade of service required, codec and compression techniques used, signaling protocol used, and network topology.
On a WAN, for example, the bandwidth required for all applications, including voice, should be no more than 75 percent of the available bandwidth on the link;[7] the rest is for overhead, including routing protocol traffic.
The following sections detail how to calculate the WAN bandwidth that is required to support a number of voice calls with a given probability that the call will go through.
To determine how much bandwidth is required, you must understand the following terminology:
Grade of service (GoS)
Erlangs
Centum call seconds (CCSs)
Busy-hour traffic (BHT)
Key Point
The grade of service is the probability that a call will be blocked—the caller will get a busy signal because of insufficient capacity—during the busiest hour.
The GoS is written as Pxx, where xx is the percentage of calls that are blocked. For example, a GoS of P05 means that a 5 percent probability exists that callers will be blocked when they call during the busiest hour.
Erlangs and CCSs are common methods of measuring voice traffic.
Key Point
One Erlang equals 1 hour, or 3600 seconds, of a telephone conversation.
A CCS is 1/36 of an Erlang. One Erlang therefore equals 36 CCSs.
The BHT, in Erlangs or CCSs, is the number of hours of traffic during the busiest hour of operation. BHTs are calculated as follows:
• To calculate the BHT in CCSs, multiply the number of calls in the busiest hour by their average duration in seconds, and divide the result by 100.
To calculate the BHT in Erlangs, multiply the number of calls in the busiest hour by their average duration in seconds, and divide the result by 3600.
For example, 1 hour of conversation—one Erlang—can be one 60-minute call, three 20-minute calls, or fifteen 4-minute calls. Receiving 200 calls with an average length of 3 minutes in the busiest hour is 600 minutes or 36,000 seconds of traffic; this would be 10 Erlangs, or 360 centum call seconds of traffic.
Erlang tables show the potential traffic for a specified number of circuits at a given probability of receiving a busy signal. The potential traffic in the Erlang tables is the BHT—the number of hours of traffic during the busiest hour of the telephone system’s operation.
One place that Erlang tables and calculators can be found is at http://www.erlang.com; other sites can also be found by using your favorite search engine. An Erlang B table is the most common traffic model that determines the number of circuits required for a given amount of busy-hour traffic and a required grade of service. For example, according to the Erlang B calculator, a BHT of 4.46 Erlangs at a GoS of P01 requires ten circuits.
After the number of circuits required is determined, the bandwidth required on the WAN for voice calls can be determined. This required bandwidth is also known as the trunk capacity.
Key Point
The trunk capacity for voice calls can be calculated by the following formula:
Trunk capacity = Number of simultaneous calls to be supported * Bandwidth required per call
The first component of this formula, the number of simultaneous calls to be supported, is simply the number of circuits required for the known amount of traffic, as calculated from the Erlang tables.
Note
If 100 percent of calls must go through, Erlang tables are not required; instead, the maximum number of simultaneous calls required should be used.
The bandwidth required for one call depends on the codec used and whether cRTP and VAD are used.
Using IP/UDP/RTP headers of 40 bytes and assuming that the Point-to-Point Protocol (PPP) is used at Layer 2 (so the Layer 2 header is 6 bytes), the following calculations can be made:[8]
Voice packet size = Layer 2 header size + IP/UDP/RTP header size + Voice payload size
Voice packets per second (pps) = Codec bit rate / Voice payload size
Bandwidth per call = Voice packet size (bits) * Voice pps
For example, the bandwidth required for a G.729 call (8-kbps codec bit rate) with a default 20-byte voice payload is calculated as follows:
Voice packet size (bytes) = Layer 2 header (6 bytes) + IP/UDP/RTP header (40 bytes) + Voice payload (20 bytes) = 66 bytes
Voice packet size (bits) = 66 bytes * 8 bits per byte = 528 bits
Voice pps = 8-kbps codec bit rate / (8 bits per byte * 20-byte voice payload size) = 8-kbps codec bit rate / 160 bits = 50 pps
Bandwidth per call = Voice packet size (528 bits) * 50 pps = 26.4 kbps
Table 7-3 summarizes the required bandwidth for G.711 and G.729 codec calls.
Table 7-3. Voice Bandwidth Requirements
Codec | Payload Size (bytes) | Bandwidth Required per Call (kbps) |
|---|---|---|
G.711 (64-kbps) | 160 | 82.4 |
G.729 (8-kbps) | 20 | 26.4 |
VAD and cRTP reduces the bandwidth required per call. The results of the calculations for G.711 and G.729 at 50 pps are illustrated in Table 7-4.
Table 7-4. Per-Call Voice Bandwidth Requirements
Codec | Payload Size (bytes) | Bandwidth Required per Call Without cRTP or VAD (kbps) | Bandwidth Required per Call with cRTP (kbps) | Bandwidth Required per Call with cRTP and VAD (kbps) |
|---|---|---|---|---|
G.711 | 160 | 82.4 | 67.2 | 33.6 |
G.729 (8-kbps) | 20 | 26.4 | 11.2 | 5.6 |
CAUTION
Including VAD in bandwidth calculations can result in insufficient bandwidth being provisioned if the calls do not include as much silence as assumed and when features such as music on hold are used.
Recall that the trunk capacity for voice calls can be calculated by the following formula:
Trunk capacity = Number of simultaneous calls to be supported * Bandwidth required per call
As an example of calculating the trunk capacity, assume that G.729 compression is used over a PPP connection at 50 pps and cRTP is used. From Table 7-4, 11.2 kbps are used by each call. If five simultaneous calls are to be supported, 5 * 11.2 = 56 kbps are required for the voice calls. (The bandwidth for other traffic that is to be on the link must also be accounted for so that no more than 75 percent of the available bandwidth on the link is used.)
Assuming that call control traffic must be sent to the CCM at a central site, the signaling traffic bandwidth requirements between the central site and remote sites depend on the number of IP phones and gateway devices.
In the case of a remote branch where no Telephony Application Programming Interface (TAPI) applications (such as Cisco IP Communicator software phone) are deployed, the recommended bandwidth needed for call control traffic can be determined from the following formula:[9]
Bandwidth (bps) = 150 * Number of IP phones and gateways in the remote site
In the case where a TAPI application is deployed at the remote site, the recommended bandwidth is higher because the TAPI protocol requires more messages to be exchanged between CCM and the endpoints. The formula then becomes as follows:[10]
Bandwidth with TAPI (bps) = 225 * Number of IP phones and gateways in the remote site
IP telephony can be designed in a network in many scenarios, including single-site and multisite deployments.
A single-site design has all the IP telephony components at one site, as illustrated in Figure 7-3.
In this scenario, the IP phones (connected to switches that can provide them in-line power), a call-processing engine (CCM), application servers, and optionally a voice gateway to the PSTN are at the same physical location. Each site is self-contained, and all calls between sites are through the PSTN. This means that the IP WAN is not involved in voice calls and is therefore not a voice bottleneck.
A multisite design has many sites, interconnected through a WAN. A centralized design means that the call-processing engine and application servers are at one of the sites, and the other sites connect to those devices for all call-processing and application requirements, as illustrated in Figure 7-4.
Because the remote sites must send call-processing information to the main site, they must have IP connectivity with the main site. Therefore, if the WAN is down, calls cannot be processed. To prevent a total breakdown of the IP telephony system, the Survivable Remote Site Telephony (SRST) feature on remote routers can be used to provide basic call processing to the remote sites if the WAN fails.
If PSTN access is not required, a voice-enabled router is not necessary in this scenario, because only IP packets are sent across the WAN. However, if PSTN access is required (which is the usual case), a voice gateway is required.
As with most emerging technologies, in its infancy, IP telephony deployments were more concerned with features and quality than with security. Because IP telephony is offered through convergence with data on one network, it can be thought of as simply another application running over the data network. As such, IP telephony can be made secure if its transmissions are treated like any other application that requires security, including authenticity, integrity, and confidentiality. With this perspective, it is easy to integrate IP telephony security into the design and security framework of a corporate network.
The security issues associated with IP telephony can be categorized as follows:
Network security concerns
Platform security issues
Network attack risks associated with IP telephony typically belong to two of the four categories of attacks seen in Chapter 4, “Network Security Design”:
Access attacks
Denial-of-service attacks
Nonauthorized and even fraudulent use of the IP telephony network could be the outcome of an access attack. During an access attack, communications could be intercepted and even replayed. Another concern would be a replay attack or even an impersonation attack.
Many IP telephony control applications run on servers. Those servers can themselves be running a commonly available operating system (OS) such as UNIX or Microsoft Windows XP. Those platforms are themselves vulnerable to attacks. It is therefore fundamental that best practices associated with servers be strictly implemented. Some of those practices, as described in Chapter 4, are as follows:
Closing all unused TCP and UDP ports
Timely patching of OS software
Using antivirus software and ensuring that it is up to date
Installing the servers in a secure location
A properly protected data network is by the same token a safe network for IP telephony. Best-practices-level protection can be accomplished by implementing the mitigation technologies that we explain in Chapter 4. This is a multipronged approach, where the perimeter and inside traffic, as well as the outbound traffic, are protected.
The following recommendations, beneficial to a converged network, can protect both data and voice traffic:
Threat defense:
Virus protection—. Protect the CCM server against viruses.
Hardened servers and workstations—. Close all unused ports and perform timely patch management.
Traffic filtering—. This is done by a stateful firewall that has the capability to ensure that only legitimate interactive traffic is crossing into and out of the corporate network.
Intrusion detection and prevention—. Detect and possibly remediate an incoming attack.
Secure communication:
Encrypted Virtual Private Networks (VPNs)—. Used between VoIP-enabled networks to communicate over nonsecure links to ensure the authenticity, confidentiality, and integrity of the communication.
Switched networks—. Prevent incidences of eavesdropping.
Trust and identity:
Authentication—. Forcing IP phones to authenticate prior to being provided with transmission capabilities.
Security must be natively incorporated in your network design for the benefit of data and consequently VoIP traffic. But as with any good thing, too much can prove to be detrimental. For example, incorporating too much security could lead to noticeable transmission delays, or worse, effectively creating your own DoS attack. Furthermore, at some point in your quest for pervasive security, you will reach a point of diminishing returns, where additional security equipment only provides your network with a marginal rate of security return.[11] So stay vigilant and keep up with the technology and the hackers, but don’t try to be overzealous.
In this chapter, you learned how voice can be transported along with other data within your network; the following topics were presented:
The benefits of including voice within your data network.
How voice is transported across the network, including how it is digitized and then packetized.
The two ways that the packetization of voice is implemented:
Using traditional phones and a PBX (or digital phones attached to a PBX) to digitize the voice, and then connecting the PBX to a voice-enabled router to perform the packetization.
Using IP phones to digitize and packetize the voice. The call-processing function previously performed by the PBX is now handled by a call-processing manager such as CCM.
The two categories of voice traffic: conversation traffic (the audio, also called bearer traffic) and control (or signaling) traffic.
The components of an IP telephony system, including an underlying functioning and robust IP infrastructure and QoS support.
The hardware and software IP phones available from Cisco, the features of CCM, and the voice applications that can be supported.
The voice compression and coding techniques, including the recommended G.729 codec that compresses a call to 8 kbps while still maintaining voice quality.
Calculating the bandwidth requirements for voice traffic and understanding the associated terminology.
Examples of single-site and multisite IP telephony designs.
Security issues associated with IP telephony.
| 1. | “IP Telephony & Business Applications Productivity Session,” Cisco Technical Symposium 2004, Brantz Myers, October 5, 2004, Toronto. |
| 2. | “Cisco IP Telephony Solution Reference Network Design (SRND),” Cisco CallManager Release 4.0, November 2004, http://www.cisco.com/go/srnd. |
| 3. | Ibid. |
| 4. | Hutton and Ranjbar, CCDP Self Study: Designing Cisco Network Architectures (ARCH), Indianapolis, Cisco Press, 2005. |
| 5. | Teare, CCDA Self Study: Designing for Cisco Internetwork Solutions (DESGN), Indianapolis, Cisco Press, 2004. |
| 6. | Ibid. |
| 7. | “Cisco IP Telephony Solution Reference Network Design (SRND),” Cisco CallManager Release 4.0, November 2004, http://www.cisco.com/go/srnd. |
| 8. | Teare, CCDA Self Study: Designing for Cisco Internetwork Solutions (DESGN), Indianapolis, Cisco Press, 2004. |
| 9. | “Cisco IP Telephony Solution Reference Network Design (SRND),” Cisco CallManager Release 4.0, November 2004, http://www.cisco.com/go/srnd. |
| 10. | Ibid. |
| 11. | Paquet and Saxe, The Business Case for Network Security: Advocacy, Governance, and ROI, Indianapolis, Cisco Press, 2004, Chapter 8. |