|
|
The gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the gatekeeper and to locate another gatekeeper. The gatekeeper provides logic variables for proxies or gateways in a call path to provide connectivity with the Public Switched Telephone Network (PSTN), to improve Quality Of Service (QoS), and to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into Domain Naming System (DNS), or via Cisco IOS configuration options.
AAA---Authentication, Authorization, and Accounting. AAA is a suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.
ANI---Answer number indication. The calling number (number of calling party).
ARQ---Admission request.
CAS---Channel associated signaling.
CCAPI---Call control applications programming interface.
CLI---Command line interface.
CO---Central office.
CPE---Customer premises equipment. Terminating equipment, such as terminals, telephones, and modems, supplied by the telephone company, installed at the customer sites, and connected to the telephone company network.
CSM---Call switching module.
dial peer---An addressable call endpoint. In Voice over IP (V0IP), there are two types of dial peers: POTS and VoIP.
DNS---Domain name system used to address translation to convert H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to assist in the location of remote gatekeepers and to reverse-map raw IP addresses to host names of administrative domains.
DNIS---Dialed number identification service. The called number.
DSP---Digital signal processor.
E.164---The international public telecommunications numbering plan. A standard set by ITU-T which addresses telephone numbers.
E&M---Ear and mouth RBS signaling.
endpoint---A H.323 terminal or gateway. An endpoint can call and be called. It generates and/or terminates the information stream.
gatekeeper---A gatekeeper maintains a registry of devices in the multimedia network. The devices register with the gatekeeper at startup, and request admission to a call from the gatekeeper.
The gatekeeper is a H.323 entity on the LAN that provides address translation and control access to the LAN for H.323 terminals and gateways. The gatekeeper may provide other services to the H.323 terminals and gateways, such as bandwidth management and locating gateways.
gateway---A gateway allows H.323 terminals to communicate with non-H.323 terminals by converting protocols. A gateway is the point at which a circuit-switched call is encoded and repackaged into IP packets.
A H.323 gateway is an endpoint on the LAN that provides real-time, two-way communications between H.323 terminals on the LAN and other ITU-T terminals in the WAN, or to another H.323 gateway.
H.323---An International Telecommunication Union (ITU-T) standard that describes packet-based video, audio, and data conferencing. H.323 is an umbrella standard that describes the architecture of the conferencing system, and refers to a set of other standards (H.245, H.225.0, and Q.931) to describe its actual protocol.
H.323 RAS---Registration, admission, and status. The RAS signaling function performs registration, admissions, bandwidth changes, status and disengage procedures between the VoIP gateway and the gatekeeper.
HSRP---Hot Standby Routing Protocol. HSRP is a Cisco proprietary protocol which provides a redundancy mechanism when more than one router is connected to the same segment/subnet of an Ethernet/FDDI/Token Ring network.
IVR---Integrated voice response. When someone dials in, it responds with a prompt to get a personal identification number (PIN), and so on.
LEC---Local exchange carrier.
LRQ---Location request.
multicast---A process of transmitting PDUs from one source to many destinations. The actual mechanism (that is, IP multicast, multi-unicast, and so forth) for this process might be different for LAN technologies.
multipoint-unicast---A process of transferring PDUs (Protocol Data Units) where an endpoint sends more than one copy of a media stream to different endpoints. This might be necessary in networks which do not support multicast.
node---A H.323 entity that uses RAS to communicate with the gatekeeper. For example, an endpoint such as a terminal, proxy, or gateway.
PDU---Protocol dara units, used by bridges to transfer connectivity information.
POTS---Plain old telephone service. Basic telephone service supplying standard single line telephones, telephone lines, and access to the PSTN.
PSTN---Public switched telephone network. PSTN refers to the local telephone company.
QoS---Quality of service, which refers to the measure of service quality provided to the user.
RAS---Registration, admission, and status protocol. This is the protocol that is used between endpoints and the gatekeeper to perform management functions.
RBS---Robbed bit signaling
RRQ---Registration request.
SPI---Service provider interface.
TCL---Tool command language.
TDM---Time division multiplexing. Technique in which information from multiple channels can be allocated bandwidth on a single wire based on preassigned time slots. Bandwidth is allocated to each channel regardless of whether the station has data to transmit.
VoIP---Voice over IP. The ability to carry normal telephone-style voice over an IP-based internet with POTS-like functionality, reliability, and voice quality. VoIP is a blanket term which generally refers to Cisco's standards based (H.323, etc.) approach to IP voice traffic.
VTSP---Voice telephony service provider.
zone---A collection of all terminals (tx), gateways (GW), and Multipoint Control Units (MCU) managed by a single Gatekeeper (GK). A Zone includes at least one terminal, and might or might not include gateways or MCUs. A Zone has only one gatekeeper. A Zone may be independent of LAN topology and may be comprised of multiple LAN segments which are connected using routes or other devices.
The H.323 gateway feature and supporting software applications in Cisco IOS Release 11.3(6)NA2 requireVCWare version 2.4. Cisco IOS Release 11.3(7)NA requires VCWare version 2.5.
The H.323 VoIP Gatekeeper feature is supported on these platforms:
There are two types of addresses used in H.323 destination calls:
The Cisco IOS Release 11.3(2)NA software feature Multimedia Conference Manager dealt primarily with H.323-ID addressing in interzone calls. With the new prefix commands, the administrator can now also configure interzone routing when calls are made using E164 addresses.
When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve "bob@cisco.com," the source endpoint's gatekeeper finds the gatekeeper for "cisco.com" and sends it the Location Request (LRQ) for target address "bob@cisco.com." The destination gatekeeper looks in the registration database, sees "bob" registered, and returns the appropriate IP address to get to bob.
When using E164 addresses, call routing is handled through means of zone prefixes and gateway-type or technology prefixes.
The zone prefixes (typically area codes) serve the same purpose as the domain names in the H.323-ID address space.
For instance, if our local gatekeeper has been configured with the knowledge that zone prefix 212xxxxxxx (that is, any address beginning 212 and followed by 7 arbitrary digits) is handled by gatekeeper gk-ny:
router(config-gk)# zone prefix gk-ny 212.......
Then when the local gatekeeper is asked to admit a call to destination address 2125551111, it knows to send the Location Request to gk-ny.
However, when the query gets to gk-ny, gk-ny still needs to resolve the address so that the call can be sent to its final destination. There could actually be a H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny will return the IP address for that endpoint. However, the probability is that the E.164 address belongs to a non-H.323 device (for example, a telephone or an H.320 terminal). Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge to whom the address belongs. It needs to be able to select a gateway which can be used to reach the non-H.323 device. This is where the technology prefixes (or gateway-type) becomes useful.
The 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 tech-prefix 1#, H.320-gateways with tech-prefix "2#," voicemail-gateways with "3#," and so on. More than one gateway may 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 they are trying to reach, can now prepend a tech-prefix to the destination address to indicate the type of gateway to use to get to the destination.
The caller might ask for 1#2125551111 if they know that the address 2125551111 is for a telephone and the tech-prefix for voice gateways is 1#. When the voice gateway receives the call for 1#2125551111, it strips off the tech-prefix and bridges the next leg of the call to the telephone at 2125551111.
In cases where the call scenario is:
telephone -----> voice-gw1 -----> voice-gw2 -----> telephone
(PSTN) (H.323) (PSTN)
voice-gw1 can be configured (using the dial-peer command) to prepend the voice tech-prefix "1," so that the use of technology prefixes is completely transparent to the caller.
There are a couple of interesting features in the implementation of the gw-type-prefix command:
If the majority of calls hop off on a particular type of gateway, the gatekeeper can be configured to use that type of gateway as the default type, so that callers no longer have to prepend a tech-prefix on the address. For example, if you use mostly voice gateways in your network, and you have configured all your voice gateways to register with tech-prefix 1, you can configure your gatekeeper to use 1xx gateways as the default:
router(config-gk)# gw-type-prefix 1# default-technologyNow a caller no longer needs to prepend 1xx to use a voice gateway. Any address that does not contain an explicit tech-prefix will be routed to one of the voice gateways that registered with 1xx.
With this default-technology definition, suppose a caller asks the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it will route the call to one of its local 1xx voice gateways, so the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it sends a Location Request for 2125551111 to gk-ny. This requires that gk-ny also be configured with some default gateway type prefix, and that its voice gateways be registered with that prefix.
The other gateway-type feature is the ability 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 tech-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. That remote gatekeeper then uses the tech-prefix to decide which of its gateways to hop off.
The zone-prefix determines the routing to a zone, where the tech-prefix determines the gateway in that zone. See "zone prefix" for a description of the command.
This behavior can be overridden by associating a forced hop-off zone with a particular tech-prefix. This forces the call to the specified zone, regardless of what the zone-prefix in the address is.
A hypothetical example to demonstrate a forced hop-off follows: If you are in the 408 area code (San Jose) and you want calls to the 212 area code to hop-off in New York via VoIP to save costs but you do not have any gateway in New York. However, you do have a H.323 gateway in Denver and to hop-off from Denver is cheaper than to locally hop-off from San Jose. In this case, you would define the gateway-type prefix 212 for H.323 gateways to always be forced to the Denver zone.
Gatekeeper Hot Standby Router Protocol (HSRP) support consists of elements in both the gateway and gatekeeper functions in the router. The gateway periodically retries its registration when it detects a possible gatekeeper failure to register itself with the backup gatekeeper. Although it is a backup, the gatekeeper operates in a passive mode in which it does not accept registrations, and becomes active when it is notified by HSRP that it will become the primary gatekeeper.
This sample configuration uses the E.164 address routing configuration and is based on the following assumptions:
The following example is for illustrative purposes only.
Step 1 Enter configuration mode:
config term
Step 2 Enter gatekeeper configuration mode
gatekeeper
Step 3 Define a local zone (that is, managed by this gatekeeper). Its gatekeeper ID is "gk-sj" and the domain name is "cisco.com."
zone local gk-sj cisco.com
Step 4 Notify the gatekeeper that gatekeeper gk-ny manages the 212 area code so that calls to E.164 addresses beginning with 212 should be sent to gk-ny (at 172.21.127.27).
zone remote gk-ny cisco.com 172.21.127.27
Step 5 Define the accessibility for local zone gk-sj. This states that the calls originating in any (default) zone, gk-sj should offer direct (unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call.
zone access gk-sj default direct
Step 6 Configure the gatekeeper to handle the 408 area code.
zone prefix gk-sj 1408.......
Step 7 Notify the gatekeeper that gatekeeper gk-ny manages the 212 area code so that calls to E.164 addresses beginning with 1212 should be sent to gk-ny (at 172.21.127.27).
zone prefix gk-ny 1212.......
Step 8 Define the gateway technology prefix 3# and stipulate that any calls to addresses beginning with this technology prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix is.
gw-type-prefix 3# hopoff gk-sj
Step 9 Define the gateway technology prefix 4#. The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing unresolveable addresses.
gw-type-prefix 4# default-technology
Step 1 Enter configuration mode:
config term
Step 2 Enter gatekeeper configuration mode:
gatekeeper
Step 3 Define a local zone (that is, managed by this gatekeeper), Its gatekeeper ID is gk-ny and the domain name is "cisco.com."
zone local gk-ny cisco.com
Step 4 Notify the gatekeeper about a remote gatekeeper called gk-sj located at IP address 172.21.1.48.
zone remote gk-sj cisco.com 172.21.1.48
Step 5 Define the accessibility for local zone gk-ny. This states that the calls originating in any (default) zone, gk-ny should offer direct (that is, unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call.
zone access gk-ny default direct
Step 6 Configure the gatekeeper to handle the 1212 area code.
zone prefix gk-ny 1212.......
Step 7 Notify the gk-ny gatekeeper that manages the 408 area code, so that calls to E.164 addresses beginning with 1408 should be sent to gk-sj (at 172.21.1.48).
zone prefix gk-sj1408......
Step 8 Define the gateway technology prefix 3# and stipulate that any calls to addresses beginning with this tech prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix is.
gw-type-prefix 3# hopoff gk-ny
Step 9 Define a gateway technology prefix "4#." The default-technology keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing otherwise unresolveable addresses.
gw-type-prefix 4# default-technology
Continuing this example in San Jose suppose we have gateways registering with gk-sj as follows:
Similarly, in New York, gateways are configured to register with gk-ny as follows:
Given the above configuration, in San Jose, a call is presented to the gatekeeper (gk-sj) with the following target address:
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 11.3 command references.
The arq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If, however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.
arq reject-unknown-prefixThis command has no arguments or keywords.
The gatekeeper accepts and processes all incoming ARQs.
Gatekeeper configuration
This command first appeared in the Cisco IOS Release 11.3(6)NA2.
You can use the arq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) for a destination E.164 address which does not match any configured zone prefixes.
When an endpoint or gateway initiates an H.323 call, it sends an ARQ to its gatekeeper. The gatekeeper uses the configured list of zone prefixes to determine to which zone the call should be directed. If the called address does not match any known zone prefixes, the gatekeeper will attempt to hairpin the call out through a local gateway. To mandate that such calls should be rejected, use the arq reject-unknown-prefix command.
This command is typically used either to restrict local gateway calls to a known set of prefixes or to deliberately fail such calls so that an alternate choice on a gateway's rotary dial-peer can be selected.
The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:
zone local gk408 cisco.comIn the above example, the gatekeeper manages a zone containing gateways to the 408 area code, and it knows about a peer gatekeeper with gateways to the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone.
If an endpoint wishes to make a call to the 408 area code, the call will be routed out through a local gateway. If the call is to the 415 area code, it will be directed to the gk415 zone and hop off on a gateway there. But if a call is made to the 212 area code for example, it will also be directed to a local gateway in the gk408 zone.
Now if you add the command arq reject-unknown-prefix, when a call is made to the 212 area code, it is now rejected because the destination address does not match any configured prefixes.
To configure a technology prefix in the gatekeeper, use the gw-type-prefix command. To remove the technology prefix, use the no form of the command.
gw-type-prefix type-prefix [hopoff gkid][default-technology]
type-prefix | A technology prefix is recognized and is stripped before checking for the zone prefix. It is strongly recommended that you select technology prefixes that do not lead to ambiguity with zone prefixes. Do this by using the # character to |
hopoff gkid | (Optional) Use this option to specify the gatekeeper or zone where the call is to hop off, regardless of the zone prefix in the destination address. The gkid |
default-technology | (Optional) Gateways registering with this prefix option are used as the default for routing any addresses that are otherwise unresolved. |
gw ipaddr ipaddr [port] | (Optional) Use this option to indicate that the gateway is incapable of registering technology prefixes. When it registers, it adds the gateway to the group for this type-prefix, just as if it had sent the technology prefix in its registration. This parameter can be repeated to associate more than one gateway with a technology prefix. |
No technology prefix is defined.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3(6)NA2.
More than one gateway can register with the same technology prefix. In such cases, a random selection is made of one of them.
You do not have to define a technology prefix to a gatekeeper if there are gateways configured to register with that prefix, and if there are no special flags (such as hopoff gkid or default-technology) that you want to associate with that prefix.
The following example specifies 4# as the default technology prefix:
gw-type-prefix 4# default-technologyzone prefix
The lrq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If, however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.
lrq reject-unknown-prefixThis command has no arguments or keywords.
no lrq reject-unknown-prefix.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3(6)NA2.
You can use the lrq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes.
When the gatekeeper receives a Location Request asking about an E.164 address, it matches the target address against the list of configured zone prefixes. If the address matches a zone prefix, the behavior is unambiguous and well-defined:
However, if the target address does not match any known local or remote zone prefixes, the default behavior is to attempt to service the call using one of the local zones. This default behavior might not be suitable for all sites, so the lrq reject-unknown-prefix command allows you to force the gatekeeper to reject such requests.
The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:
zone local gk408 cisco.com
In the above example, the gatekeeper manages two zones, one with gateways with interfaces in the 408 area code, and one with gateways in the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone. Now say some other zone had been erroneously configured to route calls to the 212 area code to this gatekeeper. When the Location Request arrives, this gatekeeper fails to match the area code, and so the LRQ is rejected.
However, if this was your only site that had any gateways in it, and you wanted your other sites to route all calls requiring gateways to this gatekeeper, then you would undo the reject command by entering: no lrq reject-unknown-prefix
Now, with this command entered, when the gatekeeper receives an LRQ for the address 12125551234, it will attempt to find an appropriate gateway in either one of the zones gk408 or gk415 to service the call.
To display the gateway-type prefix table, use the show gatekeeper gw-type-prefix EXEC command.
show gatekeeper gw-type-prefixThis command has no key words or arguments.
None.
Privileged EXEC
This command first appeared in the Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper gw-type-prefix command:
router# show gatekeeper gw-type-prefix
(GATEWAYS-TYPE PREFIX TABLE
================================
Prefix: 3#* (Hopoff- gk408)
Prefix: 4#* (Default gateway-technology)
Static Configured Gateways:
Prefix: 7#* (Hopoff gk408)
Static Configured Gateways:
1.1.1.1:1720
2.2.2.2:1720
Field
Description
Prefix
The tech-prefix defined with the gw-type-prefix command.
Hopoff gk408
Calls specifying tech-prefix 3# or 7# will always be routed to zone gk408, regardless of the actual zone-prefix in the destination address.
Default gateway-technology
The address associated with the technology prefix is a gateway used as the default for routing any addresses that are otherwise unresolveable.
Static configured gateways
Lists all IP addresses and port numbers of statically configured gateways.
To show overall gatekeeper status that includes authorization and authentication status, zone status, and so on, use the show gatekeeper status EXEC command.
show gatekeeper statusThis command has no arguments or keywords.
None.
Privileged EXEC (also known as Enable mode)
This command first appeared in Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper status command:
router# show gatekeeper status
Gatekeeper State: UP
Zone Name: gk-px4.cisco.com
Accounting: DISABLED
Security: DISABLED
| Field | Description |
|---|---|
Gatekeeper State |
|
Zone Name | Zone name. |
Accounting | Authorization and accounting status. |
Security | Security status. |
To display the zone prefix table, use the show gatekeeper zone prefix EXEC command.
show gatekeeper zone prefixThis command has no keywords or arguments
None.
Privileged EXEC
This command first appeared in the Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper zone prefix command:
5300# show gatekeeper zone prefix
ZONE PREFIX TABLE
=================
GK-NAME E164-PREFIX
------- -----------
gk.zone13 212.......
gk.zone14 415.......
gk.zone14 408.......
| Field | Description |
|---|---|
gk-name | The gatekeeper name. |
e164-prefix | The E.164 prefix and a dot that acts as a wildcard for matching each remaining number in the telephone number. |
To specify a zone controlled by a gatekeeper, use the zone local gatekeeper configuration command. To remove a zone controlled by a gatekeeper, use the no form of this command. This command can also be used to change the IP address used by the gatekeeper.
zone local gatekeeper-name domain-name [rasIPaddress]
gatekeeper-name
| The gatekeeper's name or zone name. This is usually the full domain-qualified host name of the gatekeeper. For example, if the domain-name is cisco.com, the gatekeeper-name might be gk1.cisco.com. However, if the gatekeeper is controlling multiple zones, the gatekeeper-name for each zone should be some unique string that has a mnemonic value. |
domain-name | The domain name served by this gatekeeper. |
rasIPaddress | (Optional.) The IP address of one of the interfaces on the gatekeeper. When the gatekeeper responds to gatekeeper discovery messages, it signals the endpoint or gateway to use this address in future communications. Setting this address for one local zone makes it the address used for all local zones. |
None.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3 NA.
Multiple local zones can be defined. The gatekeeper manages all configured local zones. Intrazone and interzone behavior remains the same (zones are controlled by the same or different gatekeepers).
Only one rasIPaddress argument can be defined for all local zones. You cannot configure each zone to use a different RAS IP address. If you define this in the first zone definition, you can omit it for all subsequent zones, which automatically pick-up this address. If you set it in a subsequent zone local command, it also changes the RAS address of all previously configured local zones. After it is defined, you can change it by re-issuing any zone local command with a different rasIPaddress argument.
If the rasIPaddress argument is an HSRP virtual address, it automatically puts the gatekeeper into HSRP mode. In this mode, the gatekeeper assumes STANDBY or ACTIVE status according to whether the HSRP interface is on STANDBY or ACTIVE status.
You cannot remove a local zone if there are endpoints or gateways registered in it. To remove the local zone, shut down the gatekeeper first, which forces unregistration.
Multiple zones are controlled by multiple logical gatekeepers on the same Cisco IOS release.
The following example creates a zone controlled by a gatekeeper in the domain called cisco.com:
zone local gk1.cisco.com cisco.com show gatekeeper zone statue
zone remote
To configure the gatekeeper with knowledge of its own and any remote zone's prefixes, use the zone prefix gatekeeper configuration command. To remove knowledge of zone prefixes, use the no form of this command.
zone prefix gatekeeper-name e164-prefix
gatekeeper-name
| The name of a local or remote gatekeeper, which must have been defined using the zone local or zone remote command. |
e164-prefix | An E.164 prefix in standard form followed by dots (.) that each represent a number in the E.164 address. For example, 212....... is matched by 212 and any seven numbers. |
None.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3(6)NA2.
Although a dot representing each digit in an E.164 address is the preferred configuration method, you may also enter an asterisk (*) to match any number of digits.
A gatekeeper may handle more than one zone prefix, but a zone prefix cannot be shared by more than one gatekeeper. If you have defined a zone prefix as being handled by a gatekeeper and now define it as being handled by a second gatekeeper, the second assignment will cancel the first.
When a zone handles several prefixes, all gateways in that zone constitute a common pool which can be used to hop off to any of those prefixes. You may, however, wish to partition your gateways by prefix. For instance, you have a gateway which interfaces to the 408 area code, and another which interfaces to the 415 area code, and for cost reasons you want each gateway only to be used for calls to its area code. In this case, you can define several local zones on the gatekeeper, each responsible for a prefix, and have each gateway register to the zone handling its prefix. For example, you can define local zone gk-408 handling prefix 408....... and local zone gk-415 handling 415......., and have the gateway interfacing to the 408 area code register with gk-408, and the gateway with the 415 interface register to gk-415.
The following example matches the 212 area code and any seven digits as the zone prefix for gk-ny:
zone prefix gk-ny 212....... zone local
zone remote
To statically specify a remote zone if DNS is unavailable or undesirable, use the zone remote gatekeeper configuration command. To remove the remote zone, use the no form of this command.
zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address
other-gatekeeper-name | Name of the remote gatekeeper. |
other-domain-name | Domain name of the remote gatekeeper. |
other-gatekeeper-ip-address | IP address of the remote gatekeeper. |
port-number | (Optional.) RAS signaling port number for the remote zone. Value ranges from 1 to 65535. If this is not set, the default is the well known RAS port number 1719. |
None.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3 NA.
All gatekeepers do not have to be in DNS. For those that are not, use the zone remote command so that the local gatekeeper knows how to access them. In addition, you might wish to improve call response time slightly for frequently accessed zones. If the zone remote command is configured for a particular zone, you do not need to make a DNS lookup transaction.
The following example configures the local gatekeeper to reach targets of the form xxx.cisco.com by sending queries to the gatekeeper named sj3.cisco.com at IP address 1.2.3.4:
zone remote sj3.cisco.com cisco.com 1.2.3.4 show gatekeeper zone statue
zone local
Posted: Mon Nov 29 15:43:57 PST 1999
Copyright 1989-1999©Cisco Systems Inc.