Gatekeepers are a major part of medium to large H.323 VoIP network solutions. When used, these components allow for dial-plan scalability and reduce the need to manage global dial plans locally. In this topic, you will learn the functions of a gatekeeper and directory gatekeeper. Additionally, you will learn how to configure gatekeepers to inter-operate with gateways and how to provide gatekeeper redundancy in medium to large VoIP networks.
This section reviews the functions and roles of gatekeepers and directory gatekeepers. Also, this section discusses in depth the Registration, Admission, and Status (RAS) signaling sequencing between gateways and gatekeepers and discusses the use of the Gatekeeper Transaction Message Protocol (GKTMP).
Gatekeeper Overview
A gatekeeper is an H.323 entity on a network that provides services such as address translation and network access control for H.323 terminals, gateways, and MCUs. The primary functions of a gatekeeper are admission control, zone management, and E.164 address translation. Gatekeepers are logically separated from H.323 endpoints and optional devices in an H.323 network environment.
These optional gatekeepers can manage endpoints in an H.323 network. The endpoints communicate with the gatekeeper using the RAS protocol.
Note The ITU-T specifies that although a gatekeeper is an optional device in H.323 networks, if a network does include a gatekeeper, all H.323 endpoints should use it.
Gatekeepers have mandatory and optional responsibilities. The mandatory responsibilities include the following:
■ Address resolution: Calls originating within an H.323 network might use an alias to address the destination terminal. Calls originating outside the H.323 network and received by a gateway can use an E.164 telephone number to address the destination terminal. The gatekeeper must be able to resolve the alias or the E.164 telephone number into the network address for the destination terminal. The destination end-point can be reached using the network address on the H.323 network. The translation is done using a translation table that is updated with registration messages.
■ Admission control: The gatekeeper can control the admission of the endpoints into the H.323 network. It uses these RAS messages to achieve this: Admission Request (ARQ), Admission Confirmation (ACF), and Admission Reject (ARJ). Admissions control might also be a null function that admits all requests.
■ Bandwidth control: The gatekeeper manages endpoint bandwidth requirements. When registering with a gatekeeper, an endpoint will specify its preferred codec. During H.245 negotiation, a different codec might be required. These RAS messages are used to control this codec negotiation: Bandwidth Request (BRQ), Bandwidth Confirmation (BCF), and Bandwidth Reject (BRJ).
■ Zone management: A gatekeeper is required to provide address translation, admission control, and bandwidth control for terminals, gateways, and Multipoint Control Units (MCUs) located within its zone of control.
All of these gatekeeper-required roles are configurable. The following are optional responsibilities a gatekeeper can provide:
■ Call authorization: With this option, the gatekeeper can restrict access to certain endpoints or gateways based on policies, such as time of day.
■ Call management: With this option, the gatekeeper maintains active call information and uses it to indicate busy endpoints or redirect calls.
■ Bandwidth management: With this option, the gatekeeper can reject admission when the required bandwidth is not available.
Figure 8-1 provides a sample topology illustrating the interaction between gatekeepers and other H.323 network components.
Endpoints attempt to register with a gatekeeper on startup. When they want to communicate with another endpoint, they request admission to initiate a call using a symbolic alias for the destination endpoint, such as an E.164 address or an e-mail address. If the gatekeeper decides that the call can proceed, it returns a destination IP address to the originating endpoint. This IP address might not be the actual address of the destination endpoint, but it might be an intermediate address, such as the address of a proxy or a gatekeeper that routes call signaling. A Cisco gatekeeper provides H.323 call management, including admission control, bandwidth management, and routing services for calls in the network.
Figure 8-1 Interaction of Gatekeepers with H.323 Network Components
Zones
A zone is defined as the set of H.323 nodes controlled by a single logical gatekeeper. Gatekeepers that coexist on a network might be configured so that they register end-points from different subnets. There can be only one active gatekeeper per zone. These zones can overlay subnets, and one gatekeeper can manage gateways in one or more of these subnets.
Endpoints attempt to discover a gatekeeper and consequently the zone of which they are members by using the RAS message protocol. The protocol supports a discovery message that might be sent using multicast or unicast.
If the message is sent via multicast, the endpoint registers nondeterministically with the first gatekeeper that responds to the message. To enforce predictable behavior, where endpoints on certain subnets are assigned to specific gatekeepers, the zone subnet command can be used to define the subnets that constitute a given gatekeeper zone. Any end-point on a subnet that is not enabled for the gatekeeper is not accepted as a member of that gatekeeper zone. If the gatekeeper receives a discovery message from such an end-point, it sends an explicit reject message.
Zone Prefixes
A zone prefix determines to which zone calls are sent. For a zone that is controlled by a gatekeeper, the zone prefixes help route the call to the appropriate endpoint. The zone prefixes (typically area codes) serve the same purpose as the domain names in the H.323-ID address space. For example, if a local gatekeeper has been configured with the knowledge that zone prefix 212xxxxxxx (that is, any address beginning with 212 and followed by seven arbitrary digits) is handled by gatekeeper GK1, such as the following:
Then when the local gatekeeper is asked to admit a call to destination address 2125551111, it knows to send the location request to GK1.
Technology Prefixes
A network administrator selects technology prefixes to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers with these prefixes. For example, voice gateways might register with technology prefix 1#, H.320-gateways with 2#, and voice-mail gateways with 3#. More than one gateway can register with the same type prefix. When that happens, the gatekeeper makes a random selection among gateways of the same type. The caller, who knows the type of device he or she is trying to reach, can now prepend a technology prefix to the destination address to indicate the type of gateway to use to get to the destination.
Technology Prefix with Hop-Off
The other gateway-type feature is the capability to force a hop-off to a particular zone. Normally, when an endpoint or gateway makes a call admission request to its gatekeeper, the gatekeeper resolves the destination address by first looking for the technology prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address resolves to a remote zone, the entire address, including both technology and zone prefixes, is sent to the remote gatekeeper in a Location Request (LRQ). That remote gatekeeper then uses the technology prefix to decide which of its gateways to hop off. The zone prefix determines the routing to a zone, and the technology prefix determines the gateway in that zone. This behavior can be overridden by associating a forced hop-off zone with a particular technology prefix. This forces the call to the specified zone, regardless of the zone prefix in the address.
Gatekeeper Hardware and Software Requirements
To determine the latest Cisco IOS Software version that is needed for the various router platforms, you will need to use the Feature Navigator tool to search for it. For example, you might want to search for which Cisco IOS version would be best to support a high-performance gatekeeper. You can find the platform and Cisco IOS version for the gatekeeper by using the Feature Navigator tool on Cisco.com at http://www.cisco.com/go/fn. To start the search, follow these steps:
Step 1. Click the Search by Feature link.
Step 2. Select High Performance Gatekeeper in the Available Features list. Step 3. Click the Add button to place the feature in the Selected Features box. Step 4. Click the Continue button.
The Feature Navigator returns all the versions of Cisco IOS that support this feature. This includes General Deployment (GD), Limited Deployment (LD), and Early Deployment (ED) releases as well as the release numbers, platform types, feature sets, image names, and DRAM and Flash requirements.
Gatekeeper Signaling
Cisco gatekeepers use H.323 RAS messages, the Gatekeeper Update Protocol (GUP), and the GKTMP as signaling methods when providing call services.
RAS is a subset of the H.225 signaling protocol. This signaling uses User Data Protocol (UDP). Signaling messages between gateways are H.225 call control, setup, or signaling messages.
H.225 call control signaling is used to set up connections between H.323 endpoints. The ITU H.225 recommendation specifies the use and support of Q.931 signaling messages. If no gatekeeper is present, H.225 messages are exchanged directly between endpoints.
As shown in Figure 8-2, after call signaling is set up between gateways, H.245 is negotiated. H.245, a control signaling protocol in the H.323 multimedia communication architecture, is for the exchange of end-to-end H.245 messages between communicating H.323 endpoints. The H.245 control messages are carried over H.245 control channels. The H.245 control channel is the logical channel 0 and is permanently open, unlike the media channels. The messages carried include messages to exchange capabilities of terminals and to open and close logical channels.
Figure 8-2 Gatekeeper Signaling
After a connection has been set up via the call signaling procedure, the H.245 call control protocol is used to resolve the call media type and establish the media flow before the call can be established. It also manages the call after it has been established.
As the call is set up between gateways, all other port assignments are dynamically negotiated, as in the following examples:
■ RTP ports are negotiated from the lowest number.
■ The H.245 TCP port is negotiated during H.225 signaling for a standard H.323 connection.
■ The RTP UDP port range is 16384-32767. RAS Messages
Gatekeepers communicate through the RAS channel using different types of RAS messages. Table 8-1 shows common RAS signal messages, which are initiated by a gateway or gatekeeper.
Table 8-1 H.225 RAS Messages
|
Category of RAS Message |
RAS Message |
|
Gatekeeper Discovery |
Gatekeeper Request (GRQ) |
|
Gatekeeper Confirmation (GCF) |
|
|
Gatekeeper Reject (GRJ) |
|
|
Terminal and Gateway Registration |
Registration Request (RRQ) |
|
Registration Confirmation (RCF) |
|
|
Registration Reject (RRJ) |
|
|
Terminal and Gateway Unregistration |
Unregistration Request (URQ) |
|
Unregistration Confirmation (UCF) |
|
|
Unregistration Reject (URJ) |
|
|
Resource Availability |
Resource Availability Indicator (RAI) |
|
Resource Availability Confirmation (RAC) |
|
|
Bandwidth |
Bandwidth Request (BRQ) |
|
Bandwidth Confirmation (BCF) |
|
|
Bandwidth Reject (BRJ) |
|
|
Location |
Location Request (LRQ) |
|
Location Confirmation (LCF) |
|
|
Location Reject (LRJ) |
|
|
Call Admission |
Admission Request (ARQ) |
|
Admission Confirmation (ACF) |
|
|
Admission Reject (ARJ) |
|
|
Disengage |
Disengage Request (DRQ) |
|
Disengage Confirmation (DCF) |
|
|
Disengage Rejection (DRJ) |
|
|
Request in Progress |
Request in Progress (RIP) |
|
Status |
Info Request (IRQ) |
|
Info Request Response (IRR) |
|
|
Info Request Acknowledge (IACK) |
|
|
(IRR) Information Request Response |
|
|
Info Request Neg Acknowledge (INAK) |
|
|
Information Confirm (ICF) |
RAS message types include those listed here:
■ Gatekeeper discovery messages: An endpoint unicasts or multicasts a gatekeeper discovery request. The GRQ message requests that any gatekeeper receiving it respond with a GCF message granting it permission to register. The GRJ message is a rejection of this request, indicating the requesting endpoint should seek another gatekeeper.
■ GRQ: Message sent by an endpoint to a gatekeeper.
■ GCF: Reply from a gatekeeper to an endpoint indicating the transport address of the gatekeeper RAS channel.
■ GRJ: Reply from a gatekeeper to an endpoint rejecting the request from the end-point for registration. The GRJ message usually occurs because of a gateway or gatekeeper configuration error.
■ Terminal and Gateway registration messages: The RRQ message is a request to register from a terminal to a gatekeeper. If the gatekeeper responds with a RCF message, the terminal will use the responding gatekeeper for future calls. If the gatekeeper responds with a RRJ message, the terminal must seek another gatekeeper with which to register.
■ RRQ: Sent from an endpoint to a gatekeeper RAS channel address. Included in this message is the technology prefix, if configured.
■ RCF: Reply from the gatekeeper confirming endpoint registration.
■ RRJ: Reply from the gatekeeper rejecting endpoint registration.
■ Terminal and Gateway unregistration messages: The URQ message requests the association between a terminal and a gatekeeper be broken. Note the URQ request is bidirectional (that is, a gatekeeper can request a terminal to consider itself unregistered, and a terminal can inform a gatekeeper it is revoking a previous registration).
■ Unregistration Request (URQ): Sent from an endpoint or a gatekeeper to cancel registration.
■ Unregistration Confirmation (UCF): Sent from an endpoint or a gatekeeper to confirm an unregistration.
■ Unregistration Reject (URJ): Indicates that an endpoint was not preregistered with a gatekeeper.
■ Call Admission messages: The ARQ message requests an endpoint be allowed access to a packet-based network by a gatekeeper. The request identifies the terminating endpoint and the bandwidth required. The gatekeeper either grants the request with an ACF message or denies it with an ARJ message.
■ Admission Request (ARQ): An attempt by an endpoint to initiate a call.
■ Admission Confirmation (ACF): An authorization by the gatekeeper to admit the call. This message contains the IP address of the terminating gateway or gatekeeper and enables the originating gateway to initiate call control signaling procedures.
■ Admission Reject (ARJ): Denies the request from the endpoint to gain access to the network for this particular call if the endpoint is unknown or inadequate bandwidth is available.
■ Location messages: These are commonly used between interzone gatekeepers to get the IP addresses of different zone endpoints.
■ Location Request (LRQ): Sent by a gatekeeper to the directory gatekeeper to request the contact information for one or more E.164 addresses. An LRQ is sent directly to a gatekeeper if one is known, or it is multicast to the gatekeeper discovery multicast address.
■ Location Confirmation (LCF): Sent by a responding gatekeeper, it contains the call signaling channel or RAS channel address (IP address) of itself or the requested endpoint. It uses the requested endpoint address when directed end-point call signaling is used.
■ Location Reject (LRJ): Sent by gatekeepers that received an LRQ for a requested endpoint that is not registered or that has unavailable resources.
■ Status messages: These are used to communicate gateway status information to the gatekeeper.
■ Information Request (IRQ): Sent from a gatekeeper to an endpoint requesting status.
■ Information Confirm (ICF): Sent from an endpoint to a gatekeeper to confirm the status.
■ Information Request Response (IRR): Sent from an endpoint to a gatekeeper in response to an IRQ. This message is also sent from an endpoint to a gatekeeper if the gatekeeper requests periodic status updates. Gateways use the IRR to inform the gatekeeper about active calls.
■ Info_Request_Acknowledge (IACK): Used by the gatekeeper to respond to IRR messages.
■ Info_Request_Neg_Acknowledge (INAK): Used by the gatekeeper to respond to IRR messages.
■ Bandwidth messages: An endpoint sends a bandwidth change request (BRQ) to its gatekeeper to request an adjustment in call bandwidth. The gatekeeper either grants the request with a BCF message or denies it with a BRJ message.
■ Bandwidth Request (BRQ): Sent by an endpoint to a gatekeeper requesting an increase or decrease in call bandwidth.
■ Bandwidth Confirmation (BCF): Sent by a gatekeeper confirming acceptance of a bandwidth request.
■ Bandwidth Reject (BRJ): Sent by a gatekeeper rejecting a bandwidth request.
■ Resource availability messages: RAI message is a notification from a gateway to a gatekeeper of its current call capacity for each H-series protocol and data rate for that protocol. Upon receiving an RAI message, a gatekeeper responds with a RAC message to acknowledge its reception.
■ Resource Availability Indicator (RAI): Used by gateways to inform the gatekeeper whether resources are available in the gateway to take on additional calls.
■ Resource Availability Confirmation (RAC): Notification from the gatekeeper to the gateway acknowledging receipt of an RAI message.
■ Request in Progress (RIP) message: The gatekeeper sends out an RIP message to an endpoint or gateway to prevent call failures because the RAS message timeouts during gatekeeper call processing. A gateway receiving a RIP message knows to continue to wait for a gatekeeper response.
■ Disengage messages: When a call is disconnected, a variety of disconnect messages can be exchanged between an endpoint or gateway and a gatekeeper.
■ Disengage Request (DRQ): Notification sent from an endpoint or gateway to its gatekeeper, or vice versa.
■ Disengage Confirmation (DCF): A notification sent from a gatekeeper to a gateway or endpoint confirming a disconnect request, or vice versa.
■ Disengage Rejection (DRJ): A notification sent from a gatekeeper rejecting a disconnect request from an endpoint or gateway. Note that if a DRQ is sent from a gatekeeper to an endpoint, the DRQ message forces a call to be dropped. Such a request will not be refused.
