Voice and Video Infrastructure
The overall purpose of this chapter is to present general information about designing a successful integrated voice, video, and data solution. This chapter will cover the following topics:
Traditional Voice Systems
The network designer’s role in voice solutions is very important because, regardless of the infrastructure vendor, voice transport scenarios often suffer from poor planning and implementation. Most large organizations choose their voice architecture, including Public Switched Telephone Networks (PSTN) and Private Branch Exchange (PBX) solutions, based on the financial stability of the manufacturer, the support level they offer, and the competitive pricing of the hardware, software, and maintenance components. Cisco is one of the main providers of emerging integrated voice and video solutions.
Analog versus Digital Signaling
When human voice is transported digitally over a network infrastructure, a process of analog to digital conversion takes place. The most common conversion mechanism is Pulse Code Modulation (PCM), which is the process of digitizing analog voice signals, as illustrated in Figure 9.1 below:
Figure 9.1 – Pulse Code Modulation
During the PCM process, the following things occur:
- Excess noise is filtered so that only the basic human voice frequency is captured.
- A process called Pulse Amplitude Modulation (PAM) is used to sample the analog signal.
- The signal is digitized and transposed into a series of 1s and 0s. This process includes quantizing the signal and companding (compressing and expanding) the signal using the u-law.
PBX and PSTN Technology
PSTN and PBX are traditionally the main processes of providing voice services throughout the industry. PSTN is a network that provides residential telephony services, while PBX provides telephony services to users within an organization.
PBXs are business phone systems that offer the following features:
- Call forwarding
- Call transferring
- Call parking
- Conference calls
- Music on hold
- Call history
- Voicemail
Most PBXs are digital devices that are used in the private sector and are miniature versions of phone switches (i.e., devices used in PSTN to control phone calls). PBX devices often aggregate T1/E1 lines (to a PSTN) and can scale to thousands of phones within a company. They use open or proprietary protocols for control and transparent communication for the users.
One downside of PBX technology from an administrator standpoint is that it is generally difficult to configure and maintain, and each vendor has a unique configuration process, so special training is required when working with a new PBX solution. PBX systems also connect and link to remote offices and branch offices that include their own PBX systems. This connection may or may not go through the PSTN, depending on the organizational environment.
One of the advantages of using such a technology is that phone calls between the same business phone systems are free because the entire infrastructure is owned by the company. Call savings are also induced from the fact that the company does not use the entire trunk to the PSTN (i.e., all of the phone lines at one time). Usually, the number of phones in an organization is much greater than the actual trunk size or the overall call volume to the PSTN.
PSTN is composed of a group of digital devices used in the public sector offered by telecommunications companies. PSTN switches are used to connect residential telephones to business users. PSTNs generally use open-standard protocols for control and transparent communication between telephones, circuits, switches, and PBX systems. PSTNs can even link to other PSTNs, PBX systems, or telephones.
As in PBX systems, PSTNs aggregate T1/E1 circuits, but they can scale up to hundreds of thousands of phones. PSTNs connect business BPX systems using switches located in telecommunications companies’ premises.
Figure 9.2 – PSTN and PBX Scenario
Figure 9.2 above is an example of an organization with multiple locations that uses a voice system based on PBX and PSTN technologies. The headquarters location has a PBX that connects to the PSTN on the outside as well as many phones and fax machines inside the network. The connection between the local PBX and the PSTN can be based on one or more T1/E1 lines. The internal network can support a greater number of phones than the number of phone calls supported by the T1/E1 line. The reason for this is that not everyone will use the telephone at the same time, and some of the phone calls will be between internal phones (e.g., phone calls between different departments located at the HQ).
The regional office location also uses a PBX system to connect to the PSTN and it aggregates a few user phones. The branch and remote offices do not use a PBX system because they use few devices (e.g., residential telephones), which do not need special features, and they can connect directly to a PSTN switch. The branch and home office users can have phone conversations with users at the HQ/regional offices because they are all connected by the PSTN.
If the headquarters and the regional office were located in the same campus, the PBX systems could have been connected directly, through a PBX tie trunk, without any link to the PSTN. The connections from the internal phones to the local PBX system are also called station lines. The connection that connects the PSTN switches is called a PSTN switch trunk.
Telephony Signaling
Voice systems also use different kinds of signaling between system nodes, such as the following:
- Signaling between the internal phones and the PBX
- Signaling between the PBX and the PSTN switch
- Signaling between PSTN switches
- Signaling between PBX systems
The signaling between telephones and PBX systems is often called ground start. The most common type of signaling used between PBX systems is called E&M (ear and mouth) signaling. Trunks (PBX to PSTN or PSTN to PSTN) generally use a special type of signaling called Common Channel Signaling (CCS) that can be divided into the following types of signaling:
- E1 signaling
- DPNSS signaling
- ISDN signaling (BRI or PRI)
- QSIG signaling
- SS7 signaling (often used between PSTN switches)
PSTN Numbering Plans
The way PSTNs use their numbering plans defines the fundamental basis for routing voice calls through the PSTN switch matrix. The numbering plans are different for every country and the plans used in North America will be analyzed in the following paragraphs. Numbering plans are based on the ITU-T E.164 recommendation.
Voice routing across the PSTN is tightly coupled with the signaling process and the PSTN numbering plan. Modern PSTN systems offer advantages through the call routing process, including many advanced forwarding features (e.g., call forwarding).
The North American numbering plan is also known as NANP, or the “1+10” plan. The format for this numbering plan is NXX-NXX-XXXX, where “N” is any number between 2 and 9 and “X” is any number between 0 and 9. The number is split into the following three parts:
- The first group of numbers (NXX) represents the Area Code.
- The second group of numbers (NXX) represents the prefix.
- The final four digits (XXXX) represent the line number.
The way phone numbers are represented determines the way they are routed across the PSTN, and this is similar to the IP address representation scheme that determines IP routing mechanisms.
PSTN Services
PSTN offers a wide variety of services to organizations. The most important services are as follows:
- Call center services: This represents a combination of automated systems and individuals that take inbound calls for a wide variety of customer service needs.
- Centrex solutions: These are specialized business solutions that can be outsourced to different organizations that cannot afford investing in their own solution.
- Virtual private voice networks: PSTN emulates PBX-to-PBX connections in order to form a private network of PBX systems.
- Interactive voice response: This technique allows automatic response schemes to be applied when customers call special numbers.
- Voice mail: Voice mail systems allow callers to record voice messages.
Integrated Voice Systems and IP Telephony
Traditionally, the voice solution was a separate architecture from the IP solution. However, modern organizations are driving toward an integrated solution to digitize voice packets and move them over the IP network and the public Internet. This concept was generated because data is much more predominant than voice traffic, and organizations want to lower the overall costs of wide area networking by merging data and voice technologies and leveraging the existing network infrastructure to accommodate voice traffic as well.
Because of the large scale of the PSTN systems, this process is not able to adapt fast enough to keep up with new features and technologies that merge data, voice, and video. In addition, the PSTN architecture was not designed to move data in an efficient manner. The solution to this problem is converting the circuit-switched model, which needs permanent and dedicated circuits between the callers, to a packet-switched environment, which uses bandwidth on an as-needed basis. Integrated networks combine PBX functionalities within voice-enabled routers, which work by connecting the sites using tie lines.
Note: Cisco has been building voice functionality into their routers over the last few years, including extra slots and additional modules.
IP Telephony uses packet voice technology to converge data and voice networks, which is a great improvement in how enterprise networks operate because it saves toll charges on voice telephone calls. The following three underlying protocols are used for converged services:
- Voice over Frame Relay (VoFR)
- Voice over ATM (VoATM)
- Voice over IP (VoIP)
VoIP is also referred to as IP Telephony (IPT) because it integrates IP-based signaling and call control. This is how almost all the new deployments are being implemented.
The first step in designing an IP Telephony solution is isolating the four main IPT components, as follows:
- IPT endpoints
- IPT call processing components
- IPT service applications
- Voice-enabled infrastructure
Figure 9.3 – IP Telephony Components
Referring to Figure 9.3 above, IP Telephony endpoints include components such as IP phones, IPT-enabled workstations (softphones), analog and digital voice gateways, and Digital Signal Processor (DSP) farms. Voice gateways are often used to access PBX systems, analog phones, or other IP Telephony deployments.
The main call processing component in a Cisco voice solution is the Cisco Unified Communications Manager (CUCM), commonly referred to as CallManager. CallManager servers are the brains behind the voice dial plan, and they are used to establish voice calls between IP phones.
Service applications include the following services:
- Auto-attendant
- Interactive Voice Response (IVR)
- Cisco Unity Messaging system for voice mail
- Cisco IP Contact Center (IPCC)
- Standard-based Telephony Application Programming Interface (TAPI) (allows third-party companies to develop applications for CallManager)
The voice-enabled infrastructure includes the following:
- QoS and voice-enabled Layer 2 switches (with or without PoE – Power over Ethernet)
- QoS-enabled Layer 3 switches
- Voice-enabled routers (e.g., Cisco Integrated Services Router family)
IP Telephony Design
IP Telephony replaces the traditional phone system with a newer one that uses IP phones and devices. The new system is built around the CallManager solution, which ensures call processing. IP Telephony can connect to PSTNs but only if the organization is using a gateway device (usually a router) to forward internal calls to the telecommunications company and external calls to the organization.
IP Telephony consists of the following components:
- The underlying infrastructure, composed of Layer 2 and Layer 3 switching, or a combination of both
- Voice-enabled routers (routers with voice modules added)
- Cisco Communications Manager is used as the management software
- Various applications, such as:
- Voice mail
- Interactive response
- Automated attendant
- Client-side devices (IP telephones or softphones)
Note: IP telephones can be powered via Ethernet either by connecting them to a PoE-capable switch or by using special power adapters. PoE connections are recommended because they improve on efficiency by using fewer cables.
The main goals of IP Telephony include ensuring end-to-end IP telephone services, reducing long distance costs, ensuring a more efficient WAN infrastructure, lowering total costs of ownership, increasing employee productivity, and being able to use newer technology and applications.
Network designers must be aware of the following IP Telephony deployment models:
- Single-site design
- Multisite centralized WAN call processing design
- Multisite distributed WAN call processing design
- Internet IP Telephony design
- CallManager Express deployment
Single-Site Design
The single-site deployment model (Figure 9.4) is used by enterprises that own a single large building (no remote sites) or a campus area with no voice technologies being transported on the WAN links. A single CallManager node is deployed at the enterprise campus server farm block.
The main component of a single-site IP Telephony solution is the CallManager node. This is actually a server platform that can be installed on a wide variety of hardware devices (i.e., the call processing software component for the Cisco IP Telephony solution for enterprises).
Note: CallManager was originally part of the Cisco AVVID (Architecture for Voice, Video, and Integrated Data) initiative.
The Cisco IP Telephony application server is a high availability server platform purchased by the company to be used as a platform for the Cisco CallManager solution. Cisco offers a compatibility matrix that helps customers choose the appropriate hardware platform that will be used with CallManager implementation.
Figure 9.4 – IP Telephony Single-Site Design
The CallManager application system brings enterprise telephony functionality and offers advanced features to various telephony devices, such as IP telephones, media processing devices, VoIP gateways, and multimedia applications.
Other components of the single-site IP Telephony design are IP telephones and switches that have inline power functionality (e.g., PoE) used to power the IP phones. Voice-enabled routers are also present in the design, and they are usually located in the same physical location with all the other devices presented previously.
If the organization wants to make calls to the outside world, a PSTN connection is required, using a gateway voice trunk between the local voice-enabled router and the PSTN provider.
Voice mail services can be covered using the Cisco Unity solution, with unified messaging included as an option. Cisco CallManager can support thousands of user IP phones, and these endpoints can be deployed using PoE from the LAN switches.
Note: CallManager nodes can be deployed either as single servers or as server clusters that will share the call processing load and ensure redundancy.
Multisite Centralized Design
Centralized IP Telephony (Figure 9.5) is a low-cost design for medium-sized enterprises that have one large location and multiple remote sites. The central location hosts the Cisco Communications Manager server and all the important applications (e.g., voice mail), and the remote locations host only voice switches (with PoE) and IP telephones. This design allows remote site IP Telephony functionality to be controlled from the central location, without the need for dedicated CallManager servers at each location. All the features are managed from the central site. The CallManager node is deployed only at the central location and it usually includes a multi-server cluster redundant architecture. The remote site IP phones register with the CallManager from the main site.
Figure 9.5 – Multisite Centralized IP Telephony Design
The PSTN connection is also hosted by the central site, and the voice-enabled router is connected through WAN to each remote location. The remote office uses IP connectivity to connect to the central site through the WAN connection and to access all the IP Telephony services. Since the IP phones convert voice to IP, the remote site router does not have to include any special capability. However, the router located in the central location must be a voice-enabled router because it also connects to the PSTN.
Remote sites may use voice-enabled gateway routers with Survivable Remote Site Telephony (SRST) functionality that allows them to function even if the connection to the central site is down.
Another issue that should be considered when implementing a multisite centralized solution is the need for QoS mechanisms on the WAN connection that is usually low speed. VoIP packets should be prioritized over other packet types in order to ensure an acceptable user experience.
Multisite Distributed Design
The multisite distributed architecture (Figure 9.6) is a solution used by large enterprises that have several large locations. This design involves deploying several CallManager clusters for redundancy, which can include one cluster per site or several clusters only in the large sites. Inter-cluster trunks are configured to establish communications between CallManager nodes.
Figure 9.6 – Multisite Distributed IP Telephony Design
This deployment model is similar to the multisite centralized deployment type, with IP phones and voice-enabled switches installed at every site. This solution is very flexible and allows voice application services to be deployed in a single location or in every location that has a CallManager cluster.
Internet IP Telephony Design
Internet IP Telephony (Figure 9.7) is another design type commonly used, and it involves connecting the central and remote sites through an ISP. This ensures end-to-end IP Telephony across all sites; in addition, there is no PSTN connection at any of the enterprise sites.
Figure 9.7 – Internet IP Telephony Design
The central site still hosts the CallManager node and application servers, but regular routers are used in all network locations because of the lack of connectivity to the PSTN – all the inter-site links are plain IP connections. Another difference from the centralized IP Telephony design is that all the enterprise sites have their own CallManager node. For proper voice traffic to cross between sites, the ISP must ensure a proper connection, with low latency and delay. This can be enforced through a strict SLA when signing the Internet connectivity contract (e.g., the ISP must use QoS techniques in order to give priority to voice traffic).
CallManager Express Design
The CallManager Express deployment (Figure 9.8) provides companies with the Express version of Cisco CallManager, Unity, and Contact Center solutions. CallManager Express (CME) and Cisco Unity Express can be installed on routers to provide limited functionalities of the Communications Manager solution. PSTN connectivity can be offered by a dedicated gateway router or by the CME router to further reduce costs.
Figure 9.8 – CallManager Express IP Telephony Design
Cisco CallManager Express supports a limited number of users (around several hundred), as opposed to the enterprise-level solution that can scale up to tens of thousands of users. This is a lower cost solution for small branch offices.
VoIP Control and Transport Protocols
Network designers should understand the protocols that are used for VoIP control and transport. The most important protocols are as follows:
- DHCP: The Dynamic Host Configuration Protocol is used to establish IP configuration parameters on IP phones. This includes the IP address, the subnet mask, and other options.
- DNS: The Domain Name System obtains IP addresses (by using name resolution) for the TFTP servers that will provide different configuration files.
- TFTP: The Trivial File Transfer Protocol stores configuration files that will be accessed by the IP phones.
- SCCP: The Skinny Call Control Protocol is used for call establishment.
- RTP: The Real-time Transport Protocol is used for voice stream or voice station-to-station traffic in ongoing calls.
- RTCP: The Real-time Transport Control Protocol is used for VoIP call control. RTP and RTCP are covered in RFC 1889.
- MGCP: The Media Gateway Control Protocol is used for call establishment with gateways and is covered in RFC 3435.
- 323: This is another call establishment protocol suite that supports multimedia streams (voice and video).
- SIP: The Session Initiation Protocol is a protocol defined by the IETF and specified in RFC 2543. SIP is an alternative multimedia framework to H.323. This was developed specifically for IP Telephony, with the purpose of replacing H.323, and it is supported on Cisco IP phones and gateways. SIP is an Application Layer control signaling protocol for generating, modifying, and terminating Internet multimedia conferences, Internet telephone calls, and multimedia distribution.
The first step in understanding IP Telephony involves understanding the ITU-T H.323 standard. This is the umbrella protocol for all the audio, video, and data (multimedia) services over IP networks, used by different vendors and applications.
H.323 is implemented in terminals (e.g., IP phones), workstations with softphones installed (programs that emulate IP phone functionality), gateways (voice-enabled routers or switches), gatekeepers (management nodes that can be Cisco routers or third-party software), and other conferencing software.
The H.323 standard uses the following protocols to ensure its functionality:
- 931 for call setup
- 225 for signaling
- 245 for control
- 255 for registration, admission, and status
H.323 also uses the CODEC (coder-decoder) functionality and this has two flavors. A CODEC can be an integrated device that uses PCM to transform analog signals into digital signals. On the other hand, in VoiP, Frame Relay, and ATM, CODECs are software algorithms used to compress and decompress audio signals.
IP Telephony Design and Control Issues
VoIP calls must meet recommended bandwidth and delay parameter values. The necessary amount of bandwidth generally depends on the following three factors:
- The codec used
- The Layer 2 protocols used
- Voice Activity Detection (VAD)
IP Telephony can be based on the following codec standards:
- 711 (G.711a or G.711u), which offers high quality but requires a high bit rate per call (64 kbps)
- 723, which requires 16 kbps per call
- 729, which requires the least amount of bit rate per call (8 kbps)
Codecs are used because voice is an analog signal by default and it must be converted into digital signals before it is transmitted digitally. PCM was the first modulation and encoding technique, and it is covered by the G.711 standard. When choosing the right codec for a VoIP solution, you must carefully analyze the quality versus bandwidth tradeoff. If you want high voice quality, you must ensure a high amount of bandwidth. G.729 is the proper solution for low bandwidth WAN connections. Bandwidth is also affected by the Layer 2 protocols used, which might include Frame Relay and ATM.
The use of VAD also influences the bandwidth in IP Telephony solutions. A typical voice conversation can contain up to 60% of silence, and VAD works by suppressing the silent parts of a conversation in both directions. In circuit-switched networks, all voice calls use a fixed amount of bandwidth (64 kbps), regardless of the speech-to-silence ratio. On multiservice networks, the entire conversation (including the silence) is transformed into digital packets, so using VAD can suppress the packets of silence so the bandwidth is used more efficiently (tests have shown that at least 35% of the bandwidth is saved). By default, VAD is enabled in Cisco IPT devices.
Note: When designing the VoIP network, the total bandwidth used for voice, data, and video should not exceed 75% sustained on the provisioned link capacity during peak hours.
The recommended codec to be used on slow-speed WAN connections is G.729 because it has lower bandwidth requirements.
IP Telephony network designers must be aware of the major voice control issues present in IP environments. These issues can be divided into the following categories:
- Packet loss
- Packet delay
Most user applications work fine when the one-way delay does not exceed 150 ms, and in some environments, this threshold can even reach 300 ms. Anything above that is generally considered unacceptable when planning for IP Telephony. The following types of delay exist in a regular network:
- Fixed network delay, or propagation delay
- Serialization delay
- Processor delay
- Queuing delay
Propagation delay, which expresses the length of time it takes for a packet to travel between the sending and receiving device, usually can be ignored in many environments.
Serialization delay is a fixed delay that a voice or data frame will experience when it is sent on a network interface. This is directly related to the link speed and is a measure of the time it takes for a unit of data, such as a packet, to be serialized for transmission on a narrow (e.g., serial) channel, such as a cable. Serialization delay is dependent on size, which means that longer packets experience longer delays over a given network path. It is also dependent on channel capacity (i.e., bandwidth), which means that for equal-sized packets, the faster the link, the lower the serialization delay. If serialization delay occurs frequently on some devices, bandwidth might need to be increased. This most often occurs when using links less than 1 Mbps.
Processor delay is another fixed delay value that depends on the type of codec used and the time it takes for the packet to be compressed and decompressed. Processing delay includes coding, compression, decoding, and decompression delays. For example, G.729 has a delay of 50 ms.
Voice-enabled router interfaces are configured with a wide variety of input and output queues that generate additional delay (while the packet waits to exit the queue and be transmitted). Queuing delay can be reduced by applying efficient QoS mechanisms, including traffic shaping.
In addition to delay, another important parameter that will affect voice traffic is jitter, which represents a variation in the delay of the received packets. When sending packets in a continuous stream, they are usually spaced out in an even fashion, but this packet spacing might be broken by congestion on the network or by configuration errors. This means the amount of time that passes between packets received at the destination is not constant (in other words, packets arrive at irregular intervals).
Voice-enabled routers have built-in dejitter buffers (i.e., playout delay buffers) that usually handle this issue. The network designer must ensure that the implementation team properly configures the voice-enabled routers and that the most effective QoS mechanisms are used. Another reason jitter generation occurs is when packets take different redundant paths to get to the destination (so they might not arrive at a constant rate because congestion might occur in the network). The receiving end uses dejitter buffers to smooth the delay of the received voice packets. These buffers change the variable delay into fixed delay.
Echo is another issue that might affect voice traffic, and this occurs when a proportion of the speaker’s voice is reflected back (i.e., the speaker hears a delayed copy of his or her own voice). Another type of echo is when the speaker’s voice is reflected back and then re-reflected toward the listener (i.e., the listener hears two or more copies of the speaker’s speech). A small amount of echo is acceptable but if this happens on a large scale, echo cancelation techniques should be implemented. Echo cancellers are components that are used mainly on voice gateways.
QoS Design Considerations for Voice Transport
Network designers should use general guidelines for designing QoS for voice transport. These QoS techniques are applied when using WAN connections equal to T1 or lower. When using high-bandwidth connections, you do not need to think about QoS techniques because congestion is less likely to occur.
QoS techniques are most effective on bursty WAN connections, typically in Frame Relay environments where committed information rates and burst rates are usually specified in the contract. Traffic bursts occur when large packets are sent over the network, or when the network is very busy during certain periods of the day. QoS techniques should be mandatory if the enterprise uses any kind of delay-sensitive applications, for example, applications that must function in real time (i.e., presentations over the Internet or video training sessions).
Congestion management should be considered only when the network experiences congestion, and this should be planned by analyzing the organizational policies and goals and following the network design steps (PPDIOO). Before applying any QoS configuration, traffic should be carefully analyzed in order to detect congestion problems. The best QoS mechanism should be chosen by consulting with the implementation team, and this can include packet classification and marking, queuing techniques, congestion avoidance techniques (traffic shaping or policing), or bandwidth reservation mechanisms (RSVP).
Network designers should also be familiar with the most important QoS mechanisms available for IP Telephony, which are as follows:
- cRTP
- LFI
- PQ-WFQ
- LLQ
- Auto QoS
cRTP (compressed Real-time Transport Protocol) is a compression mechanisms that reduces the IP, UDP, and RTP headers’ size from 40 bytes to 2 or 4 bytes. cRTP is configured on a link-by-link basis, and Cisco recommends using this technique for links that are lower than 768 kbps.
Note: cRTP should not be configured on devices that have high processor utilization (above 75%).
LFI is a QoS mechanisms used to reduce serialization delay. PQ is also referred to as IP RTP priority. This adds a single priority queue to the WFQ technique, which is used for VoIP traffic. All the other traffic is queued based on the WFQ algorithm. When using PQ, the router places VoIP RTP packets in a strict priority queue that is always serviced first.
LLQ is also known as PQ-CBWFQ, and it provides a single priority queue, which is preferred over the PQ-WFQ technique, to guarantee bandwidth for different classes of traffic. All voice call traffic is assigned to the priority queue, while VoIP signaling and video traffic is assigned to its own traffic classes. For example, FTP can be assigned to the low-priority traffic class, while all other data traffic can be assigned to a regular class.
Auto QoS is a recent Cisco IOS feature that uses a very simple command line interface to enable Quality of Service for VoIP in WAN and LAN environments. This is a great feature to use on Cisco ISR routers (routers that integrate data and media collaboration features) because it provides many capabilities to control the transport of VoIP protocols. Auto QoS inspects the device capabilities and automatically enables LFI and RTP where necessary. It is usually used in small- to medium-sized businesses that need to deploy IPT fast because they do not have experienced staff that can plan and deploy complex QoS features. Large customers can also deploy IPT using Auto QoS but the auto-generated configuration should be carefully revised, tested, and tuned to meet the organization’s needs.
Note: QoS techniques should be carefully configured on all the devices involved in voice transport, not just on individual devices.
IP Telephony Design Best Practices
The following are considered best practices for designing IP Telephony:
- Separate voice traffic into its own subnets and VLANs
- Use private addressing (RFC 1918) for IP phones, combined with NAT/PAT if necessary
- Strategically place the IP Telephony servers on filtered VLANs in the data center; this may be achieved by using Cisco ASA devices, but private VLANs can also be used
- Use QoS IP precedence or DSCP for packet classification and markings
- Use LLQ on WAN links
- Use LFI on slower WAN links
- Use Call Admission Control (CAC) mechanisms to avoid oversubscribing priority queues. CAC is used to keep excess voice traffic from the network by rerouting it through alternative network paths or to the PSTN. The main goal of CAC is to protect voice traffic from being affected by other voice traffic.
Integrated Video Systems Considerations
Video traffic has the same requirements and design consideration as voice traffic does. Voice and video applications can be grouped in the multimedia traffic category, and in many cases, they should be treated similarly by network devices. This involves ensuring the necessary bandwidth and providing low delay, jitter, and packet loss.
Media applications underwent a significant development process regarding IP networks, resulting in many different combinations of audio, video, and data media. Video streams can range from low-definition webcams to high-definition enterprise-level videoconferencing systems. As demand for quality video increases, network infrastructure requirements must also increase.
Companies might have another source of media streams on their network, in the form of unmanaged (not business critical) applications. These applications are aimed mainly at consumers and corporate employees and might be denied by certain corporate policies. This category includes video streaming sites such as YouTube, which can be useful to employees for documentation and training purposes.
In response to the explosion of media content and applications, network designers must revise their media application provisioning strategy. Without a properly selected strategy, the network infrastructure might not support all the multimedia traffic that is demanded by users, and the network could easily become congested.
Common high-resolution video formats include 720i, 720p, 1080i, and 1080p. The numerical value of the format represents the number of rows in the frame. High-definition video uses a 16:9 aspect ratio, which results in 1,920 columns. The most common video formats and typical bandwidth usages are summarized below:
| Format | Typical Bandwidth |
| QCIF | 260 kbps |
| CIF | 512 kbps |
| 4CIF | 1 Mbps |
| 720 HD | 1 to 8 Mbps |
| 1080 HD, H.264 | 5 to 8 Mbps |
| 1080 HD, MPG2 | 12 Mbps |
Another factor that impacts the network load is the video encoder used. H.264 encoders provide high flexibility when used in video streams. It uses higher video compression rates than other protocols and, at the same time, improves video resolution quality.
Summary
Many of the modern enterprise network designs must accommodate the transmission of voice traffic in addition to data traffic. The transmission of voice over a data network is often referred to as Voice over IP (VoIP). The inclusion of VoIP in a network design typically requires integration with existing telephony services and connectivity to the Public Switched Telephone Network (PSTN).
When you speak into an analog phone, your voice is converted into an analog waveform. However, telephony networks cannot maintain voice quality when sending analog waveforms over long distances. Therefore, telephony networks convert analog waveforms into digital signals, which can be transmitted over great distances.
The steps for converting an analog waveform into a digital signal include the following:
- Filtering
- Sampling
- Digitizing
Just as a router can make decisions about how packets should be forwarded through a network (e.g., based on an IP address), a telephone switch makes call routing decisions (e.g., based on a dialed telephone number) before forwarding a voice call through a telephony network. Although the PSTN contains a series of telephone switches, organizations can have their own telephone switches. An example of a privately owned switch is a Private Branch Exchange (PBX). Although a PBX does not scale to the degree a PSTN switch does, PBX does offer enhanced telephone features to organizations (e.g., call hold, conferencing, transferring, music on hold, call forwarding, call parking, and voice mail). In addition, PBX vendors often use their own proprietary call signaling protocols, whereas PSTN switches use standards-based signaling protocols.
Signaling information can be communicated over analog or digital connections. Common types of analog signaling include the following:
- Loop start signaling
- Ground start signaling
- E&M signaling
Just as data networks can benefit from hierarchical IP addressing, telephony networks often benefit from a hierarchical numbering plan. A numbering plan is a set of rules that dictates how telephone numbers are assigned and how voice calls are routed. For example, consider the North American Numbering Plan (NANP). NANP numbers use a numbering format of NXX-NXX-XXXX, where “N” can be any digit from 2 to 9 and “X” can be any digit from 0 to 9. In North America, the first digit pattern NXX is an area code. The next NXX pattern represents the local office code, and the final XXXX pattern represents the subscriber’s number. Notice that in North America, neither an area code nor an office code can begin with a 0 or a 1.
Traditionally, organizations kept their voice, data, and video networks separate. As a result, a data burst on the data network had no adverse effect on voice traffic. However, with the advent of higher bandwidth and more reliable QoS-enabled networks, network designers are beginning to see the utility of combining voice, data, and video on the same converged network.
An IP Telephony network transmits voice and signaling traffic in IP packets. IP Telephony networks include IP-based voice devices, for example, IP phones that contain an Ethernet port and connect directly to a network.
IP Telephony networks require gateways to convert voice and signaling information between the traditional telephony environment (e.g., a PBX or the PSTN) and the IP environment. These gateways communicate using gateway control protocols (sometimes called call control protocols).
The most mature of the gateway control protocols is H.323. The H.323 standard not only defines a suite of protocols but also includes hardware specifications for physical components in an H.323 network.
An IP Telephony network has the following core components:
- Client devices
- Call processing
- Applications
- Infrastructure
Because many organizations have multiple locations, their IP Telephony networks might span across those locations. When determining how IP Telephony components should be deployed, consider the following deployment models:
- Single-site design
- Multisite centralized design
- Multisite distributed design
- Internet IP Telephony design
- CallManager Express design
Although H.323 is a very popular gateway control protocol for IP Telephony and VoIP networks, consider some of the other protocols that might be included in IP Telephony or VoIP networks, such as the following:
- RTP (Real-time Transport Protocol)
- SCCP (Skinny Call Control Protocol)
- SIP (Session Initiation Protocol)
- MGCP (Media Gateway Control Protocol)
When designing a network to accommodate voice traffic, consider what could impact the quality of the voice and which mechanisms might be used to maintain voice quality. When voice and data traffic are competing for limited bandwidth, the following quality issues might arise:
- Delay
- Jitter
- Packet loss
To combat the quality issues described earlier, various QoS mechanisms available on Cisco routers and switches can be implemented. For example, on wiring closet Catalyst switches, voice and data traffic can be placed in separate queues. Catalyst switches can also be configured to take into account the priority markings in voice packets. QoS mechanisms include the following:
- Classification and marking
- Congestion management
- Congestion avoidance
- Traffic shaping and policing
- Link efficiency mechanisms
