Configuring Basic Gatekeeper Functionality

Successful gatekeeper implementation requires configuration of both the gatekeeper and the gateways that are going to use it. For the implementation to work properly, you should plan carefully the zone coverage, dial plan, and bandwidth limits before you begin the actual configuration.

The first step is to complete the configuration necessary to allow the gateways to successfully register to the gatekeeper.

Figure 17-1 shows the network topology used in the following examples to begin the gatekeeper configuration. As you can see, it consists of two H.323 gateways in Boise and Miami and a gateway in New York under CallManager control, which will be discussed later in this chapter. The Boise gateway has two Foreign Exchange Station (FXS) connections, and the Miami gateway has a T1 channel-associated signaling (CAS) connection to the public switched telephone network (PSTN). The gatekeeper is physically located in the Miami office. It is set up with a loopback interface having an IP address of 10.100.100.1, which you can use as the gatekeeper address.

Figure 17-1. Basic Network Topology

Configuring Gatekeeper Zones

Begin by configuring zones on the gatekeeper. Zones are logical groups of H.323 devices that the gatekeeper controls. Zone definitions include the zone name and domain name. The first zone definition also includes the IP address for the gateways to use when connecting to the gatekeeper.

Because the gatekeepers will be used for both call routing and call admission control (CAC), each of the gateways will be placed in a separate zone.

The gatekeeper stores its configuration in a separate section of the Cisco IOS configuration. To begin, enter the gatekeeper command from global configuration mode. After that, you can add the zone definitions by using the zone local zonename domain ip-address command. You enter subsequent zone commands the same way, but without the ip-address, which you enter only once.

After you define the zones, start the gatekeeper service by entering the no shutdown command. The gatekeeper is now ready to accept gateway registrations.

Example 17-1 shows the configuration done to this point.

Configuring Gateways to Use H.323 Gatekeepers

After you have defined the zones on the gatekeeper, you must configure each of the gateways. To configure a Cisco device as an H.323 gateway, configure at least one of its interfaces as a gateway interface. Use of a reliable interface, such as a loopback interface or a LAN interface, is recommended.

Begin the configuration in interface configuration mode for the selected interface. Define this interface to be a gateway interface using the h323-gateway voip interface command.

Define the name and location of the gatekeeper for this gateway using the following command:

h323-gateway voip id gatekeeper-id {ipaddr ip-address | multicast} [priority priority]

The gatekeeper-id must match the zone name that is defined to the gatekeeper for the zone that will control this gateway. The ip-address is the address of the gatekeeper. You can alternatively use the multicast keyword to let the gateway automatically discover the gatekeeper.

Optionally, you can define the H.323 name of the gateway, to help identify this gateway to the gatekeeper. The H.323 name is usually the gateway hostname and the gateway domain name. The h323-gateway voip h323-id interface-id command is used to configure the name.

After you define a gateway interface, you can activate the gateway service by entering the gateway command in global configuration mode. The gateway immediately tries to register with its gatekeeper.

You can verify that the gateways have registered properly by using the show gatekeeper endpoints command.

Example 17-2 shows the necessary configuration for both of the gateways in this sample network. The show gatekeeper endpoints command indicates that both gateways have registered properly.

Although both gateways are registered to the gatekeeper, they still cannot use it to route calls. To do that, you must properly set up the dial plan within the gateways and configure technology prefixes and zone prefixes in the gatekeeper.

Technology Prefixes

A technology prefix identifies H.323 endpoints by type or class or identifies a resource pool to the gatekeeper. It is important to configure a default technology prefix on the gatekeeper and a technology prefix on the gateway for everything to work correctly. Select a technology prefix to identify the type of gatewayin this case, a voice gatewayto the gatekeeper.

Note

Defining a technology prefix is important for proper operation because in most cases, calls do not route properly if this step is not done. Typically, the called number matches a zone prefix, not a registered E.164 address. In this case, if a technology prefix is not also matched, the call is rejected. To understand why, review Figure 16-6 in Chapter 16, "Deploying Gatekeepers."

For the sample network, 1# is selected as the technology prefix associated with a voice gateway. Because this is a voice network, 1# is also the default technology prefix for the network.

To configure the default technology prefix on the gatekeeper, use the gw-type-prefix prefix default-technology command in gatekeeper configuration mode. For this network, configure gw-type-prefix 1#* default-technology on the gatekeeper. The wildcard symbol * indicates that any number of digits can follow the prefix.

The next step is to set up the technology prefix on the voice gateways. You do this by using the h323-gateway voip tech-prefix prefix command, which is applied to the gateway interface defined earlier. For this sample network, configure h323-gateway voip tech-prefix 1# on each gateway.

Configuring Zone Prefixes and Dial Peers

The last task you need to do before routing calls is to set up the dial plan. You define the dial plan to the gateways in a gatekeeper-controlled network by using dial peers in much the same way as you do without a gatekeeper. POTS dial peers are defined for all phone numbers that are reachable through connected trunks or devices. The difference is in configuration of the Voice over IP (VoIP) dial peers for remote locations.

Without a gatekeeper, you need to set up a VoIP dial peer for each remote site, directly referencing the remote gateway IP address (or Domain Name Services [DNS] name). When a gatekeeper is installed in the network, it resolves phone numbers to the appropriate IP address of the destination gateway. This makes configuring the VoIP dial peer simple. All you need to set up is one or more dial peers that send all unknown numbers to the gatekeeper. You can construct these in different ways. Although some examples are included here, for more specific details on building dial peers, please refer to Chapter 9, "Dial Plans."

The complete dial plan is centrally managed on the gatekeeper. You configure prefixes on the gatekeeper, which identify the numbers that are reachable using each voice gateway within the network. A prefix can be equated to a destination pattern on a dial peer. In fact, the prefixes that are defined on the gatekeeper are typically the same as those that are defined on the POTS dial peers on the gateways throughout the network.

In the sample network, extensions 0100 and 0101 need to go to the phones in Boise, and all PSTN access is through Miami. The number 9 is the access code for all calls that are going to the PSTN. Plain old telephone service (POTS) dial peers are set up in both gateways for the connected devices and trunks. The VoIP dial peers are configured to use a wildcard match so that any other number matches the VoIP peer. In place of the IP address that is normally coded as the session target, use the session target ras command. This tells the gateway to issue a RAS Admission Request (ARQ) message for any call that matches this dial peer, using the gatekeeper to resolve the IP address of the destination.

You can configure a prefix in the gatekeeper by using the zone prefix zonename prefix command. In the sample network, the command is zone prefix miami 9*. This command tells the gatekeeper that any call beginning with a 9 belongs to the Miami zone. You can look at the zone prefixes that have been defined using the show gatekeeper zone prefix command.

Because the Boise gateway is running a current version of Cisco IOS, you do not need to configure a zone prefix for the phones that are attached to the FXS ports on the gateway. When the gateway creates the dial peers for those phones, it automatically registers their E.164 addresses. This is an H.323 Version 2 feature and is available in Cisco IOS version 12.1T and later. You can verify that the addresses have registered using the show gatekeeper endpoints command. You can override this behavior on the dial peer if desired using the no register e164 command.

Example 17-3 shows the configuration of the devices in the sample network after you make these changes. At this point, you should be able to route calls properly.

When this configuration is complete, you can verify that calls will route successfully. The show gatekeeper calls command provides information about any calls that are currently in progress.

A PSTN call from the phone at extension 0100 to phone number 12012012002 is shown in Example 17-4. Notice that the source and destination are identified, as is the bandwidth that this call is using. The bidirectional bandwidth used by the call is reported as 16Kb in the example, indicating that the G.729 codec is being used. You can also tell how long the call has been active342 seconds in this example.

Dynamic Prefix Registration

H.323 Version 4 added a feature that makes it even easier to set up prefixes on the gatekeeperdynamic prefix registration. This feature allows the gateways to automatically register prefixes with the gatekeeper that are configured as destination patterns on the gateway POTS dial peers. Not only does this mean that you no longer have to manually configure zone prefixes on the gatekeeper, but it also automatically tracks any new, changed, or deleted destination patterns on voice gateways that are registered to the gatekeeper zone. This lowers the administrative effort of implementing the dial plan and reduces the chance of errors caused by the configurations being out of sync.

Note

Complex destination patterns do not dynamically register. For example, if you code destination-pattern 91[2-9]..[2-9]……, which is common in North America, it does not dynamically register with the gatekeeper. In this example, you can simplify the entry to destination-pattern 91……….. The latter does register properly.

To enable this feature, you need to configure the gateway H.323 service to send the prefixes in the gatekeeper Registration Request (RRQ). You do this by coding the ras rrq dynamic prefixes command under the H.323 service configuration. You can get to H.323 service configuration mode by entering voice service voip from global command mode and then h323 to configure H.323-specific parameters.

Configure the gatekeeper to accept dynamic prefixes by coding the rrq dynamic-prefixes-accept command. By default, this feature is disabled. The gatekeeper must be in a shutdown state before you can apply this command.

When the preceding configuration is added to both the gateway and gatekeeper, all the destination patterns that are coded on the POTS dial peers for the gateway automatically register as zone prefixes on the gatekeeper.

To verify that the gateway is sending the prefix information, use the show h323 gateway prefixes command. This command lists the prefixes that the gateway is requesting be added to the gatekeeper as well as the status of those add requests.

The show gatekeeper zone prefix command does not show you the dynamically registered prefixes. To see them, you need to use the show gatekeeper zone prefix all command. Without the all parameter, only the statically defined prefixes are displayed. You can use both static and dynamic zone prefixes within the same gatekeeper zone.

Example 17-5 demonstrates the use of the dynamic prefix registration feature.

Configuring Call Admission Control

You can also configure the gatekeeper to limit the calls that are traversing the WAN based on available bandwidth. The gatekeeper is not aware of the topology of the network, so proper design is essential if bandwidth management is to work properly. For more details, see Chapter 16.

You have five options for configuring bandwidth limits on a Cisco IOS gatekeeper:

• Interzone Configure max bandwidth from a zone to all other zones.
• Remote Configure max bandwidth allowed to all remote zones.
• Total Configure max bandwidth allowed for all calls in a zone.
• Check destination The destination zone bandwidth is checked before responding.
• Session Configure the max bandwidth that is allowed for a session in a zone. You use this primarily for video.

It is easier to implement gatekeeper bandwidth management if each site is in a different zone. This allows you to use the bandwidth interzone command to assign a maximum to each remote site separately. This level of granularity helps to make the most efficient use of the available bandwidth, while protecting call quality.

In the sample network, the number of calls using the WAN bandwidth is limited by the number of phones at the Boise site. Using the G.729 codec, the two calls from Boise have no problem on the 128-kbps Frame Relay WAN link. If more phones were in Boise, the low-speed Frame Relay link would be a concern.

You can easily configure the gatekeeper to limit the bandwidth that is used for voice calls to Boise. Because calls over the WAN use a G.729 codec, the gatekeeper counts 16 Kb of interzone bandwidth for each active call.

Because each site is in a separate local zone, use the bandwidth interzone zone zonename bw-in-Kb command to implement the restriction. For example, if you want to allow only a single call to Boise from any other site, you can configure bandwidth interzone zone boise 16 on the gatekeeper.

You can view the current traffic and maximum limits using the show gatekeeper zone status command on the gatekeeper. The configuration to set up this restriction in the sample network is shown in Example 17-6.

In Example 17-6, a call is already in progress. The maximum interzone bandwidth is set to 16, so no other calls can proceed until the first call ends and releases the bandwidth. Because the maximum assumes that a G.729 codec will be used and is set to 16 Kb, no G.711 calls will be accepted, as they require 128 Kb.