Gatekeeper Discovery
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 can be sent via multicast or unicast, as depicted in Figure 8-3.
The initial signaling from a gateway to a gatekeeper is done through H.225 RAS.
Gateways can discover their gatekeepers through one of these two processes:
■ Unicast discovery:
■ Uses UDP port 1718.
■ In this process, endpoints are configured with the gatekeeper IP address and can attempt registration immediately.
■ The gatekeeper replies with a GCF or GRJ message.
Figure 8-3 Gatekeeper Discovery
■ Multicast discovery:
■ Uses UDP multicast address 224.0.1.41.
■ Auto discovery enables an endpoint to discover its gatekeeper through a multicast message. Because endpoints do not have to be statically configured for gatekeepers, this method has less administrative overhead.
■ A gatekeeper replies with a GCF or GRJ message.
Note A Cisco IOS gatekeeper always replies to a GRQ with a GCF or GRJ message. It never remains silent.
■ A gatekeeper can be configured to respond to specific subnets.
The GRQ message requests any gatekeeper receiving it to respond with a GCF message granting it permission to register. The GRJ message is a rejection of this request, indicating that the requesting endpoint should seek another gatekeeper.
If a gateway requests an explicit gatekeeper name, only that one will respond. If not, the first gatekeeper to respond will become the gatekeeper of that gateway. If a gatekeeper is not available, the gateway will periodically attempt to rediscover a gatekeeper. If the gateway-discovered gatekeeper has gone offline, it will stop accepting new calls, and the gateway will attempt to rediscover a gatekeeper. Active calls are not affected by this process because the RTP streams are directly between the phones.
Registration Request
The RRQ message is a request from a terminal or a gateway to a gatekeeper to register, as shown in Figure 8-4.
Figure 8-4 Registration Request
If the gatekeeper responds with an RCF message, the terminal will use the responding gatekeeper for future calls. If the gatekeeper responds with an RRJ message, the terminal must seek another gatekeeper with which to register.
An H.323 gateway learns of a gatekeeper by using a static configuration or dynamic discovery. Static configuration simply means configuring the gatekeeper’s IP address on an interface used for H.323 signaling.
Following is an example of the information used to register an H.323 ID or an E.164 address:
■ H323 ID: gatewayname@domain.com
■ E.164 address: 4085551212
Lightweight Registration
Prior to H.323 version 2, Cisco gateways reregistered with the gatekeeper every 30 seconds. Each registration renewal used the same process as the initial registration, even though the gateway was already registered with the gatekeeper. This behavior generated considerable overhead at the gatekeeper. H.323 version 2 defines a lightweight registration procedure that still requires the full registration process for initial registration, but uses an abbreviated renewal procedure to update the gatekeeper and minimize overhead.
Lightweight registration, as illustrated in Figure 8-5, requires each endpoint to specify a Time to Live (TTL) value in its RRQ message. If the endpoint does not indicate a TTL, the gatekeeper assigns one and sends it to the gateway in the RCF message. When a gatekeeper receives an RRQ message with a TTL value, it returns an updated TTL timer value in an RCF message to the endpoint. Shortly before the TTL timer expires, the endpoint sends an RRQ message with the keepalive field set to True, which refreshes the existing registration. No configuration changes are permitted during a lightweight registration, so all fields are ignored other than the endpoint identifier, gatekeeper identifier, tokens, and TTL. With H.323 version 1, endpoints cannot process the TTL field in the RCF. The gatekeeper probes the endpoint with IRQs for a predetermined grace period to learn if the endpoint is still alive.
Figure 8-5 Lightweight Registration
Admission Request
Figure 8-6 shows an admission request. Before the call is set up, Gateway A sends an ARQ to the gatekeeper. The gatekeeper checks the status of called party and sends either an ACF message or an ARJ message. In this case the gatekeeper sends an ACF message. Typically, the H.225 call setup occurs directly between the two gateways.
Admission messages between endpoints and gatekeepers provide the basis for call admissions and bandwidth control. Gatekeepers authorize access to H.323 networks by confirming or rejecting an admission request.
Figure 8-6 Admission Request
Admission Request Message Failures
It might not be clear from the RAS ARJ message why the message was rejected.
Following are some basic ARJ messages that might be returned and the reasons why these messages occur:
■ calledPartyNotRegistered: This message is returned because the called party either was never registered or has not renewed its registration with a keepalive RRQ.
■ invalidPermission: The call violates some proprietary policy within the gatekeeper that is typically set by the administrator of the network or by the gatekeeper. For example, only certain categories of endpoints might be allowed to use gateway services.
■ requestDenied: The gatekeeper performs zone bandwidth management, and the bandwidth required for this call would exceed the bandwidth limit of the zone.
■ undefinedReason: This message is used only if none of the other reasons are appropriate.
■ callerNotRegistered: The endpoint asking for permission to be admitted to the call is not registered with the gatekeeper from which it is asking permission.
■ routeCallToGatekeeper: The registered endpoint has been sent a setup message from an unregistered endpoint, and the gatekeeper wants to route the call-signaling channel.
■ invalidEndpointIdentifier: The endpoint identifier in the ARQ is not the one the gatekeeper assigned to this endpoint in the preceding RCF.
■ resourceUnavailable: This message indicates that the gatekeeper does not have the resources, such as memory or administrated capacity, to permit the call. It could possibly also be used in reference to the remote endpoint, meaning the endpoint is unavailable. However, another reason might be more appropriate, such as the call capacity has been exceeded, which would return a callCapacityExceeded message.
■ securityDenial: This message refers to the tokens or cryptoTokens fields. For example, failed authentication, lack of authorization (permission), failed integrity, or the received crypto parameters are not acceptable or understood. This message might also be used when the password or shared secret is invalid or not available, the end-point is not allowed to use a service, a replay was detected, an integrity violation was detected, the digital signature was incorrect, or the certificate expired.
■ qosControlNotSupported: The endpoint specified a transport quality of service (QoS) of gatekeeperControlled in its ARQ, but the gatekeeper cannot or will not provide QoS for this call.
■ incompleteAddress: This is used for "overlapped sending." If there is insufficient addressing information in the ARQ, the gatekeeper responds with this message. This message indicates the endpoint should send another ARQ when more addressing information is available.
■ routeCallToSCN: This message means the endpoint is to redirect the call to a specified telephone number on the Switched Circuit Network (SCN) or Public Switched Telephone Network (PSTN). This is used only if the ARQ was from an ingress gateway, where ARQ.terminalType.gateway was present and answerCall was FALSE.
■ aliasesInconsistent: The ARQdestinationInfo contained multiple aliases that identify different registered endpoints. This is distinct from destinationInfo containing one or more aliases identifying the same endpoint plus additional aliases that the gatekeeper cannot resolve.
■ exceedsCallCapacity: This message was formerly callCapacityExceeded. It signifies that the destination endpoint does not have the capacity to accept the call.
Information Request
A gatekeeper periodically sends an IRQ to each registered endpoint to verify it still exists, as illustrated in Figure 8-7. To limit traffic, the IRQ is sent only if the endpoint does not send some other RAS traffic within a certain interval. If an IRR is not received after an IRQ is sent, the registration is aged out of the system.
Figure 8-7 Information Request
Note In addition, during calls, endpoints are instructed to send periodic unsolicited IRRs to report their call state. Cisco endpoints (proxies and gateways) send IRRs whenever a state transition exists, so that accounting information is accurate.
Whenever an IRR is sent, the age tags on the registration information for the endpoint are refreshed. In addition, if the IRR contains Cisco accounting information in its nonStandardData field, this information is used to generate authentication, authorization, and accounting (AAA) transactions.
To ensure that accounting is as accurate and simple as possible, the gatekeeper will confirm IRRs from Cisco gateways and proxies by sending an ICF. If the gateway or proxy does not receive the ICF, the IRR should be resent.
The RAS status information messages include IRQ, IRR, IACK, and INAK.
Location Request
An H.323 LRQ message is sent by a gatekeeper to another gatekeeper to request information about a terminating endpoint, as shown in Figure 8-8.
Figure 8-8 Location Request
The second gatekeeper determines the appropriate endpoint on the basis of the information contained in the LRQ message. However, sometimes all the terminating endpoints are busy servicing other calls, and none are available. If you configure the lrq reject-resource-low command, the second gatekeeper will reject the LRQ request if no terminating endpoints are available. If the command is not configured, the second gatekeeper will allocate and return a terminating endpoint address to the sending gatekeeper even if all the terminating endpoints are busy.
Note The gatekeeper sends out a 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.
