Cisco Press CCVP CVOICE Quick Reference

Chapter 1: Understanding VoIP Basics . . . . . . . . . . . . . . . . . . .2 Chapter 2: Addressing VoIP Design Considerat...

Author: Wallace Kewin

23 downloads 615 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Chapter 1: Understanding VoIP Basics . . . . . . . . . . . . . . . . . . .2 Chapter 2: Addressing VoIP Design Considerations . . . . .16 Chapter 3: Understanding and Configuring Analog Voice Ports . . . . . . . . . . . . . . . . . . . . . . . . . .33 Chapter 4: Understanding and Configuring Digital Voice Ports . . . . . . . . . . . . . . . . . . . . . . . . . .48

CCVP CVOICE Quick Reference Second Edition

Chapter 5: Exploring Gateway Control Protocols . . . . . . . .60 Chapter 6: Working with Dial Plans . . . . . . . . . . . . . . . . . . . . .70 Chapter 7: Implementing Advanced Dial-Plan Features . . . . . . . . . . . . . . . . . . . . . . . . . .85 Chapter 8: Understanding and Configuring Gatekeepers . . . . . . . . . . . . . . . . . .100

Kevin Wallace

ciscopress.com

Chapter 9: Interconnecting VoIP Networks with a Cisco Unified Border Element . . . . . . . .119

[2] CCVP CVOICE Quick Reference, Second Edition by Kevin Wallace

CHAPTER 1 Understanding VoIP Basics

Chapter 1 Understanding VoIP Basics Modern enterprise network designs need to support the transmission of voice traffic. This voice traffic can come from analog phones (much like the phones typically found in homes) or IP phones, which are Ethernet devices that transmit voice IP packets. Because the analog phones cannot generate IP packets, they connect to analog gateways (such as Cisco routers) that convert the spoken-voice IP packets. The term Voice over IP, or VoIP, is used to describe the transmission of voice over a network using voice-enabled routers. The term IP telephony refers to the use of IP phones and a call processing server (for example, Cisco Unified Communications Manager [UCM]). However, because many voice-enabled networks contain both VoIP and IP telephony components, these terms are often used interchangeably. This chapter introduces you to the basics of VoIP networks. Specifically, you will be introduced to a collection of VoIP components and protocols, review a collection of Cisco VoIP router platforms that can act as VoIP gateways, and investigate approaches for deploying call routing intelligence across multiple sites.

VoIP Components and Protocols A VoIP network relies on a collection of specialized hardware and protocols. This section examines some of the primary components found in today’s VoIP networks, in addition to the signaling protocols and media protocols that are responsible for setting up and transmitting the spoken voice via IP packets.

© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



VoIP Components Figure 1-1 shows the basic components of an IP telephony network. FIGURE 1-1

IP Phone

IP Telephony Network

PSTN

Ethernet Switch V

Call Agent

MCU

PBX V Gateway/Gatekeeper

Unified Videoconference Messaging Station Server

IP WAN

V Gateway

Analog Phone

n

IP phone: Provides IP voice to the desktop.

n

Gatekeeper: Provides call admission control (CAC), bandwidth control and management, and address translation.

n

Gateway: Provides translation between VoIP and non-VoIP networks, such as the public switched telephone network (PSTN). A gateway also provides physical access for local analog and digital voice devices, such as telephones, fax machines, key sets, and PBXs.

n

Multipoint control unit (MCU): Mixes audio/video streams, thus allowing participants in multiple locations to attend the same conference.



CHAPTER 1 Understanding VoIP Basics n

Call agent: Provides call control for IP phones, CAC, bandwidth control and management, and address translation. A Cisco UCM server often serves as a call agent in a Cisco IP telephony deployment.

n

Application server: Provides services such as voice mail, unified messaging, and Cisco UCM Attendant Console.

n

Videoconference station: Provides access for end-user participation in videoconferencing. The videoconference station contains a video capture device for video input and a microphone for audio input. The user can view video streams and hear the audio that originates at a remote user station. Cisco targets its Unified Video Advantage product at desktop videoconferencing applications.

Other components, such as software voice applications, interactive voice response (IVR) systems, and softphones, provide additional services to meet the needs of enterprise sites. For VoIP networks to replace traditional telephony networks (for example, PBX telephony networks), VoIP needs to offer a collection of services and features that help make the migration to a VoIP environment transparent to the end user. These features and services include the following: n

Signaling: Signaling information can help set up, maintain, and tear down a voice call. This information can be transmitted using a series of signaling bits (commonly referred to as A, B, C, and D bits), or a signaling protocol can be used. Signaling System 7 (SS7) is a signaling protocol commonly used between central office (CO) locations. However, within a VoIP network, the signaling protocol is probably H.323, Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), or Skinny Client Control Protocol (SCCP).

n

Database services: Database services can add flexibility to a VoIP network. For example, a database could be used to help automate wake-up calls in a hotel environment or school closure announcements in an educational environment.

n

Bearer control: A channel carrying voice traffic (that is, the actual voice payload, as opposed to voice signaling traffic) is referred to as a B channel, or a bearer channel. To have a B-channel setup, some sort of signaling is required. This bearer control function is sometimes performed by dedicated signaling protocols.




Codecs: A coder/decoder (that is, a codec) can convert between an analog waveform, such as a waveform produced by human speech, and a digital representation of that waveform. Some codecs (for example, G.711) digitally represent an analog waveform without performing any compression. Although such a lossless encoding preserves voice quality, it requires more bandwidth than a codec (for example, G.729), which does compress the spoken voice. Because of the bandwidth savings they offer, codecs that perform compression are often an appropriate codec choice for traffic traversing an IP WAN.

VoIP Signaling Protocols To expand your understanding of signaling protocols, realize that VoIP gateways use signaling protocols (also called gateway control protocols) to set up, maintain, and tear down a call between themselves or with other devices, such as a Cisco UCM server. Consider some common VoIP signaling protocols: H.323, MGCP, SIP, and SCCP.

H.323 H.323 is the most mature of the VoIP signaling protocols, and it is considered to be a peer-to-peer protocol, because the endpoints in an H.323 network (for example, an H.323 gateway) can have their own call routing intelligence configured. The H.323 standard is not a single protocol, but rather a suite of protocols and specifications for physical components in an H.323 network. Among the H.323 protocols used for call setup are the following: n

H.225.0: The H.225.0 protocol (often written as H.225) has a couple of functions. H.225.0 can use TCP to send the initial call setup message between a couple of H.323 endpoints. Also, H.225.0 can use UDP for communication with an H.323 gatekeeper (which can be used to resolve phone numbers to IP addresses and grant or deny a call to be placed, based on bandwidth availability).

n

H.245: When the H.225.0 protocol initiates the call setup process between two H.323 endpoints, the H.245 protocol negotiates the parameters of the call (for example, how the voice will be encoded and what UDP ports to use when sending voice traffic).




In the topology shown in Figure 1-2, an H.323 gateway interconnects the PSTN with a corporate IP telephony environment. Notice an Integrated Services Digital Network (ISDN) circuit is coming into the gateway. ISDN uses the Q.921 protocol for Layer 2 signaling and the Q.931 protocol for Layer 3 signaling. Notice that both the Layer 2 and Layer 3 signaling streams are terminated at the H.323 gateway and converted into corresponding H.323 messages. FIGURE 1-2

Q.931

H.323 Gateway

H.323

Switch

Q.921

V H.323 Voice GW

ISDN

Public Switched Telephone Network (PSTN)

UCM Cluster

Session Initiation Protocol Like H.323, SIP is a peer-to-peer gateway control protocol that is popular in many mixed-vendor environments. When you are adding Cisco IP telephony components to an existing third-party IP telephony network, SIP might serve as an appropriate gateway control protocol. As discussed later, SIP uses a series of plain-text messages for call control. Also like H.323, a SIP gateway terminates Q.921 and Q.931 signaling streams coming in over an ISDN circuit. The SIP gateway then converts those ISDN signaling messages into corresponding SIP messages, which are then sent to the UCM cluster, as shown in Figure 1-3. FIGURE 1-3

Q.931

SIP Gateway

SIP

Switch

Q.921

V SIP Voice GW

ISDN


UCM Cluster




Media Gateway Control Protocol NOTE Cisco UCM Version 5.x or later is required for communication with a SIP gateway. Although Cisco UCM Version 4.x supports SIP trunks (that is, connectivity between a UCM cluster and a SIP proxy server), it does not act as a SIP user agent.

MGCP is a client/server gateway control protocol. In a Cisco IP telephony environment, a Cisco UCM server acts as the call agent, and a port on a router (for example, an analog Foreign Exchange Station [FXS] port) acts as an endpoint. The router containing the endpoint is the MGCP gateway, and this gateway registers with the call agent. When a call comes into the gateway via the endpoint, the gateway notifies the call agent, and the call agent assists in the call setup. Unlike H.323 and SIP, MGCP has the unique capability to terminate Q.921 signaling and encapsulate Q.931 messages inside of IP packets. Those encapsulated messages can then be routed to a Cisco UCM server, and the server can interpret and respond to those native Q.931 messages. This feature, illustrated in Figure 1-4, is referred to as PRI backhauling, where PRI stands for Primary Rate Interface, or BRI backhauling in a Basic Rate Interface (BRI) environment.

FIGURE 1-4

Q.931

MGCP Gateway

MGCP

Switch

Q.921

V MGCP Voice GW

ISDN


UCM Cluster

Skinny Client Control Protocol By default, Cisco IP phones use SCCP to exchange signaling messages with Cisco Unified CallManager. SCCP is considered to be a stimulus-response protocol, meaning that a SCCP device can respond to a stimulus message. For example, a UCM server could send a SCCP stimulus message to a Cisco IP phone instructing the IP phone to ring, and the IP phone would respond by ringing. Be aware, however, that some literature refers to SCCP as a client/server protocol, because the SCCP clients (for example, Cisco IP Phones) rely on a server (for example, a Cisco UCM server).




In addition to communication between IP phones and UCM servers, SCCP can be used between specific SCCP gateways (for example, Cisco VG224 and VG248 analog voice gateways) and a UCM server. As one other implementation example, a collection of digital signal processors (DSPs) residing in an IOS router can be grouped together in a DSP farm. This collection of resources can be used by a Cisco UCM server for a variety of functions, such as a conference calling resource, and SCCP is used by the UCM server to communicate with the DSP farm. Figure 1-5 illustrates these uses of SCCP. FIGURE 1-5

IP Phone

SCCP Signaling Applications

SCCP Switch

SCCP UCM Cluster

V Voice GW with DSPs

SCCP

V VG224




VoIP Media Protocols When a VoIP call is established, using the previously discussed signaling protocols, the digitized voice samples need to be transmitted. These voice samples are often called the voice media. Following are a collection of voice media protocols that might be found in a VoIP environment: n

Real-Time Transport Protocol (RTP): RTP is a Layer 4 protocol that is encapsulated inside UDP segments. RTP is the protocol that carries the actual digitized voice samples in a call.

n

Real-Time Control Protocol (RTCP): RTCP is a companion protocol to RTP. 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.

n

Compressed RTP (cRTP): One of the challenges with RTP is its overhead. Specifically, the combined IP, UDP, and RTP headers are approximately 40 bytes in size, whereas a common voice payload size on a VoIP network is only 20 bytes, which includes 20 ms of voice by default. In that case, the header is twice the size of the payload. Fortunately, Cisco supports cRTP, which is commonly referred to as RTP header compression. cRTP can reduce the 40-byte header to 2 or 4 bytes in size (depending on whether UDP checksums are in use), as shown in Figure 1-6.

FIGURE 1-6

Compressed Header

Compressed RTP IP

UDP RTP Headers

Voice Payload

V

cRTP

Voice Payload

2 – 4 Bytes 40 Bytes

n

Secure RTP (sRTP): To help prevent an attacker from intercepting and decoding or possibly manipulating voice packets, sRTP supports encryption of RTP packets. In addition, sRTP provides message authentication, integrity checking, and protection against replay attacks.


[ 10 ] CCVP CVOICE Quick Reference, Second Edition by Kevin Wallace


VoIP Gateways Earlier you learned that a VoIP gateway interconnects dissimilar telephony networks (for example, interconnecting a VoIP network with the PSTN). Cisco offers multiple platforms that can serve as VoIP gateways. As a few examples, the following platforms can act as VoIP gateways: n

Cisco 2800 series router

n

Cisco VG248 gateway

n

Cisco Catalyst 6500 Communications Media Module (CMM)

n

Cisco Analog Telephone Adapter (ADA)

n

Cisco 7200 series router

VoIP gateways can loosely be categorized as either analog gateways or digital gateways. An analog gateway contains one or more analog voice ports (which are discussed later) that connect the gateway to an analog device (for example, an analog phone or an analog port on a PBX). Similarly, a digital gateway contains one or more digital voice ports (for example, T1 or E1 ports) for connectivity to a digital circuit. For multiple connections, digital voice ports often offer economies of scale, because a single digital voice port typically supports multiple simultaneous phone calls. Cisco recommends that when you are selecting a gateway, the gateway meet the following core requirements: n

Support for the appropriate signaling protocol (for example, H.323, MGCP, or SIP)

n

The capability to communicate dual tone multifrequency (DTMF) tones across an IP network (a feature known as DTMF relay), without those tones becoming degraded by the codec in use

n

Services such as hold, transfer, and conferencing

n

Support for a redundant Cisco UCM server, in case the primary server fails

n

The capability to maintain a call if the gateway’s Cisco UCM server becomes inaccessible (a feature known as call survivability)




Support for the Q Signaling (QSIG) protocol, which enhances interoperability between PBXs from different manufacturers

n

The capability to communicate fax and modem tones across an IP network, without those tones becoming degraded by the codec in use

VoIP Deployment Models Because many organizations have multiple locations, their IP telephony networks might span those locations. When determining how IP telephony components should be deployed, consider the following deployment models: single-site deployment, multisite WAN with centralized call processing deployment, multisite WAN with distributed call processing deployment, and a clustering over the WAN deployment.

Single-Site Deployment If an IP telephony network is contained within a single location, as illustrated in Figure 1-7, and has fewer than 30,000 phones, a single-site deployment model is often appropriate. FIGURE 1-7 Single-Site Deployment

V


UCM Cluster




Multisite WAN with Centralized Call Processing Deployment Some organizations might have smaller remote sites that do not contain enough IP phones to justify the purchase of UCM servers for those locations. In those instances, the UCM servers could be located at the headquarters, and IP phones at the remote offices could then register with the centralized UCM servers over the IP WAN. In the event of an IP WAN outage, IP phones could register with the local Survivable Remote Site Telephony (SRST) routers located at each remote site, for basic call processing functionality. Figure 1-8 shows an example of this multisite WAN with centralized call processing deployment model. FIGURE 1-8

Remote Office A

Multisite WAN with Centralized Call Processing Deployment

Public Switched Telephone Network (PSTN) Headquarters

SRST V

CCM Cluster

IP WAN

UCM Cluster

SRST V

Remote Office B




Multisite WAN with Distributed Call Processing Deployment When designing a large IP telephony network with multiple locations, the expense of placing UCM servers at each location might be justified. As an example, Figure 1-9 provides a sample IP telephony topology using the multisite WAN with distributed call processing deployment model. FIGURE 1-9 Multisite WAN with Distributed Call Processing Deployment


V

V

UCM Cluster IP WAN

V

UCM Cluster

UCM Cluster




Clustering over the WAN Deployment In an IP telephony environment that spans multiple locations, having all UCM servers belong to the same cluster can simplify administration. However, having a single cluster at a single site leads to redundancy issues in the event of an IP WAN outage. However, a fourth deployment approach, clustering over the WAN, offers the benefit of having all UCM servers belong to a single server while having the servers physically dispersed across the various remote locations. Specifically, each site has one or more UCM servers on site. These dispersed UCM servers are then logically grouped together into a single cluster, as illustrated in Figure 1-10. This type of design does have bandwidth and delay requirements to support the intracluster communication among the UCM servers. For example, Cisco requires no more than a 40-ms round-trip delay between any two UCM servers in the cluster.



CHAPTER 1 Understanding VoIP Basics FIGURE 1-10 Clustering over the WAN Deployment Public Switched Telephone Network (PSTN)

V

V

IP WAN

V

UCM Cluster



CHAPTER 2 Addressing VoIP Design Considerations

Chapter 2 Addressing VoIP Design Considerations Designing a VoIP network requires the designer to consider the special requirements of voice traffic and quality challenges that can arise from just superimposing voice on top of an existing data network. This chapter considers how voice quality, in addition to the integrity of modem, fax, and dual tone multifrequency (DTMF) transmissions, can be impacted in a VoIP network, and what solutions are available. As you will see, bandwidth availability is a major design consideration, and this chapter examines various factors impacting the bandwidth demand of a voice call. Also, many VoIP features require considerable processing power (for example, mixing multiple audio streams together in a conference call). Digital signal processors (DSPs) can be used to provide the processing requirements for such features, and this chapter introduces you to the theory and configuration of DSPs.

Voice-Quality Considerations In a VoIP network, voice and data coexist on the same links. Therefore, when congestion occurs as a result of insufficient bandwidth, voice and data traffic simultaneously contend for access to the network. The impact of such contention can be poor voice quality. A primary design goal of a VoIP network, however, is to have a level of voice quality comparable to what end users are accustomed to on their home phones and traditional PBX telephony networks. Consider some of the factors that can impact end-user perception of voice quality: n

Fidelity: Fidelity represents the range of audio frequencies that are transmitted or received by a device. Although the human ear can perceive frequencies in a range of approximately 20 Hz to 20,000 (with higher-end frequencies becoming less perceptible as one grows older), more than 90 percent of speech intelligence (that is, the frequencies required to understand the spoken word) exists in the frequency range 100 to 3000 Hz. A VoIP network typically




samples human speech at a rate that can accurately reproduce a maximum frequency of 4000 Hz. Therefore, VoIP networks can easily match the fidelity of traditional telephony systems. n

Echo: Although not related to limited bandwidth, echo causes another serious problem for voice quality. You experience the symptom of echo when you speak and hear your own voice reflected back to you (that is, talker echo), or when you speak and the other party hears your voice twice (that is, listener echo). The issue of echo typically stems from an impedance mismatch in a 2-wire to 4-wire circuit, which can be found in an analog phone or in telephony switching equipment. To combat echo, Cisco voice-enabled routers can use echo-cancellation technologies to detect and remove echo from a voice stream.

n

Delay: The ITU G.114 recommendation for voice traffic specifies a maximum one-way delay of 150 ms for voice traffic. Some types of delay are considered fixed, in that they do not change during a phone call. Examples of these fixed-delay components include the following: propagation delay (the time it takes a packet to traverse a network link), serialization delay (the time it takes to send a frame out of a serial link), and processing delay (the time required by the router to encode/decode, compress/decompress, and packetize voice).

n

Jitter: Delay might vary during a phone call. One example of variable delay is jitter. Specifically, jitter is the uneven arrival of packets at a destination router. Cisco routers use dejitter buffers to help smooth out packet playout, thus concealing the jitter experienced by those packets. Another type of variable delay that can contribute to jitter is queuing delay. Queuing delay is the amount of time a packet must spend in a queue as it waits to be forwarded out of an interface.

n

Packet drops: If an interface’s output queue fills to capacity, newly arriving packets might be dropped. This occurrence is called tail drop. Although digital signal processors can correct a maximum of approximately 30 ms of lost voice, additional voice packet drops can severely compromise voice quality.

n

Side tone: When you speak into a traditional telephone handset, your voice goes into the handset’s transmitter, and you are able to hear (at a relatively low volume) your voice in the handset’s receiver. Your own voice being heard in the handset’s receiver is called side tone. Without side tone, a caller might think the handset is not functioning. The circuitry inside analog phones, and Cisco IP phones, supports side tone.



CHAPTER 2 Addressing VoIP Design Considerations n

Background noise: Cisco voice-enabled routers support a feature called voice activity detection (VAD). VAD detects when a party in a call stops speaking and suppresses the sending of silence, to preserve bandwidth. The challenge, however, is if one of the parties in a phone call hears complete silence, he might be under the impression that the call has been terminated. Fortunately, VAD supports comfort noise generation (CNG) to synthetically produce background noise, while simultaneously suppressing the transmission of silence.

With all these variables that can affect voice quality, the need arises to quantify voice quality. Consider three approaches to measuring voice quality: n

Mean Opinion Score (MOS): MOS uses a “trained ear” to judge the quality of voice after passing the voice through the codec that is being tested. MOS values range from 1, for unsatisfactory quality, through 5, for no noticeable quality degradation. For toll-quality voice, however, an MOS value in the range of 4 is appropriate. The G.711 codec has an MOS value of 4.1. Accompanied by a significant bandwidth savings, G.729 has an MOS of 3.92, whereas the less-processor-intensive G.729a has an MOS of 3.9.

n

Perceptual Speech Quality Measurement (PSQM): The challenge with MOS is that at its essence, it is based on opinion. However, PSQM digitally measures the difference in the original signal and the signal after it passes through a codec. PSQM ratings range from 0 to 6.5. Unlike MOS scores, PSQM scores with lower numbers represent better voice quality.

n

Perceptual Evaluation of Speech Quality (PESQ): Neither MOS nor PSQM measures the quality impact of endto-end network conditions (for example, packet drops, jitter, and processing delay). Therefore, neither is ideally suited for measuring voice quality in a VoIP network. Fortunately, PESQ does take such factors into account. Like PSQM, PESQ uses circuitry to measure the quality, thus eliminating human opinion. However, PSQM’s range of values is 1 to 4.5, with 4.5 being best. Also, PESQ attempts to match the corresponding MOS value for a specific codec. So, for example, if you measure the quality of a particular codec using MOS, and then you measure the quality of that same codec using PESQ, those values should be approximately the same.

To combat the quality issues described earlier, you can implement various quality-of-service (QoS) mechanisms available on Cisco routers and switches. For example, on wiring closet Cisco Catalyst switches, you can place voice and data




traffic in separate queues. Also, you can configure these Catalyst switches not to trust priority markings originating from a PC connected to a Cisco IP phone. Most QoS mechanisms, however, are deployed in routers, where bandwidth tends to be at more of a premium. As a few examples, Cisco router IOS QoS mechanisms include the following: n

Classification and marking: Classifying traffic recognizes characteristics of traffic and categorizes that traffic. For instance, you can use access control lists (ACLs) to classify traffic. When categorized, the traffic can be marked by, for example, altering bits in a packet’s header to indicate the packet’s relative level of priority.

n

Congestion management: Congestion management defines the queuing algorithm used by an interface’s output queue. The queuing algorithm can specify which type of traffic receives priority treatment (that is, be forwarded out of an interface ahead of other traffic) and how much bandwidth is available to various traffic types during periods of network congestion. The Cisco recommended queuing mechanism for voice networks is low-latency queuing (LLQ).

n

Congestion avoidance: To prevent an interface’s output queue from filling to capacity, after which newly arriving packets are discarded, routers can use a congestion-avoidance mechanism (that is, weighted random early detection [WRED]) to increase the probability that lower-priority traffic will be discarded as a queue begins to fill.

n

Traffic conditioning: Traffic-conditioning mechanisms (for example, policing and shaping) limit the amount of bandwidth that specific traffic types can consume.

n

Link efficiency: Link-efficiency mechanisms, such as link fragmentation and interleaving (which fragments larger packets and interleaves voice packets in among the fragmented data packets, thus reducing the serialization delay experienced by the voice traffic) and Real-Time Transport Protocol (RTP) header compression, attempt to make the most efficient use of limited WAN bandwidth.

n

Call admission control (CAC): As mentioned earlier, if too many simultaneous calls are sent across an IP WAN, and the IP WAN becomes oversubscribed, all calls experience poor voice quality. Therefore, IP telephony and VoIP networks require CAC tools to prevent this oversubscription. One approach to CAC is to use the previously described gatekeeper. Another approach is to use the Resource Reservation Protocol (RSVP). With RSVP, a Cisco voice-enabled router, or a Unified CallManager server (version 5.0 or later) can request a bandwidth reservation for a voice call that no other application can encroach in on, thus preventing IP WAN oversubscription.




The Challenge of Compressing Nonvoice Streams Although codecs such as G.729 do a great job of compressing voice, they are not designed to compress nonvoice signals such as fax, modem, or DTMF tones. Although fax, modem, and DTMF information can be transmitted using G.711 without a problem, the G.729 codec corrupts these signals to a point where a device on the other side of an IP WAN cannot interpret them, as illustrated in Figure 2-1. FIGURE 2-1 ?

Fax Transmission with G.729 V

G.729

Fax

V

Fax

Fax Transmission Cisco supports several solutions for transmitting fax tones across an IP network. Consider the following: n

Fax pass-through: Fax pass-through detects a fax call is in progress and switches from the codec in use (for example, G.729) to G.711, which does not do compression and therefore does not degrade the fax tones. The fax tones are then transmitted using G.711. Although this approach does preserve the integrity of fax transmissions, it might not be the most desirable approach because it uses extra bandwidth (due to the G.711 codec) for the duration of the fax transmission.

n

Cisco Fax Relay: Cisco Fax Relay is the default approach used on most Cisco routers. This approach to fax transmission sends fax information in specially formatted RTP packets. Specifically, these packets have a different RTP payload type and are not subject to the compression of the voice codec in use.




T.38: Similar to Cisco Fax Relay, T.38 transmits fax information via specially formatted packets, specifically T.38 Internet Fax Protocol (IFP) packets, which are sent using UDP. However, unlike Cisco Fax Relay, T.38 is an industry standard and might therefore be more appropriate in a mixed-vendor environment.

n

T.37: T.37 is referred to as store-and-forward fax. With T.37, a fax transmission is terminated on an incoming voice gateway (called an on-ramp gateway). The on-ramp gateway converts the fax transmission into a graphical representation of the fax. Specifically, the fax is converted into a TIFF graphic format, and the on-ramp gateway then sends the TIFF file, as an email attachment, to an Simple Mail Transfer Protocol (SMTP) server. The email recipient could be a user’s email account, which would enable her to read the fax transmission in her email. Alternatively, the recipient could be another voice gateway (known as an off-ramp gateway). The off-ramp gateway could receive the email with the TIFF attachment and convert the graphic back into fax tones, which could be sent out of the voice gateway to a destination fax machine.

Modem Transmission Similar to the challenges of fax transmission, modem tones can also be corrupted as a result of codecs performing compression. Although Cisco voice gateways support modem pass-through, similar to fax pass-through, to allow modem tones to be transmitted using G.711, a more bandwidth-friendly approach is modem relay. Specifically, to transmit modem tones across a WAN when you have specified the G.729 codec for voice traffic, you can use modem relay, which sends modem information through the Simple Packet Relay Transport (SPRT) protocol. The lasthop router then remodulates the data and sends it to the destination router.

DTMF Transmission DTMF tones are generated, for example, when a user presses a button on a telephone’s touch-tone keypad. A DTMF tone is a pair of simultaneously generated frequencies. This combination of frequencies can be interpreted as signaling




information. However, like fax tones and modem tones, DTMF tones may be degraded by the voice codec in use, to the point where the receiving equipment cannot correctly interpret the DTMF values. Therefore, some sort of DTMF relay technology is required to successfully transmit DTMF tones across an IP WAN using a codec that performs compression. The DTMF relay approach largely depends on the call control protocol in use.

Options for H.323 DTMF Relay n

Cisco DTMF Relay: DTMF tones are sent via RTP, using a different RTP payload type value.

n

H.245 alphanumeric: DTMF tones are sent as text rather than tones.

n

H.245 signal: Similar to H.245 alphanumeric, H.245 signal sends tones as text and sends duration information to indicate how long individual tones were generated.

n

NTEs: Named Telephony Events (NTEs) are used to transmit DTMF tones inside of RTP packets, as specified in RFC 2833 Section 3, with a negotiated RTP payload type.

Options for MGCP DTMF Relay n

Cisco DTMF Relay: DTMF tones are sent via RTP, using a different RTP payload type value.

n

NSEs: Named Signal Events (NSEs) are used to transmit DTMF tones inside of RTP packets, with a preconfigured RTP payload type.

n

NTEs: Media Gateway Control Protocol (MGCP) can use NTEs in one of two modes: gateway-controlled mode and call agent–controlled mode. With gateway-controlled mode, the payload type is negotiated by the gateways. With call agent–controlled mode, a call agent (for example, a Cisco Unified Communications Manager [UCM] server) sends MGCP messages to gateways instructing the gateway how to process DTMF tones.

n

Out-of-band: Out-of-band DTMF relay sends DTMF digits to a Cisco UCM server using a control channel, as opposed to sending the digit information in an RTP stream.




SIP DTMF Relay If you are in a Session Initiation Protocol (SIP) environment, Cisco voice gateways support a proprietary method of encoding DTMF tones in SIP NOTIFY messages, resulting in NOTIFY-based out-of-band DTMF relay.

Factors Impacting Bandwidth Requirements A variety of factors need to be analyzed when determining how much bandwidth is required for a voice call. Consider the following: n

Codec selection: One approach is to use a codec requiring less bandwidth per call. For example, the G.711 codec does not perform any compression, and it requires 64 kb/s of bandwidth (not including overhead) for a single voice call. However, over an IP WAN, where bandwidth is at a premium, Cisco networks often use the G.729a codec, which requires only 8 kb/s of bandwidth (not including overhead). Because G.729a performs compression, whereas G.711 does not, voice quality is somewhat compromised when using G.729a.

n

Compressed RTP (cRTP): When using G.729a, voice packets contain 20 bytes of voice payload, while the packet contains 40 bytes of header information. However, because most information in these headers is identical (for example, the same source/destination IP address / UDP port numbers and the same RTP payload type), cRTP does not send this redundant header information in each frame. Therefore, cRTP reduces the 40-byte header down to only 2 or 4 bytes, allowing more calls to be placed over the same link speed.

n

Voice activity detection (VAD): Statistics show that approximately 35 percent of an average voice call is silence. Instead of consuming bandwidth to send silence information, VAD can detect the silence and suppress the transmission of silence.

n

Voice sample size: By default, Cisco voice gateways encapsulate 20 ms of audio in a single packet. However, more audio could be contained in a single packet. Although this approach would conserve bandwidth, because fewer headers are being used to transmit a certain amount of audio, the loss of a single packet could be more noticeable. Therefore, voice sample sizes are usually left at their default value.




Data-link overhead: Layer 2 of the OSI reference model (that is, the data link layer) adds its own header to a voice packet. For example, when you are sending voice packets over an Ethernet network, the Layer 2 header is 18 bytes in size. For Multilink PPP (MLP) and Frame Relay Forum Standard 12 (FRF.12), 6 bytes of Layer 2 header information is added.

The following formula shows how to calculate a network’s required voice bandwidth: Bandwidth = ((Layer 2 header) + (IP/UDP/RTP header)) * (Codec bit rate) / (Voice payload size)

When working with this formula, make the following assumptions:

NOTE Your Cisco.com account must have appropriate access permissions to access the Voice Codec Bandwidth Calculator URL.

n

IP/UDP/RTP header = 40 bytes

n

With cRTP, the header = 2 or 4 bytes

n

A WAN’s Layer 2 header = 6 bytes

An easier, and more detailed, bandwidth calculation can be performed using the Cisco Voice Codec Bandwidth Calculator, available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.

Digital Signal Processors DSPs are microprocessors residing in Cisco IOS routers or Cisco Catalyst switches (for example, a Cisco Catalyst 6500 series switch with a CMM module). These DSPs can be leveraged in an IP telephony environment to perform processorintensive applications, or to offload processing from a UCM server.




DSP Applications Consider some of the applications of DSPs: n

Transcoding: Translating between a high-bandwidth codec (for example, G.711) and a low-bandwidth codec (for example, G.729)

n

Voice termination: Interconnecting a time-division multiplexing (TDM) link (for example, a T1 circuit coming in from the public switched telephone network [PSTN]) with a VoIP network

n

Media termination point (MTP): Interconnecting two VoIP call legs, both of which use the same codec

n

Conferencing: Mixing multiple audio streams into a single stream

Codec Complexity Because codec algorithms vary in their arithmetic complexity, the number of calls supported by a single DSP depends on the codec in use. For example, G.711, G.729a, and G.729ab are considered medium-complexity codecs, whereas G.729 and G.729b are considered high-complexity codecs. Another consideration is the chipset used by a router. Newer Integrated Services Routers (ISRs) use the C5510 chipset, whereas older routers often use the C549 chipset. With a medium-complexity codec, the C549 DSPs can support four calls per DSP, whereas the C5510 DSPs can support eight calls per DSP. With a high-complexity codec, the C549 DSPs can support two calls per DSP, and the C5510 DSPs can support as many as six calls. To configure the codec complexity for the C549 chipset, you can use the voice-card configuration mode command codec complexity {medium | high}. However, for the C5510 chipset, you can issue the voice-card configuration mode command codec complexity {medium | high | flex | secure}.




Notice the C5510 chipset support for the flex and secure parameters. The flex parameter allows the complexity to automatically adjust to either medium or high complexity depending on the needs of a call. For example, if a call uses the G.711 codec, the C5510 chipset automatically adjusts to the medium-complexity mode. However, if the call uses G.729, the C5510 chipset uses the high-complexity mode. Thus, the chipset can accommodate all codecs, while automatically using the most efficient complexity mode. This feature is not supported in the C549 chipset. Another parameter supported on the C5510 chipset that is not supported on the C549 chipset is the secure parameter. This parameter supports Secure RTP (sRTP), which adds authentication and encryption services for voice streams. You can view codec complexity for a DSP by using the show voice dsp command. Specifically, output from this command shows the chipset installed in the router and the chipset’s configured complexity mode.

DSP Configuration Cisco offers the DSP Calculator, as illustrated in Figure 2-2, which can provide a network designer with the number of DSPs needed for a particular design and a template of the required command-line interface (CLI) configuration. With the appropriate login credentials, you can access the DSP Calculator at http://www.cisco.com/cgibin/Support/DSP/dsp-calc.pl. To make DSP resources available to the Cisco UCM-based IP telephony environment, you must configure both the platform containing the DSPs and the Cisco UCM server. Figure 2-3 shows a sample configuration. In the sample topology, the Kentucky site has a router containing DSP resources, and those resources are to be used to support conference calling. Therefore, the router and the Cisco UCM server need to be configured such that the router has a DSP farm that can be invoked by the Cisco UCM server.




FIGURE 2-2 DSP Calculator



CHAPTER 2 Addressing VoIP Design Considerations FIGURE 2-3 DSP Farm Sample Topology 192.168.0.10

Conference Bridge

V Fa1/1 KY_Router

IP WAN

Kentucky

V AZ_Router

Arizona

Cisco IOS DSP Configuration First, consider the configuration of the router KY_Router. As a first step, you enter voice-card configuration mode and assign the DSPs on that card to a DSP farm, as shown in Example 2-1. Example 2-1

DSP Farm Configuration

KY_Router(config)#voice-card 0 KY_Router(config-voicecard)#dsp service dspfarm

Next, you create a DSP farm profile on the router KY_Router. This profile defines the purpose of the DSP farm (conferencing in this example), defines the supported codecs (listed in order of priority), specifies the maximum number of simultaneous sessions, and associates the DSP farm with the Skinny Client Control Protocol (SCCP), which is the protocol used to communicate between the DSP farm and the Cisco UCM server. The DSP farm profile is administratively shut down by default, and must be brought up using the no shutdown command. Example 2-2 illustrates the creation of a DSP farm profile for conferencing services.



CHAPTER 2 Addressing VoIP Design Considerations Example 2-2

DSP Farm Profile Configuration

KY_Router(config)#dspfarm profile 1 conference KY_Router(config-dspfarm-profile)#codec g711ulaw KY_Router(config-dspfarm-profile)#codec g729abr8 KY_Router(config-dspfarm-profile)#codec g729ar8 KY_Router(config-dspfarm-profile)#codec g729br8 KY_Router(config-dspfarm-profile)#maximum sessions 2 KY_Router(config-dspfarm-profile)#associate application SCCP KY_Router(config-dspfarm-profile)#no shutdown

Because SCCP will be used for communication between the DSP farm and the Cisco UCM server, the router needs to be configured to run SCCP. Example 2-3 shows the syntax for specifying the router interface that will speak SCCP and for specifying the IP address of a Cisco UCM server (which is a version 4.1 server in this example). Also, the sccp command is used to start SCCP. An SCCP group is then configured. The group is associated with an interface and a UCM server (although a keyword of ccm is used rather than ucm, because Cisco Unified Communications Manager was previously know as Cisco CallManager [CCM]). Also, the SCCP group is associated with a DSP farm profile, and the name for the DSP resource is specified using the register command. This same name will need to be entered exactly into the Cisco UCM server configuration. Example 2-3

SCCP Configuration

KY_Router(config)#sccp local fastethernet 1/1 KY_Router(config)#sccp ccm 192.168.0.10 identifier 1 priority 1 version 4.1 KY_Router(config)#sccp KY_Router(config)#sccp ccm group 1 KY_Router(config-sccp-ccm)#bind interface fastethernet1/1 KY_Router(config-sccp-ccm)#associate ccm 1 priority 1 KY_Router(config-sccp-ccm)#associate profile 1 KY_Router(config-sccp-ccm)#register CFB_KY_Router




Cisco UCM Server Configuration to Reference a DSP Farm Now that the router has been configured to offer a DSP conferencing resource, the Cisco UCM server needs to be configured to accept a registration from the DSP farm, which will allow the DSP resources to be invoked by the Cisco UCM server when it is in need of a conferencing resource. From the Cisco UCM Administration screen, navigate to the Service > Media Resource > Conference Bridge menu option, as shown in Figure 2-4. FIGURE 2-4 Accessing the Conference Bridge Configuration Screen




Click the Add a New Conference Bridge link that appears onscreen. Assume that in this example you are using a router that uses the C5510 chipset. You will therefore specify Cisco IOS Enhanced Conference Bridge in the Conference Bridge Type field, as shown in Figure 2-5. If your router uses the C549 chipset, you instead specify Cisco IOS Conference Bridge. FIGURE 2-5 Specifying the Conference Bridge Type




Enter the name you assigned in the IOS configuration (using the register command) into the Conference Bridge Name field, as shown in Figure 2-6. Select an appropriate device pool, and click Insert. FIGURE 2-6 Specifying the Name of the DSP Resource



CHAPTER 3 Understanding and Configuring Analog Voice Ports

Chapter 3 Understanding and Configuring Analog Voice Ports Now that you understand the fundamental components of a VoIP network, and you have been exposed to various VoIP design considerations, in this chapter you learn how to start configuring voice interfaces on a VoIP router. Specifically, this chapter addresses the configuration of analog voice ports; Chapter 4, “Understanding and Configuring Digital Voice Ports,” addresses digital voice ports.

Call Types First, consider the following categories of voice calls that will be using these voice ports: n

Local calls: A local call occurs when the calling and called phones are both physically attached to the same router.

n

On-net calls: On-net calls span more than one router. Specifically, the calling phone is attached to one router, and the called phone attaches to a different router. In this case, the routers are both part of the same network.

n

Off-net calls: Off-net calls originate on a router but terminate on the public switched telephone network (PSTN).

n

Private line, automatic ringdown (PLAR) calls: A PLAR call occurs when a caller picks up a phone and the phone automatically dials a preconfigured number.

n

PBX to PBX calls: PBX-to-PBX calls are on-net calls, where the source and destination are PBXs. A PBX-to-PBX call could be placed over a tie line (which is brought up on demand) or a trunk (which is up all the time, but can wait until a call is placed before it is initially brought up).

n

Intercluster trunk calls: Intercluster trunk calls occur when IP phones register with Cisco Unified Communications Manager (UCM) servers in different clusters, and the signaling information is sent over an intercluster trunk.



CHAPTER 3 Understanding and Configuring Analog Voice Ports n

On-net to off-net calls: An on-net to an off-net call is a call that was intended to be on-net only. However, because of conditions such as WAN oversubscription or a WAN outage, the call is diverted off-net (for example, to the PSTN).

Analog Voice Ports The three primary types of analog voice ports available for Cisco voice-enabled gateways, as depicted in Figure 3-1, are FXS, FXO, and E&M ports. FIGURE 3-1 Analog Voice Ports

PSTN Analog Phone

FXS FXO V

E&M IP WAN PBX

n

FXS: A Foreign Exchange Station (FXS) port enables you to connect plain old telephone service (POTS) devices to a router. For example, you can attach a traditional analog phone, speakerphone, or fax machine to an FXS port on a Cisco router, and that FXS port can act like a PBX or central office (CO) switch. For example, an FXS port can provide a dial tone when the phone goes off-hook, interpret dialed digits, and send ringing voltage to an attached phone.

n

FXO: A Foreign Exchange Office (FXO) port connects to a phone switch (for example, a PBX or the PSTN). The FXO port can connect into the traditional tip-and-ring connection that comes from a CO or a PBX. Because it is acting as a phone, an FXO port can go off-hook, dial digits, and answer incoming calls.

n

E&M: E&M is the third type of analog port, and this port interconnects PBXs. The E and M originally referred to earth and magneto, although you can think of ear and mouth to better visualize the receive and transmit functions of E&M. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



Analog Signaling Consider the following types of signaling present in the analog telephony world: n

Supervisory signaling: Supervisory signaling indicates the on-hook or off-hook condition of a phone, based on whether loop current is flowing. In addition, ringing is considered to be supervisory signaling. Ringing voltage is sent from the phone switch to alert the destination phone that it is receiving an incoming call. In the United States, the default pattern of ringing (that is, ring cadence) is 2 seconds on and 4 seconds off.

n

Address signaling: Address signaling allows a phone to dial (that is, specify the address of) a destination phone. The older method of dialing digits was with a rotary phone, which used pulse dialing. Pulse dialing rapidly opens and closes the tip-and-ring circuit. This series of open and closed circuit conditions within specific timing parameters indicates a dialed digit. A more efficient approach to address signaling is dual tone multifrequency (DTMF) dialing. With DTMF, two simultaneous frequencies are generated, and this combination of frequencies is interpreted by the phone switch as a dialed digit. For example, the combination of a 697-Hz tone and a 1209-Hz tone indicates a dialed digit of 1.

n

Information signaling: Like DTMF, information signaling uses combinations of frequencies to, in this case, indicate the status of a call (that is, to provide information to the caller). For example, a busy signal is a combination of a 480-Hz tone and a 620-Hz tone, with on/off times of 0.5/0.5 seconds.

Configuring Analog Voice Ports Although analog voice-port configuration is similar for FXS, FXO, and E&M ports (for example, the configuration is performed in voice-port configuration mode, and some of the commands might be the same), some commands are very port specific. For example, an FXS port can send ringing voltage to a phone, which can be configured with the ring cadence command. However, that is not a valid command for an FXO or E&M port. Following are discussions about how to configure each of these analog voice-port types, in addition to configuring various timing parameters.




FXS Port Configuration A phone connects to an FXS port, just as a phone would connect to a PBX or the PSTN. Therefore, you can configure parameters such as signal type (that is, loop start or ground start), ring pattern, impedance (to match the impedance of the connecting device), and call progress tones (for example, what a busy signal sounds like). Consider the following FXS configuration scenario, as illustrated in Figure 3-2 and Example 3-1. FIGURE 3-2 FXS Port Sample Topology

FXS V

1/1/1 Analog Phone

Example 3-1

FXS Port Configuration

Router(config)#voice-port 1/1/1 Router(config-voiceport)#signal loopstart Router(config-voiceport)#impedance 600r Router(config-voiceport)#ring cadence pattern02 Router(config-voiceport)#output attenuation -2 Router(config-voiceport)#input gain 3 Router(config-voiceport)#echo-cancel coverage 32

In this example, voice port 1/1/1 is an FXS port, and you are specifying that it should use loop-start signaling, as opposed to ground start. FXS (and FXO) analog ports can use either loop-start or ground-start signaling. Loop-start signaling is the type of signaling commonly found in a residential environment, whereas ground start is more likely to be used between a PBX and a CO. Ground start eliminates loop start’s issue of glare. As an example, glare occurs when you pick up a phone’s handset to place a call, and another party is already on the line. Specifically, the other party called you, and you picked up the handset before the phone rang.




Also, the impedance is set to 600 ohms resistive (that is, no capacitive component). The ringing pattern is set to the predefined pattern02, which specifies a cadence of 1 second on and 4 seconds off. Because you want the volume (that is, the amplitude) of VoIP calls to be approximately the same as the volume of the calls in a PBX environment (to make the VoIP network as transparent to the users as possible), you can make gain and attenuation adjustments. In this example, you are attenuating (that is, reducing the volume) of calls that are being sent out of the port to the attached phone by 2 decibels (dB), with the output attenuation command. The input gain command, in this example, is increasing the volume of the waveforms that are coming from the phone into the router by 3 dB. To combat echo, you are increasing the coverage (that is, how long a router memorizes a waveform, as it waits for echo from that waveform) to 32 ms, with the echo-cancel coverage command. Finally, to maximize echo cancellation, you enabled the nonlinear feature, which suppresses all incoming waveforms from the phone until the volume is loud enough to be interpreted as speech. Note that this nonlinear feature can lead to clipping when the other party begins to speak. You can enter the nonlinear feature with the non-linear voice-port configuration mode command.

FXO Port Configuration An FXO port connects to a phone switch (for example, a CO switch or PBX). Therefore, an FXO port acts like a phone. Typical parameters that you can configure on an FXO port are signaling (which must match the signaling type of the phone switch to which you are connecting), dial type (that is, DTMF or pulse), and the number of incoming rings before the FXO port answers (that is, goes off-hook). Consider the following FXO configuration sample, as shown in Figure 3-3 and Example 3-2. FIGURE 3-3 FXO Port Sample Topology

V

FXO 1/2/1

Line Side

Station Side

PSTN PBX



CHAPTER 3 Understanding and Configuring Analog Voice Ports Example 3-2

FXO Port Configuration

Router(config)#voice-port 1/2/1 Router(config-voiceport)#signal loopstart Router(config-voiceport)#ring number 3 Router(config-voiceport)#dial-type pulse

In this example, voice port 1/2/1 is an FXO port, and you are specifying that it should use loop-start signaling. Also, because the FXO port acts like a phone, you can specify how many rings it receives before it answers. In this case, the FXO port will answer after three rings. Also, when the FXO port dials, it is configured to use pulse dialing.

E&M Port Configuration An E&M port in a router typically connects to an existing E&M port on a PBX. Parameters that you can configure on an E&M port include the signaling type (for example, wink start), the E&M type (that is, 1, 2, 3, or 5), and the number of wires that are used for the voice path (that is, the operation). Figure 3-4 and Example 3-3 provide a sample E&M configuration. FIGURE 3-4 E&M Port Sample Topology

E&M 2/1/1

E&M V

V

PBX

PBX

Example 3-3

E&M Port Configuration

Router(config)#voice-port 2/1/1 Router(config-voiceport)#type 1 Router(config-voiceport)#operation 4-wire Router(config-voiceport)#signal wink-start




In this example, an E&M port is configured as E&M Type I. Type I is most common in North America, and Type V is most common outside North America. Another E&M type you might encounter is Type II, which does not require the calling and called equipment (for example, a router or PBX) to be located in the same building (that is, a common ground is not required). In addition, the voice path, which does not use the E&M leads, uses four wires, meaning that both the tip and ring leads have their own return path. The default signaling method of wink start is also specified. With wink-start signaling, the calling equipment goes off-hook on its E-lead and waits for the called equipment to send a brief off-hook pulse (that is, a wink) on its M-lead. This wink indicates to the calling equipment that the called equipment is ready to receive digits.

Timing Options Numerous timing options can optionally be configured for Cisco voice ports. To illustrate, consider Example 3-4. Example 3-4

Timing Parameter Configuration

Router(config)#voice-port 1/1/1 Router(config-voiceport)#timeouts interdigit 20 Router(config-voiceport)#timeouts initial 20 Router(config-voiceport)#timeouts call-disconnect 20

In this example, voice port 1/1/1 is an FXS port. The interdigit parameter determines the maximum number of seconds that are allowed between dialed digits. The initial parameter specifies how long the caller can receive dial tone before the first digit is dialed. Finally, the call-disconnect parameter indicates how long this port remains in an off-hook condition if the other party disconnects first. All units of measure in this example are seconds.




Dial Peers At this point, you have seen how to configure voice ports on Cisco voice-enabled routers. However, you have not yet trained the routers to reach specific destinations. That is the focus of this section. Specifically, you will see how to create dial peers that inform the routers how to reach specific phone numbers. Consider the following topology (see Figure 3-5). FIGURE 3-5

POTS Dial Peer

POTS Dial Peer

Dial Peers and Call Legs

x1111 => 1/1/1

x2222 => 1/1/1

VoIP Dial Peer

VoIP Dial Peer

x2222 => 10.1.1.2

x1111 => 10.1.1.1

10.1.1.1 x1111

FXS 1/1/1

Call Leg 1

V R1

10.1.1.2

Call Leg 2

Call Leg 3

V R2

FXS 1/1/1

x2222

Call Leg 4

Routers R1 and R2 each have a POTS dial peer that points to their locally attached phone and a VoIP dial peer that points to the IP address of the remote router. Therefore, when extension 1111 dials extension 2222, router R1 searches for a dial peer that matches a destination pattern of 2222. In this case, R1 has a VoIP dial peer that points to R2’s IP address of 10.1.1.2. R1 then forwards the call to R2. Then, R2 receives the incoming call that is destined for extension 2222. R2 searches for a dial peer that matches a destination of 2222, and it finds a POTS dial peer that specifies FXS port 1/1/1. The FXS port then sends ringing voltage out port 1/1/1. Extension 2222 goes off-hook, and the end-to-end call is complete.




Notice that you have a total of four dial peers that allow a call in the opposite direction. Also, notice that four stages of the call (that is, call legs) are defined, two call legs from the perspective of each router, as follows: n

Call Leg 1: The call comes into R1 on FXS port 1/1/1.

n

Call Leg 2: The call is sent from R1 to IP address 10.1.1.2.

n

Call Leg 3: R2 receives an incoming call that is destined for extension 2222.

n

Call Leg 4: R2 forwards the call out FXS port 1/1/1.

POTS Dial Peers When configuring a POTS dial peer, specify the following two parameters: n

The destination-pattern (that is, the phone numbers)

n

The physical port address

Consider the POTS dial-peer configuration presented in Figure 3-6 and Example 3-5. FIGURE 3-6

POTS Dial Peer

POTS Dial-Peer Topology

x1111 => 1/1/1

x1111

FXS 1/1/1

Example 3-5

V R1

POTS Dial-Peer Configuration

R1(config)#dial-peer voice 1111 pots R1(config-dial-peer)#destination-pattern 1111 R1(config-dial-peer)#port 1/1/1




In this example, an analog phone is attached to FXS port 1/1/1. You entered dial-peer configuration mode for a POTS dial peer with the dial-peer voice 1111 pots command. Notice that the 1111 in the dial-peer command does not need to match the phone number. The number is merely a locally significant tag. However, to make the configuration more intuitive to interpret, you might want to adopt a practice of using the extension number as the dial-peer tag. The phone’s extension number of 1111 is specified with the destination-pattern 1111 command. The phone’s physical location is specified with the port 1/1/1 command.

VoIP Dial Peers When configuring a VoIP dial peer, you specify a remote phone number with the same destination-pattern command that was used in a POTS dial peer. However, instead of identifying a local port, a VoIP dial peer often specifies the voice packets’ destination IP address. Consider the VoIP dial-peer configuration provided in Figure 3-7 and Example 3-6. FIGURE 3-7

VoIP Dial Peer

VoIP Dial-Peer Topology

x2222 => 10.1.1.2 10.1.1.1 V R1

Example 3-6

10.1.1.2

V R2

FXS 1/1/1

x2222

VoIP Dial-Peer Configuration

R1(config)#dial-peer voice 2222 voip R1(config-dial-peer)#destination-pattern 2222 R1(config-dial-peer)#session target ipv4:10.1.1.2

In this example, router R1 is sending voice packets that are destined for extension 2222 across the IP WAN to IP address 10.1.1.2, as specified with the session target command. Note that you must prepend ipv4: to the IP address.




Matching Multiple Phone Numbers Using Wildcards At this point, you understand how to establish a dial plan for two phones that are separated by an IP WAN. However, what if you have 1000 extensions on the other side of the WAN? You certainly would not want to create 1000 dial peers. Fortunately, the Cisco IOS enables you to use wildcards to specify a range of addresses. A few of the more frequently used wildcards are as follows: n

T: A T represents a dial string of any length. For example, you could specify a destination pattern of 9T to match any number that begins with a 9, and then you could point any calls matching that pattern out to the PSTN. Because the T can be any number of digits, the router forwards the call, by default, after no digits have been dialed for 10 seconds or after the caller presses the # key.

n

.: A period indicates any single digit. For example, you could specify extension numbers in the range 7000 to 7999 with the 7… destination pattern.

n

[]: Brackets can be used to specify a range of numbers. For example, a 123[4-6] destination pattern identifies a fourdigit number of 1234, 1235, or 1236.

Figure 3-8 demonstrates how wildcard characters used in the destination-pattern command can point to a range of destination phone numbers, instead of just a single phone number. Note that the 9T pattern matches any dial string that begins with a 9. So, the users could be trained to dial a 9 to get an outside line, after which they dial the destination PSTN number. Also note how the 7… destination pattern is used to point to a remote office containing directory numbers in the range 7000 to 7999.



CHAPTER 3 Understanding and Configuring Analog Voice Ports FIGURE 3-8 Wildcard Pattern Examples

PSTN Destination-Pattern 9T

V

Destination-Pattern 7... IP WAN

V

PBX x7000 – 7999

Inbound Versus Outbound Dial-Peer Matching Be aware that not only does a router need to match an outbound dial peer, it also needs to match an inbound dial peer. The router attempts to match an inbound dial peer in the following order: n

incoming called-number: This command matches the Dialed Number Identification Service (DNIS) information (that is, the dialed number).

n

answer-address: This command matches the Automatic Number Identification (ANI) information (that is, the caller ID number).

n

destination-pattern: Much like the incoming called-number command, this command matches the DNIS information. However, unlike the incoming called-number command, this command can be used for outbound dial-peer matching in addition to inbound dial-peer matching.

n

port: This command references the voice port over which the inbound call arrived.




In the event of a tie (that is, if multiple dial peers match the same port parameter), the first dial peer to be configured is selected. However, if no match is found, the default dial peer (that is, dial peer 0) is used. The default dial peer can be used in the absence of an appropriately configured inbound dial peer. However, the default dial peer cannot take the place of an outbound dial peer.

Multiple Dial Peers with Matching Destination Patterns You can have a configuration in which multiple destination patterns match a dialed number. However, which destination pattern is used? The most specific destination pattern is used when multiple destination patterns match a called number. Consider the configuration presented in Example 3-7. Example 3-7

Multiple Dial-Peer Matches

Router(config)#dial-peer voice 1 voip Router(config-dial-peer)#destination-pattern 2468 Router(config-dial-peer)#session target ipv4:192.168.1.1 Router(config-dial-peer)#dial-peer voice 2 voip Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session target ipv4:192.168.2.2 Router(config)#dial-peer voice 3 voip Router(config-dial-peer)#destination-pattern 2T Router(config-dial-peer)#session target ipv4:192.168.3.3

In this configuration, a dialed number of 2468 is matched by all three dial peers. However, dial peer 1 is the most specific dial peer, matching the dialed pattern exactly without the use of wildcards, and it is therefore used to forward the call. You might want to have multiple dial peers that match specific numbers, for redundancy reasons. For example, you might want to send calls that are destined for extension 4444 across the IP WAN. However, if the WAN is not available, you want to place the call through the PSTN. To accomplish this, you can have two dial peers, a VoIP dial peer that pointed




across the IP WAN and a POTS dial peer that pointed to a physical port attached to a PBX or the PSTN. You can then indicate that you prefer to use the VoIP dial peer by assigning priority values to the dial peers with the preference number command. For example, in dial-peer configuration mode for the VoIP dial peer, you could enter the preference 0 command. Similarly, you could use the preference 1 command for the POTS dial peer. Because lower-preference values are preferred, the VoIP dial peer is used, if it is available. If the VoIP dial peer is not available, the call fails over to the POTS dial peer. Note that the valid range of preference values is 0 to 10.

Digit Forwarding When the router is connected to a PBX or the PSTN, you need to understand how the router forwards digits. By default, digits that are explicitly matched by the destination-pattern command in a POTS dial peer are not forwarded. For example, consider a destination pattern of 123…, and that pattern matches the dialed digits 1235555. By default, the router forwards only the digits 5555 to the attached equipment, because explicitly matched digits are stripped. To prevent this behavior, you can use the no digit-strip command in dial-peer configuration mode. In addition to forwarding dialed digits, you might want to forward additional digits. For example, you might want to prepend a dialed number with a 9 before forwarding the number to a PBX. You can prepend digits to a dialed number with the prefix number command. As opposed to using the no digit-strip command, you can specify exactly how many digits to forward using the forward-digits number command. For example, you could use the dial-peer configuration mode command forwarddigits 5 to forward the five rightmost digits in the dialed number. You can even instruct the router to replace one dialed number with another. For example, you might have a telecommuter whose home phone number is 555-1234. However, employees at the headquarters location all have four-digit extension numbers. To make the telecommuter’s phone appear as a local extension, you can use the num-exp dialed_number translated_number command. In this example, if you want to represent the telecommuter’s home phone with a four-digit extension number of 2020, you enter the num-exp 2020 5551234 command in global configuration mode. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



Voice-Port and Dial-Peer Verification Various test commands are also available for troubleshooting purposes. For example, you can force a voice port to send ringing voltage to a voice port with the following command: Router#test voice port 1/1 relay ring on

You can also play a tone out to an attached phone during a phone call with the following command: Router#test voice port 1/1 inject-tone local 500hz

Note that other frequencies can be specified. You can even cause a gateway to dial a number with the csim start number command. For example, you can enter the csim start 5551212 command to cause the router to place a call to a destination phone number of 555-1212.



CHAPTER 4 Understanding and Configuring Digital Voice Ports

Chapter 4 Understanding and Configuring Digital Voice Ports Digital voice ports, unlike analog voice ports, have the unique capability to carry multiple simultaneous conversations on the same circuit. Therefore, in installations with multiple circuits (about seven or more), the economies of scale offered by digital voice ports start to make digital voce ports more economically attractive that multiple analog ports.

Digital Voice-Port Theory Although analog ports send and receive analog waveforms that continually vary, digital ports send binary data (that is, binary 1s/0s), which are represented on the wire as the presence of voltage or the absence of voltage. Examples of digital circuits include T1, E1, and Integrated Services Digital Network (ISDN) circuits, as shown in Figure 4-1. FIGURE 4-1 Digital Port Examples

IP WAN

T1

T1 E1 V

E1

ISDN BRI

ISDN ISDN BRI

ISDN PRI

V

ISDN PRI

PSTN PBX

PBX




Multiplexing, Framing, and Line Coding A common technology used to send multiple conversations over a single connection is time-division multiplexing (TDM). Consider a T1 circuit, which has 24 separate channels. With TDM, a T1 circuit can send an 8-bit sample from its first channel, followed by an 8-bit sample from its second channel, followed by an 8-bit sample from its third channel, and so on. Each channel, which means each conversation, gets its own time slice in which it can transmit its voice sample, as illustrated in Figure 4-2. FIGURE 4-2

T1 Circuit

Time-Division Multiplexing

V

V

Channel 1 Channel 2 Channel 3

24

3

2

1

24

3

2

1

Channel 24

A T1 digital circuit has 1.544 Mb/s of bandwidth. Consider the calculation of that bandwidth: n

Each frame is 193 bits in size: 24 channels x 8 bits per channel + 1 framing bit = 193 bit frames

n

The Nyquist theorem requires that you send 8000 samples per second: Samples per second = 2 * The highest frequency being sampled = 2 * 4000 = 8000

n

The total bandwidth on a T1 is 1.544 Mb/s: 193 bit frames * 8000 samples per second = 1.544 Mb/s




However, a T1 port does not send a single T1 frame at a time. Rather, it groups multiple frames together and sends them all simultaneously. Two approaches to grouping these frames together are as follows: n

Super frame (SF): Combines 12 standard 193-bit frames into a super frame

n

Extended super frame (ESF): Combines 24 standard 193-bit frames into an extended super frame

When you are configuring a T1 port (also known as a T1 controller on a Cisco router), the T1 port defaults to SF as the framing type. However, for real-world installations, ESF is almost always used. Another configuration parameter for a T1 controller is the line coding. A T1 circuit’s line coding is the set of rules that dictates how binary 1s and 0s are represented over the wire. Binary 1s are often thought of as being the presence of voltage, and binary 0s being the absence of voltage. Although that is true, the goal on a T1 line is to keep the average voltage on the line 0 volts, which means when you send a binary 1 using a positive voltage, the next binary 1 uses a negative voltage. Therefore, on average, the voltage on the wire is approximately 0. If two consecutive voltages have the same polarity, an error, called a bipolar violation, occurs. The approach of representing binary 1s as alternating voltages is called alternate mark inversion (AMI), and is shown in Figure 4-3. FIGURE 4-3

Bit Pattern

Alternate Mark Inversion

Voltage

0

1

1

0

1

0

1

0

0

Voltage

Although AMI does meet the goal of maintaining an average of 0 volts on the circuit, it has a major challenge. AMI has issues when it attempts to send a byte containing all 1s (that is, eight binary 0s in a row). Although various workarounds address this issue, errors can occur when sending eight 0s in a row over a T1 circuit using generic AMI line coding, as depicted in Figure 4-4.



CHAPTER 4 Understanding and Configuring Digital Voice Ports FIGURE 4-4 AMI’s Issue with Eight Consecutive 0s

Bit Pattern

Voltage

0

0

0

0

0

0

0

0

0

ERROR

Voltage

Because of AMI’s limitation, another type of line coding was developed. Bipolar 8-zero substitution (B8ZS) can represent a byte containing all 0s by creating a couple of bipolar violations. If a T1 circuit using B8ZS line coding experiences two bipolar violations at very specific bit positions, as seen in Figure 4-5, the equipment the T1 connects to (for example, a voice-enabled router) knows that a byte containing eight 0s is being transmitted. FIGURE 4-5

Byte Containing All Zeros

B8ZS Bit Pattern

Voltage

1

0

0

0

0

0

0

0

0

1

0

Voltage Bipolar Violations

Approaches to Digital Signaling Just as an FXS port needs some type of signaling (for example, loop start or ground start) to determine when a phone is on-hook or off-hook, a T1 circuit needs a signaling mechanism. Two approaches to sending signaling across a T1 circuit are as follows: n

Common channel signaling (CCS): With CCS, at least one channel is dedicated to sending a signaling protocol, while each of the other channels carry, for example, a voice conversation.



CHAPTER 4 Understanding and Configuring Digital Voice Ports n

Channel associated signaling (CAS): With CAS, specific low-order bits are “robbed” from voice samples in specific channels. The SF or ESF takes these low-order bits from every sixth channel (that is, channels 6 and 12 for SF and channels 6, 12, 18, and 24 for ESF). This approach is sometimes referred to as robbed-bit signaling. Because none of the 24 channels are dedicated to just sending signaling information, unlike CCS, all 24 channels can be used.

Common Channel Signaling Consider CCS in more detail. As the name suggests, all the channels used for sending voice, video, or data use the same channel (that is, a “common channel”) to send signaling information. A signaling protocol is sent over this dedicated channel. A popular technology that leverages CCS is ISDN. As previously mentioned, an ISDN circuit is made up of B channels and a D channel. A B-channel is a bearer channel, which carries the voice, data, or video. These bearer channels typically carry information at a rate of 64 kb/s. The D channel acts as the signaling channel, meaning that the D channel carries the data necessary to set up and tear down calls on the B channels. Depending on your bandwidth needs, you might select either the BRI or the PRI types of ISDN: n

Basic Rate Interface (BRI): BRI ISDN connections contain two 64 kb/s B channels and one 16 kb/s D channel, for a total usable bandwidth of 128 kb/s.

n

Primary Rate Interface (PRI): A PRI ISDN connection can use the channels on either a T1 or an E1 circuit. If the PRI is based on a T1 circuit, 23 of the T1’s 24 channels are used as B channels, and the remaining channel serves as the D channel. However, if the PRI is based on an E1 circuit, 30 of the E1’s 32 channels are used as B channels. One of the 32 channels (channel 1) carries framing and synchronization information, and the remaining channel (channel 17) acts as the D channel, carrying the signaling information for the 30 B channels.

The D channel in each of these instances uses Q.931 as its signaling protocol. PRI ISDN connections are often used to connect a company’s PBX to the public switched telephone network (PSTN). However, a BRI ISDN circuit might be used in a small office/home office (SOHO) environment.




Channel Associated Signaling With CAS on a T1 circuit, the low-order (that is, the rightmost) bit in every sixth frame in an SF or an ESF is used for signaling, rather than for voice sampling, as shown in Figure 4-6. The impact on voice quality resulting from the robbing of these bits is generally considered to be negligible. FIGURE 4-6 Robbed-Bit Signaling

Super Frame (24 193-Bit Frames)

Robbed Bits

Just as T1 circuits are popular in North America, E1 circuits are common in Europe. An E1 circuit has 32 channels, as opposed to the 24 channels available in a T1. The first of those 32 channels is dedicated to framing and synchronization, and the seventeenth channel is dedicated to signaling. Based on the discussion of how a T1 can free up its signaling channel using CAS, it might be tempting to think you could do the same with an E1 circuit, giving you 31 usable channels to send your voice, video, and data. However, an E1 circuit approaches CAS very differently than a T1. On a standard E1 circuit, the seventeenth channel is always used for signaling, regardless of whether CAS or CCS is being used. If CCS is being used, a signaling protocol (for example, Q.931) is sent over that channel. However, if CAS is being used, the 8 bits in the seventeenth channel are used for signaling. Consider how these bits can represent signaling information for the remaining channels. Understand that an E1 does not use the SFs or ESFs seen in the T1 world. Instead, an E1 combines sixteen frames together in a multiframe. If you examine the first frame in a multiframe and look at its seventeenth channel, you discover the seventeenth channel indicates the beginning of that multiframe. But then, if you examine the second frame in a multiframe, you see that its seventeenth channel is used to send signaling information. Specifically, 4 bits of signaling information for channel number 2




and 4 bits of signaling information for channel number 18 are being carried in the seventeenth channel of the second frame in an E1 multiframe. Similarly, the seventeenth channel of the third frame in a multiframe carries 4 bits of signaling information for channel 3 and 4 bits of signaling information for channel 19, as shown in Figure 4-7. This process continues for each of the remaining frames in the multiframe, such that the multiframe sends signaling information for 30 channels, which is exactly the number of channels you use in an E1 to send voice, video, and data. FIGURE 4-7 E1 Multiframe

Time Slot Frame

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

1 2 3

NOTE An E1 CAS trunk is commonly referred to as an E1 R2 trunk.

4 5 6 7 8 9 10 11 12 13 14 15 16




CAS Configuration Digital voice interfaces, such as T1, E1, and ISDN interfaces, have unique interface-specific configuration parameters. These parameters can include the type of line coding (for example, B8ZS) and framing (for example, ESF) that is used on the digital circuit. Consider the following T1 CAS configuration example, as illustrated in Figure 4-8 and Example 4-1. Note that a T1 is configured from controller configuration mode, as opposed to interface or voice-port configuration mode: FIGURE 4-8 T1 CAS Sample Topology

PSTN

T1 2/0 IP WAN

V

Router1

Example 4-1

V Router2

T1 Configuration Example

Router1(config)#controller 2/0 Router1(config-controller)#clock source line Router1(config-controller)#framing esf Router1(config-controller)#linecode b8zs Router1(config-controller)#ds0-group 0 timeslots 1-8 type fxo-loop-start Router1(config-controller)#exit Router1(config)#dial-peer voice 100 pots Router1(config)#destination-pattern 3... Router1(config)#port 2/0:0 Router1(config)#preference 1 Router1(config)#forward-digits all




In this example, T1 controller 2/0 gets its clocking from the network, as indicated by the clock source line command. In addition, the T1 is configured for extended superframing (ESF) and B8ZS line coding. The first eight channels in the T1 are grouped together in DS0 group 0, and they support FXO loop-start signaling. Next, a plain old telephone service (POTS) dial peer is configured to match four-digit numbers beginning with a 3. This dial peer forwards the call out of port 2/0:0, where 2/0 identifies the T1 controller (that is, slot 2, port 0), and the final 0 references the number of the previously configured DS0 trunk group. In this example, the preference 1 command is issued to make this POTS dial peer less preferable than a VoIP dial peer (not shown), which would complete the call over an IP WAN. Also, because a POTS dial peer only forwards digits matching the wildcard characters in the destinationpattern command, the forward-digits all command is issued to prevent the stripping of the 3. Also, notice the fxo-loop-start parameter. This parameter specifies the signaling type for the DS0 trunk group. Several other options are supported for this type parameter. For example, E&M offers different feature groups with different capabilities, as follows: n

E&M FG-B: E&M Feature Group B can send and receive Dialed Number Information Service (DNIS) information, and it can receive Automatic Number Identification (ANI) information. However, this feature group is supported only on the Cisco AS5x00 series platforms.

n

E&M FG-D: E&M Feature Group D supports incoming and outgoing DNIS, and it can receive ANI information.

n

E&M FG-D EANA: E&M Feature Group D Exchange Access North American supports incoming and outgoing DNIS, and it can transmit ANI information.

Consider an example that leverages the E&M feature groups. Suppose you have a router that needs to send and receive ANI information on a single T1 circuit. One approach for accomplishing this is divide the T1 into two DS0 trunk groups, one configured with E&M FG-D (to receive ANI) and one configured with E&M FG-D EANA (to send ANI). Example 4-2 illustrates the syntax for this scenario.



CHAPTER 4 Understanding and Configuring Digital Voice Ports Example 4-2

Using Multiple Trunk Groups to Send and Receive ANI

Router(config)#controller 2/0 Router(config-controller)#clock source line Router(config-controller)#framing esf Router(config-controller)#linecode b8zs Router(config-controller)#ds0-group 0 timeslots 1-12 type e&m-fgd Router(config-controller)#ds0-group 1 timeslots 12-24 type fgd-eana Router(config-controller)#exit Router(config)#dial-peer voice 100 pots Router(config-dial-peer)#incoming called-number . Router(config-dial-peer)#port 2/0:0 Router(config-dial-peer)#exit Router(config)#dial-peer voice 200 pots Router(config-dial-peer)#destination-pattern 9T Router(config-dial-peer)#port 2/0:1

CCS Configuration To illustrate the configuration of a CCS circuit, consider the configuration of an ISDN circuit, as shown in Figure 4-9 and Example 4-3. Router1 is connected to a PBX via an ISDN PRI circuit.



CHAPTER 4 Understanding and Configuring Digital Voice Ports FIGURE 4-9 ISDN PRI Sample Topology

T1 2/0 V Router1

Example 4-3

ISDN PRI PBX

ISDN PRI Configuration Example

Router1(config)#isdn switch-type primary-qsig Router1(config)#controller t1 2/0 Router1(config-controller)#pri-group timeslots 1-24 Router1(config-controller)#exit Router1(config)#interface serial 2/0:23 Router1(config)#isdn incoming-voice voice

In this example, the type of ISDN switch is globally defined as primary-qsig. Although vendor-specific switches can be configured, the primary-qsig option specifies that the attached ISDN switch uses Q Signaling (QSIG), which is often used to support multiple ISDN features between ISDN equipment for multiple vendors. In controller configuration mode, the 24 channels of the ISDN circuit are grouped together into a PRI group. To configure the D channel (that is, the signaling channel) of the T1 PRI circuit, you enter serial interface configuration mode. Notice that this example goes into interface configuration mode for interface serial 2/0:23, where 2/0 identifies the T1 controller, and the 23 indicates the D channel on that T1 controller. The number 23 is used rather than 24 (even though the D channel is the twenty-fourth channel on the T1) because the channel numbering for this command begins at 0. ISDN circuits support several features and options. For example, the previously mentioned QSIG signaling protocol can be used to help with vendor interoperation. Also, Non-Facility Associated Signaling (NFAS) can help leverage the D channel on one PRI to carry signaling information for B channels on multiple PRIs.

Q Signaling Many PBX vendors use proprietary signaling, making it challenging for one vendor’s PBX to communicate with another vendor’s PBX. Fortunately, QSIG can help provide vendor interoperability. Specifically, QSIG helps make sure that basic © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



Q.931 functions are communicated from one PBX, or other QSIG-speaking node, to another. Consider a few examples of QSIG features: n

Callback: If you call another party, and you receive a busy signal, because the other party is on the phone, the callback feature can be used to alert you after their phone goes on-hook.

n

Call transfer: QSIG can support the transfer of a call, without hairpinning (that is, without having an unneeded tandem hop as part of the call path).

n

Message waiting: QSIG supports signaling that can activate or deactivate message waiting indicators (MWIs).

Non-Facility Associated Signaling If you have multiple PRIs, instead of using up a D channel on each of those PRIs, you can free up extra channels using NFAS. Specifically, NFAS enables you to control multiple PRI interfaces with a single D channel. You can also have a backup D channel if the primary D channel is lost.

Verification of Voice Ports For verification and troubleshooting purposes, consider the following commands: n

show voice port: Displays detailed settings for voice ports

n

show voice port summary: Displays a concise view of installed voice ports

n

show voice dsp: Displays the codecs that are currently being supported by a router’s digital signal processors (DSPs)

n

show controller {T1 | E1}: Displays the operating parameters for T1/E1 controllers

n

show isdn status: Displays Layer 1, 2, and 3 information for an ISDN interface



CHAPTER 5 Exploring Gateway Control Protocols

Chapter 5 Exploring Gateway Control Protocols In this chapter, you learn about the theory and configuration of the following gateway control protocols: H.323, Session Initiation Protocol (SIP), and Media Gateway Control Protocol (MGCP). The discussion begins with the most mature of these protocols, H.323.

H.323 Theory and Configuration H.323 is not a single protocol. Instead, it is a suite of protocols. This suite specifies such things as audio/video codecs and call signaling. You should be aware of the following two protocols used to establish an H.323 call: n

H.225: Performs call setup and registration, admission, and status (RAS) functions

n

H.245: Performs call control, including a capabilities exchange (for example, codec negotiation)

In addition to various protocols, H.323 identifies the physical components of an IP telephony network, as follows: n

Terminals: An H.323 terminal is an end-user device that communicates with another end-user device. By definition, an H.323 terminal must support the G.711 codec.

n

Gateways: A gateway (GW) converts between different audio formats/signaling. For example, on one side of the GW, you might use H.225 and H.245 signaling, and the other side of the GW might use E&M wink-start signaling.

n

IP-to-IP gateways: These gateways allow different VoIP networks to interconnect. For example, if two companies have their own internal VoIP networks, a service provider’s IP-to-IP gateway could allow the two companies to join their VoIP networks. This solution requires no extension-number overlapping between the two companies. The Cisco IP-to-IP gateway product is Cisco Unified Border Element (UBE). © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.


CHAPTER 5 Exploring Gateway Control Protocols n

Gatekeepers: To prevent voice calls from oversubscribing the WAN bandwidth, groups of routers, called zones, can be identified. Then, a gatekeeper (GK) can keep track of the number of calls made from one zone to another, or calls made within a zone. Based on the available bandwidth within or between zones, a GK can permit or deny a call attempt. The GK can also perform centralized E.164 number resolution, in addition to several other features discussed later in these reference sheets.

n

Multipoint control units (MCUs): An MCU supports conference calling by adding and removing participants from a call and by mixing voice streams together.

GKs are optional components because you can have an H.323 GW directly communicate with another H.323 GW. However, this approach has scalability limitations. If you introduce GKs into the network, GWs communicate with GKs using the RAS channel. In larger topologies, you can have multiple GKs, and those GKs communicate with each other using the RAS channel. Consider how a call is completed in the following H.323 call scenarios: n

GW-to-GW calls: This topology does not require a GK. Specifically, both GWs communicate directly with each other. First, H.225 performs the call setup, followed by H.245 performing a capabilities exchange, as illustrated in Figure 5-1. However, this negotiation requires numerous packet exchanges between the GWs. Another option is to use H.323 Fast Connect, which performs call setup and does a capabilities exchange in a single exchange of messages between the two GWs.

n

GW-to-GK-to-GW calls: With a GK in your topology, the originating GW requests permission from the GK to place a call using an admission request (ARQ) message, after which the GK can send an admission confirm (ACF) or admission reject (ARJ) message. If permission is granted, the call setup proceeds. The destination GW also sends an ARQ to the GK. If permission is granted, the call setup proceeds as usual, using H.225 and H.245, after which Real-Time Transport Protocol (RTP) is used to stream audio directly between the GWs, as depicted in Figure 5-2.



CHAPTER 5 Exploring Gateway Control Protocols FIGURE 5-1 H.323 Call Setup Without a GK

x1111

V H.323 GW

V H.323 GW

x2222

H.225 Call Setup

H.245 Capabilities Exchange

RTP Streams RTCP Stream

FIGURE 5-2 H.323 Call Setup with a GK

H.323 GK (1) Admission Request and Confirmation (H.225 RAS)

x1111

V

V H.323 GW

(2) (4)

(3) Admission Request and Confirmation (H.225 RAS)

V H.323 GW

x2222

H.225 Call Setup






For even larger environments, you can have multiple GKs involved in the call setup. The main difference with such a configuration is that when the first GK gets an admission request, it sends a location request (LRQ) and must receive a location confirm (LCF) from the remote GK before sending an ACF to the originating GW. To increase the availability of H.323 networks, you can configure multiple GKs/GWs to service the same phone numbers. High-availability technologies such as Hot Standby Router Protocol (HSRP) can also be used to maintain uptime in an H.323 network. These reference sheets cover H.323 GW and GK configuration in Chapter 8, “Understanding and Configuring Gatekeepers.” However, for now, you can verify and troubleshoot an H.323 configuration with various show commands, as follows: n

show gatekeeper calls: Displays current phone calls that the GK participated in

n

show call active voice [brief]: Displays details for current voice calls

n

show call history voice [last n | record | brief]: Displays call record logs

SIP Theory and Configuration SIP uses the concept of inviting participants into sessions, and those sessions can be advertised by the Session Announcement Protocol (SAP). Like H.323, SIP is a peer-to-peer protocol. These peers are called user agents (UAs). The two types of UAs are as follows: n

User agent clients (UACs): Initiate the connection by sending an INVITE message

n

User agent servers (UASs): Reply to INVITE messages

SIP can optionally leverage the following types of SIP servers: n

Proxy server: Performs forwarding for a UAC

n

Registrar server: Registers the location of current clients © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.


CHAPTER 5 Exploring Gateway Control Protocols n

Redirect server: Informs the UA of the next server to contact

n

Location server: Performs address resolution for SIP proxy and redirect servers

SIP uses clear text for sending messages. The two types of SIP messages are as follows: n

Request: A message from a client to a server

n

Response: A message from a server to a client

A request includes messages such as an INVITE (which requests a participant to join the session) or a BYE (which disconnects the current call). Conversely, a response message uses HTML status messages. For example, you have probably attempted to connect to a website and received a “404 error” or a “500 error.” Those same types of responses are used in the SIP environment. For a SIP client to get the IP address of a SIP server, it has to resolve the SIP server’s address. These addresses are actually URLs that begin with sip: rather than http:, which is commonly used in web browsers. SIP addresses can include a variety of information, such as username, password, hostname, IP address, and phone number. Following is an example of a SIP address: sip:[email protected];user=phone

In this example, the user=phone argument specifies that the user portion of the URL (that is, 18595551212) is a phone number and not a user ID. SIP devices can dynamically make their addresses known by registering with a SIP registrar server. When SIP devices have their addresses registered, a SIP client might have the capability to resolve a SIP address by itself, perhaps through Domain Name System (DNS) or through a local host table. However, a SIP client can alternatively use a SIP proxy server to query a SIP location database to resolve the SIP IP address. Consider a basic SIP call, where one SIP GW communicates directly with another SIP GW, without the use of proxy or redirect servers, as illustrated in Figure 5-3.



CHAPTER 5 Exploring Gateway Control Protocols FIGURE 5-3 SIP Call Setup SIP UAC

V SIP GW

V SIP GW

SIP UAS

INVITE TRYING RINGING OK ACK RTP Streams

RTCP Stream

The basic call setup begins when a SIP client sends an INVITE to a SIP server (noting that a SIP IP phone can act as either a client or server, depending on whether it is originating or terminating the call). The destination server (that is, a UAS) responds if it is willing to join the session to which it has been invited. The originating client (that is, a UAC) sends an acknowledgment (that is, an ACK message) to the destination server, and at this point, the RTP streams can flow directly between the SIP GWs (or SIP IP phones). If you introduce a SIP proxy server into your topology, the call setup procedure is similar to that just discussed. However, the INVITE is sent to the proxy server rather than to the destination UAS. The proxy server can consult a location server to learn the IP address of the final endpoint. The destination exchanges call parameters with the proxy server, which responds to the originating UAC. The UAC then forwards an ACK through the proxy server to the destination UAS, after which the RTP stream is established. When a redirect server is used, the originating UAC sends an INVITE message to a redirect server, which can consult a location server to determine the path to the destination. The registrar server responds to the UAC with a moved message, telling the UAC the IP address of the destination UAS. This operation is much like when you connect to a website and




you receive a message saying that the page you are looking for has moved to a new URL. You are then automatically redirected to the new URL. When the UAC learns the location of the destination UAS, a direct connection can be set up between the UAC and UAS. Therefore, the main purpose of a redirect server is to offload the IP resolution procedure from the UAC. If one of your SIP servers goes down, the voice network could be rendered unavailable. One way to provide redundancy is to have multiple instances of proxy and redirect servers. Therefore, the UAs can have multiple entries, and if the first server fails, the second server takes over. Use the following two basic steps to configure SIP on a Cisco router: Step 1. Enable the UA. Step 2. Configure dial peers.

Consider Example 5-1. Example 5-1

Basic SIP Configuration Example

Router(config)#sip-ua Router(config-sip-ua)#sip-server dns:SERVER1 Router(config-sip-ua)#dial-peer voice 1 voip Router(config-dial-peer)#destination-pattern 5... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target sip-server

In this example, you enable the SIP UA with the sip-ua global configuration mode command. Then, you specify the DNS name of your SIP server with the sip-server command. After the SIP server has been defined, in VoIP dial-peer configuration mode, you specify that you want the dial peer to use SIP Version 2, with the session protocol sipv2 command. Finally, instead of specifying an IP address as the session target, you use the session target sip-server command, which points your dial peer to the SIP server that is defined under SIP UA configuration mode.




In addition to the show call commands that you used for H.323 verification, you can use the show sip-ua statistics command to display three different sets of statistics (that is, SIP response statistics, SIP total traffic statistics, and retry statistics).

MGCP Theory and Configuration Although H.323 and SIP are peer-to-peer protocols, MGCP is more of a client/server approach to call control. Specifically, MGCP allows GWs to point to a centralized call agent for processing. In a Cisco environment, this centralized call agent is the Cisco Unified Communications Manager (UCM) server, as illustrated in Figure 5-4. FIGURE 5-4

Call Agent (Cisco UCM Server)

MGCP Call Setup

Create Connection

x1111

Create Connection

V MGCP GW

V MGCP GW

x2222





The physical pieces that make up an MGCP network, such as call agents, GWs, and endpoints, are called components. However, the logical pieces of an MGCP network, such as calls and connections, are called concepts. First, consider the following MGCP components: n

Endpoints: An endpoint is where you interface between the VoIP network and the traditional telephony network. For example, an FXS port that connects to a telephone is considered an endpoint. Endpoint names look much like an email address (for example, [email protected]). These names are composed of two parts, the locally significant name of the endpoint (before the @ sign) and the DNS name of the MGCP GW (after the @ sign).

n

Gateways: GWs are in charge of converting audio between a VoIP network and a circuit-switched network. For example a residential GW supports devices that you typically find in residential environments (for example, plain old telephone service [POTS] telephones).

n

Call agents: A call agent is the intelligence of an MGCP network and controls the GWs and their endpoints. An MGCP GW can report events to the call agent, and the call agent can, for example, tell the endpoint what type of signaling to send to the phone.

Recall that an MGCP concept is a logical piece of an MGCP network. Consider the following MGCP concepts: n

Call: A call is formed when two or more endpoints are interconnected.

n

Event: An event is what an endpoint has been instructed (by the call agent) to watch for. For example, an FXS port might notice the event of an attached POTS device going off-hook.

n

Signal: A call agent instructs an endpoint to send a specific signal when a certain event occurs. For example, after the event of a POTS phone going off-hook, the call agent might instruct the FXS endpoint to send the signal of dial tone to the phone.

MGCP groups relevant events and signals into packages. For example, a line package contains events and signals that are used on subscriber lines, such as an off-hook event and a dial-tone signal. MGCP GW types are defined by the types of packages they support. For example, a trunk GW supports the generic media, dual tone multifrequency (DTMF), trunk, and RTP packages. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



You do not have to configure an MGCP GW with dial peers for every destination phone number. Instead, the GW can send each dialed digit to the call agent, until a match is made. However, that approach can put a processor burden on the call agent. An alternative approach is for the GW to download a digit map, which is a copy of the dial plan that is contained in the call agent. When a GW has a digit map, it then has the responsibility of collecting all the dialed digits and finding a pattern match. To enhance the availability of an MGCP network, survivability strategies such as MGCP switchover and switchback and MGCP gateway fallback are supported. MGCP switchover and switchback uses two or more UCM servers. When a GW sees no MGCP messages from a call agent for a period of time, the GW attempts to establish a connection with a backup UCM server. If the primary UCM comes back up, the GW can be configured to switch back to the primary. MGCP gateway fallback works with Survivable Remote Site Telephony (SRST) to maintain a remote office that connects to a centralized UCM server. If the WAN link that the GW uses to reach the UCM server fails, the GW relies on a fallback H.323 configuration that provides basic functionality for the GW’s voice ports. MGCP is enabled in global configuration mode with the mgcp command. The IP address of the call agent is then specified with the mgcp call-agent ip_address command. When MGCP is enabled, you specify which packages the GW expects the call agent to use when communicating with the GW. Consider Example 5-2, where you are specifying that a router is acting as an MGCP GW and that its call agent is located at IP address 10.1.1.1. Example 5-2

Basic MGCP Configuration Example

NOTE

Router(config)#mgcp

In a Cisco environment, because an MGCP gateway works in conjunction with a Cisco UCM server, the UCM server also has to be configured to allow the MGCP gateway to register.

Router(config)#mgcp call-agent 10.1.1.1

A POTS dial peer that is used by MGCP does not have a destination-pattern command. Instead, it uses the application MGCPAPP command to indicate that the port specified by the dial peer is controlled by an MGCP call agent. To view information about current MGCP connections on a GW, you can use the show mgcp connection command.



CHAPTER 6 Working with Dial Plans

Chapter 6 Working with Dial Plans A dial plan determines how calls are routed through a VoIP network. In this chapter, you will see what a dial plan contains and how to create a dial plan that points outward to the public switched telephone network (PSTN). Having multiple sites can add complexity to a dial plan (for example, because of overlapping number ranges). This chapter also covers potential solutions for such design challenges.

Dial-Plan Characteristics Dial plans typically organize a group of phone numbers in a hierarchical fashion. Consider the North American dialing plan, which consists of 10 digits, an example of which follows: 859-555-1212

The first three digits (that is, 859) indicate an area code, which is typically associated with a geographic location within North America. The following three digits (that is, 555) are the central office (CO) code (that is, the NXX code), which identifies a central office location within the area that is specified by the area code. The final four digits (that is, 1212) point the local CO to a specific local loop that goes out to a subscriber’s physical location. This section identifies the characteristics of a dial plan. Each of these characteristics is then discussed in more detail.




Dial-Plan Elements A dial plan contains elements that perform the following functions: n

Assigning endpoint addresses: Endpoint addressing determines the format of phone numbers.

n

Selecting a path: You might, for example, configure a dial plan to place calls over an IP WAN (as a preferred path), but calls might be routed over the PSTN as a backup.

n

Manipulating digits: Dialed digits and the digits making up a caller ID string might need to be manipulated when calling between phones. For example, digits such as area code and office code digits might need to be added when calling out to the PSTN, or one dial string (for example, a 0 to reach a company operator) might need to be replaced with another dial string (for example, the actual directory number of the operator’s phone).

n

Applying call restrictions: Call restrictions can be configured to control which destinations phones are allowed to call. For example, you might not want a lobby phone calling an international number.

n

Supporting call coverage: The call coverage feature allows a group of phones, sometimes called a hunt group, to handle incoming calls (for example, calls coming into a call center).

Assigning Endpoint Addresses Endpoint addressing assigns directory numbers (DNs) to devices, such as phones. Also, endpoint addressing maps internal extensions to incoming direct inward dial (DID) numbers. However, if you do not have a DID number to map to each internal DN, an auto attendant can be used to take an incoming call and route that call to an appropriate internal DN. One of the biggest challenges with endpoint addresses occurs when you have multiple sites, and those sites have overlapping DNs, as illustrated in Figure 6-1. Notice that both the Kentucky and Arizona locations have DNs of 1500 and 5101.



CHAPTER 6 Working with Dial Plans FIGURE 6-1

Site Code: 810

Site Code: 820

Overlapping DNs

UCM

V KY_Router

1500

UCM

PSTN

1501 Kentucky

IP WAN

V AZ_Router

1500

1501 Arizona

To allow callers in Kentucky and Arizona to have their calls extended to the appropriate locations, the administrator could require the use of site codes, where the dialed number is prepended with a site code when calling a remote site. In this example, if a caller at DN 1501 in Kentucky wants to call DN 1502 in Arizona, the caller can dial 8201502. Digit manipulation must then be performed to strip the 820 site code from the dialed number. Also, a good practice is to manipulate the caller ID number to prepend the Kentucky site code of 810 to 1501. As a result, the recipient of the call, at DN 1502 in Arizona, would look at his phone and see 8101501 displayed as the caller ID. This provides the called party with the exact number he should dial to call back the calling party.

Selecting a Path The call routing and path selection component of a dial plan dictates where and how calls should be routed through a network. Usually, how a call is routed depends on the dialed number. For example, was the dialed number on-net or off-net?




An IOS router acting as an H.323 gateway makes these call routing decisions based on dial peers. As a result, in some larger deployments, the number of dial peers can be large. Recall that multiple dial peers can be configured to point to the same destination, and the preference command can be issued in dial-peer configuration mode to influence which dial peer is used. The preferred dial peer could therefore point across an IP WAN, while a lesser-preferred dial peer could point outward to the PSTN.

Manipulating Digits Dial plans also need to accommodate for digit manipulation. For example, when a call comes in, the called number needs to match a destination pattern that the router knows how to reach. Also, you might want the caller ID of the calling number to appear as the number that the called party would have to dial to call back the calling party. For outbound calls, you need to present a valid dial string to, perhaps, the PSTN. In addition, you might need to support 911 calls, which might require Centralized Automatic Message Accounting (CAMA) trunks. A CAMA trunk can help preserve caller ID information being sent out on an analog trunk. For example, suppose a university spans several square miles and has several buildings. If a caller in Building Z calls 911, but the analog trunks coming in from the PSTN are located in Building A, the location information sent out to the 911 public-safety answering point (PSAP) will reflect the location of Building A rather than Building Z. CAMA can help solve this issue by transmitting the original caller ID over an analog trunk to the PSAP.

Applying Call Restrictions You probably do not want your users calling any destination they choose, such as international numbers, 900 numbers (that is, premium service numbers), or perhaps even 411 calls (that is, directory assistance calls). In a PBX environment, the feature that supports setting call limitations is commonly referred to as class of service (CoS). In a Cisco Unified Communications Manager (UCM) environment, partitions and calling search spaces are commonly used to apply call restrictions. Also, the class of restriction (CoR) feature adds call restriction support for IOS-based voice gateways.




Supporting Call Coverage The call coverage component of a dial plan helps minimize the number of dropped incoming calls. If you are not at your desk, for example, you might have your phone forwarded to another phone. In a call center environment, the goal is to intelligently distribute incoming calls across multiple customer service agents. The phones of these customer service agents can belong to a hunt group. However, callers do not directly dial one of the customer service agents. Instead, they dial a hunt pilot number, which distributes incoming calls among the hunt group members.

PSTN Dial Plans Configuring a dial plan to point outward to the PSTN can be a complex task. Often, you need to use solutions provided by Cisco UCM, Cisco UCM Express, or an IOS-based voice gateway. This section discusses PSTN dial-plan design considerations, and it examines syntax used to configure PSTN dial plans.

PSTN Dial-Plan Design Considerations Call routing and path selection should be set up in both the incoming and outgoing directions. To make the linkage between the PSTN and the internal VoIP network transparent to the end users, and to present appropriate caller ID information to both the called and calling parties, digit manipulation might be required. Consider the example shown in Figure 6-2. The topology shows an outbound call coming from DN 1500 in the Kentucky office and destined for a phone on the PSTN with a phone number of 480-555-1345.



CHAPTER 6 Working with Dial Plans FIGURE 6-2 Outbound PSTN Call Example

Kentucky DID Range: 8595551XXX

UCM matches the dial string and strips off the 9. ANI: 1500 DNIS: 4805551345

UCM

2 4

PSTN

V KY_Router

480-555-1345 3

1500 1

1501 DN 1500 Dials 94805551345.

Destination phone rings.

KY_Router prepends the local area code and office code to the ANI. ANI: 8595551500 DNIS: 4805551345

1. DN 1500 in the Kentucky office dials 94805551345 to reach a phone on the PSTN. The leading 9 indicates to the

UCM server that this call should be routed out the PSTN gateway. At this point, the Automatic Number Identification (ANI; that is, caller ID information) is 1500, and the Dialed Number Identification Service (DNIS; that is, the dialed number) is 94805551345. 2. The UCM server matches the DNIS against one of its route patterns. The UCM server is also configured to strip the

leading 9 from the DNIS before sending the call to the PSTN gateway. At this point, the ANI is 1500, and the DNIS is 4805551345. 3. The KY_Router prepends the ANI of 1500 with the local area code and office code. The call is then forwarded out

to the PSTN. At this point, the ANI is 8595551500, and the DNIS is 4805551345.




4. The destination phone (that is, 4805551345) rings, and the caller ID that appears on the destination phone is

8595551500.

ISDN Dial-Plan Considerations When using Integrated Services Digital Network (ISDN) trunks, you need to be aware of a couple of additional design considerations: n

An ISDN network might represent the ANI number as the shortest dialable number, along with type of number (TON) information. As a result, if you just add on the PSTN access code to this ANI number, you might not have a valid number that can be called back. You can, however, use digit manipulation to overcome this issue.

n

An ISDN network, or PBX, might require that when a call setup message is sent to them, numbering-plan information and TON information needs to be included. Digit-manipulation commands can again be used to present this type of information to the ISDN network or PBX.

Configuring PSTN Dial Plans Figure 6-3 shows syntax that might be used when configuring a PSTN dial plan. This PSTN dial plan has two primary requirements: n

Prepend outgoing ANI (that is, caller ID) information with the area code and office code of the Kentucky office.

n

Strip the area code and office code from the incoming DNIS (that is, the dialed number), so that only the four rightmost digits from the DNIS are used to route the call within the Kentucky office.



CHAPTER 6 Working with Dial Plans FIGURE 6-3

Kentucky

PSTN Dial-Plan Configuration Example

DID Range: 8595551XXX

UCM Prepend ANI with 859555

T1 PRI 1/0/0 PSTN

V KY_Router

480-555-1345 Translate DNIS to 4 Digits

1500

1501

Prepending Digits to the Outgoing ANI Example 6-1 shows the syntax that satisfies the first requirement, prepending outgoing ANI information with the area code and office code of the Kentucky office (that is, 859555). NOTE The next chapter digs deeper into the syntax used to configure voice translation profiles.

Example 6-1

Prepending Area Code and Office Code Information to Outgoing ANI

KY_Router(config)#voice translation-rule 1 KY_Router(cfg-translation-rule)#rule 1 /^1/ /8595551/ KY_Router(cfg-translation-rule)#exit KY_Router(config)#voice translation-profile ANI-OUT KY_Router(cfg-translation-profile)#translate calling 1 KY_Router(cfg-translation-profile)#exit KY_Router(config)#voice-port 1/0/0:23 KY_Router(config-voiceport)#translation-profile outgoing ANI-OUT




In Example 6-1, voice translation rule 1 matches a dial string beginning with a 1 and replaces the 1 with 8595551. So, this rule would replace the number of 1500 with 8595551500. The voice translation rule is then applied to a voice translation profile named ANI-OUT. Notice the calling parameter in the translate calling 1 command. The calling parameter means that the translation will be performed on the calling number, which is the ANI number. Finally, the voice translation profile of ANI-OUT is applied in the outgoing direction to the T1-based PRI. The D channel of an ISDN PRI circuit built on T1 voice port 1/0/0 is referenced as voice port 1/0/0:23.

Stripping Area Code and Site Code Information from the Incoming DNIS Example 6-2 illustrates the commands used to remove the area code and site code information from the DNIS number coming in from the PSTN. Example 6-2

Digit Stripping from the Incoming DNIS

KY_Router(config)#voice translation-rule 2 KY_Router(cfg-translation-rule)#rule 1 /^8595551/ /1/ KY_Router(cfg-translation-rule)#exit KY_Router(config)#voice translation-profile DNIS-IN KY_Router(cfg-translation-profile)#translate called 2 KY_Router(cfg-translation-profile)#exit KY_Router(cfg-translation-rule)#voice-port 1/0/0:23 KY_Router(config-voiceport)#translation-profile incoming DNIS-IN

Example 6-2 uses voice translation rule 2 to match a number beginning with 8595551. That string of digits is then translated to the number 1. Therefore, if DNIS information of 8595551500 were coming into the KY_Router gateway, voice translation rule 2 would replace the leading 8595551 digits with a 1, resulting in a DNIS of 1500.




Voice translation rule 2 is then applied to the voice translation profile DNIS-IN. Note the called parameter in the translated called 2 command, implying the translation rule is applied to dialed digits (that is, DNIS information). Finally, the voice translation profile is applied in the incoming direction to the D channel of the T1-based PRI circuit.

Monitoring and Troubleshooting PSTN Dial Plans Cisco offers a collection of show and debug commands for monitoring and troubleshooting dial-plan configuration, as shown in Table 6-1. Table 6-1

PSTN Dial-Plan Monitoring and Troubleshooting Commands

Command

Description

show dial-peer voice tag

Displays detailed configuration information about the specified dial peer

show dial-peer voice summary

Displays summary information (for example, type of dial peer, destination pattern, port, and session target) for all dial peers configured on a router

show dialplan number dial-string Shows which dial peer would be used by the router if a call were placed to the specified dial string debug isdn q931

Displays real-time ISDN Layer 3 signaling messages, which include ANI and DNIS information

debug voip dialpeer

Displays real-time dial-peer matching

debug voice translation

Displays real-time operation of voice translation rules

Numbering-Plan Characteristics A numbering plan is a component of a dial plan. Specifically, one of the functions of a dial plan described earlier was the addressing of endpoints. The number plan describes the strategy used to assign those addresses. Numbering plans should be scalable, logical, and comprehensive. This section explores various categories of numbering plans and design strategies for implementing numbering plans. Also, a critical aspect of many numbering plans is their capability to support emergency services. Therefore, this section concludes with a discussion of 911 services.




Introduction to Numbering Plans Just as an IP network benefits from a hierarchical IP addressing scheme, a VoIP network can benefit from a hierarchical numbering plan. In additional to being hierarchical, a good numbering plan should be able to scale for future growth.

Types of Numbering Plans Numbering plans can be categorized into one of two broad numbering-plan types: private numbering plans and PSTN numbering plans.

Private Numbering Plans A private numbering plan is used within an organization, and so these plans do not have to conform to any external standards. Following are a few design considerations for private numbering plans: n

Number of endpoints: The numbering plan should be able to address all existing endpoints, plus any anticipated growth, while using the fewest number of digits as possible.

n

Number of sites: The length of site codes should be minimized, while still accommodating the current number of sites, plus any anticipated growth.

n

Direct inward dial: If a block of numbers is purchased from the local telephone company, the last few digits of that block of numbers might be able to map directly to internal directory numbers. This type of arrangement is known as direct inward dial (DID). If the block of numbers purchased is not large enough to accommodate all internal directory numbers, an auto attendant might be used to intercept incoming calls and then direct those incoming calls to appropriate internal destinations.

n

Access codes: When assigning internal DNs, try to avoid beginning the DN numbering with numbers that are to be used for access codes. For example, if in an environment site codes begin with an 8, and PSTN calls begin with a 9, internal DNs should not begin with an 8 or 9.




PSTN Numbering Plans PSTN numbering plans can vary widely based on the country being supported. However, to understand a country’s numbering plan, the international E.164 numbering plan must be considered in addition to the country numbering plan. The following contrasts these two different categories of PSTN numbering plans: n

E.164: E.164 is an ITU standard for an international numbering plan. In this plan, each number has an associated country code (CC), which can be either one, two, or three digits in length. The country code is followed by the national destination code (NDC), which is then followed by the subscriber number (SN). The maximum number of digits in an E.164 number is 15.

n

National numbering plan: A country can define its own national numbering plan. For example, the United States uses a 10-digit numbering plan, where the first three digits represent the area code, which is formally known as the numbering plan area (NPA) code. The next three digits are the office code, also known as the NXX code, and the last four numbers are the subscriber numbers.

Following are common elements found in national numbering plans: n

Numbers for emergency services

n

Directory assistance services

n

Free calls within a geographic region

n

Billing calls to mobile phones (Note that the United States is an exception, and does not bill calls to mobile phones.)

n

Support for long-distance calls, with an accompanying charge

n

Toll-free number ranges

n

Support for premium services (for example, 900 numbers in the United States)

n

Support for international calls




Integrating Private Numbering Plans with PSTN Numbering Plans Following are design considerations for integrating a company’s private numbering plan with a PSTN numbering plan: n

Variable-length dial strings: When calling PSTN numbers from within an organization, the length of the dial strings may vary based on the destination. For example, a local call might not require an area code, whereas a longdistance call does. Therefore, digit manipulation might be required to support PSTN fallback, while making the numbering plan complexity as transparent as possible to the end users.

n

Centrex support: For some smaller office environments, the local telephony company can provide PBX-like features for the office location, without requiring the office to have a PBX or key system. These Centrex services typically have DNs that are four or five digits long. This can add significant numbering-plan complexity when a call comes into a VoIP network from the PSTN and that call is routed out to the Centrex environment.

n

Support for voice mail: Some voice mail systems use a different numbering plan than the telephone system they support. As a result, digit manipulation might be required to support transfers to voice mail.

n

PSTN fallback: If a call cannot be placed over the IP WAN, perhaps because of a lack of bandwidth or because of the IP WAN being unavailable, that call might be able to use the PSTN as a backup path. However, the originally dialed digits (for example, a DN or a DN prepended by a site code) are typically not sufficient to route the call through the PSTN. Therefore, digit manipulation needs to be performed to prepend appropriate digits, such as an area code, office code, or an access code.

n

International calls: Because country codes vary in length, numbering plans must be constructed to support the international destinations that need to be called.

n

End-user training: Even though a VoIP network implementation should strive to make the transition as transparent as possible to end users, some aspects of how end users place their calls, interpret caller ID, or check their voice mail might be different. Therefore, a critical implementation step is educating the end users about the operation of the newly deployed VoIP telephony system.



CHAPTER 6 Working with Dial Plans n

Number normalization: In a large VoIP network, such as a VoIP network supported by service providers, different sites in the overall VoIP network might use different DN lengths. To support calling from one site to another site over the VoIP network, number normalization can be used. The idea of number normalization is that when calling between sites, the calling and called numbers are modified to a standardized format (such as 10-digit dialing). Equipment at the individual sites can then perform digit manipulation to create appropriate calling and called dial strings for use within those individual sites.

Understanding 911 Services Although understanding the implementation of 911 emergency calling is beyond the scope of these reference sheets, you should understand some of the basic components that allow callers to have their location information correctly communicated to a 911 operator. Following is a listing of some of these basic components: n

Automatic Number Identification (ANI): The ANI is the phone number of the person placing the call.

n

Automatic Location Identification (ALI): The ALI is a database that associates a phone number with a physical location. Updates to this database can take about 48 hours. Therefore, updating the ALI database in a mobile environment is not an effective solution.

n

Public-safety answering point (PSAP): The PSAP is where a 911 call is terminated.

n

Emergency-response location (ERL): The ERL is used in mobile environments to identify the approximate location from which an emergency call was placed (for example, a specific floor in a building).

n

Emergency Location Identification Service (ELIN): The ELIN is used for mobile environments. Specifically, the ELIN phone number replaces the ANI phone number when an emergency call is sent to the PSAP.

n

Master Street Address Guide (MSAG): The MSAG is a government-maintained database that maps geographic regions to PSAPs, which are responsible for handling calls coming from those regions.



CHAPTER 6 Working with Dial Plans NOTE

n

Network designers should be aware of and follow local, municipal, state, and federal laws regarding 911 service.

Selective router: A selective router is a telephone switch that routes 911 calls to appropriate PSAPs, based on a call’s ANI information.

n

Centralized Automated Message Accounting (CAMA): A CAMA trunk is an analog trunk that connects a customer’s phone switch directly to a selective router. A CAMA trunk carries only 911 calls, and in the case of an analog trunk, if CAMA were not used, location information visible to the PSAP might be incorrect.



CHAPTER 7 Implementing Advanced Dial-Plan Features

Chapter 7 Implementing Advanced Dial-Plan Features A Cisco Unified Communications Manager (UCM) server offers several features to manipulate digits, select appropriate pathing, and limit which destinations various phones can call. However, IOS voice gateways might also need to perform these types of features. This chapter, therefore, explores the theory and configuration for these types of IOS features.

Digit Manipulation As evidenced in the preceding chapter, digit manipulation is often required in voice gateways to create appropriate caller ID and dialed number information. Digit manipulation encompasses several features, including prepending digits to a number, removing digits from a number, and translating one number to another number. These numbers can be such things as caller ID or dialed number information.

Using the digit-strip Command When using a plain old telephone service (POTS) dial peer, by default only digits matching wildcard characters in the destination-pattern command are forwarded out of the POTS port. For example, consider Figure 7-1. The analog phone is calling a number that that router should forward to an attached PBX. The phone sends the digits of 4123 to the router. However, the router has a destination-pattern command that matches 4…, and because only the digits 123 match wildcards (that is, the periods), the 4 is stripped off the string sent to the PBX.



CHAPTER 7 Implementing Advanced Dial-Plan Features Destination-Pattern 4… V Router

4123

PBX

123

FIGURE 7-1 The digit-strip Command

The digit-strip command can be used to override default digit stripping behavior. In this example, the command no digitstrip could have been issued in dial-peer configuration mode to prevent any digit stripping.

Using the forward-digits Command Another approach to overriding the previously described digit-stripping behavior is to use the forward-digits command. Specifically, the forward-digits command can be issued in dial-peer configuration mode, followed by a number. The number indicates the number of digits, beginning at the right of the dial string, that should be forwarded out of a POTS port. In this example, the forward-digits 4 command could have been used to cause the router’s dial peer to forward all four of the dialed digits.

Using the prefix Command The prefix command, followed by one or more numbers, could be used to prepend those numbers to a dial string. For example, the command prefix 9 might be used to prepend a 9 to a dial string being forwarded to a PBX, if the PBX required a 9 to place an outside call.




However, the prefix command could also be used in the previous example. Because the default digit-stripping behavior of the dial peer stripped off the digit 4, the prefix 4 command could be used to replace this stripped digit.

Using the num-exp Command The number expansion command (num-exp) can be used to replace one number with another number. For example, consider a telecommuter working from home, as depicted in Figure 7-2. Even though the telecommuter could be reached via the PSNT by dialing 555-1345, you might want this telecommuter’s phone to be reachable via a four-digit number, like the other internal numbers. You could therefore use the num-exp command to replace an internal directory number (DN) with the public switched telephone network (PSTN) number. For example, if the telecommuter were assigned a DN of 2020, the global configuration mode command of num-exp 2020 5551345 could be issued to take the dialed number of 2020 and replace it with a dialed number of 5551345. Be aware, however, you still need a dial peer that can match the newly created dial string of 5551345. FIGURE 7-2

Telecommuter’s Home

The num-exp Command

V

PSTN 555-1345

Headquarters




The clid Command In Integrated Services Digital Network (ISDN) circuits, there is a calling party number information element (IE), which is sent via the Q.931 protocol, that is used to send caller ID (or CLID) information. This information element can include two different calling numbers. One is a user-provided, or unscreened, number. The other one is a network-provided number. If you want to manipulate this caller ID information, you can use the clid command in dial-peer configuration mode. For example, the clid network-number number command enables you to set the network-provided number inside of Q.931 information elements. You can use the clid second-number strip to remove the user-provided number from the information element. Also, the clid restrict command sets the presentation bit in the Q.931 message to prevent the display of CLID information. You can also remove the numbers completely by using the clid strip command twice, to remove not only the calling number but also the calling name. Specifically, you enter clid strip to remove the calling number. You then enter clid strip name to remove the name.

Using Voice Translation Rules and Voice Translation Profiles The most advanced of the IOS-based digit-manipulation approaches involves voice translation rules and voice translation profiles. Specifically, a voice translation rule can define a set of rules (as many as 15) to change digits, ISDN numbering type, and number plan. These voice translation rules are associated with a voice translation profile, which can reference up to three voice translation rules: n

A rule to translate the dialed number

n

A rule to translate the caller ID information

n

A rule to translate the redirected called number




These profiles can be applied to, for example, voice ports or dial peers. Each of these entities can have two voice translation profiles applied, one for the inbound direction and one for the outbound direction. A translation rule uses regular expressions to perform digit matching. Table 7-1 provides a partial list of some of the more commonly used regular expressions. Table 7-1

Commonly Used Regular Expressions

Regular Expression

Description

^

Matches a number at the beginning of a string of numbers

/

Denotes the beginning and ending of matching and replacement strings in a voice translation rule

\

Negates the special meaning of the next character, such that the next character will be interpreted as the literal character

.

Matches one digit

*

Matches the previous character 0 or more times

+

Matches the previous character 1 or more times

\(\)

Groups elements of regular expressions into sets

To better understand the use of these regular expressions, consider the voice translation rule shown in Example 7-1. Example 7-1

Voice Translation Rule Example

Router(config)#voice translation-rule 1 Router(cfg-translation-rule)#rule 1 /^555\(....\)/ /111\1/

In Example 7-1, the two sets of forward slashes indicate the matching string and the replacement string, respectively, as shown in Figure 7-3.



CHAPTER 7 Implementing Advanced Dial-Plan Features FIGURE 7-3 Voice Translation Rule Structure: Matching and Replacement Strings

rule 1 /^555\(….\)/ /111\1/ Matching String

Replacement String

In the matching string, the ˆ555 means that for the voice translation rule will match a string, the string must begin with 555. Next, notice the \(…\), which matches any four digits. Also notice that the four periods are inside of a set of parentheses, and the parentheses are prepended with backslashes. The backslashes are used to negate any special meaning associated with the parentheses. The parentheses themselves are used to identify a set, which can be referenced in the replacement string. Because this is the first and only set in the matching pattern, the set number is one. In summary, for a string to match this voice translation rule, it must begin with a 555 and have at least four additional digits after the 555. Also, those four extra digits can be referenced by the replacement pattern as set one. The replacement string begins with 111, meaning that the first three digits of the translated string will begin with 111. The replacement string ends with a \1, which refers to set one from the matching pattern. For example, if the matched string were 5551345, the replacement string would be 1111345. When the voice translation rule is created, it can be referenced by a voice translation profile. Continuing with the preceding example, examine the syntax in Example 7-2. Example 7-2

Voice Translation Profile Example

Router(config)#voice translation-profile OFFICE-CODE Router(cfg-translation-profile)#translation called 1

In Example 7-2, the voice translation rule created in Example 7-1 is referenced by a voice translation profile named OFFICE-CODE (using the voice translation rule’s number of 1). Notice the called keyword in the translation called 1 command. This keyword means that the translation rule will be applied to a called number (that is, a number that was dialed).




The voice translation profile then needs to be applied to an entity such as a voice port of a dial peer for it to take effect. Example 7-3 shows the voice translation profile being applied to a voice port. Example 7-3

Applying a Voice Translation Profile

Router(config-voiceport)#translation-profile incoming OFFICE-CODE

The result of the command shown in Example 7-3 is that dialed numbers coming into the voice port that match the matching string (that is, a string of numbers beginning with a 555 and followed by at least four additional numbers) will be replaced with a seven-digit number beginning with 111, with the fourth through the seventh digits copied directly from the matching string to the replacement string.

Influencing Path Selection Various IOS configurations can influence the route selected for placing a phone call. For example, the previously discussed preference dial-peer configuration mode command can be used. In addition, tail-end hop off (TEHO) can be used to leverage the IP WAN to more cost-effectively place calls to the PSTN.

Influencing Path Selection with Dial-Peer Configuration Mode Commands Earlier you read about various dial-peer configuration mode commands that you can use to match incoming and outgoing dial peers, many of which enable you to influence call path selection. As a review, examine the dial-peer configuration mode commands presented in Table 7-2.



CHAPTER 7 Implementing Advanced Dial-Plan Features Table 7-2

Dial-Peer Configuration Mode Commands for Call Routing

Regular Expression

Description

destination-pattern number

Used by outgoing dial-peer matching to match a dialed number

incoming called-number number

Matches Dialed Number Identification Service (DNIS) information for inbound dial-peer matching

answer-address number

Matches Automatic Number Identification (ANI) information for inbound dial-peer matching

direct-inward-dial

Allows a router to take the DNIS digits coming in, from the PSTN, for example, and forward a call based on those digits, without presenting a dial tone to the caller

preference [0 – 10]

Breaks a tie between equally matched dial peers, where lower-preference values are more preferable

In addition, on some ISDN links, you might be able to benefit from the no dial-peer outbound status-check pots command. This command disables the checking of the status of an outbound POTS dial peer during the call setup process, which might otherwise disallow a dial peer whose status was down.

Influencing Path Selection with Tail-End Hop Off Imagine a scenario where a company has two offices, one in New York and one in Dallas. Suppose you are the New York office and want to call one of your company’s suppliers in Dallas. You will pay toll charges if you call over the PSTN. However, because your office in Dallas has a PSTN gateway that can place a local call to the supplier, you can call across the company’s IP WAN, from New York to Dallas, and hop off of the Dallas PSTN gateway to make a local call to the supplier. This scenario uses a feature called tail-end hop off (TEHO). TEHO can be especially beneficial for corporations that have multiple geographic locations. However, consult local restrictions before implementing TEHO, because TEHO is not legal in some countries.



CHAPTER 7 Implementing Advanced Dial-Plan Features To configure TEHO, you must

Step 1. Create outbound VoIP dial peers to point across the IP WAN. Step 2. Perform digit manipulation (for example, to prepend the digits necessary to place a call to the PSTN). Step 3. Create a POTS dial peer at the tail-end site, which points out to the PSTN.

Restricting Calls with Class of Restriction To restrict calls on an IOS router, instead of using partitions and calling search spaces (as used by Cisco Unified Communications Manager [UCM]), you can use an approach called class of restriction (CoR). Be aware, however, that using CoR might necessitate the creation of additional dial peers, as compared to what might otherwise be required. Specifically, instead of having a single dial peer to point out to the PSTN, you might need to create a dial peer to point out to the PSTN for emergency calls, another dial peer to point out to the PSTN for local calls, another one for longdistance calls, and perhaps another one for international calls. By being this granular in your configuration, you can create different rules for different categories of PSTN destinations.

CoR Theory CoR is configured by creating a series of CoRs. These CoRs are then assigned to a CoR list. These CoR lists can then be assigned to incoming/outgoing dial peers (or an ephone-dn in a Cisco UCM environment, or to a Survivable Remote Site Telephony [SRST] configuration). To help understand how CoR is configured, think of an incoming CoR list (for example, a CoR list applied to an inbound dial peer) as containing a set of keys (that is, the CoRs assigned to the incoming CoR list). Also, think of an outgoing CoR list (for example, a CoR list applied to an outbound dial peer) as containing a set of locks (that is, the CoRs assigned to the outgoing CoR list).




If both the incoming and outgoing dial peers for a call have a CoR list assigned, for the call to be placed the incoming CoR list must have a CoR (that is, a key) that matches each of the CoRs (that is, the locks) in the outgoing CoR list. If either the incoming dial peer or the outgoing dial peer does not have a CoR list assigned, however, the call is permitted. Figure 7-4 shows an example. FIGURE 7-4 CoR Sample Topology: Call Permitted

Incoming COR List – LOCAL-IN

Incoming COR List – LOCAL-OUT

- 911

- LOCAL

- INTERNAL - LOCAL

FXS 1/0/0

PSTN

V

1

Caller dials a local number of 5551345.

2

Gateway matches an incoming POTS dial peer that has the LOCAL-IN COR list assigned.

3

Gateway matches an outgoing POTS dial peer that has the LOCAL-OUT COR list assigned.

4

The call is permitted.

1. A caller in a VoIP network picks up a phone and dials 5551345. 2. The call is placed from an analog phone. So, when the call comes into the router, the router matches an incoming

dial peer that points to the local FXS port of 1/0/0. That incoming dial peer has a CoR list of LOCAL-IN associated with it. 3. The dial string of 5551345 matched an outbound POTS dial peer pointing out to the PSTN, and that dial peer has the

LOCAL-OUT CoR list applied.



CHAPTER 7 Implementing Advanced Dial-Plan Features 4. The call is permitted.

Recall that for the call to be permitted, the incoming CoR list must contain CoRs for each of the CoRs in the outgoing CoR list. In this example, the incoming CoR list contains the following CoRs: 911, INTERNAL, and LOCAL. Metaphorically, recall that you can think of CoRs in an incoming CoR list as keys. Also in this example, the outgoing CoR list contains the following CoR: LOCAL. Therefore, in this example, because the incoming CoR list contains the CoR of LOCAL (that is, the key of LOCAL), it matches the one and only CoR contained in the outgoing CoR list, which is LOCAL (that is, the lock of LOCAL). Therefore, the call is permitted. However, consider an example where a call would be denied (see Figure 7-5). FIGURE 7-5 CoR Sample Topology: Call Denied

Incoming COR List – LOCAL-IN

Incoming COR List – LD-OUT

- 911

- LD

- INTERNAL - LOCAL

FXS 1/0/0

PSTN

V

1

Caller dials a long distance number of 8595551345.

2

Gateway matches an incoming POTS dial peer that has the LOCAL-IN COR list assigned.

3

Gateway matches an outgoing POTS dial peer that has the LDOUT COR list assigned.

4

The call is rejected.

1. In this example, the caller dials a long-distance number. 2. The calls is placed from an analog phone. So, when the call comes into the router, the router matches an incoming

dial peer that points to the local FXS port of 1/0/0. That incoming dial peer has a CoR list of LOCAL-IN associated with it. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



3. The dial string of 8595551345 matched an outbound POTS dial peer pointing out to the PSTN, and that dial peer has

the LD-OUT CoR list applied. 4. The call is denied.

In this example, the LD-OUT CoR list contains the CoR of LD. However, because the incoming CoR list of LOCAL-IN does not contain the CoR of LD, the call is rejected.

CoR Configuration The first step when configuring CoR is to configure CoR lists, which is performed in CoR custom configuration mode, as demonstrated in Example 7-4. If you are familiar with creating partitions and calling search spaces in a UCM environment, this step is somewhat analogous to the creation of partitions. In this example, four CoRs are created: 911, INTERNAL, LOCAL, and LD. Example 7-4

Creating CoRs

Router(config)#dial-peer cor custom Router(config-dp-cor)#name 911 Router(config-dp-cor)#name INTERNAL Router(config-dp-cor)#name LOCAL Router(config-dp-cor)#name LD

Next, CoR lists are created. A CoR list is a collection of CoRs, and these CoR lists can be applied to incoming/outgoing dial peers. Example 7-5 illustrates the configuration of the incoming CoR lists used in this example. Four CoR lists, to be used as incoming CoR lists, are created in this example: 911-IN, INTERNAL-IN, LOCAL-IN, and LD-IN. Notice the member command is used to add CoRs to a CoR list. These CoRs were the keys used in the previous metaphorical explanation.



CHAPTER 7 Implementing Advanced Dial-Plan Features Example 7-5

Creating Incoming CoR Lists

Router(config)#dial-peer cor custom 911-IN Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom INTERNAL-IN Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member INTERNAL Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom LOCAL-IN Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member INTERNAL Router(config-dp-corlist)#member LOCAL Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom LD-IN Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member INTERNAL Router(config-dp-corlist)#member LOCAL Router(config-dp-corlist)#member LD

Example 7-6 shows the creation of the outgoing CoR lists used in this example. Members of these CoR lists are the locks that need to be unlocked by the keys in the incoming CoR list.



CHAPTER 7 Implementing Advanced Dial-Plan Features Example 7-6

Creating Outgoing CoR Lists

Router(config)#dial-peer cor custom 911-OUT Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom INTERNAL-OUT Router(config-dp-corlist)#member INTERNAL Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom LOCAL-OUT Router(config-dp-corlist)#member LOCAL Router(config-dp-corlist)#exit Router(config)#dial-peer cor custom LD-OUT Router(config-dp-corlist)#member LD

After the creation of the incoming and outgoing CoR lists, these lists need to be applied. Example 7-7 shows the application of an incoming CoR list to an existing POTS dial peer. Example 7-7

Applying an Incoming CoR List

Router(config)#dial-peer voice 100 pots Router(config-dial-peer)#corlist incoming LOCAL-IN

Finally, outgoing CoR lists are applied to outgoing dial peers. To illustrate, Example 7-8 shows the application of an outgoing CoR list to an outgoing dial peer. Example 7-8

Applying an Outgoing CoR List

Router(config)#dial-peer voice 200 pots Router(config-dial-peer)#corlist outgoing LD-OUT




Using CoR can benefit not only POTS and VoIP dial peers but also UCM Express (UCME) and SRST configurations. Both UCME and SRST configurations allow Cisco IP phones to register with a router running the UCME or SRST feature. CoR can therefore be used to enforce call restrictions on those Cisco IP phones. Specifically, the cor {incoming | outgoing} list-name command can be used in ephone-dn configuration mode on a UCME router, and the cor {incoming | outgoing} list-name tag starting number – ending-number command can be used in callmanager fallback configuration mode to apply a CoR list to a range of SRST directory numbers.



CHAPTER 8 Understanding and Configuring Gatekeepers

Chapter 8 Understanding and Configuring Gatekeepers An H.323 gatekeeper offers multiple benefits for larger enterprise networks. For example, a gatekeeper can make sure the bandwidth in the IP WAN does not become saturated with too many simultaneous voice calls. This chapter investigates this and many other features of the gatekeeper, in addition to exploring the theory and syntax of a basic gatekeeper configuration. You will also see how to scale your network with multiple gatekeepers.

Gatekeeper Features and Functions Among a gatekeeper’s many features, some are mandatory, and some are optional. This section distinguishes between the two. In addition, gatekeepers use a series of registration, admission, and status (RAS) messages, and some of the most commonly used RAS messages will be described. You will also see how directory gatekeepers can help scale a network and the use of technology prefixes. Finally, you will learn that you can offload some of a gatekeeper’s processing burden to an external server using the Gatekeeper Transaction Message Protocol (GKTMP) protocol.

Gatekeeper Functions Even though a gatekeeper is not a required component in an H.323 network, a gatekeeper could certainly help an H.323 network to scale, in addition to performing a collection of other features. Some of the gatekeeper’s features are mandatory, whereas others are optional, as shown in Table 8-1.



CHAPTER 8 Understanding and Configuring Gatekeepers Table 8-1

Gatekeeper Features

Feature

Mandatory or Optional

Description

Address translation

Mandatory

Address translation can translate a dialed phone number into a corresponding IP address to which a setup packet should be sent.

Admission control

Mandatory

Admission control uses a series of RAS messages to permit or deny a call to be placed.

Bandwidth control

Mandatory

Bandwidth control supports mid-call codec negotiation.

Zone management

Mandatory

Zone management can provide features (for example, address translation, admission control, and bandwidth control) to a device based on the logical zone with which a terminal or gateway is associated.

Call authorization

Optional

Call authorization can permit or deny access to H.323 endpoints based on policies (for example, time-of-day policies).

Call management

Optional

Call management keeps status information on current calls and influences routing of additional calls based on that information.

Bandwidth management

Optional

Bandwidth management is a subset of the admission control feature, and can permit or reject a call based on available bandwidth.

Call control signaling

Optional

Even though H.225 and H.245 call control signaling messages are exchanged directly between the H.323 endpoints involved in a call, the gatekeeper supports a configuration where these protocols can flow through the gatekeeper.

To understand the theory and operation of a gatekeeper, you need to understand a few basic terms. These terms include the following: zone, zone prefix, and technology prefix.

Definition of a Zone As mentioned in Table 8-1, a gatekeeper can treat H.323 endpoints (that is, terminals or gateways) differently based on the zone to which they belong. Figure 8-1 shows a simple topology with one gatekeeper. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.


CHAPTER 8 Understanding and Configuring Gatekeepers FIGURE 8-1 Gatekeeper Local Zones

V GK1

606-555-1111

V GW1

V GW2

ZoneA

859-555-2222

ZoneB

Notice that each H.323 GW belongs to a zone, but the gatekeeper itself does not belong to a zone. When each of these gateways registers with the gatekeeper, they register as members of their zone. Because members of both ZoneA and ZoneB register with the gatekeeper, both zones are considered to be local zones, from the perspective of the gatekeeper. If the topology contained an additional gatekeeper, as illustrated in Figure 8-2, and Zone B had registered with gatekeeper GK2, ZoneB would be considered to be a remote zone from the perspective of gatekeeper GK1. However, ZoneB would be considered to be a local zone from the perspective of gatekeeper GK2. FIGURE 8-2 Gatekeeper Remote Zones

V GK1

606-555-1111

ZoneA

V GW1

V GK2

V GW2

859-555-2222

ZoneB




Definition of a Zone Prefix When a gatekeeper learns about the H.323 terminals and gateway that have registered as members of various zones, the gatekeeper can direct calls destined for particular phone numbers to a terminal or gateway in a zone that can appropriately route a call destined for that phone number (see Figure 8-3). FIGURE 8-3 Gatekeeper Zones Prefixes

V GK1

V GW1

606-555-1111

ZoneA Zone Prefix 606

V GW2

859-555-2222

ZoneB Zone Prefix 859

In Figure 8-3, GW1 registered with GK1, as a member of ZoneA. GW2 registered with GK1, as a member of ZoneB. The gatekeeper GK1 might be configured with zone prefixes that say calls destined for area code 606 should be forwarded to ZoneA, and calls destined for area code 859 should be forwarded to ZoneB. As a result, if 606-555-1111 calls 859-5552222, gateway GW1 will ask gatekeeper GK1 how to route the call. Gatekeeper GK1 will examine the dial string and notice the destination area code of 859. The gatekeeper’s zone prefix configuration states that if a call is destined for area code 859, it should be routed to ZoneB. Since gateway GW2 has registered with gatekeeper GK1 as a member of ZoneB, gatekeeper GK1 will tell GW1 that it should send a call setup message directly to GW2.

Definition of a Technology Prefix You might have a family physician who handles most of your medical needs and regular checkups. On occasion, however, you might need to see a specialist. For example, you might go to a dermatologist for your skin, a podiatrist for your feet,




or an ophthalmologist for your eyes. Similarly, when a gateway registers with a gatekeeper, the gateway can register as a specialist for a particular type of call. For example, a gateway might register as a specialist for video calls, for modem calls, for fax calls, or another specific call type. Alternatively, much like a family physician, a gateway can register as a default technology gateway. A default technology gateway can handle calls that did not request a specialist. The way a call requests a specialist is by specifying a technology prefix as part of the dial string. When the gatekeeper receives a dial string that is prefixed with a technology prefix, the gatekeeper can forward the call to a gateway that registered with that specific technology prefix.

Registration, Admission, and Status Gatekeepers communicate with H.323 endpoints and gateways, in addition to other gatekeepers, using RAS messages. Although several RAS messages exist, these reference sheets describe some of the more commonly used RAS messages.

Discovery RAS Messages Before an H.323 terminal or gateway can register with a gatekeeper, it needs to discover a gatekeeper. Perhaps a gateway is preconfigured with the IP address of a gatekeeper. In that case, the gateway sends a gatekeeper request (GRQ) RAS message to make sure the gatekeeper is up and responsive. This GRQ is sent using a unicast message directed toward the preconfigured IP address. However, if the gateway does not know the IP address of a gatekeeper, it can attempt to dynamically discover a gatekeeper. This dynamic gatekeeper discovery involves sending a GRQ message to a multicast address of 224.0.1.41. After a gatekeeper receives a GRQ, it can respond with a gatekeeper confirm (GCF) RAS message to say that it is up and available. If the gatekeeper is not available (that is, it does not want the endpoint to attempt to register with it), however, it can respond with a gatekeeper reject (GRJ) RAS message.




Registration RAS Messages When an endpoint has discovered a gatekeeper, the next step is for that endpoint to register with that gatekeeper. Specifically, the endpoint sends a registration request (RRQ) RAS message to the gatekeeper requesting permission to register. As part of this registration message, the endpoint tells the gatekeeper about itself. For example, an RRQ RAS message might include information such as the name of the endpoint, the IP address of the endpoint, and the phone numbers reachable by that endpoint. If the gatekeeper permits registration from that endpoint, the gatekeeper responds with a registration confirm (RCF) RAS message. If the gatekeeper rejects the registration request, however, the gatekeeper can respond with a registration reject (RRJ) RAS message. After the endpoint registers with the gatekeeper, the endpoint continues to periodically send RRQ messages to the gatekeeper, and the endpoint expects an RCF in response. Although this RAS exchange can be useful to provide a keepalive function between the endpoint and gatekeeper, repeatedly sending all the information contained in the original RRQ message is not very bandwidth efficient. Fortunately, as of H.323 Version 2, these endpoints can send lightweight RRQ messages, which are considerably smaller than the initial RRQ message.

Admission RAS Messages After an endpoint discovers a gatekeeper and registers with that gatekeeper, when that endpoint wants to place a call across the IP WAN, it can send an admission request (ARQ) RAS message to the gatekeeper. The ARQ message requests two things. First, the ARQ asks permission to place the call. Second, the ARQ asks how to place the call. Specifically, the gatekeeper can keep track of available bandwidth on the IP WAN; and if the requested call will oversubscribe the IP WAN bandwidth, the gatekeeper can reject the request by sending an admission reject (ARJ) RAS message. If the call is permissible, however, the gatekeeper can respond with an admission confirm (ACF) RAS message. Also, the gatekeeper can take the phone number in the ARQ RAS message and translate the phone number into a corresponding IP address to which the endpoint should send its H.225 call setup message. Therefore, if the gatekeeper sends




an ACF message back to the endpoint, not only does the ACF message grant permission for the endpoint to place the call, the ACF message contains the IP address with which the endpoint should establish the call. To review how an H.323 call is established using a gatekeeper, take a look at Figure 8-4, which previously appeared in Chapter 5, “Exploring Gateway Control Protocols.” FIGURE 8-4

H.323 GK

ARQ RAS Message (1) Admission Request and Confirmation (H.225 RAS)

x1111

V

V H.323 GW

(2) (4)

(3) Admission Request and Confirmation (H.225 RAS)

V H.323 GW

x2222

H.225 Call Setup



1. Phone number 1111 dials phone number 2222, and 1111’s local gateway sends an ARQ message to the gatekeeper.

1111 receives an ACF in response to its ARQ. Embedded inside the ACF is the IP address of the target gateway. 2. Phone number 1111 sends an H.225 call setup message to the IP address of the target gateway. 3. The target gateway also sends an ARQ message to the gatekeeper, and it receives an ACF response from the gatekeeper. 4. After the target gateway receives an ACF from the gatekeeper, it completes the H.225 exchange with the originating

gateway. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



At this point, the remainder of the call setup is identical to a call setup that does not use a gatekeeper. After the completion of the H.245 exchange (and after phone number 2222 goes off-hook), the two gateways can set up a bidirectional Real-Time Transport Protocol (RTP) stream between themselves.

Location RAS Messages If a gatekeeper receives an ARQ and the phone number in the ARQ is in a remote zone (that is, the zone is registered with another gatekeeper), the gatekeeper can send a location request (LRQ) RAS message to another gatekeeper. This LRQ asks the other gatekeeper for the IP address of the H.323 endpoint to which call setup traffic should be sent. If the other gatekeeper responds with the requested information, it does so with a location confirm (LCF) RAS message. If the other gatekeeper cannot provide the requested information, however, it might respond with a location reject (LRJ) RAS message.

Directory Gatekeepers Large VoIP networks might contain several gatekeepers. Unfortunately, a large number of gatekeepers can significantly add to the required configuration, because every gatekeeper needs to have knowledge of every other gatekeeper. This results in a logical full mesh of connectivity between all the VoIP network’s gatekeepers. Fortunately, Cisco offers a proprietary solution called a directory gatekeeper, to which all other gatekeepers can point. A directory gatekeeper contains configuration information about all the zones in the VoIP network and IP addresses of gatekeepers responsible for those zones. This allows the directory gatekeeper to intelligently forward LRQ requests from one gatekeeper to another. More than one directory gatekeeper can be supported, to form a hierarchical structure of gatekeepers. However, an LRQ can be forwarded over a maximum of only five hops. Figure 8-5 illustrates how an LRQ gets forwarded to an appropriate gatekeeper in a simple directory gatekeeper deployment.



CHAPTER 8 Understanding and Configuring Gatekeepers FIGURE 8-5 2

GK1

V DGK

V

3

Q LR

LR Q

Directory Gatekeeper

V

GK2

1

606-555-1111

ZoneA

ARQ

ZoneDGK

V GW1

V GW2

859-555-2222

ZoneB

1. The gateway GW1 sends an ARQ message, on behalf of its attached phone, requesting permission to call 859-555-

2222 and requesting the IP address to which an H.225 call setup message should be sent. 2. Gatekeeper GK1 receives the ARQ message, but it does not have a zone prefix configured for the 859 area code. It

does, however, have a zone prefix configured for all unknown phone numbers. This zone prefix configuration causes GK1 to send and LRQ message to the directory gatekeeper DGK, in the ZoneDGK zone. 3. The directory gatekeeper examines the LRQ message and determines a caller is trying to reach phone number 859-

555-2222. Based on its zone prefix configuration, the directory gatekeeper knows that this phone number resides in the ZoneB zone. The DGK directory gatekeeper further knows that the ZoneB zone is local to the GK2 gatekeeper. Therefore, the DGK forwards the LRQ message to GK2, which then responds with the IP address of gateway GW2.




Advanced Call Routing with GKTMP If you need more advanced call routing decisions, beyond the capability of basic gatekeeper configuration, you can turn to the Gatekeeper Transaction Message Protocol (GKTMP). Specifically, GKTMP allows a gateway to convert a RAS message into text messages and send those text messages to an external server. The external server can then make routing decisions based on a variety of criteria, such as the time of day. The GKTMP server to which you can offload call routing decisions is platform independent. Specifically, GKTMP can run on Solaris, Linux, or Microsoft platforms.

Basic Gatekeeper Configuration To better understand the syntax used to configure basic gateway and gatekeeper operation, take a look at Figure 8-6. FIGURE 8-6 Gateway and Gatekeeper Configuration Sample Topology

V GK1 10.7.7.1

S0/0

606-555-1111

ZoneA

V GW1

S0/0 V GW2

859-555-2222

ZoneB

In this example, phone numbers for area code 606 are available in the ZoneA zone, and phone numbers for area code 859 are available in the ZoneB zone. Also, because gateways from both ZoneA and ZoneB register with the gatekeeper GK1, both ZoneA and ZoneB are considered to be local zones from the perspective of GK1.




Gatekeeper GK1 Configuration Example 8-1 shows the configuration for gatekeeper GK1. Example 8-1

Gatekeeper GK1 Configuration

GK1(config)#gatekeeper GK1(config-gk)#zone local ZoneA ciscopress.com 10.7.7.1 GK1(config-gk)#zone local ZoneB ciscopress.com GK1(config-gk)#zone prefix ZoneA 606....... GK1(config-gk)#zone prefix ZoneB 859....... GK1(config-gk)#gw-type-prefix 1#* default-technology GK1(config-gk)#no shutdown

NOTE If a zone has more than one endpoint that registers with the gatekeeper, the gatekeeper can specify the priority of these endpoints using the zone prefix zone-name dial-string gw-priority priority endpoint-name command. The valid range of priority values for this command range from 0 through 10, and 5 is the default. Higherpriority values for an endpoint make that endpoint more preferable for use by the gatekeeper.

To configure the gatekeeper, you first enter gatekeeper configuration mode, with the gatekeeper command. Next, you specify the zones known to this gatekeeper. In this simple topology, both zones register with GK1. As a result, both zones are considered to be local zones. The zone local gatekeeper-name domain-name [RAS-IP-Address] command is used to identify the local zones. Even though the syntax specifies a gatekeeper-name parameter, that parameter is actually the name of a local zone. When endpoints from that zone register with the gatekeeper, they attempt to register with a gatekeeper with the name of their zone. This often leads to some confusion. Therefore, it is often easier to think of the gatekeeper-name parameter in the zone local command as a zone-name parameter. The domain-name parameter must be specified, even if you are not using Domain Name System (DNS) services. The RAS-IP-Address parameter refers to the IP address on the gatekeeper used to send and receive RAS messages. To prevent conflicting IP addresses, only one zone local command can specify a RAS IP address. The zone prefix zone-name dial-string command associates a zone with one or more phone numbers. In this example, the zone prefix commands are used to associate the 606 area code with ZoneA and the 859 area code with ZoneB.




The gw-type-prefix 1#* default-technology command enables you to specify the technology prefix that will be used to route calls that do not specify a specific technology prefix. Finally, like an interface, the gatekeeper service can be administratively enabled or disabled. The no shutdown command enables you to administratively bring up the gatekeeper service.

Gateway GW1 Configuration Example 8-2

Gateway GW1 Configuration

GW1(config)#interface serial 0/0 GW1(config-if)#h323-gateway voip interface GW1(config-if)#h323-gateway voip id ZoneA ipaddr 10.7.7.1 GW1(config-if)#h323-gateway voip h323-id GW1 GW1(config-if)#h323-gaeway voip tech-prefix 1# GW1(config-if)#exit GW1(config)#dial-peer voice 100 voip GW1(config-dial-peer)#session target ras GW1(config-dial-peer)#destination-pattern 859....... GW1(config-dial-peer)#exit GW1(config)#gateway

In this example, GW1’s serial 0/0 interface is used to communicate with the gatekeeper via H.323 RAS messages. In interface configuration mode, the h323-gateway voip interface command is issued to declare that interface serial 0/0 is an H.323 interface. The h323-gateway voip id ZoneA ip addr 10.7.7.1 command says that this gateway wants to register with a gatekeeper at an IP address of 10.7.7.1, and that this gateway wants to register as a member of the ZoneA zone. Next, the h323-gateway voip h323-id GW1 command specifies the name of this gateway, as it will be known to the gatekeeper it registers with. Finally, in interface configuration mode, the h323-gateway voip tech-prefix 1# command is




issued to cause this gateway to register with a technology prefix of 1#. This particular technology prefix, as you saw in Example 8-1, will be considered by the gatekeeper as a default technology prefix. For a dial peer to send an ARQ message to a gatekeeper, the dial peer’s session target should be configured to use RAS, rather than point to a specific IP address. This is accomplished with the session target ras command in dial-peer configuration mode. Finally, for an IOS router to function as an H.323 gateway, the gateway process must be started on the router. This process is started by issuing the gateway command in global configuration mode.

Gateway GW2 Configuration Even through the configuration of GW2 is very similar to that of GW1, Example 8-3 shows (for the sake of completion) the gateway-specific configuration commands for GW2. Example 8-3

Gateway GW2 Configuration

GW2(config)#interface serial 0/0 GW2(config-if)#h323-gateway voip interface GW2(config-if)#h323-gateway voip id ZoneB ipaddr 10.7.7.1 GW2(config-if)#h323-gateway voip h323-id GW2 GW2(config-if)#h323-gaeway voip tech-prefix 1# GW2(config-if)#exit GW2(config)#dial-peer voice 100 voip GW2(config-dial-peer)#session target ras GW2(config-dial-peer)#destination-pattern 606....... GW2(config-dial-peer)#exit GW2(config)#gateway




Directory Gatekeeper Configuration A directory gatekeeper can act as a repository for call routing information in a network. A major benefit, therefore, is minimized configuration on nondirectory gatekeepers. Specifically, a gatekeeper serving a particular region could be configured with just two zone prefix commands, one pointing to a local zone for local numbers and another pointing to the directory gatekeeper’s zone for all other numbers.

Directory Gatekeeper Configuration To better understand the syntax used to configure a directory gatekeeper, take a look at Figure 8-7. FIGURE 8-7 Directory Gatekeeper Configuration Sample Topology

V DGK 10.3.3.1

GK1 10.7.7.1

V

V

GK2 10.5.5.1

ZoneDGK

606-555-1111

ZoneA

V GW1

V GW2

859-555-2222

ZoneB




Example 8-4 illustrates the configuration of the DGK directory gatekeeper. Example 8-4

Directory Gatekeeper Configuration

DGK(config)#gatekeeper DGK(config-gk)#zone local ZoneDGK ciscopress.com 10.3.3.1 DGK(config-gk)#zone remote ZoneA ciscopress.com 10.7.7.1 DGK(config-gk)#zone remote ZoneB ciscopress.com 10.5.5.1 DGK(config-gk)#zone prefix ZoneA 606....... DGK(config-gk)#zone prefix ZoneB 859....... DGK(config-gk)#lrq forward-queries DGK(config-gk)#no shutdown

Notice the DGK directory gatekeeper is configured for three zones in this example. It has a local zone of ZoneDGK and two remote zones of ZoneA and ZoneB. Because no phone numbers are reachable in the ZoneDGK zone, the configuration has no zone prefix command referencing that zone. The most significant distinction between a directory gatekeeper configuration and a nondirectory gatekeeper configuration, however, is the lrq forward-queries command, which instructs the directory gatekeeper to intelligently forward LRQ RAS messages to an appropriate destination gatekeeper. Only directory gatekeepers use this command.

Configuring Gatekeeper GK1 to Point to the Directory Gatekeeper Example 8-5 shows the configuration of the GK1 gatekeeper, which is acting as a regional gatekeeper.



CHAPTER 8 Understanding and Configuring Gatekeepers Example 8-5

Configuring GK1 as a Regional Gatekeeper

GK1(config)#gatekeeper GK1(config-gk)#zone local ZoneA ciscopress.com 10.7.7.1 GK1(config-gk)#zone remote ZoneDGK ciscopress.com 10.3.3.1 GK1(config-gk)#zone prefix ZoneA 606....... GK1(config-gk)#zone prefix ZoneDGK * GK1(config-gk)#gw-type-prefix 1#* default-technology GK1(config-gk)#no shutdown

The regional gatekeeper GK1 needs knowledge of only two zones, one local zone (that is, ZoneA) and the ZoneDGK zone. Specifically, if GK1 receives an ARQ specifying a phone number in the 606 area code, it can be directed to the ZoneA zone. ARQ messages specifying any other phone number (that is, a phone number outside of the 606 area code) will cause GK1 to forward an LRQ message to the directory gatekeeper, which will then forward the LRQ message to an appropriate gatekeeper.

Configuring Gatekeeper GK2 to Point to the Directory Gatekeeper For completion, Example 8-6 shows the configuration of the GK2 gatekeeper. This configuration, like GK1’s configuration, sends an LRQ to a directory gatekeeper for all nonlocal phone calls. Example 8-6

Configuring GK2 as a Regional Gatekeeper

GK2(config)#gatekeeper GK2(config-gk)#zone local ZoneB ciscopress.com 10.5.5.1 GK2(config-gk)#zone remote ZoneDGK ciscopress.com 10.3.3.1 GK2(config-gk)#zone prefix ZoneB 859....... GK2(config-gk)#zone prefix ZoneDGK * GK2(config-gk)#gw-type-prefix 1#* default-technology GK2(config-gk)#no shutdown




Using a Gatekeeper for Call Admission Control An H.323 gatekeeper, in addition to its number-resolution function, can be used as a call admission control (CAC) mechanism. A gatekeeper can set up bandwidth limits for calls between defined zones. This section discusses the theory of controlling bandwidth between zones and the syntax used to add CAC functionality to a gatekeeper.

Limiting Bandwidth Between Zones An IOS gatekeeper can be used to perform CAC between a Unified Communications Manager (UCM) server, a UCM Express (UCME) router, or an H.323 gateway. The amount of bandwidth allowed between different defined zones is statically configured, rather than dynamically learned. A gatekeeper can keep track of bandwidth going into and coming out of a zone. However, the gatekeeper does not actually measure the bandwidth. Instead, the gatekeeper keeps track of bandwidth based on the codecs used by the calls. Because bandwidth is not actually being measured, if you are using a bandwidth-compression technology (for example, compressed RTP), the gatekeeper does not change its bandwidth calculation. A gatekeeper makes its bandwidth calculation by taking the payload-only bandwidth demand of a voice call (based on the codec to be used) and doubles that number. Therefore, the gatekeeper’s bandwidth calculations for the G.711 and G.729 codecs are as follows: Gatekeeper bandwidth = Payload-only bandwidth requirement * 2 n

G.711: 64 kb/s * 2 = 128 kb/s

n

G.729: 8 * 2 = 16 kb/s




Configuring Zone Bandwidth Limitations The command to limit bandwidth between zones is issued in gatekeeper configuration mode and is as follows: Router(config-gk)#bandwidth {interzone | total | session | {default | zone zone-name} bandwidth

Table 8-1 describes the options available in the bandwidth command. Table 8-1

bandwidth Command Parameters

Parameter

Description

interzone

Refers to the amount of bandwidth from a zone to another zone

total

Refers to the cumulative amount of bandwidth allowed in a zone

session

Refers to the maximum amount of bandwidth that can be consumed by a single session

default

Refers to a default value used for all zones

zone

Refers to a specific zone

zone-name

The name of a zone for which you are assigning a bandwidth amount

bandwidth

An amount of bandwidth, in kilobits per second (kb/s)

To illustrate the use of the bandwidth command, consider Figure 8-8 and Example 8-7, which show a simple gatekeeper topology and the corresponding gatekeeper configuration.



CHAPTER 8 Understanding and Configuring Gatekeepers FIGURE 8-8 Bandwidth Configuration Sample Topology

V GK1 10.7.7.1

S0/0 V GW1

606-555-1111

S0/0 V GW2

ZoneA

Example 8-7

859-555-2222

ZoneB

Configuring Bandwidth Limitations

GK1(config)#gatekeeper GK1(config-gk)#zone local ZoneA ciscopress.com 10.7.7.1 GK1(config-gk)#zone local ZoneB ciscopress.com GK1(config-gk)#zone prefix ZoneA 606....... GK1(config-gk)#zone prefix ZoneB 859....... GK1(config-gk)#gw-type-prefix 1#* default-technology GK1(config-gk)#interzone default 64 GK1(config-gk)#interzone session default 16 GK1(config-gk)#no shutdown

In Example 8-7, the interzone default 64 command is used to set the maximum bandwidth limit from any zone to any zone to 64 kb/s. Recalling how the gatekeeper does its bandwidth calculations, a value of 64 kb/s supports four simultaneous G.729 calls (that is, (8 kb/s * 2) * 4 calls = 64 kb/s for 4 calls). Also, the interzone session default 16 command limits a single phone call to 16 kb/s, which supports one G.729 call.



CHAPTER 9 Interconnecting VoIP Networks with a Cisco Unified Border Element

Chapter 9 Interconnecting VoIP Networks with a Cisco Unified Border Element Two companies might use their own VoIP networks internally, and they might have frequent communication between one another. Instead of sending these intercompany calls over the public switched telephone network (PSTN), the call could remain a VoIP call end to end. To join together two VoIP call legs, however, you need an IP-to-IP gateway. The Cisco IPto-IP gateway is known as the Cisco Unified Border Element (UBE). This chapter discusses the theory and configuration of Cisco UBE.

Cisco UBE Theory A Cisco UBE is physically the same as a Cisco voice-enabled router. However, Cisco UBE has an IOS feature set with the unique capability to interconnect two VoIP call legs, as opposed to the traditional interconnection of a VoIP call leg with a plain old telephone service (POTS) call leg.

Cisco UBE Features Normally, as a VoIP call passes through a voice-enabled gateway, one leg is a POTS call leg, and the other is a VoIP call leg. However, if you want to interconnect two VoIP networks, perhaps VoIP networks from different companies, you need a gateway that supports VoIP-to-VoIP call legs. For example, you could have H.323-to-SIP (Session Initiation Protocol), H.323-to-H.323, or SIP-to-SIP call legs.




Figure 9-1 depicts a Cisco UBE interconnecting two VoIP call legs. FIGURE 9-1 Interconnecting Two VoIP Call Legs with a Cisco UBE

VoIP Call Leg VoIP

VoIP Call Leg V V

VoIP

Cisco UBE

Cisco UBE requires special IOS feature sets. Specifically, you need to use one of the following IOS feature sets: n

INT VOICE/VIDEO, IPIPGW, TDMIP GW AES

n

INT VOICE/VIDEO, IPIPGW, TDMIP GW

Cisco UBE in the Enterprise Cisco UBE can be used to interconnect different enterprises, but it can also be used within an enterprise to interconnect, for example, VoIP and video over IP users to increase interoperability. Cisco UBE offers several features that could benefit an enterprise network, such as the capability to have an H.323 VoIP call leg communicate with a SIP VoIP call leg. In addition, because Cisco UBE terminates, and then reoriginates, a call, it provides a demarcation point for billing purposes. Also, for security purposes, the Cisco UBE can hide the IP addresses of the customer equipment, replacing those addresses with the IP address of the Cisco UBE.

Protocol Interworking The term protocol interworking seems to imply interconnecting VoIP call legs from two different VoIP protocols (for example, H.323 and SIP). However, you can use a Cisco UBE to interconnect the same protocol. For example, you might have different H.323 devices with slightly different capabilities. In that instance, you can use a Cisco UBE to make those dissimilar devices work together. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



As an example of this interworking feature, consider SIP and H.323. H.323 offers a faster process for setting up a connection, called H.323 Fast Start. With H.323 Fast Start, instead of an exchange of H.225 messages followed by an exchange of H.245 messages, H.323 can completely set up a call in a single round trip. SIP has a similar feature, called Early Offer. Without a Cisco UBE gateway, one of the Fast Start mechanisms from one of these protocols would not be able to set up a call with one of the Slow Start mechanisms. However, with a Cisco UBE, these diverse call setup types become interoperable.

Media Flow in a Cisco UBE Environment Because a Cisco UBE gateway forwards signaling protocols, it can influence the setup of the media channels, and it can use one of two approaches: n

Media flow-through: Media flow-through is the default mode, where the voice media flows through the Cisco UBE. For security purposes, this approach might be desirable when connecting to an external network. One of the benefits of this approach is that it can conceal the IP address of an endpoint, because the endpoint’s IP address is replaced with the IP address of a Cisco UBE gateway.

n

Media flow-around: By having media flow through a gateway, the Cisco UBE is subject to extra processor overhead, which might limit scalability and might not be desirable. Therefore, for handling internal calls, a better approach might be the use of media flow-around, which leaves the IP addresses of the endpoints as they are. Although the Cisco UBE is responsible for handling the signaling to set up a call, after the call is set up, the two endpoints can stream voice directly between themselves.

Codec Filtering in a Cisco UBE Environment An H.323 gateway can be configured with a list of supported codecs, and when a VoIP call is being set up between two H.323 gateways, the H.245 protocol is used to negotiate the codec used by the call. However, in a Cisco UBE environment, the Cisco UBE can also participate in the codec negotiation. In that instance, both H.323 gateways and the Cisco UBE gateway must support and agree upon the codec to be used the call. © 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 130 for more details.



Having a Cisco UBE involved in codec negotiation is not a requirement. A transparency configuration exists, which will allow the H.245 codec negotiation to be conducted without any intervention by a Cisco UBE.

RSVP-Based CAC in a Cisco UBE Environment If a network has two Cisco UBEs, rather than just one, you can use Resource Reservation Protocol (RSVP) to act as a call admission control (CAC) mechanism between those two Cisco UBEs, thus preventing WAN oversubscription. However, be aware that if you are using RSVP, the Cisco UBE must be configured for media flow-through operation. Media flow-around is not supported with RSVP-based CAC, because if the media is not flowing through the Cisco UBEs, the treatment of the media cannot be guaranteed. Figure 9-2 illustrates the call setup between two H.323 gateways when RSVP-based CAC is being used in conjunction with two Cisco UBEs. FIGURE 9-2 RSVP-Based CAC in a Cisco UBE Environment

H.323_GW1

Cisco_UBE1

V

V

1

Cisco_UBE2

H.225 2

V

H.245

8

V

RSVP RSVP

4

H.323_GW2

3

H.225 H.245 with Media FlowThrough RTP

5 7

H.225 H.245

6 9




1. The H.323_GW1 gateway initiates a call by sending an H.225 message to Cisco_UBE1. 2. Before a call is set up, an RSVP reservation should be established. Therefore, Cisco_UBE1 sends an RSVP reserva-

tion request to Cisco_UBE2. 3. Cisco_UBE2 responds to the RSVP reservation request, and the RSVP reservation is established. 4. Cisco_UBE1 then sends an H.225 call setup message to Cisco_UBE2. 5. Cisco_UBE2 sends an H.225 call setup message to H.323_GW2. 6. H.323_GW2 and Cisco_UBE2 exchange H.245 messages. 7. Cisco_UBE2 and Cisco_UBE1 exchange H.245 messages. 8. Cisco_UBE1 and H.323_GW1 exchange H.245 messages. 9. With the call now set up end-to-end, the H.323 gateways can exchange RTP packets.

Using a Gatekeeper in a Cisco UBE Environment Just as a regular H.323 gateway can register with a gatekeeper, a Cisco UBE can register with a gatekeeper. A gatekeeper can then use a Cisco UBE along with via-zones. Specifically, when a call is being routed between two zones, the gatekeeper can be configured to route the call via the zone containing the Cisco UBE. This approach enables you to have a centralized Cisco UBE without having a Cisco UBE at every site. Figure 9-3 shows a call between two zones (each of which map to an area code). Notice the Cisco UBE terminates and then reoriginates the call. Specifically, H.323_GW1 sends an admission request (ARQ) to GK1. GK1 then sends an location request (LRQ) to the VIA-Zone_GK gatekeeper. The VIA-Zone_GK gatekeeper responds to the LRQ with a location confirm (LCF) that specifies the IP address of the Cisco_UBE gateway. Therefore, H.323_GW1 sends its call setup message to the Cisco_UBE gateway. A call is established between H.323_GW1 and Cisco_UBE. The Cisco_UBE gateway also establishes a call with H.323_GW2. Therefore, the use of a via-zone gatekeeper caused the insertion of a




Cisco UBE in the call setup path between H.323_GW1 and H.323_GW2. FIGURE 9-3

Zone_606

Zone_VIA

Zone_859

Via-Zone Gatekeeper VIA-Zone_GK

GK1

V

V

Call 1

V H.323_GW1

GK2 V

Call 2

V Cisco_UBE

V H.323_GW2

Cisco UBE Configuration A Cisco UBE can be configured to support protocol interworking. Among its configurable options are whether media will flow through or flow around the Cisco UBE, in addition to whether the Cisco UBE becomes involved in codec negotiation. This section shows the syntax used to configure these features and parameters. In addition, a Cisco UBE can be used in conjunction with a via-zone gatekeeper. Therefore, this section also discusses the syntax for via-zone gatekeeper configuration.




Protocol Interworking Protocol interworking supports the interconnection of two call legs. For example, an H.323 call leg can be interconnected with another H.323 call leg, or with a SIP call leg. The voice service configuration mode command allow-connections from-protocol to to-protocol can be used to configure protocol interworking. Example 9-1 illustrates the configuration of H.323-to-H.323 interworking. Example 9-1

Configuring H.323 Interworking

Cisco_UBE(config)#voice-service voip Cisco_UBE(config-voice-service)#allow-connections h323 to h323

Example 9-2 shows how protocol interworking is configured for connecting H.323 and SIP call legs. NOTE The allow-connections command is unidirectional. Therefore, to allow protocol interworking between H.323 and SIP, the allow-connections command must be issued twice, once for H.323-to-SIP and once for SIP-to-H.323.

Example 9-2

Configuring H.323 and SIP Interworking

Cisco_UBE(config)#voice-service voip Cisco_UBE(config-voice-service)#allow-connections h323 to sip Cisco_UBE(config-voice-service)#allow-connections sip to h323

Media Flow and Codec Transparency In a Cisco UBE environment, call signaling flows through the Cisco UBE. However, you have the option of having the media (that is, the voice packets) flow through the Cisco UBE or around the Cisco UBE. If you do want the media to flow through the Cisco UBE (which can provide address hiding for security purposes), you can issue the media flowthrough command in dial-peer configuration mode.



CHAPTER 9 Interconnecting VoIP Networks with a Cisco Unified Border Element NOTE Media flow-through is the default setting for a dial peer. Therefore, the media flow-through command does not have to be entered.

If you prefer to have the media not flow through the Cisco UBE (which can ease the processor burden on the Cisco UBE), however, you can issue the media flow-around command in dial-peer configuration mode. Also, when the H.323 endpoints are performing their codec negotiation, if you do not want the Cisco UBE to become involved in that negotiation, you can enter the codec transparent command in dial-peer configuration mode. Otherwise, the Cisco UBE will also have to agree to support the selected codec.

Configuring a Via-Zone Gatekeeper for Use with a Cisco UBE Figure 9-4 illustrates the configuration of a Cisco UBE and a via-zone gatekeeper within a via-zone. FIGURE 9-4 Via-Zone Configuration: Sample Topology

Zone_606

GK1

GK2

V

V

Call 1

V H.323_GW1

Zone_859

Zone_VIA VIA-Zone_GK 10.10.1.1

V

Call 2

V 10.10.1.2 Cisco_UBE

V H.323_GW2




Example 9-3 shows the configuration of the via-zone gatekeeper (named VIA-Zone_GK). Example 9-3

Configuring a Via-Zone Gatekeeper

VIA-Zone_GK(config)#gatekeeper VIA-Zone_GK(config-gk)#zone local Zone_606 ciscopress.com 10.10.1.1 invia Zone_VIA outvia Zone_VIA VIA-Zone_GK(config-gk)#zone local Zone_859 ciscopress.com invia Zone_VIA outvia Zone_VIA VIA-Zone_GK(config-gk)#zone local Zone_VIA ciscopress.com VIA-Zone_GK(config-gk)#zone prefix Zone_606 606....... VIA-Zone_GK(config-gk)#zone prefix Zone_859 859....... VIA-Zone_GK(config-gk)#gw-type-prefix 1#* default-technology VIA-Zone_GK(config-gk)#no shutdown

The primary difference between the configuration of a via-zone gatekeeper and a traditional gatekeeper configuration is that the zone local commands (for zones other than the via-zone) specify an intermediary zone through which a call should pass before reaching the destination zone. For example, the zone local Zone_606 ciscopress.com 10.10.1.1 invia Zone_VIA outvia Zone_VIA command says that call setup traffic going into or out of Zone_606 should pass through the Zone_VIA zone.




Configuring a Cisco UBE for Use with a Via-Zone Gatekeeper Example 9-4 provides the gateway-specific syntax for the Cisco UBE gateway in this example. Example 9-4

Configuring a Cisco UBE Gateway

Cisco_UBE(config)#voice service voip Cisco_UBE(config-voice-service)#allow-connections h323 to h323 Cisco_UBE(config-voice-service)#exit Cisco_UBE(config)#interface fa 0/1 Cisco_UBE(config-if)#ip address 10.10.1.2 Cisco_UBE(config-if)#h323-gateway voip interface Cisco_UBE(config-if)#h323-gateway voip id Zone_VIA ipaddr 10.10.1.1 Cisco_UBE(config-if)#h323-gateway voip h323-id Cisco_UBE Cisco_UBE(config-if)#h323-gateway voip tech-prefix 1# Cisco_UBE(config-if)#exit Cisco_UBE(config)#dial-peer voice 606 voip Cisco_UBE(config-dial-peer)#destination-pattern 606....... Cisco_UBE(config-dial-peer)#session target ras Cisco_UBE(config-dial-peer)#exit Cisco_UBE(config)#dial-peer voice 859 voip Cisco_UBE(config-dial-peer)#destination-pattern 859....... Cisco_UBE(config-dial-peer)#session target ras Cisco_UBE(config-dial-peer)#exit Cisco_UBE(config)#gateway




The primary distinctions between a traditional gateway configuration and the Cisco UBE gateway configuration shown in Example 9-4 are the following: n

The allow-connections command is issued in voice service configuration mode to allow protocol interworking.

n

The Cisco UBE registers with the via-zone gatekeeper as a member of the via-zone.

n

Phone numbers available in other zones are configured using VoIP dial peers, with a session target of ras.

Verifying Via-Zone Gatekeepers Because a via-zone gatekeeper is an H.323 gatekeeper, traditional gatekeeper verification commands are also applicable for verifying a via-zone gatekeeper. For example, consider the following commands for verifying via-zone gatekeeper configuration and operation: n

show gatekeeper endpoints: Shows an H.323 endpoint’s IP address, H.323 ID, maximum call capacity, current call capacity, and the gatekeeper’s total number of endpoint registrations

n

show gatekeeper calls: Provides information about the call legs currently joined together to create end-to-end calls


[ 130 ] Feedback Information

CCVP CVOICE Quick Reference, Second Edition

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members of the professional technical community.

Wallace, Kevin

Reader feedback is a natural continuation of this process. If you have any comments on how we could improve the quality of this digital Short Cut, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please be sure to include the digital Short Cut title and ISBN in your message.

Copyright © 2009 Cisco Systems, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA

We greatly appreciate your assistance.

All rights reserved. No part of this digital Short Cut may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Second Digital Edition January 2009 ISBN-10: 1-58705-824-3

Corporate and Government Sales The publisher offers excellent discounts on this digital Short Cut when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected]. For sales outside the United States, please contact International Sales [email protected]

ISBN-13: 978-1-58705-824-0

Warning and Disclaimer This digital Short Cut is designed to provide information about networking. Every effort has been made to make this digital Short Cut as complete and accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this digital Short Cut. The opinions expressed in this digital Short Cut belong to the authors and are not necessarily those of Cisco Systems, Inc.

Trademark Acknowledgments All terms mentioned in this digital Short Cut that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this digital Short Cut should not be regarded as affecting the validity of any trademark or service mark.


Cisco Press CCVP CVOICE Quick Reference

CCVP CVoice Quick Reference Sheets

CCVP TUC Quick Reference Sheets

Cisco press CCNP ROUTE 642 902 Quick Reference

Cisco 802.11 Wireless Networking Quick Reference

Cisco IOS Reference Guide

bash Quick Reference

Cisco Voice over IP CVoice) Authorized Self-Study Guide

PERL 5 Quick Reference

CCNP Quick Reference

Access 97 Quick Reference

Essential XML quick reference

Osteoarthritis Quick Reference Guide (Quick Study Health)

Pharmacology Quick Reference Guide (Quick Study Academic)

Genetics Quick Reference Guide (Quick Study Academic)

Cisco Voice over IP (CVOICE) (Authorized Self-Study Guide)

Quick Scripture Reference for Counseling

PCs for Dummies: Quick Reference

HTML5 For Dummies Quick Reference

Bourne Shell quick reference guide

Apache Geronimo 2.1 Quick Reference

Medical Psychiatry: The Quick Reference

PCs For Dummies Quick Reference

Apache Geronimo 2.1: Quick Reference

Route 66 Quick Reference Encyclopedia

Oracle DBA SQL Quick Reference

IFRS: A Quick Reference Guide

Laptops For Dummies Quick Reference

Linux Security Quick Reference Guide

Quick Reference Clinical Chiropractic Handbook

Cisco TCP-IP routing professional reference

Cisco Press CCVP CVOICE Quick Reference

CCVP CVoice Quick Reference Sheets

CCVP TUC Quick Reference Sheets

Cisco press CCNP ROUTE 642 902 Quick Reference

Cisco 802.11 Wireless Networking Quick Reference

Cisco IOS Reference Guide

bash Quick Reference

Cisco Voice over IP CVoice) Authorized Self-Study Guide

PERL 5 Quick Reference

CCNP Quick Reference

Access 97 Quick Reference

Essential XML quick reference

Osteoarthritis Quick Reference Guide (Quick Study Health)

Pharmacology Quick Reference Guide (Quick Study Academic)

Genetics Quick Reference Guide (Quick Study Academic)

Cisco Voice over IP (CVOICE) (Authorized Self-Study Guide)

Quick Scripture Reference for Counseling

PCs for Dummies: Quick Reference

HTML5 For Dummies Quick Reference

Bourne Shell quick reference guide

Apache Geronimo 2.1 Quick Reference

Medical Psychiatry: The Quick Reference

PCs For Dummies Quick Reference

Apache Geronimo 2.1: Quick Reference

Route 66 Quick Reference Encyclopedia

Oracle DBA SQL Quick Reference

IFRS: A Quick Reference Guide

Laptops For Dummies Quick Reference

Linux Security Quick Reference Guide

Quick Reference Clinical Chiropractic Handbook

Cisco TCP-IP routing professional reference

Recommend Documents