Voice over IP Design Considerations

Introduction

In the previous section, you learned about the configuration of a basic VoIP network. However, additional considerations are required. In this section, you examine various VoIP design considerations and are introduced to two additional voice-over-data technologies: Voice over Frame Relay (VoFR) and Voice over ATM (VoATM).

RTP

Consider the characteristics of IP networks. They are considered to be “connectionless,” meaning that the IP protocol by itself does not provide guaranteed packet delivery. Also, thanks to various routing protocols, IP networks can support multiple paths between a source and destination; this provides load balancing and fault tolerance.

Voice packets use a Layer 4 protocol, called the Real-Time Transport Protocol (RTP). RTP is encapsulated within the User Datagram Protocol (UDP), another Layer 4 protocol that is connectionless. Because these RTP packets travel over an IP network, with multiple paths, the packets can arrive at different times. Fortunately, RTP provides sequence number information so that the far side of a VoIP call can reorder voice packets.

However, other quality issues must be addressed on a VoIP network. The three main quality challenges are as follows:

• Delay—Delay is the time that is required for a packet to travel from its source to its destination. You might have witnessed delay on the evening news, when the news anchor is talking through a satellite to a foreign news correspondent. Because of the satellite delay, the conversation might have seemed unnatural.

• Jitter—Jitter is the uneven arrival of packets. For example, consider that in a Voice over IP (VoIP) conversation, packet 1 arrives. Then, 20 ms later, packet 2 arrives. After another 70 ms, packet 3 arrives, and then packet 4 arrives 20 ms behind packet 3. This variation in arrival times (that is, variable delay) is not dropping packets, but this jitter can be interpreted by the listener as dropped packets.

• Drops—Packet drops occur when a link is congested and a buffer overflows. Some types of traffic, such as UDP traffic (for example, voice), are not retransmitted if packets are dropped.

In the section “Ensuring Voice Quality,” later in these Quick Reference Sheets, a variety of the Cisco quality of service (QoS) solutions address these quality issues.

VoFR and VoATM

In addition to Voice over IP, you can encounter a Voice over Frame Relay (VoFR) or Voice over ATM (VoATM) network. Whereas VoIP networks forward voice traffic based on Layer 3 information (that is, an IP address), VoFR and VoATM networks forward voice traffic at Layer 2. Specifically, instead of having the session target command specify a remote IP address, VoFR uses the session target command to point to a local Data Link Connection Identifier (DLCI). In a similar fashion, VoATM uses the session target command to forward voice traffic to a local virtual path identifier/virtual channel identifier (VPI/VCI).

Although forwarding voice traffic at Layer 2 offers the advantage of eliminating Layer 3 overhead (that is, IP header, UDP header, and RTP header), VoFR and VoATM networks do not offer the ability to load-share across multiple paths, as VoIP networks do. Also, you can lose some redundancy in your design, because VoFR and VoATM do not use multiple paths.

Although bandwidth requirements are due in large part to the codec that you select, bandwidth demands also vary based on the transport (for example, FR or ATM) that you use. You can use the following formula to calculate per-call bandwidth requirements for a VoFR circuit:

Per_Call_Bandwidth = Codec_Bandwidth * (Payload + Overhead) / Payload

The units of measure for Codec_Bandwidth are bps, whereas the Payload and Overhead parameters are measured in bytes. Note that the default payload size that is used by G.729 on a VoFR network is 30 bytes.

Cisco provides a web-based Voice Bandwidth Calculator to calculate bandwidth requirements for VoFR, VoATM, and VoIP calls. The calculator, which requires a Cisco.com login, is available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.

Each asynchronous Transfer Mode (ATM) cells is 53 bytes in size: 48 bytes of payload and 5 bytes of header. If your voice payload does not consume all 48 payload bytes in a cell, the remainder of those 48 bytes is filled with “padding,” which can lead to inefficient bandwidth usage. The following formula is used to calculate the per-call bandwidth requirements for a VoATM circuit:

Per_Call_Bandwidth = Codec_Bandwidth * (Number_of_Cells * 53) / Payload

Note that whereas the G.711 codec requires six ATM cells to send a single voice sample, the G.729 codec requires only one cell per voice sample.

Gateway Considerations

When selecting a gateway (GW) for a VoIP network, consider the following items:

• Do you need an analog or digital gateway?

• What specific ports are required on the gateway?

• What signaling protocol does the gateway need to support?

• Does the gateway need to support Survivable Remote Site Telephony (SRST)?

Voice Protocols

Gateway protocols that you should be familiar with include H.323, the Media Gateway Control Protocol (MGCP), and the Session Initiation Protocol (SIP). Session protocols map to Layer 5 (that is, the session layer) of the OSI model. The session layer is responsible for the setup and teardown of sessions. In the voice environment, you can use these gateway control protocols to set up and tear down voice sessions. In the next section, you learn about each of these protocols.

Voice packets are transmitted using the Real-time Transport Protocol (RTP). A companion protocol, called the Real-Time Transport Control Protocol (RTCP), can monitor the quality of an RTP stream. Both RTP and RTCP operate at Layer 4 and are encapsulated in UDP. UDP ports 16,384 to 32,767 are used by RTP and RTCP. However, RTP uses the even port numbers in that range, whereas RTCP uses the odd port numbers.

One of the challenges with RTP is its overhead. Specifically, the combined IP, UDP, and RTP headers are approximately 40 bytes in size, and the typical voice payload size on a VoIP network is only 20 bytes, which includes 20 ms of voice by default. In this case, the header is twice the size of the payload. Fortunately, Cisco supports RTP Header Compression (cRTP), which can reduce the 40-byte header to 2 or 4 bytes in size (depending on whether UDP checksums are in use).

Because cRTP requires router processor resources, you should not enable it in every instance. Specifically, Cisco recommends that you enable cRTP on slow link speeds (that is, speeds of less than 2 Mbps) or when you need to optimize your bandwidth usage on a WAN interface.

Bandwidth Considerations

In the section “Digitizing the Spoken Voice,” earlier in these Quick Reference Sheets, you reviewed the codec bandwidth requirements for the G.711 and G.729 codecs, as follows:

• G.711 (64 kbps of bandwidth required for voice payload)

• G.729 (8 kbps of bandwidth required for voice payload)

However, other factors impact the overall bandwidth requirements for voice traffic. For example, the decision of whether to use cRTP can impact the overall bandwidth requirements dramatically. Layer 2 header sizes can vary also. For example, whereas Ethernet has an 18-byte Layer 2 header, both Multilink PPP (MLP) and Frame Relay require only 6 bytes for their Layer 2 header.

In a tunneling environment, you might need to consider the overhead of such protocols as IP Security (IPSec) (50- to 57-byte overhead) and Layer 2 Tunneling Protocol/generic Routing encapsulation (L2TP/GRE) (24-byte overhead). Also, in a service provider environment, you can use Multiprotocol Label Switching (MPLS), which has 4 bytes of overhead.

When you read about the G.729b codec, the concept of voice activity detection (VAD) was introduced. When you have multiple simultaneous conversations (that is, approximately 24 or more), you can benefit from the economies of scale that are offered by VAD to reduce the overall bandwidth consumption. Although you should not use this number for design purposes because VAD’s benefit varies with speech patterns, you can enjoy bandwidth savings on the order of a 35 percent reduction when using VAD.

Security Considerations

As another design consideration, you must ensure that your VoIP solution can function in the presence of an enterprise’s existing security infrastructure. The Cisco model for security design is called SAFE (Secure Architecture For Enterprise). The main goal of the SAFE blueprint is to provide best-practice information for designing and implementing secure networks. Specifically, the SAFE blueprint seeks to detect and defend against intrusions into the network, to control which traffic can enter and leave the network, and to protect data as it travels through the network. For more information on the Cisco SAFE blueprint, consult http://www.cisco.com/go/safe.

An enterprise network might already have a firewall and a Virtual Private Network (VPN) concentrator in place when you decide to overlay voice traffic on that network. A firewall maintains a set of rules that specify which protocols you can use to communicate from specific outside devices to specific inside devices, and vice versa. The challenge with establishing a voice call through a firewall is that the UDP port that is negotiated for the voice stream varies from session to session. Specifically, voice streams can use any even-numbered UDP port in the range 16,384 to 32,767. Therefore, a “stateful” firewall is required to monitor this negotiation and to open the appropriate port. The Cisco PIX firewall product is an example of a stateful firewall.

One way to protect voice packets from eavesdropping is to send them through a VPN connection. A VPN is a tunnel over which you can send encrypted packets. As a result, if the voice packets were intercepted, they would be worthless to anyone who intercepted the packets, because the packets are encrypted.

Various VPN mechanisms exist. For example, you can use Layer 2 Tunneling Protocol (L2TP) at Layer 2 or IPSec at Layer 3. Because various VPN technologies have different header sizes, your overall voice bandwidth requirements vary with the VPN technology that you select. However, as a rule, you typically add 30 to 60 bytes of overhead per VoIP packet when you transmit the packet over a VPN.