|
|
This feature module describes enhancements to Cisco H.323 Version 2 for Phase 2, which is described in the following sections:
Cisco H.323 Version 2 Phase 2 upgrades Cisco IOS software by adding several optional features of the H.323 Version 2 specification and facilitates customized extensions to the Cisco Gatekeeper.
The Fast Connect feature allows endpoints to establish media channels without waiting for a separate H.245 connection to be opened. This streamlines the number of messages that are exchanged and the amount of processing that must be done before endpoint connections can be established. A high-level view of the Fast Connect procedures within the H.323 protocol follows:
1. The calling endpoint transmits a SETUP message containing the fastStart element that contains a sequence of encoded logical channel structures, each representing a different capability media type for both "send" and "receive" directions.
2. The called endpoint selects one or more of the media types offered by the calling endpoint for the send and receive directions and returns its selections as logically encoded Q.931 messages up to and including CONNECT. At this point, the called endpoint must be prepared to receive media along any of the channels it selected.
3. If H.245 procedures are needed and one or both of the endpoints do not support tunneling, then a separate H.245 connection is used.
This feature is not explicitly configurable. It is assumed that the gateway is capable of sending and receiving Fast Connect procedures unless its corresponding dial peer has been configured for RSVP (in other words, the req-qos is set to a value other than the default of best-effort). If the dial peer has been configured for RSVP, then traditional "slow" connect procedures will be followed, and the endpoint will neither attempt to initiate Fast Connect nor respond to a Fast Connect request from its peer.
A terminating endpoint can reject Fast Connect by simply omitting the fastStart element from all Q.931 messages up to and including CONNECT. In this case, normal H.245 procedures are followed and a separate H.245 TCP connection is established. So, if an endpoint does not support the Fast Connect procedures, normal H.245 procedures are followed. In addition, certain conditions can cause a Fast Connect call to fall back to normal H.245 procedures to complete the call.
Once a media connection has been opened (an audio path has been established), either endpoint has the option of switching to H.245 procedures (if they are needed) by using H.245 tunneling, whereby H.245 messages are encapsulated within the h245Control element of Q.931 messages.
The dtmf-relay command is the only H.245 cognizant command that can initiate H.245 tunneling procedures from a Fast Connect call. If H.245 tunneling is active on the call, switching to a separate TCP H.245 connection is not supported.
A Cisco terminating endpoint accepts a Fast Connect request only if a pair of symmetric codecs (codecs in both directions are the equivalent or identical) can be selected from a list that has been offered. The originating endpoint is constrained only by what it can send through the codec (or voice class codec list) associated with the dial peer.
If the Cisco originating endpoint has offered multiple codecs and the terminating endpoint selects a pair of asymmetric (mismatched) codecs, then, the originating endpoint initiates separate H.245 procedures to correct the asymmetric codec situation.
Fast Connect is backward compatible with H.323 Version 1 configurations.
Through H.245 tunneling, H.245 messages are encapsulated within Q.931 messages without using a separate H.245 TCP connection. When tunneling is enabled, one or more H.245 messages can be encapsulated in any Q.931 message. H.245 tunneling is not supported as a standalone feature; initiation of H.245 tunneling procedures can be initiated only by using the dtmf-relay command, and only from an active Fast Connect call. Furthermore, if dtmf-relay is configured on a Version 2 VoIP dial peer and the active call has been established by using Fast Connect, tunneling procedures initiated by the opposite endpoint are accepted and supported.
H.245 tunneling is backward compatible with H.323 Version 1 configurations.
Call Transfer allows an H.323 endpoint to redirect an answered call to another H.323 endpoint. Cisco gateways support H.450.2 Call Transfer as the transferred and transferred-to party. The transferring endpoint must be an H.450-capable terminal; the Cisco gateway cannot act as the transferring endpoint. Gatekeeper-controlled or Gatekeeper-initiated Call Transfer is not supported.
![]() |
Note Certain devices are limited in their support of H.450. The Cisco 1700 and ubr820 platforms do not support Interactive Voice Response (IVR). Therefore, these platforms are not able to act as H.450 Transferring endpoints. |
H.450.2 specifies two variants of Call Transfer:
1. Transfer without consultation---The transferring endpoint supplies the number of the transferred-to endpoint as part of the transfer request, and the two remote endpoints are transferred together. As mentioned above, a Cisco gateway cannot be the transferring endpoint.
2. Transfer with consultation---This feature is not currently supported.
Call Deflection is a feature under H.450.3 Call Diversion (Call Forwarding) that allows a called H.323 endpoint to redirect the unanswered call to another H.323 endpoint. Cisco gateways support H.450.3 Call Deflection as the originating, deflecting, and deflected-to gateway. The Cisco gateway as the deflecting gateway will support invocation of Call Deflection only by using an incoming PRI QSIG message (a Call Deflection cannot be invoked by using any other trunk type).
If the deflecting endpoint is a Cisco gateway, the telephony endpoint on the deflecting gateway's PRI invokes Call Deflection by sending an equivalent QSIG Reroute Invoke within a FACILITY message to the gateway. The deflecting gateway then uses the procedures outlined in H.450.3 Call Deflection to transfer the call to another endpoint. Note that the initiation of Deflection using QSIG Reroute Invoke is valid only on calls that arrived as H.323 calls at the deflecting Gateway. In other words, for calls that arrived at the Gateway through a telephony interface (such as a hairpin call) or using a non-H.323 IP protocol, QSIG Reroute Invoke will be ignored.
H.323 Version 2 Phase 2 does not support Gatekeeper-controlled or initiated Call Deflection.
![]() |
Note Certain devices are limited in their support of H.450. The Cisco 5800 is not able to convert QSIG to H.450. The Cisco 1700 and ubr820 platforms do not support IVR. Therefore, these devices are not able to act as H.450 Deflecting endpoints. |
A "hookflash" indication is a brief on-hook condition during a call. The indication is not long enough in duration to be interpreted as a signal to disconnect the call. You can create a hookflash indication by quickly depressing and releasing the hook on your telephone.
PBXs and telephone switches are frequently programmed to intercept hookflash indications and use them as a way to allow a user to invoke supplemental services. For example, your local service provider might allow you to enter a hookflash as a means of switching between calls if you subscribe to a call-waiting service.
In the traditional telephone network, a hookflash results in a voltage change on the telephone line. Because there is no equivalent of this voltage change in an IP network, the ITU H.245 standard defines a message representing a hookflash. To send a hookflash indication using this message, an H.323 endpoint sends an H.245 user input indication message containing a "H.245-signal" or "H.245-alpha" structure with a value of "!". This value represents a hookflash indication.
In H.323 Version 2 Phase 2, an FXS hookflash relay is generated only if the following two conditions are met:
1. The other endpoint must support the reception of an H.245 hookflash and advertise this using the "Receive User Input Capability" message during H.245 capabilities exchange;
2. The call must be established with either the "H245-alpha" or "h245-signal" variant of dtmf-relay.
This implies that the VoIP dial peer must be configured for dtmf-relay h245-alpha or h245-signal, but not cisco-rtp.
Enter the timing hookflash-input command on FXS interfaces to specify the maximum length in milliseconds of a hookflash indication. If the hookflash lasts longer than the specified limit, then the FXS interface processes the indication as an onhook.
The acceptable duration of a hookflash indication varies by equipment vendor and by country. One PBX can consider a 250 ms on-hook condition to be a hookflash; another PBX can consider this condition to be a disconnect.
Security for Registration, Admission, and Status protocol (RAS) signaling between H.323 endpoints and Gatekeepers is enhanced in H.323 Version 2 Phase 2 by including secure endpoint registration of the Cisco gateway to the Cisco Gatekeeper and secure per-call authentication. The authentication type is "password with hashing" as described in ITU H.235. Specifically, the encryption method is MD5 with password hashing. This functionality is provided by the security token required-for CLI on the Gatekeeper and the security password CLI on the gateway.
The Gatekeeper can interact with a RADIUS security server to perform the authentications. The gateway can also authenticate an external application by using the Gatekeeper Transaction Message Protocol (GKTMP) API.
Per-call authentication is accomplished by validating account and pin numbers that are entered by the user connected to the calling gateway by using an interactive voice response (IVR) prompt.
The security mechanisms described above require the gateway and Gatekeeper clocks to be synchronized within 30 seconds of each other by using a Network Time Protocol (NTP) server.
The Gatekeeper Transaction Message Protocol (GKTMP) for the Cisco Gatekeeper provides a transaction-oriented application protocol that allows an external application to modify Gatekeeper behavior by processing specified RAS messages.
You can specify a set of triggers that use RAS messages that the Gatekeeper recognizes. Triggers are specified filter conditions that must match each type of RAS message. These triggers can be dynamically registered by using the external application, or you can configure this information by using the CLI on the Gatekeeper.
When the Gatekeeper receives a RAS message that meets the specified trigger conditions, it forwards the message to the external application in a GKTMP message format. This message is text encoded and sent over TCP. The external application can then modify fields in the message before returning it to the Gatekeeper for further processing, or it may return a RAS response to the Gatekeeper to be forwarded to the RAS client.
The following messages can be sent in GKTMP:
The application server interprets RAS messages in the following ways:
![]() |
Note Cisco has developed an API that you can use to provide an interface to the Cisco Gatekeeper. See the Cisco Gatekeeper External Interface Reference. |
To configure the Gatekeeper to receive trigger registrations from the external applications, specify the server's registration port using the server registration-port command where the Gatekeeper listens for server connections.
You can also configure the Gatekeeper to initiate the connection to a specified external application by using the server trigger command to specify a set of static trigger conditions for a specified server. You can specify only one application server for each server trigger command. All RAS messages that don't match the selection criteria for any external application are processed normally by the Gatekeeper. You can enter the show Gatekeeper servers and debug Gatekeeper servers commands to assist in the configuration.
The Alternate Endpoint feature allows a Gatekeeper to specify alternative destinations for a call when queried with an Admission Request (ARQ) by an originating gateway. If the first destination gateway fails to connect, the Gatekeeper tries all the alternate destinations before going to the next dial peer rotary (if a rotary is configured).
![]() |
Note This feature is not supported by the Cisco Gatekeeper; it is intended for use with third-party Gatekeepers that implement the Alternate Endpoint field in the ACF message. No support is provided for the gateway to send a list of alternate endpoints in RRQ messages. |
This feature informs the Gatekeeper of the specific voice port or T1/E1 span from which an incoming call entered the ingress gateway. This is done using a Cisco proprietary, nonstandard field that has been added to the Admission Request (ARQ) message sent by the ingress gateway. No configuration is necessary for this feature.
This feature provides the Gatekeeper with a configurable string that identifies the voice port or T1/E1 span from which an incoming call entered the ingress gateway. This is done using a Cisco proprietary, nonstandard field that has been added to the ARQ message sent by the ingress gateway. The string in the ARQ corresponds to the setting of the voice-port description command.
This feature is similar to network-based billing number feature, but differs in two important respects:
Cisco H.323 Version 2 Phase 2 adds the following benefits to Cisco H.323 Gatekeepers, gateways, and proxies:
H.323 Version 2 Phase 2 features will not interoperate with H.323 Version 1 features in Cisco IOS releases earlier than 11.3(9)NA or 12.0(3)T. Earlier Cisco IOS releases contain H.323 Version 1 software that does not support protocol messages with an H.323 Version 2 protocol identifier.
![]() |
Note All systems must be running either Cisco IOS release 11.3(9)NA and later releases or Cisco IOS version 12.0(3)T and later releases to interoperate with H.323 Version 2. |
To use H.450 services (Call Transfer or Call Deflection), you must use Release 12.1(1)T of the Gatekeeper; H.450 on the gateways is incompatible with previous releases of the Cisco Gatekeeper.
If you are planning to use a Cisco AS5300 universal access server, your software requires VCWare Version 4.04.
Cisco H.323 Version 2 technologies are typically configured by using a number of available compression and decompression (CODECs) and the following high-density DSP/voice modules.
The following table lists the documentation available for configuring and using Cisco IOS H.323 Gatekeepers, gateways, and proxies:.
| Document | Release | 2500 Series | 2600 Series | 3600 Series | AS5300 |
|---|---|---|---|---|---|
11.3NA | x |
| x |
| |
11.3NA | x |
| x |
| |
11.3(7)NA | x |
| x | x | |
Using Cisco 3600 and Cisco 2600 Series Routers as H.323 VoI P Gateways | 12.0(2)XD |
| x | x | x |
The Gatekeeper and proxy features apply to the following platforms:
The gateway features apply to the following platforms:
No new MIBs are supported by this feature. No RFCs are supported by this feature.
This feature provides support for the following ITU-T Recommendations:
Before you can use H.323 Version 2 Phase 2 features, you must:
The H.323 Version 2 Phase 2 configuration options allow you to configure the H.323 components discussed in the following sections:
Because Fast Connect is a H.323 Version 2 compliant feature and the majority of endpoints prefer to establish a call by using Fast Connect procedures, this feature is not configurable. H.323 Fast Connect does not require any additional configuration beyond a working voice configuration.
For more information about configuring voice ports, see "Configuring Voice Ports" in the Cisco IOS Release 12.0 Voice, Video, and Home Applications Configuration Guide.
The dtmf-relay command configured on the outgoing VoIP dial peer initiates H.245 tunneling procedures from a Fast Connect call. Note that H.245 tunneling will be activated only if dtmf-relay "h245-alpha" or "h245-signal" (but not "cisco-rtp") are configured on the VoIP dial peer.
How you configure a Cisco gateway for H.450 depends upon whether you want your gateway to:
Although there are no new CLI commands for configuring H.450 services, the services are enabled only when a TCL/IVR Session Application is configured. Therefore, to use H.450 services, you must configure a TCL/IVR-based "application" on each applicable incoming dial peer for each Cisco Gateway that will be involved in Call Transfer or Call Deflection. If no special TCL/IVR behavior is required, you can use the standard TCL/IVR application "session." This is not to be confused with application "SESSION," which is not TCL/IVR-based and does not support H.450 services.
In addition, if Call Deflection is to be initiated from a QSIG PRI, you must configure the PRI for "isdn switch-type primary-qsig" and "isdn alert end-to-end." See the examples that follow.
![]() |
Note For general information on configuring dial peer application and the meaning of incoming dial peer, please refer to Voice over IP for the Cisco AS5300 . |
An example configuration is shown in Figure 2.
In this example, three gateways are configured to redirect unanswered calls, so that when Party A calls Party B, Party B can invoke deflection to pass the call to Party C. For this to work, you must to configure "application session" or another TCL/IVR-based application on each applicable incoming dial peer as follows:
1. On Gateway A, the POTS dial peer for destination-pattern 8880000.
2. On Gateway B, the VoIP dial peer for destination-pattern 8880000.
3. On Gateway C, the VoIP dial peer for destination-pattern 8880000.
To configure Gateway A POTS dial peer, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | dial-peer voice 1 pots | Enter the dial-peer configuration mode to configure parameters for the specified Gateway A POTS dial peer. The specific dial peer is identified by tag number 1. |
Step 3 | application session | Specifies the application that will be invoked for this dial peer. Only TCL-based applications are able to support H.450 services. In this example, the standard TCL/IVR application session is indicated. |
Step 4 | destination-pattern 8880000 | Specifies the telephone number (E.164 or otherwise) associated with dial peer 1. |
Step 5 | port 1/1/0 | Specifies the voice slot number, subunit number, and port through which incoming VoIP calls will be received. |
Step 6 | exit | Exit the dial-peer configuration mode. |
To configure Gateway A global ISDN alert-end-to-end parameter, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | isdn alert-end-to-end | Configures Gateway ISDN interface such that an Alert message is not indicated until it has actually been received from the ISDN endpoint. The default Gateway behavior is to indicate Alert as soon as Call Proceeding has been received; the default setting could result in incorrect behavior by the Call Deflection service. |
Step 3 | exit | Exit configuration mode. |
To configure Gateway B VoIP peer, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | dial-peer voice 888 voip | Enter the dial-peer configuration mode to configure parameters for the specified Gateway B and C VOIP dial peer. The specific dial peer is identified by tag number 888. |
Step 3 | application session | Specifies the application that will be invoked for this dial peer. Only TCL-based applications are able to support H.450 services. In this example, the standard TCL/IVR application session is indicated. |
Step 4 | destination-pattern 8880000 | Specifies the telephone number (E.164 or otherwise) associated with dial peer 888. |
Step 5 | session target ipv4:1.1.1.1 | Specifies the IP address of the destination gateway for "outbound" dial peers. Because this is an "incoming" dial peer, the session target is not applicable, so the IP address is ignored. |
Step 6 | exit | Exit the dial-peer configuration mode. |
To configure Gateway B PRI, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | interface serial0:23 | Configure the serial interface. |
Step 3 | isdn switch-type primary-qsig | Configure the ISDN interface as a primary QSIG interface. |
Step 4 | exit | Exit the dial-peer configuration mode. |
To configure Gateway C VoIP dial peers, follow these steps:
| Step | Command | Purpose |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | dial-peer voice 888 voip | Enter the dial-peer configuration mode to configure parameters for the specified Gateway B and C VOIP dial peer. The specific dial peer is identified by tag number 888. |
Step 3 | application session | Specifies the application that will be invoked for this dial peer. Only TCL-based applications are able to support H.450 services. In this example, the standard TCL/IVR application session is indicated. |
Step 4 | destination-pattern 8880000 | Specifies the telephone number (E.164 or otherwise) associated with dial peer 888. |
Step 5 | session target ipv4:1.1.1.1 | Specifies the IP address of the destination gateway for "outbound" dial peers. Since this is an "incoming" dial peer, the session target is not applicable, so the IP address is ignored. |
Step 6 | exit | Exit the dial-peer configuration mode. |
An example configuration is shown in Figure 3.
In this example, two gateways are configured to handle call transfers without consultation, so that when Party A calls Party B at 555-3017 at Endpoint B, Endpoint B answers and then invokes Call Transfer to Party C. To do this, you must configure the application session or another TCL/IVR-based application on each applicable incoming dial peer as follows:
1. On Gateway A, the POTS dial peer for destination-pattern 8880000.
2. On Gateway C, the VoIP dial peer for destination-pattern 8880000.
To configure Gateway A POTS dial peer, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | dial-peer voice 1 pots | Enter the dial-peer configuration mode to configure parameters for the specified Gateway A POTS dial peer. The specific dial peer is identified by tag number 1. |
Step 3 | application session | Specifies the application that will be invoked for this dial peer. Only TCL-based applications are able to support H.450 services. In this example, the standard TCL/IVR application session is indicated. |
Step 4 | destination-pattern 8880000 | Specifies the telephone number (E.164 or otherwise) associated with dial peer 1. |
Step 5 | port 1/1/0 | Specifies the voice slot number, subunit number, and port through which incoming VoIP calls will be received. |
Step 6 | exit | Exit the dial-peer configuration mode. |
To configure Gateway C VoIP dial peer, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | configure terminal | Enter the global configuration mode. |
Step 2 | dial-peer voice 888 voip | Enter the dial-peer configuration mode to configure parameters for the specified Gateway C VOIP dial peer, which is identified by tag number 888. |
Step 3 | application session | Specifies the application that will be invoked for this dial peer. Only TCL-based applications are able to support H.450 services. In this example, the standard TCL/IVR application session is indicated. |
Step 4 | destination-pattern 8880000 | Specifies the telephone number (E.164 or otherwise) associated with dial peer 888. |
Step 5 | session target ipv4:1.1.1.1 | Specifies the IP address of the destination gateway for "outbound" dial peers. Because this is an "incoming" dial peer, the session target is not applicable, so the IP address is ignored. |
Step 6 | exit | Exit the dial-peer configuration mode. |
For more information about POTS dial peers, see Cisco IOS Release 12.0 Voice, Video, and Home Applications Configuration Guide.
For more information about any of the commands used to configure VoIP dial peers, see Cisco IOS Release 12.0 Voice, Video, and Home Applications Command Reference.
The voice-port description feature uses the existing description subcommand for the voice port. When you configure the voice-port description, the exact contents of the description field are included in the ARQ message sent from the ingress gateway.
![]() |
Note Configuring the voice-port description has no effect for calls that are not configured to use RAS. |
To configure the description on a voice-port, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | Router# config terminal | Enter global configuration mode. |
Step 2 | Router(config)# voice-port voice_port_ID | Enter voice-port configuration mode for the specified voice port. |
Step 3 | Router(config-voiceport)# description string | Defines the description associated with the voice-port. |
To configure the RADIUS/AAA server with information about the Gatekeeper for your network installation, follow these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# aaa new-model | Initiates the AAA script. |
Step 2 | Router(config)# aaa authentication login h323 group radius | Configures the router to use the H.323 method list for authentication purposes. |
Step 3 | Router(config)# radius-server deadtime seconds | Defines a threshold time in seconds until the router assumes the RADIUS server is dead. After 120 seconds, the router sends messages alerting an administrator about a security problem. |
Step 4 | Router(config)# radius-server host ip-address auth-port port-num acct-port port-num | Sets the server host IP address and the ports for both the authentication service and the accounting service. |
Step 5 | Router(config)# radius-server key testing123 | Configure the radius key secret. |
In addition to the above configuration, make sure that the following information is configured in your CiscoSecure AAA server:
#Client Name Key #----------- ------------------- gk215.cisco.com testing123
taeduk@cisco.com Password = "thiswouldbethepassword" User-Service-Type = Framed-User, Login-Service = Telnet
With this version of the Gatekeeper software, you can configure the Gatekeeper for interaction with external applications. Make sure that you include a priority value for selecting between multiple gateways when you configure the Gatekeeper. To configure the Gatekeeper, perform the tasks discussed in the following sections:
To put all your gateways in the same zone use the gw-priority argument and specify which gateways are used for calling different area codes. For example:
router(config-gk)# zone local localgk xyz.com router(config-gk)# zone prefix localgk 408....... router(config-gk)# zone prefix localgk 415....... gw-pri 10 gw1 gw2 router(config-gk)# zone prefix localgk 650....... gw-pri 0 gw1
In the above commands the following is accomplished:
There are two ways of configuring the Gatekeeper for interaction with an external application. You can configure a port number where the Gatekeeper listens for dynamic registrations from applications. Using this method, the application connects to the Gatekeeper and specifies the trigger conditions in which it is interested.
The second method involves using the CLI to statically configure the information about the application and its trigger conditions, in which case the Gatekeeper initiates a connection to the external application.
This configuration is for a Gatekeeper (sj.xyz.com) that uses port 20000 for a specific connection with an external server (Server-123). Server-123 has a number of triggers that are used to maintain a database of active gateways, which are used for active call resolution. The configuration is as follows:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# Gatekeeper | Access the Cisco IOS Gatekeeper configuration mode by entering the Gatekeeper command. |
Step 2 | Router(config)# server registration-port port-num | Establish the server registration port that is used for communication between sj.xyz.com and Server-123 by entering the server registration-port command. |
Server-123 establishes a connection with Gatekeeper sj.xyz.com on port 20000 and sends a REGISTER RRQ message to Gatekeeper sj.xyz.com to express interest in all RRQs from voice gateways that support a technology prefix of 1# or 2#.
The following is an example of a registration message:
REGISTER RRQ Version-id:1 From:Server-123 To:sj.xyz.com Priority:2 Notification-Only: Content-Length:29 t=voice-gateway p=1# p=2#
When Gatekeeper sj.xyz.com receives this message, the information supplied in the message is added to the trigger list. Then, when an endpoint registers with this Gatekeeper by using an RRQ that matches the specified trigger condition in the message, the Gatekeeper sends a notification to Server-123.
See the following example of an RRQ notification sent from the Gatekeeper to the server when the above trigger condition matches:
REQUEST RRQ Version-id:1 From:sj.xyz.com To:Server-123 Notification-Only: Content-Length:89 c=I:171.69.136.205:1720 r=I:171.69.136.205:16523 a=H:gw3-sj t=voice-gateway p=1# 2#
To establish statically configured triggers on a router, follow these general steps:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# Gatekeeper | Access the Cisco IOS Gatekeeper configuration mode by entering the Gatekeeper command. |
Step 2 | Router(config)# server trigger {arq | lcf | lrj | lrq | rrq | urq} gkid priority server-id server-ip_address server-port
| Enter the trigger configuration mode and specify the RAS message type for a trigger, enter the server trigger command. |
Step 3 | Router(config)# info-only | If the trigger is to end qualifying messages on a notification-only basis, enter the info-only command. |
Step 4 | Router(config)# destination-info {e164 | email-id | h323-id} value
| If you want to limit the qualifying message based upon the destination information, enter the destination-info command. Repeat this command for more destinations. |
Step 5 | Router(config)# redirect-reason value | If you want to limit the qualifying messages based upon the redirect reason, enter the redirect-reason command. Repeat this command for more destinations. |
Step 6 | Router(config)# remote-ext-address value | If you want to limit the qualifying messages based upon the remote extension address, enter the remote-ext-address command Repeat this command for more destinations. |
Step 7 | Router(config)# endpoint-type value | If you want to limit the qualifying messages based upon the endpoint type, enter the endpoint-type command. Repeat this command for more destinations. |
Step 8 | Router(config)# supported-prefix value | If you want to limit the qualifying messages based upon the supported prefix, enter the supported-prefix command. Repeat this command for more destinations. |
Step 9 | Router(config)# exit | When you have specified all the parameters for this trigger, exit trigger submode by entering the following command Repeat Steps 2 through 9 for each trigger that you want to define. |
To remove a trigger, enter the no server trigger command. To temporarily suspend a trigger, enter the trigger configuration mode, as described in step 2, and enter the shutdown subcommand.
The configuration examples for H.450 and the GKTMP Gatekeeper are described in the following sections:
This section documents new or modified commands for the Gatekeeper. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.
In Cisco IOS Release 12.0(1)T or later releases, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character ( | ), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expressionSee the following example of the show atm vc command where the command output begins with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRateFor more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module CLI String Search.
To configure the RAS messages so that the Gatekeeper checks for access tokens, enter the security token required-for command from the config-gk mode. To disable the Gatekeeper from checking for tokens in RAS messages, enter the no form of this command.
security token required-for {registration | all}Syntax Description
registration | Requires the registering gateway to send an access token in the registration request to the Gatekeeper. |
all | Requires the gateway to send an access token in registration and call setup messages to the Gatekeeper. |
Defaults
No access token is required for authentication if the Gatekeeper is configured.
Command Modes
Gatekeeper configuration mode
Command History
12.1(1)T This command was first introduced.
Release
Modification
Usage Guidelines
Use this command to configure the Gatekeeper to search for access tokens in RAS messages. These tokens are verified by an AAA server before the Gatekeeper responds. If you use the "registration" option, the Gatekeeper checks for tokens in all heavyweight RRQ messages. If you use the "all" option, the Gatekeeper also checks all ARQ messages---in addition to the RRQ messages.
By using the no option of the command the Gatekeeper stops checking for authentication tokens in RAS messages.
![]() |
Note When you use this command to configure the Gatekeeper to check for tokens in RAS messages, heavyweight ARQ and RRQ messages are not forwarded to an external application even if ARQ or RRQ trigger conditions are met. |
Examples
See the following example to configure a Gatekeeper to utilize an AAA server, enter the gateways that will be registering on the AAA security server, by entering the following commands:
Router# aaa new-model Router(config)#aaa authentication login h323 group radius Router(config)#radius-server deadtime 120 Router(config)#radius-server host 172.18.192.59 auth-port 1645 acct-port 1646 key lab
Related Commands
| Command | Description |
debug h225 ans1 | Shows additional information about contents of H.225 RAS messages. |
debug aaa auth | Shows information on AAA/TACACS+ authorization. |
debug ras | Shows the types of addressing for RAS messages sent and received. |
To configure the listener port for the server to establish a connection with the Gatekeeper, enter the server registration-port command from Gatekeeper mode. Enter the no form of this command to force the Gatekeeper to close the listening socket so that no more new registration takes place. However, existing connections between the Gatekeeper and the external applications are left open.
server registration-port port numberSyntax Description
port number | Specifies a single range of values from 1 through 65535 for the port number on which the Gatekeeper listens for external server connections |
Defaults
The registration port of the Gatekeeper is not configured, so no external server can register with this Gatekeeper.
Command Modes
Gatekeeper configuration mode
Command History
12.1(1)T This command was first introduced.
Release
Modification
Usage Guidelines
Use this command to configure a server registration port to poll for servers that want to establish connections with the Gatekeeper on this router.
![]() |
Note The no form of this command forces the Gatekeeper on this router to close the listen socket, so it cannot accept more registrations. However, existing connections between the Gatekeeper and servers are left open. |
Examples
See the following example of how a listener port for a server is established for connection with a Gatekeeper:
Router# server registration-port 20000
Related Commands
| Command | Description |
server trigger | Configure static server triggers for specific RAS messages to be forwarded to a specified server. |
To configure a static server trigger for external applications, enter the server trigger command from Gatekeeper mode. Enter the no form of this command to remove a single statically configured trigger entry. Enter the "all" form of the command to remove every static trigger you configured if you want to delete them all.
server trigger {arq | lcf | lrj | lrq | rrq | urq} gkid priority server-id server-ipaddress server-portSyntax Description
all | Specified to delete all CLI configured triggers. |
arq, lcf, lrj, lrq, rrq, urq | RAS message types. Use these message types to specify a submode in the Gatekeeper configuration mode where you configure a trigger for the Gatekeeper to act upon. Specify only one message type per server trigger command. There is a different trigger submode for each message type. Each trigger submode has its own set of applicable commands. |
gkid | The local Gatekeeper identifier. |
priority | The priority for each trigger. The range is from 1 through 20, with 1 being the highest priority. |
server-id | The external application's ID number. |
server-ipaddress | The server's IP address. |
server-port | The port on which the Cisco IOS Gatekeeper listens for messages from the external server connection. |
Defaults
No server triggers are set.
Command Modes
Configure from Gatekeeper mode.
Command History
12.1(1)T This command was first introduced.
Release
Modification
Usage Guidelines
Use this command to configure a static server trigger. There are six different server triggers---one for each of the RAS messages. To configure a trigger, go to its submode where a set of subcommands are used to trigger a condition. See the following examples.
In ARQ submode, enter the following syntax:
router(config-gk)#server trigger arq gkid priority
server-id server-ipaddress
server-port
router(config-gk-arqtrigg)#
In LCF submode, enter the following syntax:
router(config-gk)#server trigger lcf gkid priority
server-id server-ipaddress
server-port
router(config-gk-lcftrigg)#
In LRJ submode, enter the following syntax:
router(config-gk)#server trigger lrj gkid priority
server-id server-ipaddress
server-port
router(config-gk-lrjtrigg)#
In LRQ submode, enter the following syntax:
router(config-gk)#server trigger lrq <gkid> <priority>
<server-id> <server-ipaddress>
<server-port>
router(config-gk-lrqtrigg)#
In RRQ submode, enter the following syntax:
router(config-gk)#server trigger rrq gkid priority
server-id server-ipaddress
server-port
router(config-gk-rrqtrigg)#
In URQ submode, enter the following syntax:
router(config-gk)#server trigger urq gkid priority
server-id server-ipaddress
server-port
router(config-gk-urqtrigg)#
The following options are available in all submodes:
info-only | Information only---no need to wait for acknowledgement. |
shutdown | Enter this subcommand to temporarily disable a trigger. The Gatekeeper does not consult triggers in a shutdown state when determining what message to forward. |
The destination-info command is under the ARQ, LRQ, LCF, and LRJ submode and has the following options:
destination-info | Configure destination-info to trigger one of the following conditions: | |
| e164 | Configure an E.164 pattern. |
| email-id | Configure an email ID. |
| h323-id | Configure an H.323 ID. |
| word | When configuring the e164 address option, the email-id option, or the h323-id option above, the E.164 address can end in a trailing `., `s, or `*'. |
The redirect-reason command is under the ARQ and LRQ submodes and has the following options:
redirect-reason | Configure a redirect-reason to trigger on (range of 0 through 65535) with the following reserved values: | |
| 0 | Unknown reason. |
| 1 | Call forwarding busy or called DTE busy. |
| 2 | Call forwarded no reply. |
| 4 | Call deflection. |
| 9 | Called DTE out of order. |
| 10 | Call forwarding by the call DTE. |
| 15 | Call forwarding unconditionally. |
The remote-ext-address command is under the LCF trigger submode and has the following options:
remote-ext-address | Configure remote extension addresses, with the following options: | |
| e164 | Configure an E.164 pattern. |
| word | When configuring the e164 address option, the email-id option, or the h323-id option above, the E.164 address can end in a trailing `., `s, or `*'. |
The endpoint-type command is under the RRQ and URQ trigger submodes and has the following options:
endpoint-type | Configure the type of endpoint to trigger, with the following options: | |
| Gatekeeper | The endpoint is an H.323 Gatekeeper. |
| h320-gateway | The endpoint is an H.320 gateway. |
| mcu | The endpoint is a multipoint control unit (MCU). |
| other-gateway | The endpoint is another type of gateway not specified on this list. |
| proxy | The endpoint is a H.323 proxy. |
| terminal | The endpoint is an H.323 proxy. |
| voice-gateway | The endpoint is a voice gateway. |
The supported-prefix command is under the RRQ and URQ submodes and has the following options:
supported-prefix | Configure the gateway technology prefix to trigger on. | |
| word | Enter a word within the set of "0123456789#*" when configuring the E.164 pattern for a gateway technology prefix. |
Entering the no form of the server trigger command removes the trigger definition from the Cisco IOS Gatekeeper with all statically configured conditions under that trigger.
Examples
See the following example to configure a server trigger on Gatekeeper sj.xyz.com to notify external server "Server-123" of any call to an E.164 number that starts with 1800 followed by any 7 digits (1800551212, for example):
Router# Gatekeeper Router(config-gk)# server trigger arq sj.xyz.com 1 Server-123 1.14.93.130 1751 Router(config-gk-arqtrigg)#destination-info e164 1800....... Router(config-gk-arqtrigg)#exit
Related Commands
| Command | Description |
server registration port | Configure a Gatekeeper listening port to listen for external server connections. |
show Gatekeeper servers | Show a list of currently registered and statically configured triggers on this Gatekeeper router. |
Enter the timing hookflash-input command from privileged EXEC mode to specify the maximum duration of a hookflash for an FXS interface. Enter the no form of this command to restore the default duration for hookflash timing.
timing hookflash-input millisecondsSyntax Description
milliseconds | Specifies the duration of the hookflash. Possible values are 50 through 1550. |
Defaults
Default value is 600 milliseconds.
Command Modes
Privileged EXEC
Command History
12.1(1)T This command was introduced.
Release
Modification
Usage Guidelines
This command does not affect whether hookflash relay is enabled; hookflash relay is only enabled when dtmf-relay h245-signal is configured on the applicable VoIP dial peers. Hookflash is relayed by using an h245-signal indication and can be sent only when h245-signal is available.
Enter the timing hookflash-input command on FXS interfaces to specify the maximum duration (in milliseconds) of a hookflash indication. If the hookflash lasts longer than the specified limit, then the FXS interface processes the indication as an on-hook. To set hookflash timing parameters for analog voice interfaces, use the voice-port timing subcommand.
Examples
To implement timing for the hookflash with a duration of 200 milliseconds, see the following example:
Router# configure terminal Router(config)# voice-port 1/0/0 Router(config-voiceport)# timing hookflash-input 200
Related Commands
| Command | Description |
voice-port | Switch to the voice-port configuration mode from the global configuration mode. |
Enter the timing hookflash-output command to specify the duration of hookflash indications that the gateway generates on an FXO interface. Enter the no form of this command to restore the default duration for hookflash timing.
timing hookflash-output durationSyntax Description
milliseconds | Specifies the duration of the hookflash. Possible values are 50 through 1550. |
Defaults
Default value is 400 milliseconds.
Command Modes
Privileged EXEC
Command History
12.0(6)T This command was introduced. 12.1(1)T The default value was changed.
Release
Modification
Usage Guidelines
This command does not affect whether hookflash relay is enabled; hookflash relay is only enabled when dtmf-relay h245-signal is configured on the applicable VoIP dial peers. Hookflash is relayed by using an h245-signal indication and can be sent only when h245-signal is available
Enter the timing hookflash-output command on FXO interfaces to specify the duration (in milliseconds) of a hookflash indication. To set hookflash timing parameters for analog voice interfaces, use the voice-port timing subcommand.
Examples
To implement timing for the hookflash with a duration of 200ms, see the following example after you have configured voice-port 1/0/0:
Router# configure terminal Router(config)# voice-port 1/0/0 Router(config-voiceport)# timing hookflash-output 200
Related Commands
| Command | Description |
voice-port | Switch to the voice-port configuration mode from the global configuration mode. |
Enter the show Gatekeeper servers command to see a list of currently registered and statically configured triggers on this Gatekeeper router.
show Gatekeeper servers [ gkid ]Syntax Description
gkid | (Optional) The local Gatekeeper name to which this trigger applies. |
Command Modes
EXEC
Command History
12.0(6)T This command was introduced.
Release
Modification
Usage Guidelines
Enter this command to show all server triggers (whether dynamically registered from the external servers or statically configured from the command line interface) on this Gatekeeper. If gkid is specified, only triggers applied to the specified Gatekeeper zone appear. If gkid is not specified, server triggers for all local Gatekeeper zones on this router appear.
Examples
This example shows the operating information of the specified gk102 server:
Router# show Gatekeeper servers gk102
GATEKEEPER SERVERS STATUS
=========================
Gatekeeper Server listening port:20000
Gatekeeper-ID:gk102
--------------------
RRQ Priority:1
Server-ID:sj-server
Server IP address:1.14.93.28:42387
Server type:dynamically registered
Connection Status:active
Trigger Information:
Supported Prefix:10#
Supported Prefix:3#
RRQ Priority:2
Server-ID:sf-server
Server IP address:1.14.93.43:3820
Server type:CLI-configured
Connection Status:inactive
Trigger Information:
Endpoint-type:MCU
Endpoint-type:VOIP-GW
Supported Prefix:99#
ARQ Priority:1
Server-ID:sj-server
Server IP address:1.14.93.28:42387
Server type:dynamically registered
Connection Status:active
Trigger Information:
Destination Info:M:nilkant@zone14.com
Destination Info:E:1800.......
Redirect Reason:Call forwarded no reply
Redirect Reason:Call deflection
Related Commands
| Command | Description |
debug Gatekeeper server | Trace all the message exchanges between the Cisco IOS Gatekeeper and the external applications. I Show any errors that occur in sending messages to the external applications or in parsing messages from the external applications. |
Enter the debug Gatekeeper server command from EXEC mode to trace all the message exchanges between the Cisco IOS Gatekeeper and the external applications. Show any errors that occur in sending messages to the external applications or in parsing messages from the external applications. Enter the no form of this command to disable debugging output.
debug Gatekeeper serverSyntax Description
There are no arguments or keywords.
Defaults
Disabled.
Command Modes
EXEC
Command History
12.1(1)T This command was introduced.
Release
Modification
Usage Guidelines
Use this command to see information about a Gatekeeper server.
Examples
This example shows debugging information about a Gatekeeper server
Router# debug Gatekeeper servers Router# show debug Gatekeeper: Gatekeeper Server Messages debugging is on
To turn the Gatekeeper server debugging message off, see the following example:
Router# no debug all
or
Router# no debug Gatekeeper servers
Related Commands
| Command | Description |
show Gatekeeper server | Show information about the Gatekeeper servers configured on your network by ID. |
AAA---Authentication, authorization, and accounting. AAA is a suite of network security services that provides the primary framework through which access control can be set up on your Cisco router or access server.
CHAP---Challenge Handshake Authentication Protocol.
CODEC---Compression/decompression software.
DNS---Domain name system used in address translation to convert H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to locate remote Gatekeepers and to translate names of network nodes into IP addresses or host names of administrative domains.
DNIS---Dialed number identification service (the called number). Feature of trunk lines where the called number is identified; this called number information is used to route the call to the appropriate service.
DTMF---Dual tone multi-frequency.
E1---European digital carrier facility used for transmitting data through the telephone hierarchy. The transmission rate for E1 is 2.048 megabits per second (Mbps).
E.164---International Telecommunication Union (ITU-T) recommendation for international telecommunication numbering. This recommendation provides the number structure and functionality for the three categories of numbers used for international public telecommunication; geographic areas, global services, and networks.
E&M---rEceive and transMit, or Ear and Mouth. Type of signaling originally developed for analog two-state voltage telephony using the ear and mouth leads; in digital telephony, uses two bits.
endpoint---An H.323 terminal or gateway. An endpoint can call and be called. It generates or terminates the information stream.
ESF---Extended Superframe. Framing type used on T1 circuits that consists of 24 frames of 192 bits each, with the 193rd bit providing timing and other functions. ESF is an enhanced version of SF format.
FXO---Foreign Exchange Office. A voice interface emulating a PBX trunk line to a switch or telephone equipment to a PBX extension interface.
FXS---Foreign Exchange Station. A voice interface for connecting telephone equipment, which emulates the extension interface of a PBX or the subscriber interface for a switch.
Gatekeeper---An H.323 entity on the LAN that provides address translation and control access to the LAN for H.323 terminals and gateways. The Gatekeeper can provide other services to the H.323 terminals and gateways, such as bandwidth management and locating gateways. 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.
gateway---An H.323 endpoint on the LAN that provides real-time, two-way communication between H.323 terminals on the LAN, other ITU-T terminals in the WAN, or to another H.323 gateway. A gateway allows H.323 terminals to communicate with non-H.323 terminals by converting protocols. A gateway is the point where a circuit-switched call is encoded and repackaged into IP packets.
GKAPI---Gatekeeper Application Programming Interface.
GKTMP---Gatekeeper Transaction Message Protocol.
H.245---An ITU-T standard that describes H.245 endpoint control.
H.323---An 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.450.2---Call transfer supplementary service for H.323.
H.450.3---Call diversion supplementary service for H.323.
hookflash---A brief on-hook condition that occurs during a call. The on-hook condition is not long enough to be interpreted as a signal to disconnect the call. You can create a hookflash indication by quickly depressing and then releasing the hook on your telephone.
ICW---Internet call waiting service.
IVR---Interactive voice response. Term used to describe systems that provide information in the form of recorded messages over telephone lines in response to user input in the form of spoken words or more commonly DTMF signaling.
ITU-T---International Telecommunications Union-Telecommunication Standardization Sector.
OSP---Open Settlement Protocol.
packet---Logical grouping of information that includes a header containing control information and (usually) user data. Packets are most often used to refer to network layer units of data.
POTS---Plain old telephone service. Basic telephone service supplying standard single line telephones, telephone lines, and access to the Public Switched Telephone Network.
PSTN---Public Switched Telephone Network. General term referring to the variety of telephone networks and services in place worldwide.
Q.931---ITU-T specification for signaling to establish, maintain, and clear ISDN network connections.
QSIG---Q (point of the ISDN model) signaling. A common channel signaling protocol based upon ISDN Q.931 standards for digital PBXs.
RRQ---Registration Request RAS message. This message type is sent from an H.323 endpoint to an H.323 gateway.
RTP---Real Time Transport protocol. See RFC 1889.
SF---Super Frame. Common framing type used on T1 circuits. SF consists of 12 frames of 192 bits each with the 193rd bit providing error checking and other functions. SF is superseded by ESF, but is still widely used. Also called D4 framing.
T1---Digital WAN carrier facility. T1 transmits DS 1-formatted data at 1.544 Mbps through the telephone switching network by using alternate mark inversion or B8ZS coding.
T1 trunk---Digital WAN carrier facility. See T1.
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 that generally refers to Cisco's standards-based (for example, H.323) approach to IP voice traffic.
zone---A collection of all terminals, gateways, and multipoint control units (MCUs) managed by a single Gatekeeper. A zone has only one Gatekeeper, can be independent of LAN topology, and can comprise multiple LAN segments that are connected by using routers or other devices.
For a list of other internetworking terms, see Internetworking Terms and Acronyms that accompanied your access server and is available on the Documentation CD-ROM and Cisco Connection Online (CCO) at the following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Tue Apr 18 10:31:12 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.