Integrating Cisco CME in an H.323 Network

There are two basic approaches to connecting a Cisco CME system to an H.323 network: the first uses no gatekeeper (GK), and the second does. A direct interconnection of sites with H.323 implies that each site must be knowledgeable about how to reach every other site. This works well in small networks of only a handful of nodes, but as the network grows larger, the configuration becomes increasingly cumbersome to maintain. In its simplest form, a gatekeeper is a device that provides a directory service that translates a telephone number into an IP address. Using a gatekeeper provides significant scalability by centralizing the interconnection of the individual sites so that each site needs to be aware of only the gatekeeper and not every other site in the network.

The following sections discuss different approaches to building Cisco CME networks. Rather than being alternative approaches, they represent a simpler approach for smaller networks with only a few nodes and a more scalable approach for larger multinode networks.

A Simple Two-Node Topology with H.323

In the simplest case, you can just connect two Cisco CME systems via an IP-enabled serial data link (or Ethernet), and configure VoIP dial peers on each system to symmetrically direct calls that are destined for nonlocal extension numbers to the other Cisco CME system. In other words, if the Cisco CME recognizes that the extension number being dialed isn't present in its internal list of phone numbers, it can assume that it should send the call to the other Cisco CME, as shown in Figure 7-1.

Figure 7-1. Simple Two-Node Cisco CME H.323 Network

Example 7-1 shows the relevant configuration extracts of the two systems. It shows a pair of Cisco CME systems that have extensions 1000 to 1099 on CME 1 (IP address 10.1.1.1) and 2000 to 2099 on CME 2 (IP address 10.1.2.1).

Example 7-1. Dial Peers for Figure 7-1

CME 1:
Router#show running-config
dial-peer voice 2000 voip
 destination-pattern 20..
 session target 10.1.2.1
 dtmf-relay h245-alphanumeric
 codec g729r8


CME 2:
Router#show running-config
dial-peer voice 1000 voip
 destination-pattern 10..
 session target 10.1.1.1
 dtmf-relay h245-alphanumeric
 codec g729r8

Note

The dtmf-relay configuration portion of the output is explained later, in the section "DTMF Relay for H.323."

You can use this simple symmetrical VoIP dial peer technique to join two Cisco CME systems even within a single site to increase the total phone count supported beyond the capacity of a single Cisco CME system. The downside of doing this is that it doesn't give you a truly monolithic system from a configuration, inter-CME feature transparency, and management point of view. This arrangement requires you to administer the two systems separately, which may be acceptable if the two systems are split between naturally different and separate sections of your company (for example, administration and manufacturing).

This arrangement also limits the phone features you can use across the two systems. You can operate simple features such as call transfer and forwarding, and you can share a single voice mail device between systems, including inter-CME distribution of message waiting indication (MWI). However, Cisco CME does not support more advanced features, such as shared line and call pickup, across the H.323 or SIP interconnection.

One final point about this arrangement is that you can optionally choose to provide a physical PSTN connection on just one Cisco CME system and have that Cisco CME system also act as a VoIP PSTN gateway for the second Cisco CME system.

Although this discussion considers H.323 and SIP "long-distance" protocols, the use of these protocols is not related to physical distance. You can use H.323/SIP to link systems 1000 feet apart the same as you would link systems 1000 miles apart. This ability is one of the key advantages of VoIP technology over traditional TDM systems. With the appropriate IP infrastructure, you can link systems and users more or less independent of the physical distance that separates them. This means that you can give a remotely located Cisco CME system a phone extension number and voice mailbox that appears to your phone users to belong to their local Cisco CME system (with the aforementioned restriction on advanced phone feature operation between systems across VoIP). The historical out-of-area-code restrictions that apply to traditional TDM-based centrex phone systems largely do not apply in the VoIP context.

The one caveat in this area is the effect on access to public emergency services. Users dialing for emergency assistance (such as police, fire, or ambulance) should be routed into the PSTN via a PSTN connection that is local to their physical location. The calling party information provided to the PSTN connection and emergency services operator for this type of call must display an appropriate phone number (and therefore an associated physical location) that is within the emergency services area of the PSTN link being used.

A Large Multinode Topology with H.323

If you want to connect more than two Cisco CME systems, you can extend the basic approach used to connect two systems and add a third, fourth, or more Cisco CME systemsup to a point. For a low number of systems, such as five or six, it's usually possible to add VoIP dial peers to your Cisco CME system that indicate the static IP address of the other system to reach. This is especially true if your dial plan is reasonably well segmented such that you can infer to which Cisco CME system the call should be sent based on the first one or two digits of the dialed extension number. For example, Cisco CME system 1 is given extension numbers 5000 to 5099, Cisco CME system 2 is given extension numbers 5100 to 5199, and so on.

Even if your dial plan isn't entirely evenly divided, you can still use this approach if you're prepared to build the necessary dial peer-based configuration. At the limit of this method, you can construct systems in which you create an individual H.323 VoIP dial peer on each Cisco CME system for each remotely located extension number. You can follow this approach as far as available memory and your patience in creating and maintaining the configuration allow. As the number of dial peers increases, the post-dial delay increases somewhat, because the Cisco CME system might need to search through a couple hundred dial peers to find the right information. In the very worst case, a network of five Cisco CME systems with 20 extensions each would need 80 VoIP dial peers created (and maintained) on each system. That's assuming that your extension number distribution is fully random across the full set of Cisco CME systems. Troubleshooting such a system in the event of misconfiguration is challenging, however.

Another drawback of the multiple dial peer configuration is that there's no good way to do call admission control (CAC) to prevent too many voice calls from trying to use the same WAN link at the same time. This may be an issue if your expected maximum call volume might be greater than the capacity of your WAN links. See the next section for more on this issue.

Alternatively, you can use the VoIP tandem call routing feature of Cisco CME 3.1 and above. This allows you to construct hub-and-spoke or hop-by-hop call routing arrangements. Hub-and-spoke call routing arrangements are historically common in small-scale voice over Frame Relay (VoFR) and voice over ATM (VoATM) networks. In these small-scale networks, you might have a single larger "hub" Cisco CME system with approximately 100 users at a primary site, with perhaps five satellite Cisco CME systems, each with 20 users linked on VoIP "spokes" to the primary. In this arrangement, only the central hub site needs VoIP dial peers to be configured to define the location of all network-wide extensions. The spoke satellite sites only need to know to send nonlocal calls to the hub site. The central hub site can then relay the call to the final spoke site destination.

This type of arrangement makes the most sense if the physical Layer 1/Layer 2 connection topology of your IP transport network mirrors the same hub-and-spoke arrangement as the dial plan. With this situation, IP packets that flow between different spoke sites inevitably get IP Layer 3 routed via the central hub site Cisco CME router. The hub-and-spoke dial plan arrangement causes the VoIP calls and voice packets to get routed by the application layer instead, with relatively minor added delay, as shown in Figure 7-2.

Figure 7-2. Multinode Cisco CME Tandem H.323 Network

Example 7-2 shows the relevant configurations of the nodes shown in the network.

Example 7-2. Node Configurations

CME 1:
Router#show running-config
dial-peer voice 2345 voip
 destination-pattern [2345]0..
 session target ipv4:10.1.5.1
CME 2:
Router#show running-config
dial-peer voice 1345 voip
 destination-pattern [1345]0..
session target ipv4:10.1.5.1

Tandem Node:
Router#show running-config
voice service voip
 allow-connections h323 to h323
 dial-peer voice 1000 voip
 destination-pattern 10..
 session target ipv4:10.1.1.1
 dial-peer voice 2000 voip
 destination-pattern 20..
 session target ipv4:10.1.2.1

Using a single dial peer at the spoke sites to direct calls to the hub site and all far-end spoke sites beyond it also allows you to more easily use CAC per dial peer call-counting mechanism (which you'll learn more about in the following section). This is shown in Figure 7-2. You can use UNIX-style regular expressions in dial peer destination patterns. For example, if you need a single dial peer that references extensions in multiple ranges, such as 10xx, 30xx, 40xx, and 50xx (not including 20xx), you can use the following command:

destination-pattern [1345]0..

The values in square brackets ([ ]) provide a list of alternative valuesin this case, 1, 3, 4, and 5. You can also use this to encompass a continuous range. For example, you can also write the preceding example as 1,3-5:

destination-pattern [13-5]0..

However, an even better and fundamentally more scalable approach to inter-CME H.323 VoIP call routing is to use an H.323 GK (as you will see in the next section). This is the most practical approach to link tens or hundreds of Cisco CME systems.

The Role of an H.323 Gatekeeper

The primary role of an H.323 gatekeeper is to provide a conversion lookup between a telephone number and an IP address. This service essentially centralizes the dial plan (all the telephone numbers in the network and how to reach them) in a single place in the network, as opposed to each node needing the configuration information to do this. This significantly eases the management of a large network.

Gatekeepers also provide other services, depending on the type of gatekeeper used. These services are discussed in this section:

• Telephone address lookup
• Call admission control
• Billing
• Proxy

Figure 7-3 shows a sample gatekeeper network.

Figure 7-3. Multinode Cisco CME Gatekeeper Network

Example 7-3 shows the relevant dial peer configurations of the nodes shown in the network. Note the use of session target ras; it is explained in the next section.

Example 7-3. CME Node and Gatekeeper Configurations

CME 1:
Router#show running-config
dial-peer voice 2345 voip
 destination-pattern [2345]0..
 session target ras

CME 2:
Router#show running-config
dial-peer voice 1345 voip
 destination-pattern [1345]0..
 session target ras

CME 3:
Router#show running-config
dial-peer voice 1234 voip
 destination-pattern [1234]0..
 session target ras

Example 7-4 shows a more detailed example from an individual Cisco CME router setup to interwork with an H.323 gatekeeper connected via the Cisco CME router's Ethernet interface. Note the gk ipaddr that defines the gatekeeper's IP address.

Example 7-4. Cisco CME Gatekeeper Connectivity

Router#show running-config
interface FastEthernet0/0
ip address 10.1.1.1 255.255.0.0
load-interval 30
duplex auto
speed auto
no cdp enable
h323-gateway voip interface
h323-gateway voip id gk ipaddr 10.1.10.1 1719
h323-gateway voip h323-id cme1
h323-gateway voip tech-prefix 1#
h323-gateway voip bind srcaddr 10.1.1.1

dial-peer voice 1234 voip
 destination-pattern [1-4]0..
 session target ras

 

Telephone Address Lookup

The simplest type of gatekeeper provides only telephone number-to-IP address resolution. When a Cisco CME system uses a gatekeeper to help route a call, it sends a message to the gatekeeper to request the IP address that corresponds to a certain specific phone number. As soon as Cisco CME gets the correct IP address, it can send an H.323 call setup message for the desired phone number to the IP address of the remote Cisco CME system (provided by the gatekeeper) that hosts that phone number. Instead of having a VoIP dial peer that points to every Cisco CME system in your network, the Cisco CME has only one dial peer that points to the IP address of the H.323 gatekeeper.

To reference a gatekeeper from a VoIP dial peer, use ras as the target instead of a specific IP address:

session target ras

In most cases, the H.323 gatekeeper gets the appropriate phone number-to-IP address configuration dynamically from the component Cisco CME systems. For each individual phone number that's configured on a Cisco CME system, the Cisco CME system can send a Registration message to the gatekeeper. The Registration message basically says, "I'm an H.323 gateway-like device at IP address x.x.x.x, and I have phone number Y." The gatekeeper aggregates the information from the H.323 Registration messages from all the Cisco CME gateways (and other H.323 gateways) into a composite database that contains all the current locations of all the telephone numbers in the network.

Call Admission Control

In addition to providing simple telephone number-to-IP address resolution, a gatekeeper can provide CAC for your VoIP network. CAC keeps track of the number of simultaneous VoIP calls present at each H.323 gateway and prevents overloading of the gateway's WAN links (and sometimes also provides load balancing for PSTN access ports). Without CAC, if too many calls attempt to use the same WAN link at the same time, either calls will fail in uncontrolled ways, or too many voice packets will try to get sent at the same time, leading to voice quality problems.

The Cisco CME can do a limited amount of CAC itself without a gatekeeper, either by limiting the number of simultaneous calls associated with each dial peer or by using an end-to-end bandwidth reservation protocol called Resource Reservation Protocol (RSVP). However, per-dial peer call counting does not work well if you are using more than one dial peer per WAN link, and the RSVP mechanism requires end-to-end support of the RSVP protocol within your network infrastructure, so the gatekeeper-based CAC approach generally is far superior.

Billing

The gatekeeper keeps track of the number of active calls based on messages from the gateway indicating when individual calls start and stop. Because the gatekeeper knows the start and stop times and the called and calling phone numbers, a gatekeeper can provide a centralized point to connect to a billing service (for the VoIP calls).

This type of billing typically does not know about calls being made by a Cisco CME system using its local PSTN connection. These calls don't involve H.323 VoIP call legs, so the H.323 gatekeeper typically does not see them. You can use the Cisco IOS Voice Gateway Remote Authentication Dial-In User Service (RADIUS) feature in conjunction with a central RADIUS server to track all Cisco CME calls for both H.323 and PSTN for billing purposes.

Using a Gatekeeper as a Proxy for Additional Services

The other major type of gatekeeper to consider is a Routed Signaling Gatekeeper. Instead of simply providing phone number-to-IP address resolution, the Routed Signaling Gatekeeper acts as an H.323 proxy device and participates in all the H.323 call signaling. With this type of gatekeeper, the Cisco CME system sends the H.323 call setup directly to the gatekeeper. The gatekeeper then relays the H.323 setup to the final (or next-hop) destination. This is very similar to the tandem hub-and-spoke VoIP call routing described earlier with Cisco CME systems.

The Routed Signaling Gatekeeper approach has two disadvantages:

• You tend to need more Routed Signal Gatekeepers because each individual gatekeeper has more work to do per call. Instead of just being primarily involved in the phone number-to-IP address resolution at the start of the call, a Routed Signaling Gatekeeper stays involved throughout the call. It has to process all the H.323-related messages that pass through it.
• Routed Signaling Gatekeepers tend not to be transparent to the supplementary service ITU-T H.450 messages used for call transfer and forwarding between Cisco CME systems. The presence of a Routed Signaling Gatekeeper may actually prevent you from using H.450 services between Cisco CME systems.

On the other hand, a Routed Signaling Gatekeeper may be able to provide your network with additional services. This is generally truer in an H.323 VoIP network that is used for residential services. In this case, a Routed Signaling Gatekeeper can provide services, such as call forwarding and call waiting, on behalf of H.323 endpoints that (unlike Cisco CME) do not natively support these services. The situation can get more complicated in some service provider networks where the same VoIP infrastructure is used to provide both direct residential and hosted or managed enterprise and small or medium business VoIP services.

Finally, one other point that sometimes favors using Routed Signaling Gatekeepers is in service provider networks, where there is a legal regulatory requirement to support lawful interception of telephone calls for government law enforcement agencies. In the United States this requirement is called Communications Assistance to Law Enforcement Agencies (CALEA). In this case, having the Routed Signaling Gatekeeper present in both the signaling and media path for all calls to the H.323 endpoint allows wiretapping to take place such that it is undetectable to the H.323 endpoint that is having its voice calls monitored. If you are interested in building a private corporate VoIP network, however, you do not need to be concerned with this consideration.

Public and Internal Phone Numbers in an H.323 Network

You have already seen how a Cisco CME system can register its phone numbers to a central H.323 gatekeeper to provide the VoIP network with a phone number-to-IP address directory. Now you must determine which phone numbers to register. In some cases, you may simply want to register all of them. The effect of this is to give all your Cisco CME extensions a direct inward dial (DID) phone number that means that any extension within your Cisco CME system can be called from anywhere in your VoIP network. However, when phone numbers are registered to a gatekeeper, they typically have to be in an appropriate form. In many cases, gatekeepers cannot handle raw (abbreviated) three- or four-digit extension numbers. Extension numbers typically must be converted into a format that looks more like regular PSTN phone numbers. For example, if you have extensions 1000 to 1099 on your CME system, you may need to register them in long form as something like 408-555-1000 to 408-555-1099.

This makes the most sense when your Cisco CME extension numbers also have matching real PSTN phone numbers. In this case, you most likely have a PSTN link that uses an ISDN interface so that the PSTN network signals the calls from the PSTN number by providing you with the full national phone number of the number called. This type of numbering is often called E.164 format after the ITU-T specification that describes the transnational telephone number formatting rules. The term E.164 is often used a little loosely in that strictly using E.164 requires an indication of whether the phone number includes an international access code or otherwise.

One advantage of using E.164 numbers with a gatekeeper is that it simply gives you a larger number space to work with. This means that you are less likely to run out of phone numbers. It also makes it easier to add links to independent external VoIP networks if you need to. A larger number space also means that you can have overlapping extension numbers across different Cisco CME systems. For example, you might have two Cisco CME systems that (for historical reasons) need to use the same extension number range. You could have two Cisco CME systems that both use the extension range 1000 to 1099 but have different E.164 numbers, such as 408-555-1000 and 510-555-1000. Using the full E.164 number helps resolve any potential conflict.

Cisco CME can automatically convert your local extension numbers from two to five digits into E.164 format using the dialplan-pattern command. Example 7-5 shows a basic example.

Example 7-5. Simple dialplan-pattern Configuration

Router#show running-config
telephony-service
 dialplan-pattern 1 40855510.. extension-length 4

The dialplan-pattern command causes the Cisco CME system to attempt to match the extension numbers created by the ephone-dn command entries against the defined pattern. Using this example, the extension number 1023 would be matched against the final four digits of the dialplan pattern 10.., where the . characters provide a wildcard match. The extension number 1023 would be expanded to 4085551023, and this number would be registered with the gatekeeper. You can define up to five different dialplan patterns. The 1 immediately following the dialplan-pattern command is simply a tag number, 1 to 5, that indicates which of the five dialplan pattern entries you are using.

The dialplan-pattern command can also perform leading-digit replacement for cases in which the extension number to E.164 number expansion is not a simple concatenation of a PSTN area code and prefix. Example 7-6 shows a more complex configuration.

Example 7-6. More Complex dialplan-pattern Example

Router#show running-config
telephony-service
 dialplan-pattern 1 51055599.. extension-length 3 extension-pattern 1..

Using Example 7-6, extension 123 is expanded to E.164 number 5105559923. The three-digit extension number is matched first against the extension pattern and then is substituted into the E.164 pattern defined. Without this capability, simple truncation of the ten-digit E.164 number to a three-digit extension would result in three-digit extensions in the range 900 to 999, which causes a number plan conflict with the traditional "Dial 9 for an outside line."

The dialplan-pattern command allows the Cisco CME's IP phone extension lines to be dialed using both the abbreviated two-to-five-digit extension number and the full E.164 or national phone number. In addition to helping with matching the called number on incoming calls, the dialplan-pattern command also promotes the calling party number included on outgoing calls from the extension to E.164 format. This is often a requirement on PSTN links using ISDN that usually will not accept abbreviated extension numbers as legitimate calling party identification. You have to choose your extension number range such that it does not conflict with the E.164 area code. For example, if your E.164 phone number is 408555xxxx, you cannot use extension numbers of the form 408x.

Note

Using the dialplan-pattern command does not require you to use an H.323 gatekeeper.

You can turn off the gatekeeper registration triggered by the dialplan-pattern command using the no-reg command option at the end of the command.

Registering Individual Telephone Numbers with a Gatekeeper

If you don't want to register all your Cisco CME system's extension numbers with a gatekeeper, you can forgo usage of the global dialplan-pattern command, and control registration of each individual extension number from within the ephone-dn command that is used to create the extensions (or virtual voice ports).

Each ephone-dn allows you to assign a primary and secondary number to associate with the extension. You then have a choice to register both, either, or neither of these with the gatekeeper using the no-reg, no-reg primary, or no-reg both command options for the ephone-dn number command.

If you decide not to use the dialplan-pattern command, you can still provide the three-to-five-digit abbreviated number and full E.164 numbering for each ephone-dn by using the secondary number option, as shown in Example 7-7.

Example 7-7. Secondary Number Options

Router#show running-config
ephone-dn 1
 number 1023 secondary 4085551023 no-reg primary

Using the secondary number allows incoming calls to the ephone-dn to use either 1023 or 4085551023 as the called number. It also only registers the secondary number 4085551023 to the Cisco CME's gatekeeper. This approach gives you control over what is registered on a per-ephone-dn basis. However, it does use up the secondary number, which prevents you from using the secondary number for call coverage purposes. (Refer to Chapter 5, "Cisco CME Call Processing Features.")

Note that this approach does not modify the default calling party number selected on outgoing calls from the extension. In Example 7-7, the calling party number for outgoing calls is set to 1023. This is normally just fine for internal extension-to-extension calling. If you need to promote the calling party number to E.164 format for the benefit of VoIP or ISDN calls, you can do this using an IOS voice gateway translation rule applied to the call's outgoing dial peer.

You can mix and match the two approaches for controlling gatekeeper registration by using narrower extension pattern matches within the dialplan-pattern command. For example, instead of using extension-pattern 10.. to match all the extensions in the 1000 to 1099 range, you can add multiple (up to five) dialplan-pattern commands that have narrow match ranges such as extension-pattern 102., which matches only extension numbers in the 1020 to 1029 range.

If you don't have enough E.164 DID numbers available, but you still need a few extra extension lines, you can assign them to a different range of numbers. You can then use the dialplan-pattern command to register E.164 phone numbers in the match range with a gatekeeper. For example, you might give all your employees extension numbers in the 1000 to 1099 range, have these match a dialplan-pattern and, thus, register to a gatekeeper, and then simply assign nonemployee phone numbers, such as break room and lobby phones, into a separate range that doesn't have corresponding DID E.164 numbers, as shown in Example 7-8.

Example 7-8. Dial Plan Configuration

Router#show running-config
telephony-service
 dialplan-pattern 1 40855510.. extension-length 4
ephone-dn 1
 number 1023
 name employee1
ephone-dn 2
 number 1024
 name empolyee2
ephone-dn 3
 number 2001
 name BreakRoom

In Example 7-8 the extension numbers 1023 and 1024 are registered with the gatekeeper as 4085551023 and 4085551024. The break room extension 2001 is not registered.

With this approach, one final detail to take care of is deciding what calling party number identification you want to provide for ISDN or VoIP calls placed from the break room phone. The simplest solution is to add a translation rule on the outgoing dial peer for calls from the break room phone to map the calling party number to your main or receptionist E.164 number, such as 4085551000. You may choose to do this for all outgoing calls from all extensions if you don't want the called party to be able to see individual extension numbers.

Internal and External Callers for VoIP

With the dialplan-pattern command, you can cause certain incoming VoIP calls to be treated as "internal" calls. By default, calls between IP phones on the same Cisco CME system are treated as internal calls and ring with an internal ringer cadence. All other calls (VoIP and PSTN) are treated as external calls and ring with a different external call ringer cadence. Analog phones attached to router Foreign Exchange Station (FXS) voice ports also are treated as external calls by default. However, incoming calls that have calling party numbers that match one of the available five dialplan-pattern commands are treated as internal calls.

For example, suppose you have two Cisco CME systems linked via VoIP and you use extension numbers 100 to 199 with E.164 numbers 4085550100 to 4085550199 on one system and extension numbers 200 to 299 with E.164 numbers 5105550200 to 5105550299 on the second system. You can create dialplan-pattern commands on both systems that provide extension number matches for both systems, as shown in Example 7-9.

Example 7-9. dialplan-pattern Configuration

Router#show running-config
telephony-service
 dialplan-pattern 1 40855501.. extension-length 3
 dialplan-pattern 2 51055502.. extension-length 3

Any incoming calls that match either of the dialplan patterns are treated as internal calls, regardless of where the call physically originates. When the incoming calling party number matches the dialplan pattern, the Caller ID displayed for the call is demoted from E.164 format back to abbreviated three-to-five-digit extension number format. Also, the call is presented using the internal ring cadence. This allows you to treat incoming VoIP calls from other Cisco CME systems within your network as internal calls.

To make a call coming from a router FXS voice port appear as an internal call, you need to set the voice port station-id number to match the dialplan pattern number range, as shown in Example 7-10.

Example 7-10. FXS Station ID

Router#show running-config
voice-port 1/0/0
 station-id number 4085550188
 station-id name AnalogPhone
dial-peer voice 408188 pots
 destination-pattern 4085550188
 port 1/0/0
dial-peer voice number 188 pots
 destination-pattern 188
 port 1/0/0

This configuration causes calls from the analog phone to have caller ID 4085550188. It also allows the analog phone to be called by dialing either the long form 4085550188 or the abbreviated three-digit extension number 188.

Note that calls from analog phones that are attached to Cisco Analog Telephony Adapters (ATAs) are treated as IP phones and don't need any special treatment.

DTMF Relay for H 323