Document ID: 44946
Updated: Oct 13, 2005
Contents
Introduction
A gatekeeper device, also known as a Cisco Multimedia Conference Manager (MCM), supports the H.225 Registration, Admission, and Status Protocol (RAS) message set that is in use for call admission control, bandwidth allocation, and dial pattern resolution (call routing). The gatekeeper can provide these services for communications between Cisco CallManager clusters and H.323 networks. You can configure multiple gatekeeper devices for each Cisco CallManager cluster as well as configure alternate gatekeepers for redundancy. For alternate gatekeeper configuration details, refer to the MCM documentation.
Gatekeeper configuration with Cisco CallManager comprises of these two steps:
Prerequisites
Requirements
This document is intended for the networking personnel who deploy the IP Telephony networks. Readers of this document should have knowledge of these topics:
-
Voice Over IP Configuration
-
IP Telephony Concepts
Components Used
The information in this document is based on these software and hardware versions:
-
Cisco CallManager version 3.3(2) spB - 171.69.85.171
-
Gatekeeper IOSĀ® version c3640-ix-mz.122-15.T2 - 172.16.13.7
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to Cisco Technical Tips Conventions.
Configure the Gatekeeper and Trunk in Cisco CallManager
Each Cisco CallManager cluster can register with one or more gatekeepers. This section describes how to configure the gatekeeper in Cisco CallManager. You also need to configure trunk devices on the Trunk Configuration page. See the Trunk Configuration section for details.
Add a Gatekeeper
Use this procedure in order to add a gatekeeper device.
-
Select Device > Gatekeeper in order to display the Gatekeeper Configuration page.
-
Enter the appropriate settings. See Table 1 for details about different options. The default settings are used for this setup.
-
Click Insert in order to add the new gatekeeper.
The Gatekeepers list displays the page updates, and the name of the new gatekeeper.
Gatekeeper Configuration Options
Table 1 describes the gatekeeper configuration settings.
Table 1
Field | Description |
---|---|
Host Name/IP Address | Enter the IP address or Domain Name System (DNS) name of the gatekeeper in the appropriate field. You can register multiple gatekeepers for each Cisco CallManager cluster. |
Description | Enter a descriptive name for the gatekeeper. |
Registration Request Time to Live | Do not change this value unless you have an instruction to do so by a Cisco Technical Support engineer. Enter the time in seconds. The default value specifies 60 seconds. The Registration Request Time to Live field indicates the length of time that the gatekeeper considers a registration request (RRQ) valid. The system must send a keepalive RRQ to the gatekeeper before the RRQ Time to Live expires. Cisco CallManager sends an RRQ to the gatekeeper in order to register and subsequently to maintain a connection with the gatekeeper. The gatekeeper can confirm (RCF) or deny (RRJ) the request. |
Registration Retry Timeout | Do not change this value unless you have an instruction to do so by a Cisco Technical Support engineer. Enter the time in seconds. The default value specifies 300 seconds. The Registration Retry Timeout field indicates the length of time that Cisco CallManager waits before it retries gatekeeper registration after a failed registration attempt. |
Enable Device | This check box allows you to register this gatekeeper with Cisco CallManager. By default, this check box remains checked. In order to unregister the gatekeeper from Cisco CallManager, uncheck this check box. The gatekeeper unregisters within approximately one minute after you update this field. |
You can configure trunks in Cisco CallManager administration in order to function in either of these ways:
-
Non-gatekeeper-Controlled Trunks
Note: This document only focuses on how to configure Gatekeeper-Controlled H.225 trunks.
Gatekeeper-Controlled Trunk
In this case, a single intercluster trunk is sufficient to communicate with all remote clusters. Similarly, a single H.225 trunk is necessary to communicate with any H.323 gatekeeper-controlled endpoints. You also need to configure route patterns or route groups in order to route the calls to and from the gatekeeper. In this configuration, the gatekeeper dynamically determines the appropriate IP address for the destination of each call to a remote device, and the local Cisco CallManager uses that IP address in order to complete the call.
This configuration works well in large as well as smaller systems. For large systems where many clusters exist, this configuration helps in order to avoid the configuration of individual intercluster trunks between each cluster.
If you configure gatekeeper-controlled trunks, Cisco CallManager automatically creates a virtual trunk device. The IP address of this device changes dynamically in order to reflect the IP address of the remote device which the gatekeeper determines. Use trunks when you configure the route patterns or route groups that route calls to and from a gatekeeper.
Add a Gatekeeper Controlled H.225 Trunk
Use this procedure in order to add a gatekeeper controlled H.225 trunk.
-
In Cisco CallManager Administration select Device > Trunk, select Add a New Trunk. You then see another page.
-
Select H.225 Trunk (Gatekeeper Controlled) and then select Next. You then see another page.
-
Specify the Device Name and Device Pool information. In this configuration all other values are left as default.
-
On the same page specify the Gatekeeper IP address and terminal type. In the Technology prefix section specify the appropriate Technology (for example Prefix 1#*) and in the zone box select the appropriate zone (for example SJGK1).
-
Select Insert and select OK to the message that indicates to reset the trunk.
-
The page refreshes. Select Reset Trunk and choose either Restart or Reset appropriately.
Configure a Route Pattern
Configure a route pattern in order to route calls to each gatekeeper-controlled trunk.
Refer to Route Pattern Configuration for further information.
In the Route Pattern configuration, specify the pattern to route the call towards the Trunk Device.
This graphic represents an example of how to configure a route pattern in Cisco CallManager. Use the appropriate route pattern as per your route plan.
Configure the Gatekeeper on the Router
Cisco CallManager registers with a gatekeeper with the use of its IP address and the H.323 ID. You can specify the CallManager IP address in one of these ways:
-
In static configuration, use the gw-type-prefix <prefix> gw ipaddr <address> command on the gatekeeper in order to specify each Cisco CallManager IP address explicitly.
-
In dynamic configuration, when a Cisco CallManager registers with the gatekeeper, it sends its IP address and the specified technology prefix to the gatekeeper. The gatekeeper then registers this Cisco CallManager as a valid gatekeeper-controlled VoIP device.
In order to specify the directory number range for a particular Cisco CallManager, use the zone prefix command to configure the range on the gatekeeper. For example, this command specifies the DN for zone SJGK1 that starts from 408-527.
zone prefix SJGK1 408527*
The maximum number of active calls that are allowed for each zone depends on the codec in use for each call and the bandwidth that is allocated for the zone. Cisco CallManager requests different bandwidths for different codecs:
Codec | Requested Bandwidth by CallManager |
---|---|
G.711 | 128 kpbs |
G.729 | 16 kbps |
G.723 | 14 Kbps |
Use Regions in Cisco CallManager in order to specify the codec type. Use the bandwidth command on the gatekeeper in order to specify the available bandwidth. For example, this command allocates 512 kbps to the SJGK1 zone.
bandwidth total zone SJGK1 512
With an allocation of 512 kbps, the SJGK1 zone in this example can support up to:
-
4 G.711 calls or
-
32 G.729 calls or
-
36 G.723 calls at the same time
Note: In a scenario where Gatekeeper controls several zones, Cisco recommends you make use of the bandwidth interzone command. The bandwidth total command can cause issues in some configurations. For more information about Gatekeeper considerations, refer to the Centralized Gatekeeper Configuration section of Cisco IP Telephony Solution Reference Network Design.
Sample Gatekeeper Configuration
interface FastEthernet0/0 ip address 172.16.13.7 255.255.255.224 duplex auto speed auto gatekeeper zone local SJGK1 cisco.com zone prefix SJGK1 408* gw-type-prefix 1#* default-technology no shutdown !--- The Cisco CallManager trunks register and appear as VoIP-GW. 3640-1#show gatekeeper endpoints GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --------------- ----- --------------- ----- --------- ---- ----- 171.69.85.31 1720 171.69.85.31 4724 SJGK1 TERM E164-ID: 3166188111 171.69.85.171 4613 171.69.85.171 1160 SJGK1 VOIP-GW H323-ID: TrunkDevice1GK_1 Total number of active registrations = 2
For more information about how to configure the gatekeeper, refer to VoIP with Gatekeeper.
Debugs
In this sample scenario, the IP phone makes a call for the H.323 NetMeeting Client (NetMeeting is directly registered with the gatekeeper). Cisco CallManager then sends the call to the gatekeeper through the gatekeeper trunk. This is the output for the debug RAS command on the gatekeeper.
Oct 15 06:06:22.595: RAS INCOMING PDU ::= value RasMessage ::= admissionRequest : { requestSeqNum 4343 callType pointToPoint : NULL endpointIdentifier {"61C97A1000000001"} destinationInfo { dialedDigits : "3166188111" } srcInfo { dialedDigits : "4085273175" } srcCallSignalAddress ipAddress : { ip 'AB4555AB'H port 1720 } bandWidth 1280 callReferenceValue 8 conferenceID '80480FB2D81C911D08000000AC10F07F'H activeMC FALSE answerCall FALSE canMapAlias TRUE callIdentifier { guid '80480FB2D81C911D08000000AC10F07F'H } gatekeeperIdentifier {"SJGK1"} } Oct 15 06:06:22.599: ARQ (seq# 4343) rcvd Oct 15 06:06:22.603: H225 NONSTD OUTGOING PDU ::= value ACFnonStandardInfo ::= { srcTerminalAlias { e164 : "4085273175" } dstTerminalAlias { e164 : "3166188111" } } Oct 15 06:06:22.603: H225 NONSTD OUTGOING ENCODE BUFFER::= 00 01048073 B85A64A8 01048064 994BB444 Oct 15 06:06:22.603: Oct 15 06:06:22.603: RAS OUTGOING PDU ::= value RasMessage ::= admissionConfirm : { requestSeqNum 4343 bandWidth 1280 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AB45551F'H port 1720 } irrFrequency 240 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '0001048073B85A64A801048064994BB444'H } willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } Oct 15 06:06:22.611: RAS OUTGOING ENCODE BUFFER::= 2B 8010F640 050000AB 45551F06 B800EF40 B5000012 11000104 8073B85A 64A 80104 8064994B B4442800 C0000100 020000 Oct 15 06:06:22.615: Oct 15 06:06:22.615: IPSOCK_RAS_sendto: msg length 48 from 172.16.13.7:1719 to 171.69.85.171: 1160 Oct 15 06:06:22.615: RASLib::RASSendACF: ACF (seq# 4343) sent to 171.69.85.171 Oct 15 06:06:25.439: RecvUDP_IPSockData successfully rcvd message of length 113 from 171.69.85.31:4724 Oct 15 06:06:25.439: RAS INCOMING ENCODE BUFFER::= 26 D0000B03 C0003600 31004200 38004600 41004500 38003000 30003000 300 03000 30003000 32020480 64994BB4 44048064 994BB444 00AB4555 1F06B800 00AB4555 AB06B800 013ED080 480FB2D8 1C911D08 000000 AC 10F07F44 E0200100 11008048 0FB2D81C 911D0800 0000AC10 F07F0100 Oct 15 06:06:25.443:
Cisco CallManager Trace
!--- Cisco CallManager sends the RRQ to the gatekeeper. 10/14/2003 23:26:40.082 CCM|value V2Message ::= registrationRequest : { requestSeqNum 4372, protocolIdentifier { 0 0 8 2250 0 2 }, discoveryComplete FALSE, callSignalAddress { ipAddress : { ip 'AB4555AB'H, !--- 171.69.85.171 is the IP address of the Cisco CallManager. port 4613 } }, rasAddress { ipAddress : { ip 'AB4555AB'H, port 1160 } }, terminalType { gateway { protocol { h323 : { }, voice : { supportedPrefixes { { prefix e164 : "1#*" } } } } }, mc FALSE, undefinedNode FALSE }, gatekeeperIdentifier "SJGK1", endpointVendor { vendor { t35CountryCode 181, t35Extension 0, manufacturerCode 18 } }, timeToLive 60, keepAlive TRUE, endpointIdentifier "61C97A1000000001" } !--- Registration is confirmed at this point (there is omission of some output). 10/14/2003 23:26:40.142 CCM|value V2Message ::= registrationConfirm : { requestSeqNum 4372, protocolIdentifier { 0 0 8 2250 0 4 }, callSignalAddress { }, gatekeeperIdentifier "SJGK1", endpointIdentifier "61C97A1000000001", timeToLive 60, willRespondToIRR FALSE } !--- Cisco CallManager sends Admission Request (ARQ) to !--- the gatekeeper in order to place the call. 10/14/2003 23:27:26.063 CCM|value V2Message ::= admissionRequest : { requestSeqNum 4376, callType pointToPoint : NULL, endpointIdentifier "61C97A1000000001", destinationInfo { e164 : "3166188111" !--– This is the phone number of the called !--- party that is the NetMeeting client. }, srcInfo { e164 : "4085273175" !--– This is the phone number of the calling party !--- that is the IP phone. }, srcCallSignalAddress ipAddress : { ip 'AB4555AB'H, port 1720 }, bandWidth 1280, callReferenceValue 13, conferenceID '806076A3DB1C911D0D000000AC10F07F'H, activeMC FALSE, answerCall FALSE, canMapAlias TRUE, callIdentifier { guid '806076A3DB1C911D0D000000AC10F07F'H }, gatekeeperIdentifier "SJGK1" } !--- This line indicates the client that sends this request. <NID::171.69.85.171><CT::1,100,90,1.1098993><IP::172.16.240.127> !--- Here is the Advanced Communications Function (ACF) !--- message from the gatekeeper. 10/14/2003 23:27:26.093 CCM|value V2Message ::= admissionConfirm : { requestSeqNum 4376, bandWidth 1280, !--– For a G.711 call, the bandwidth confirmed is 128 kbps. callModel direct : NULL, destCallSignalAddress ipAddress : { ip 'AB4555AB'H, port 4613 }, irrFrequency 240, nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181, t35Extension 0, manufacturerCode 18 }, data '0001048073B85A64A801048064994BB444'H }, willRespondToIRR FALSE, uuiesRequested { setup FALSE, callProceeding FALSE, connect FALSE, alerting FALSE, information FALSE, releaseComplete FALSE, facility FALSE, progress FALSE, empty FALSE } } !--- Cisco CallManager displays the RAS information. 10/14/2003 23:27:26.143 CCM|SPROCRas - { h323-uu-pdu { h323-message-body setup : { protocolIdentifier { 0 0 8 2250 0 2 }, sourceAddress { e164 : "4085273175", h323-ID : "4085273175" }, sourceInfo { terminal { }, mc FALSE, undefinedNode FALSE }, destinationAddress { e164 : "3166188111" }, activeMC FALSE, conferenceID '806076A3DB1C911D0D000000AC10F07F'H, conferenceGoal create : NULL, callType pointToPoint : NULL, sourceCallSignalAddress ipAddress : { ip 'AB4555AB'H, port 1720 }, callIdentifier { guid '806076A3DB1C911D0D000000AC10F07F'H }, mediaWaitForConnect FALSE, canOverlapSend FALSE }, h245Tunneling FALSE, nonStandardControl { { nonStandardIdentifier h221NonStandard : { |<CLID::ADESALU-SUNPC-Cluster><NID::171.69.85.171> 10/14/2003 23:27:26.143 CCM|t35CountryCode 181, t35Extension 0, manufacturerCode 18 }, data '80440400010100'H } } }
Verify
There is currently no verification procedure available for this configuration.
Troubleshoot
There is currently no specific troubleshooting information available for this configuration.
Related Information
Open a Support Case (Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.