-
Cisco IOS Voice Command Reference
-
About Cisco IOS Software Documentation
-
Using Cisco IOS Software
-
New and Modified Commands
-
Commands: A
-
Commands: B
-
Commands: cache --> call fallback jitter-probe num-packets
-
Commands: call fallback jitter-probe precedence --> ces connect
-
Commands: ces initial-delay --> codec preference
-
Commands: comfort-noise --> customer-id
-
Commands: default (MGCP profile) through direct-inward-dial
-
Commands: E
-
Commands: F
-
Commands: G
-
Commands: H
-
Commands: I
-
Commands: K
-
Commands: L
-
Commands: M
-
Commands: N
-
Commands: O
-
Commands: P through Q
-
Commands: R
-
Commands: SCCP through sgcp tse payload
-
Commands: show aal2 profile through show controllers timeslots
-
Commands: show controllers voice through show mgcp
-
Commands: show mgcp connection through show ss7 sm session
-
Commands: show ss7 sm set through shutdown (voice-port)
-
Commands: signal through suppress
-
Commands: T
-
Commands: U
-
Commands: V through W
-
Commands: Z
-
Feedback
Table Of Contents
session protocol (Voice over Frame Relay)
session target (MMoIP dial peer)
session target (POTS dial peer)
session target (VoATM dial peer)
session target (VoFR dial peer)
session target (VoIP dial peer)
sgcp quarantine-buffer disable
Cisco IOS Voice Commands:
S
This chapter contains commands to configure and maintain Cisco IOS voice applications. The commands are presented in alphabetical order. Some commands required for configuring voice may be found in other Cisco IOS command references. Use the command reference master index or search online to find these commands.
For detailed information on how to configure these applications and features, refer to the Cisco IOS Voice Configuration Guide.
sccp
To enable the Skinny Client Control Protocol (SCCP) protocol and its related applications (transcoding and conferencing), use the sccp command in global configuration mode. To disable the protocol, use the no form of this command.
sccp
no sccp
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
The router on which this command is used must be equipped with one or more digital T1/E1 packet voice trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms (NM-HDV-FARMs) to provide digital-signal-processor (DSP) resources.
SCCP and its related applications (transcoding and conferencing) become enabled only if digital-signal-processor (DSP) resources for these applications are configured, DSP-farm service is enabled, and the Cisco CallManager registration process is completed.
The no form of this command disables SCCP and its applications by unregistering from the active Cisco CallManager, dropping existing connections, and freeing allocated resources.
Examples
The following example sets related values and then enables SCCP:
Router(config)# sccp ccm 10.10.10.1 priority 1Router(config)# sccp local fastEthernet 0/0Router(config)# sccp switchback timeout guard 180Router(config)# sccp ip precedence 5Router(config)# sccpRouter(config)# endRelated Commands
sccp ccm
To add a Cisco CallManager server to the list of available servers and set various parameters—including address or Domain Name System (DNS) name, priority if more than one server is available, port number, and version number— use the sccp ccm command in global configuration mode. To remove a particular server from the list, use the no form of this command.
sccp ccm {ip-address | dns} priority priority [port port-number] {version 3.0 | 3.1+}
no sccp ccm {ip-address | dns} priority priority port port-number {version 3.0 | 3.1+}
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Command History
Usage Guidelines
The router on which this command is used must be equipped with one or more digital T1/E1 packet voice trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms (NM-HDV-FARMs) to provide digital-signal-processor (DSP) resources.
You can configure up to four Cisco CallManager systems—a primary and up to three backups—to support digital-signal-processor (DSP) farm services.
Examples
The following example configures the Cisco CallManager whose IP address is 10.0.0.0:
Router# sccp ccm 10.0.0.0 priority 1 port 1025 version 3.1+Related Commands
sccp ip precedence
To set the IP precedence value to be used by Skinny Client Control Protocol (SCCP), use the sccp ip precedence command in global configuration mode. To reset to the default, use the no form of this command.
sccp ip precedence value
no sccp ip precedence
Syntax Description
Defaults
5
Command Modes
Global configuration
Command History
Usage Guidelines
The router on which this command is used must be equipped with one or more digital T1/E1 packet voice trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms (NM-HDV-FARMs) to provide digital-signal-processor (DSP) resources.
Examples
The following example sets IP precedence to the highest possible value:
Router# sccp ip precedence 1Related Commands
sccp local
To select the local interface that the Skinny Client Control Protocol (SCCP) applications (transcoding and conferencing) should use to register with Cisco CallManager, use the sccp local command in global configuration mode. To deselect the interface, use the no form of this command.
sccp local interface-type interface-number
no sccp local interface-type interface-number
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Command History
Usage Guidelines
The router on which this command is used must be equipped with one or more digital T1/E1 packet voice trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms (NM-HDV-FARMs) to provide digital-signal-processor (DSP) resources.
Examples
The following example selects an Ethernet interface for the SCCP applications to use to register with Cisco CallManager:
Router# sccp local Ethernet 1Related Commands
sccp switchback timeout guard
To set the Skinny Client Control Protocol (SCCP) switchback guard timer, use the sccp switchback timeout guard command in global configuration mode. To reset to the default, use the no form of this command.
sccp switchback timeout guard seconds
no sccp switchback timeout guard
Syntax Description
Defaults
1200 seconds
Command Modes
Global configuration
Command History
Usage Guidelines
The router on which this command is used must be equipped with one or more digital T1/E1 packet voice trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms (NM-HDV-FARMs) to provide digital-signal-processor (DSP) resources.
You can use the guard timer value for the switchback algorithm that follows the Graceful Timer method.
Examples
The following example sets the switchback guard timer value to 180 seconds (3 minutes):
Router# sccp switchback timeout guard 180Related Commands
sctp
To enter the Stream Control Transmission Protocol (SCTP) configuration, use the sctp command in IDSN User Adaptation Layer (IUA) configuration mode. To disable, use the no form of this command.
sctp [[t1-init milliseconds][t3-rtx-min seconds][t3-rtx-max milliseconds][startup-rtx number][assoc-rtx number][path-rtx number]]
no sctp
Syntax Description
Defaults
No default behavior or values.
Command Modes
IUA configuration
Command History
Usage Guidelines
To enter SCTP configuration commands, you must first enter IUA configuration mode and then enter sctp at the Router(config-iua)# prompt to enter SCTP configuration mode.
Examples
The following example shows how to enter IUA configuration mode:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# iuaRouter(config-iua)#The following is an example of how to set failover time (in milliseconds) between 1 and 10 seconds as part of SCTP configuration of the T1 initiation timer. This example uses the lowest failover timer value allowed (1 second):
Router(config-iua)# as as5400-3 fail-over 1000The following is an example of how to set SCTP maximum startup retransmission interval. This example uses the maximum startup retransmission interval value allowed:
Router(config-iua)# as as5400-3 sctp-startup 20The following is an example of how to configure the number of SCTP streams for this AS. This example uses the maximum SCTP streams allowed:
Router(config-iua)# as as5400-3 sctp-streams 57The following is an example of how to configure the SCTP T1 initiation timer (in milliseconds). This example uses the maximum timer value allowed:
Router(config-iua)# as as5400-3 sctp-t1init 60000Related Commands
security
To enable authentication and authorization on a gatekeeper, use the security command in gatekeeper configuration mode. To disable security, use the no form of this command.
security {any | h323-id | e164} {password default password | password separator character}
no security {any | h323-id | e164} {password default password | password separator character}
Syntax Description
Defaults
No default
Command Modes
Gatekeeper configuration
Command History
11.3(2)NA
This command was introduced on the Cisco 2600 series and Cisco 3600 series.
Usage Guidelines
Use this command to enable identification of registered aliases by RADIUS/TACACS+. If the alias does not exist in RADIUS/TACACS+, the endpoint is not allowed to register.
A RADIUS/TACACS+ server and encryption key must have been configured in Cisco IOS software for security to work.
Only the first alias of the proper type is identified. If no alias of the proper type is found, the registration is rejected.
This command does not allow you to define the password mechanism unless the security type (h323-id or e164 or any) has been defined. Although the no security password command undefines the password mechanism, it leaves the security type unchanged, so security is still enabled. However, the no security command disables security entirely, including removing any existing password definitions.
Examples
The following example enables identification of registrations using the first H.323 ID found in any registration:
security h323idThe following example enables security, authenticating all users by using their H.323-IDs and a password of qwerty2x:
security h323-idsecurity password qwerty2xThe next example enables security, authenticating all users by using their H.323-IDs and the password entered by the user in the H.323-ID alias he or she registers:
security h323-idsecurity password separator !Now if a user registers with an H.323-ID of joe!024aqx, the gatekeeper authenticates user joe with password 024aqx, and if that is successful, registers the user with the H.323-ID of joe. If the exclamation point is not found, the user is authenticated with the default password, or a null password if no default has been configured.
The following example enables security, authenticating all users by using their E.164 IDs and the password entered by the user in the H.323-ID alias he or she registers:
security e164security password separator !Now if a user registers with an E.164 address of 5551212 and an H.323-ID of !hs8473q6, the gatekeeper authenticates user 5551212 and password hs8473q6. Because the H.323-ID string supplied by the user begins with the separator character, no H.323-ID is registered, and the user is known only by the E.164 address.
Related Commands
security acl answerarq
To configure the gatekeeper to use tokenless call authorization, use the security acl answerarq command in gatekeeper configuration mode. To disable, use the no form of this command.
security acl answerarq access-list-number
no security acl answerarq access-list-number
Syntax Description
Defaults
By default, tokenless call authorization is not configured.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command in conjunction with the access-list command to configure tokenless call authorization on a gatekeeper. The IP access list contains endpoints that are not in the gatekeeper's administrative domain, but from which calls should be accepted. This command configures the gatekeeper to use the IP access list for security.
Examples
The following example shows how to configure a gatekeeper to use a previously configured IP access list with an IP access list number of 20 for call authorization:
Router(config-gk)# security acl answerarq 20Related Commands
access-list
Configures the access list mechanism for filtering frames by protocol type or vendor code.
sequence-numbers
To enable the generation of sequence numbers in each frame generated by the digital signal processor (DSP) for Voice over Frame Relay applications, use the sequence-numbers command in dial-peer configuration mode. To disable the generation of sequence numbers, use the no form of this command.
sequence-numbers
no sequence-numbers
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Dial-peer configuration
Command History
12.0(3)XG
This command was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco MC3810.
12.0(4)T
This command was integrated into Cisco IOS Release 12.0(4)T.
Usage Guidelines
Sequence numbers on voice packets allow the digital signal processor (DSP) at the playout side to detect lost packets, duplicate packets, or out-of-sequence packets. This helps the DSP to mask out occasional drop-outs in voice transmission at the cost of one extra byte per packet. The benefit of using sequence numbers versus the cost in bandwidth of adding an extra byte to each voice packet on the Frame Relay network must be weighed to determine whether to disable this function for your application.
Another factor to consider is that this command does not affect codecs that require a sequence number, such as G.726. If you are using a codec that requires a sequence number, the DSP generates one regardless of the configuration of this command.
Examples
The following example disables generation of sequence numbers for VoFR frames on a Cisco 2600 series or Cisco 3600 series router or on a Cisco MC3810 for VoFR dial peer 200, starting from global configuration mode:
dial-peer voice 200 vofrno sequence-numbersRelated Commands
server (RLM)
To identify an RLM server, use the server RLM configuration command. To remove the identification, use the no form of this command
server name-tag
no server name-tag
Syntax Description
name-tag
Name to identify the server configuration so that multiple entries of server configuration can be entered.
Defaults
Disabled
Command Modes
RLM configuration
Command History
Usage Guidelines
Each server can have multiple entries of IP addresses or aliases.
Examples
The following example identifies the RLM server and defines the associated IP addresses:
rlm group 1
server r1-server
link address 10.1.4.1 source Loopback1 weight 4
link address 10.1.4.2 source Loopback2 weight 3
Related Commands
server absent reject
To configure the gatekeeper to reject new registrations or calls when the connection to the Gatekeeper Transaction Message Protocol (GKTMP) server is down, use the server absent reject command in gatekeeper configuration mode. To disable, use the no form of this command.
server absent reject {arq | rrq}
no server absent reject {arq | rrq}
Syntax Description
Defaults
By default, registrations and calls are not rejected.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
This command configures the gatekeeper to reject new registrations or calls when it is unable to reach the GKTMP server because the TCP connection between the gatekeeper and GKTMP server is down. If multiple GKTMP servers are configured, the gatekeeper tries all of them and rejects registrations or calls only if none of the servers respond. You can also use this feature for security or service denial if a connection with the server is required to complete a registration.
Note
This command assumes that RRQ and ARQ triggers are used between the gatekeeper and GKTMP server.
Examples
The following example directs the gatekeeper to reject registrations when it cannot connect to the GKTMP server:
Router# show gatekeeper configuration...h323id tetgw-type-prefix 1#* default-technologygw-type-prefix 9#* gw ipaddr 1.1.1.1 1720no shutdownserver absent reject rrq...server flow-control
To enable flow control on the Cisco IOS gatekeeper (GK) and reset all thresholds to default, use the server flow-control command in gatekeeper configuration mode. To disable GK flow control, use the no form of this command.
server flow-control [onset value] [abatement value] [qcount value]
no server flow-control
Syntax Description
Defaults
Onset: 80
Abatement: 50
Qcount: 50Command Modes
Gatekeeper configuration
Command History
12.2(2)XB
This command was introduced.
12.2(8)T
This command was integrated into Cisco IOS Release 12.2(8)T.
Usage Guidelines
Suppose the server timeout value is 3 seconds, the onset value is 50, and the abatement value is 40. When the average response time from the server to the Gatekeeper Transaction Message Protocol (GKTMP) reaches 1.5 seconds (the onset percentage of the server timeout value), the server is marked as unusable. During the period that the server is marked as unusable, REQUEST ALV messages are still sent to the unusable server. When the response time is lowered to 1.2 seconds (the abatement percentage of the timeout value), the server is marked usable again, and the GKTMP resumes sending messages to the server.
If you change one parameter using the server flow-control command, all other parameters revert to the default values. For example, if the onset is configured at 70 percent and you use the server flow-control command to set the abatement level, the onset resets to the default (80 percent).
Examples
The following example uses the command with the default values:
Router# server flow-controlThe following example enables the GKTMP Interface Resiliency Enhancement feature with an onset level of 50:
Router# server flow-control onset 50*Mar 8 20:05:34.081: gk_srv_handle_flowcontrol: Flow control enabledRouter# show running-configBuilding configuration...Current configuration : 1065 bytes!version 12.2no service single-slot-reload-enableservice timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!hostname snet-3660-3!...gatekeeperzone local snet-3660-3 cisco.comzone remote snet-3660-2 cisco.com 209.165.200.225 1719zone prefix snet-3660-2 408*lrq forward-queriesno use-proxy snet-3660-3 default inbound-to terminalno use-proxy snet-3660-3 default outbound-from terminalno shutdownserver registration-port 8000server flow-control onset 50!...endThe following example enables the GKTMP Interface Resiliency Enhancement feature:
Router# show gatekeeper statusGatekeeper State: UPLoad Balancing: DISABLEDFlow Control: ENABLEDZone Name: snet-3660-3Accounting: DISABLEDEndpoint Throttling: DISABLEDSecurity: DISABLEDMaximum Remote Bandwidth: unlimitedCurrent Remote Bandwidth: 0 kbpsCurrent Remote Bandwidth (w/ Alt GKs): 0 kbpsThe following example shows the server statistics, including timeout encountered, average response time, and the server status:
Router# show gatekeeper serverGATEKEEPER SERVERS STATUS=========================Gatekeeper Server listening port: 8250Gatekeeper Server timeout value: 30 (100ms)GateKeeper GKTMP version: 3.1Gatekeeper-ID: Gatekeeper1------------------------RRQ Priority: 5Server-ID: Server43Server IP address: 209.165.200.254:40118Server type: dynamically registeredConnection Status: activeTrigger Information:Trigger unconditionallyServer Statistics:REQUEST RRQ Sent=0RESPONSE RRQ Received = 0RESPONSE RCF Received = 0RESPONSE RRJ Received = 0Timeout encountered=0Average response time(ms)=0Server Usable=TRUERelated Commands
timer server timeout
Specifies the timeout value for a response from a back-end GKTMP server.
server registration-port
To configure the listener port for the server to establish a connection with the gatekeeper, use the server registration-port command in gatekeeper configuration mode. To force the gatekeeper to close the listening socket so that no more new registration takes place, use the no form of this command.
server registration-port port-number
no server registration-port port-number
Syntax Description
port-number
Port number on which the gatekeeper listens for external server connections. Range is from 1 to 65535. There is no default.
Defaults
No registration port is configured.
Note
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command to configure a server registration port to poll for servers that want to establish connections with the gatekeeper.
Note
Examples
The following example establishes a listener port for a server connection with a gatekeeper:
Router(config)# gatekeeperRouter(config-gk)# server registration-port 20000Related Commands
server routing
To specify the type of circuit messages sent to the Gatekeeper Transaction Message Protocol (GKTMP) server, use the server routing command in gatekeeper configuration mode. To return to the default, use the no form of this command.
server routing {both | carrier | trunk-group}
no server routing {both | carrier | trunk-group}
Syntax Description
Defaults
Carrier
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command to route carrier and trunk-group messages from the gatekeeper to the GKTMP server.
The carrier keyword sends the "I" and "J" tags in the GKTMP messages. The trunk-group keyword sends the "P" and "Q" tags in the GKTMP messages. The both keyword sends both sets of tags.
Examples
The following example enables trunk-group information to be sent in GKTMP messages from the gatekeeper:
Router(config)# gatekeeperRouter(config-gk)# server routing trunk-groupRelated Commands
server trigger arq
To configure the admission request (ARQ) trigger statically on the gatekeeper, use the server trigger arq command in gatekeeper configuration mode. Submode commands are available after the server trigger arq command is entered. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of this command.
server trigger arq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} value
redirect-reason reason-numberno server trigger arq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the admission request (ARQ) static server trigger. The gatekeeper checks incoming gateway ARQ messages for the configured trigger information. If an incoming ARQ message contains the specified trigger information, the gatekeeper sends the ARQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the ARQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the ARQ messages, the gatekeeper sends all ARQ messages to the GKTMP server application.
If the gatekeeper receives an ARQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming ARQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two ARQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two ARQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming ARQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one ARQ trigger registration message with the same priority but for different GKTMP servers, the gatekeeper retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all ARQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger arq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_arqtrigger)# exitThe following example configures an ARQ trigger registration on gatekeeper "alpha", which sends to GKTMP server "Server-west" any ARQ message that contains H.323 ID "3660-gw1", e-mail ID "joe.xyz.com", or a redirect reason 1. All other ARQ messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger arq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-arqtrigger)# destination-info h323-id 3660-gw1Router(config-gk-arqtrigger)# destination-info email-id joe.xyz.comRouter(config-gk-arqtrigger)# redirect-reason 1Router(config-gk-arqtrigger# exitIf the ARQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger arq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_arqtrigger)# destination-info e164 1800....Router(config-gk_arqtrigger)# exitThen gatekeeper "alpha" checks all incoming ARQ messages for the destination H.323 ID, e-mail ID, or redirect reason before checking for the E.164 address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the ARQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" ARQ trigger registration had been defined with a priority 1 instead of priority 2, the second server trigger definition would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those ARQ messages that contain a destination E.164 address that starts with 1800. All other ARQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger brq
To configure the bandwidth request (BRQ) trigger statically on the gatekeeper, use the server trigger brq command in gatekeeper configuration mode. Submode commands are available after entering the server trigger brq command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger brq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
redirect-reason reason-numberno server trigger brq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the bandwidth request (BRQ) static server trigger. The gatekeeper checks incoming gateway BRQ messages for the configured trigger information. If an incoming BRQ message contains the specified trigger information, the gatekeeper sends the BRQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the BRQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the BRQ messages, the gatekeeper sends all BRQ messages to the GKTMP server application.
If the gatekeeper receives BRQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming BRQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two BRQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two BRQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming BRQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one BRQ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all BRQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger brq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_brqtrigger)# exitThe following example configures BRQ trigger registration on gatekeeper "alpha", which sends to GKTMP server "Server-west" any BRQ message containing redirect reason 1 or redirect reason 2. All other BRQ messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger brq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-brqtrigger)# redirect-reason 1Router(config-gk-brqtrigger)# redirect-reason 2Router(config-gk-brqtrigger# exitIf the BRQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger brq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_brqtrigger)# redirect-reason 10Router(config-gk_brqtrigger)# exitThen gatekeeper "alpha" checks all incoming BRQ messages for redirect reasons 1 or 2 before checking for redirect reason 10. If any one of those conditions is met, the gatekeeper sends the BRQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" BRQ trigger registration had been defined with a priority 1 instead of priority 2, then the second server trigger definition would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those BRQ messages that contain a redirect reason 10. All other BRQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger drq
To configure the disengage request (DRQ) trigger statically on the gatekeeper, use the server trigger drq command in gatekeeper configuration mode. Submode commands are available after entering the server trigger drq command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger drq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} valueno server trigger drq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the disengage request (DRQ) static server trigger. The gatekeeper checks incoming gateway DRQ messages for the configured trigger information. If an incoming DRQ message contains the specified trigger information, the gatekeeper sends the DRQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the DRQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the DRQ messages, the gatekeeper sends all DRQ messages to the GKTMP server application.
If the gatekeeper receives DRQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming DRQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two DRQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two DRQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming DRQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one DRQ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all DRQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger drq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_drqtrigger)# exitThe following example configures DRQ trigger registration on gatekeeper "alpha", which sends to GKTMP server "Server-west" any DRQ message containing an H.323 ID "3660-gw1" or e-mail ID "joe.xyz.com". All other DRQ messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger drq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-drqtrigger)# destination-info h323-id 3660-gw1Router(config-gk-drqtrigger)# destination-info email-id joe.xyz.comRouter(config-gk-drqtrigger# exitIf the DRQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger drq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_drqtrigger)# destination-info e164 1800....Router(config-gk_drqtrigger)# exitthen gatekeeper "alpha" checks all incoming DRQ messages for the destination H.323 ID or e-mail ID before checking for the E.164 address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the DRQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" DRQ trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server Server-west only those DRQ messages that contain a destination E.164 address starting with 1800. All other DRQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger irr
To configure the information request response (IRR) trigger statically on the gatekeeper, use the server trigger irr command in gatekeeper configuration mode. Submode commands are available after entering the server trigger irr command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger irr gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} value
redirect-reason reason-numberno server trigger irr gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the information request response (IRR) static server trigger. The gatekeeper checks incoming gateway IRR messages for the configured trigger information. If an incoming IRR message contains the specified trigger information, the gatekeeper sends the IRR message to the GKTMP server application. In addition, the IRR message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the IRR messages, the gatekeeper sends all IRR messages to the GKTMP server application.
If the gatekeeper receives an IRR trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming IRR RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two IRR trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two IRR trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming IRR messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one IRR trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all IRR messages to GKTMP server "Server-123":
Router(config-gk)# server trigger irr sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_irrtrigger)# exitThe following example configures an IRR trigger registration on gatekeeper "alpha", which send to GKTMP server "Server-west" any IRR message containing an H.323 ID "3660-gw1", e-mail ID "joe.xyz.com, or a redirect reason 1. All other IRR messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger irr alpha 1 Server-west 10.10.10.10 1751Router(config-gk-irrtrigger)# destination-info h323-id 3660-gw1Router(config-gk-irrtrigger)# destination-info email-id joe.xyz.comRouter(config-gk-irrtrigger)# redirect-reason 1Router(config-gk-irrtrigger# exitIf the IRR registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger irr alpha 2 Server-west 10.10.10.10 1751Router(config-gk_irrtrigger)# destination-info e164 1800....Router(config-gk_irrtrigger)# exitThen gatekeeper "alpha" checks all incoming IRR messages for the destination H.323 ID, e-mail ID, or redirect reason before checking for the E.164 address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the IRR message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" IRR trigger registration had been defined with a priority 1 instead of priority 2, then the second server trigger definition would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those IRR messages that contain a destination E.164 address starting with 1800. All other IRR messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger lcf
To configure the location confirm (LCF) trigger statically on the gatekeeper, use the server trigger lcf command in gatekeeper configuration mode. Submode commands are available after entering the server trigger lcf command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger lcf gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} value
remote-ext-address e164 valueno server trigger lcf gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the RAS message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the location confirm (LCF) static server trigger. The gatekeeper checks incoming gateway LCF messages for the configured trigger information. If an incoming LCF message contains the specified trigger information, the gatekeeper sends the LCF message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the LCF message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the LCF messages, the gatekeeper sends all LCF messages to the GKTMP server application.
If the gatekeeper receives an LCF trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming LCF RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two LCF trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two LCF trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming LCF messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one LCF trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all LCF messages to GKTMP server "Server-123":
Router(config-gk)# server trigger lcf sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_lcftrigger)# exitThe following example configures an LCF trigger registration on gatekeeper "alpha", which send to GKTMP server "Server-west" any LCF message containing an H.323 ID "3660-gw1", e-mail ID joe.xyz.com, or a remote extension address starting with 1408. All other LCF messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger lcf alpha 1 Server-west 10.10.10.10 1751Router(config-gk-lcftrigger)# destination-info h323-id 3660-gw1Router(config-gk-lcftrigger)# destination-info email-id joe.xyz.comRouter(config-gk-lcftrigger)# remote-ext-address e164 1408....Router(config-gk-lcftrigger# exitIf the LCF registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger lcf alpha 2 Server-west 10.10.10.10 1751Router(config-gk_lcftrigger)# remote-ext-address e164 1800....Router(config-gk_lcftrigger)# exitthen gatekeeper "alpha" checks all incoming LCF messages for the destination H.323 ID, e-mail ID, or remote extension address 1408 before checking for the remote extension address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the LCF message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" LCF trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those LCF messages that contain a remote extension address E.164 address starting with 1800. All other LCF messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger lrj
To configure the location reject (LRJ) trigger statically on the gatekeeper, use the server trigger lrj command in gatekeeper configuration mode. Submode commands are available after entering the server trigger lrj command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger lrj gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} valueno server trigger lrj gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the location reject (LRJ) static server trigger. The gatekeeper checks incoming gateway LRJ messages for the configured trigger information. If an incoming LRJ message contains the specified trigger information, the gatekeeper sends the LRJ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the LRJ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the LRJ messages, the gatekeeper sends all LRJ messages to the GKTMP server application.
If the gatekeeper receives an LRJ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming LRJ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two LRJ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two LRJ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming LRJ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one LRJ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all LRJ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger lrj sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_lrjtrigger)# exitThe following example configures an LRJ trigger registration on gatekeeper "alpha", which send to GKTMP server "Server-west" any LRJ message containing an H.323 ID "3660-gw1" or e-mail ID joe.xyz.com. All other LRJ messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger lrj alpha 1 Server-west 10.10.10.10 1751Router(config-gk-lrjtrigger)# destination-info h323-id 3660-gw1Router(config-gk-lrjtrigger)# destination-info email-id joe.xyz.comRouter(config-gk-lrjtrigger# exitIf the LRJ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger lrj alpha 2 Server-west 10.10.10.10 1751Router(config-gk_lrjtrigger)# destination-info e164 1800....Router(config-gk_lrjtrigger)# exitthen gatekeeper "alpha" checks all incoming LRJ messages for the destination H.323 ID or email ID before checking for the E.164 address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the LRJ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" LRJ trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those LRJ messages that contain a destination E.164 address starting with 1800. All other LRJ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger lrq
To configure the location request (LRQ) trigger statically on the gatekeeper, use the server trigger lrq command in gatekeeper configuration mode. Submode commands are available after entering the server trigger lrq command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger lrq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
destination-info {e164 | email-id | h323-id} value
redirect-reason reason-numberno server trigger lrq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the location request (LRQ) static server trigger. The gatekeeper checks incoming gateway LRQ messages for the configured trigger information. If an incoming LRQ message contains the specified trigger information, the gatekeeper sends the LRQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the LRQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the LRQ messages, the gatekeeper sends all LRQ messages to the GKTMP server application.
If the gatekeeper receives an LRQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming LRQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two LRQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two LRQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming LRQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one LRQ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all LRQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger lrq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_lrqtrigger)# exitThe following example configures an LRQ trigger registration on gatekeeper "alpha", which sends to GKTMP server "Server-west" any LRQ message containing an H.323 ID "3660-gw1", e-mail ID joe.xyz.com, or a redirect reason 1. Other LRQ messages are not sent to the GKTMP server application.
Router(config-gk)# server trigger lrq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-lrqtrigger)# destination-info h323-id 3660-gw1Router(config-gk-lrqtrigger)# destination-info email-id joe.xyz.comRouter(config-gk-lrqtrigger)# redirect-reason 1Router(config-gk-lrqtrigger# exitIf the LRQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger lrq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_lrqtrigger)# destination-info e164 1800....Router(config-gk_lrqtrigger)# exitthen gatekeeper "alpha" checks all incoming LRQ messages for the destination H.323 ID, email ID, or redirect reason before checking for the E.164 address 1800 (for example, 18005551212). If any one of those conditions is met, the gatekeeper sends the LRQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" LRQ trigger registration had been defined with a priority 1 instead of priority 2, then the second server trigger definition would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those LRQ messages that contain a destination E.164 address starting with 1800. All other LRQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger rai
To configure the resources available indicator (RAI) trigger statically on the gatekeeper, use the server trigger rai command in gatekeeper configuration mode. Submode commands are available after entering the server trigger rai command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger rai gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
endpoint-type value
supported-prefix valueno server trigger rai gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the resources available indicator (RAI) static server trigger. The gatekeeper checks incoming gateway RAI messages for the configured trigger information. If an incoming RAI message contains the specified trigger information, the gatekeeper sends the RAI message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the RAI message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the RAI messages, the gatekeeper sends all RAI messages to the GKTMP server application.
If the gatekeeper receives an RAI trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming RAI RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two RAI trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two RAI trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming RAI messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one RAI trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all RAI messages to GKTMP server "Server-123":
Router(config-gk)# server trigger rai sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_raitrigger)# exitThe following example configures an RAI trigger registration on gatekeeper "alpha", which sends to the GKTMP server "Server-west" any RAI message that contain an MCU endpoint, an H.323 proxy endpoint, or a supported prefix 1#. All other RAI messages are not sent to the GKTMP server.
Router(config-gk)# server trigger rai alpha 1 Server-west 10.10.10.10 1751Router(config-gk-raitrigger)# endpoint-type mcuRouter(config-gk-raitrigger)# endpoint-type proxyRouter(config-gk-raitrigger)# supported-prefix 1#Router(config-gk-raitrigger# exitIf the RAI registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger rai alpha 2 Server-west 10.10.10.10 1751Router(config-gk_raitrigger)# supported-prefix 1234*Router(config-gk_raitrigger)# exitThen gatekeeper "alpha" checks all incoming RAI messages for the MCU or H.323 proxy endpoint or the supported prefix 1# before checking for the supported prefix 1234*. If any one of those conditions is met, the gatekeeper sends the RAI message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" RAI trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those RAI messages that contain a supported prefix of 1234*. All other RAI messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger rrq
To configure the registration request (RRQ) trigger statically on the gatekeeper, use the server trigger rrq command in gatekeeper configuration mode. Submode commands are available after entering the server trigger rrq command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger rrq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
endpoint-type value
supported-prefix valueno server trigger rrq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the registration request (RRQ) static server trigger. The gatekeeper checks incoming gateway RRQ messages for the configured trigger information. If an incoming RRQ message contains the specified trigger information, the gatekeeper sends the RRQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the RRQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the RRQ messages, the gatekeeper sends all RRQ messages to the GKTMP server application.
If the gatekeeper receives an RRQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming RRQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two RRQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two RRQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming RRQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one RRQ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all RRQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger rrq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_rrqtrigger)# exitThe following example configures an RRQ trigger registration on gatekeeper "alpha", which sends to the GKTMP server "Server-west" any RRQ message containing an MCU endpoint, an H.323 proxy endpoint, or a supported prefix 1#. Other RRQ messages are not sent to the GKTMP server.
Router(config-gk)# server trigger rrq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-rrqtrigger)# endpoint-type mcuRouter(config-gk-rrqtrigger)# endpoint-type proxyRouter(config-gk-rrqtrigger)# supported-prefix 1#Router(config-gk-rrqtrigger# exitIf the RRQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger rrq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_rrqtrigger)# supported-prefix 1234*Router(config-gk_rrqtrigger)# exitthen gatekeeper "alpha" checks all incoming RRQ messages for the MCU or H.323 proxy endpoint or the supported prefix 1# before checking for the supported prefix 1234*. If any one of those conditions is met, the gatekeeper sends the RRQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" RRQ trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those RRQ messages that contain a supported prefix of 1234*. All other RRQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
server trigger urq
To configure the unregistration request (URQ) trigger statically on the gatekeeper, use the server trigger urq command in gatekeeper configuration mode. Submode commands are available after entering the server trigger urq command. To delete a single static trigger on the gatekeeper, use the no form of this command. To delete all static triggers on the gatekeeper, use the all form of the command.
server trigger urq gkid priority server-id server-ip-address server-port
Submode Commands:
info-only
shutdown
endpoint-type value
supported-prefix valueno server trigger urq gkid priority server-id server-ip-address server-port
no server trigger all
Syntax Description
Submode Commands
After the command is entered, the software enters a submode that permits you to configure additional filters on the reliability, availability, and serviceability (RAS) message. These filters are optional, and you may configure any of them, one per command line.
Defaults
No trigger servers are set.
Command Modes
Gatekeeper configuration
Command History
Usage Guidelines
Use this command and its optional submode commands to configure the unregistration request (URQ) static server trigger. The gatekeeper checks incoming gateway URQ messages for the configured trigger information. If an incoming URQ message contains the specified trigger information, the gatekeeper sends the URQ message to the GKTMP server application. In addition, the gatekeeper processes the message according to its programmed instructions. If the URQ message does not contain the specified information, the gatekeeper processes the message but does not send it to the GKTMP server application.
If no submode commands are configured for the URQ messages, the gatekeeper sends all URQ messages to the GKTMP server application.
If the gatekeeper receives a URQ trigger registration message that contains several trigger conditions, the conditions are treated as "OR" conditions. In other words, if an incoming URQ RAS message meets any one of the conditions, the gatekeeper sends the RAS message to the GKTMP server.
If the gatekeeper receives two URQ trigger registration messages with the same priority for the same GKTMP server, the gatekeeper retains the second registration and discards the first one. If the gatekeeper receives two URQ trigger registration messages with different priorities for the same GKTMP server, the gatekeeper checks incoming URQ messages against the conditions on the higher priority registration before using the lower priority registration. If the gatekeeper receives more than one URQ trigger registration message with the same priority but for different GKTMP servers, the gatekeepers retains all of the registrations.
The the no form of the command removes the trigger definition from the Cisco IOS gatekeeper with all statically configured conditions under that trigger.
Examples
The following example configures a trigger registration on gatekeeper "sj.xyz.com" to send all URQ messages to GKTMP server "Server-123":
Router(config-gk)# server trigger urq sj.xyz.com 1 Server-123 1.14.93.130 1751Router(config-gk_urqtrigger)# exitThe following example configures a URQ trigger registration on gatekeeper "alpha", which sends to the GKTMP server "Server-west" any URQ message containing an MCU endpoint, an H.323 proxy endpoint, or a supported prefix 1#. Other URQ messages are not sent to the GKTMP server.
Router(config-gk)# server trigger urq alpha 1 Server-west 10.10.10.10 1751Router(config-gk-urqtrigger)# endpoint-type mcuRouter(config-gk-urqtrigger)# endpoint-type proxyRouter(config-gk-urqtrigger)# supported-prefix 1#Router(config-gk-urqtrigger# exitIf the URQ registration message defined above for gatekeeper "alpha" is configured and the gatekeeper receives the following trigger registration:
Router(config-gk)# server trigger urq alpha 2 Server-west 10.10.10.10 1751Router(config-gk_urqtrigger)# supported-prefix 1234*Router(config-gk_urqtrigger)# exitthen gatekeeper "alpha" checks all incoming URQ messages for the MCU or H.323 proxy endpoint or the supported prefix 1# before checking for the supported prefix 1234*. If any one of those conditions is met, the gatekeeper sends the URQ message to the GKTMP server "Server-west".
If the second gatekeeper "alpha" URQ trigger registration had been defined with a priority 1 instead of priority 2, then the second trigger registration would have overridden the first one. In other words, the gatekeeper "alpha" would send to GKTMP server "Server-west" only those URQ messages that contain a supported prefix of 1234*. All other URQ messages would not be sent to the GKTMP server.
Related Commands
server registration-port
Configures the server listening port on the gatekeeper.
show gatekeeper servers
Displays the triggers configured on the gatekeeper.
service local-directory
To enable the availability of the local directory service on IP phones served by Cisco IOS Telephony Service (ITS), use the service local-directory command in telephony service configuration mode. To disable the display, use the no form of this command.
service local-directory
no service local-directory
Syntax Description
This command has no arguments or keywords.
Defaults
Local directory service is available on IP phones.
Command Modes
Telephony-service configuration
Command History
12.2(11)YT
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
Use this command with Cisco ITS V2.1 or a later version.
The local directory service is available on IP phones by default.
Examples
The following example specifies that the directory service should not be available on the IP phones served by this ITS router:
Router(config)# telephony-serviceRouter(config-telephony-service)# no service local-directoryRelated Commands
telephony-service
Enables Cisco ITS and enters telephony-service configuration mode.
service-relationship
To enter Annex G neighbor configuration mode and enable service relationships for the particular neighbor, use the service-relationship command in Annex G neighbor configuration mode. To exit this mode, use the no form of this command.
service-relationship
no service-relationship
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Annex G neighbor configuration
Command History
Usage Guidelines
Service relationships are defined to be unidirectional. If a service relationship is established between border element A and border element B, A is entitled to send requests to B and to expect responses. For B to send requests to A and to expect responses, a second service relationship must be established. Repeat this command for each border-element neighbor that you configure.
Note
Examples
The following example enables a service relationship on a border element:
Router(config-annexg-neigh)# service-relationshipRelated Commands
service-type call-check
To identify preauthentication requests to the authentication, authorization, and accounting (AAA) server, use the service-type call-check command in AAA preauthentication configuration mode. To return this setting to the default, use the no form of this command.
service-type call-check
no service-type call-check
Syntax Description
This command has no arguments or keywords.
Defaults
The service type is not set to call-check.
Command Modes
AAA preauthentication configuration
Command History
Usage Guidelines
Setting the service-type attribute to call-check causes preauthentication access requests to include this value, which allows AAA servers to distinguish preauthentication requests from other types of Access-Requests. This command has no effect on packets that are not of the preauthentication type.
Examples
The following example sets the RADIUS service-type attribute to call-check:
Router(config)# aaa preauthRouter(config-preauth)# service-type call-checkRelated Commands
session
To associate a transport session with a specified session group, use the session command in backhaul session manager configuration mode. To delete the session, use the no form of this command.
session group group-name remote-ip remote-port local-ip local-port priority
no session group group-name remote-ip remote-port local-ip local-port priority
Syntax Description
Defaults
No default behavior or values
Command Modes
Backhaul session manager configuration
Command History
Usage Guidelines
It is assumed that the server is located on a remote machine.
Examples
The following example associates a transport session with the session group "group5" and specifies the parameters:
Router(config-bsm)# session group group5 172.13.2.72 5555 172.18.72.198 5555 1session group
To associate a transport session with a specified session group, use the session group command in backhaul session-manager configuration mode. To delete the session, use the no form of this command.
session group group-name remote-ip remote-port local-ip local-port priority
no session group group-name remote-ip remote-port local-ip local-port priority
Syntax Description
Defaults
No default behavior or values.
Command Modes
Backhaul session-manager configuration
Command History
Usage Guidelines
The Cisco VSC3000 server is assumed to be located on a remote machine.
Examples
The following example associates a transport session with the session group named "group5" and specifies the keywords described above:
session group group5 172.16.2.72 5555 192.168.72.198 5555 1session protocol
To specify a session protocol for calls between local and remote routers using the packet network, use the session protocol command in dial-peer configuration mode. To reset to the default, use the no form of this command.
session protocol {aal2-trunk | cisco | sipv2 | smtp}
no session protocol
Syntax Description
Defaults
No default behaviors or values
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
The cisco keyword is applicable only to VoIP on the Cisco 1750, Cisco 1751, Cisco 3600 series, and Cisco 7200 series routers.
The aal2-trunk keyword is applicable only to VoATM on the Cisco MC3810 multiservice access concentrator and the Cisco 7200 series router.
This command applies to both on-ramp and off-ramp store-and-forward fax functions.
Examples
The following example shows that AAL2 trunking has been configured as the session protocol:
dial-peer voice 10 voatmsession protocol aal2-trunkThe following example shows that Cisco session protocol has been configured as the session protocol:
dial-peer voice 20 voipsession protocol ciscoThe following example shows that a VoIP dial peer for SIP has been configured as the session protocol for VoIP call signaling:
dial-peer voice 102 voipsession protocol sipv2Related Commands
session protocol (Voice over Frame Relay)
To establish a Voice over Frame Relay protocol for calls between the local and remote routers via the packet network, use the session protocol command in dial-peer configuration mode. To reset to the default, use the no form of this command.
session protocol {cisco-switched | frf11-trunk}
no session protocol
Syntax Description
cisco-switched
Proprietary Cisco VoFR session protocol. (This is the only valid session protocol for the Cisco 7200 series.)
frf11-trunk
FRF.11 session protocol.
Defaults
cisco-switched
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
For Cisco-to-Cisco dial peer connections, Cisco recommends that you use the default session protocol because of the advantages it offers over a pure FRF.11 implementation. When connecting to FRF.11-compliant equipment from other vendors, use the FRF.11session protocol.
Note
Examples
The following example configures the FRF.11 session protocol on a Cisco 2600 series or Cisco 3600 series router for VoFR dial peer 200:
dial-peer voice 200 vofrsession protocol frf11-trunkcalled-number 5552150The following example configures the FRF.11 session protocol on a Cisco MC3810 for VoFR dial peer 200:
dial-peer voice 200 vofrsession protocol frf11-trunkRelated Commands
session protocol aal2
To enter voice-service-session configuration mode and specify ATM adaptation layer 2 (AAL2) trunking, use the session protocol aal2 command in voice-service configuration mode.
session protocol aal2
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Voice-service configuration
Command History
Usage Guidelines
This command applies to VoATM on the Cisco MC3810 multiservice access concentrator and the Cisco 7200 series router.
In the voice-service-session configuration mode for AAL2, you can configure only AAL2 features, such as call admission control and subcell multiplexing.
Examples
The following example accesses voice-service-session configuration mode, beginning in global configuration mode:
voice service voatmsession protocol aal2session protocol multicast
To set the session protocol as multicast, use the session protocol multicast command in dial-peer configuration mode. To reset to the default protocol, use the no version of this command.
session protocol multicast
no session protocol multicast
Syntax Description
This command has no arguments or keywords.
Defaults
Default session protocol: Cisco.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use this command for voice conferencing in a hoot and holler networking implementation. This command allows more than two ports to join the same session simultaneously. It is supported on Cisco 1700, Cisco 2600, and Cisco 3600 series routers.
Examples
The following example shows the use of the session protocol multicast dial-peer configuration command in context with its accompanying commands:
dial-peer voice 111 voipdestination-pattern 111session protocol multicastsession target ipv4:237.111.0.111:22222ip precedence 5codec g711ulawRelated Commands
session target ipv4
Assigns the session target for voice-multicasting dial peers.
session-set
To create a Signlaing System 7 (SS7)-link-to-SS7-session-set association or to associate an SS7 link with an SS7 session set on the Cisco 2600-based Signaling Link Terminal (SLT), enter the session-set command in global configuration mode. To remove the link from its current SS7 session set and to add it to SS7 session set 0 (the default), use the no form of this command.
session-set session-set-id
no session-set
Syntax Description
Defaults
SS7 session set 0
Command Modes
Global configuration
Command History
Usage Guidelines
On Cisco AS5350 and Cisco AS5400 platforms, the channel-id command is used to create an SS7-link-to-SS7-session-set association on the Cisco SLT. The Cisco 26xx platforms do not support the channel-id command, so channel IDs on the Cisco 26xx-based SLT are implicitly assigned on the basis of the slot location of the WAN interface card (WIC) and the channel group ID used to create the SS7 link.
If this command is omitted, the link is implicitly added to the SS7 session set 0, which is the default.
Examples
The following example shows how the session-set command is used to add the associated SS7 link to an SS7 session set:
session-set 1The following example shows how the no session-set command is used to remove the link from its current SS7 session set and add it to SS7 session set 0, which is the default:
no session-setRelated Commands
channel-id
Assigns a session channel ID to a Signaling System 7 (SS7) serial link or assign an SS7 link to an SS7 session set on a Cisco AS5350 or Cisco AS5400.
session target (MMoIP dial peer)
To designate an e-mail address to receive T.37 store-and-forward fax calls from a Multimedia Mail over IP (MMoIP) dial peer, use the session target command in dial peer configuration mode. To remove the target address, use the no form of this command.
session target mailto:{name | $d$ | $m$ | $e$}[@domain-name]
no session target
Syntax Description
mailto:
Matching calls are passed to the network using Simple Mail Transfer Protocol (SMTP) or Extended Simple Mail Transfer Protocol (ESMTP).
name
String that can be an e-mail address, name, or mailing list alias.
$d$
Macro that is replaced by the destination pattern of the gateway access number, which is the called number or dialed number identification service (DNIS) number.
$m$
Macro that is replaced by the redirecting dialed number (RDNIS) if present; otherwise, it is replaced by the gateway access number (DNIS). This macro requires use of the fax detection interactive voice response (IVR) application.
Note
$e$
Macro that is replaced by the DNIS, the RDNIS, or a string that represents a valid e-mail address, as specified by the cisco-mailtoaddress variable in the transfer tag of the VoiceXML fax detection document. By default, if the cisco-mailtoaddress variable is not specified in the fax detection document, the DNIS is mapped to $e$.
If $e$ is not specified for the session target mailto command in the MMoIP dial peer, but the cisco-mailtoaddress variable is specified in the transfer tag of the fax detection document, then whatever is specified in the MMoIP dial peer takes precedence; the cisco-mailtoaddress variable is ignored.
Note
@domain-name
(Optional) String that contains the domain name to be associated with the target address, preceded by the at sign (@); for example, @mycompany.com.
Defaults
No default behavior or values
Command Modes
Dial peer configuration
Command History
Usage Guidelines
Use this command to deliver e-mail to one recipient by specifying one e-mail name, or to deliver e-mail to multiple recipients by specifying an e-mail alias as the name argument and having that alias expanded by the mailer.
Use the $m$ macro to include the redirecting dialed number (RDNIS) as part of the e-mail name when using the fax detection IVR application. If $m$ is specified and RDNIS is not present in the call information, the access number of the gateway (the dialed number, or DNIS) is used instead. For example, if the calling party originally dialed 6015551111 to send a fax, and the call was redirected (forwarded on busy or no answer) to 6015552222 (the gateway), the RDNIS is 6015551111, and the DNIS is 6015552222.
Use the $e$ macro to map the cisco-mailtoaddress variable in the VoiceXML fax detection document to the username portion of the e-mail address when sending a fax. If the VoiceXML document does not specify the cisco-mailtoaddress variable in the transfer tag, the application maps the DNIS to the e-mail address username.
Examples
The following example delivers fax-mail to multiple recipients:
dial-peer voice 10 mmoipsession target mailto:marketing-information@mailer.example.comAssuming that mailer.example.com is running the sendmail application, you can put the following information into its /etc/aliases file:
marketing-information:john@example.com,fax=+14085551212@sj-offramp.example.comThe following example uses the fax detection IVR application. Here, the session target (MMoIP dial peer) command forwards fax calls to an e-mail account that uses the Redirected Dialed Number Identification Service (RDNIS) as part of its address. In this example, the calling party originally dialed 6015551111 to send a fax, and the call was forwarded (on busy or no answer) to 6015552222, which is the incoming number for the gateway being configured. The RDNIS is 6015551111, and the dialed number (DNIS) is 6015552222. When faxes are forwarded from the gateway, the session target in the example is expanded to 6015551111@mail-server.unified-messages.com.
dial-peer voice 4 mmoipsession target mailto:$m$@mail-server.unified-messages.comThe following examples configure a session target for a VoiceXML fax detection application. In this example, the VoiceXML document passes just the username portion of the e-mail address, for example, "johnd":
dial-peer voice 4 mmoipsession target mailto:$e$@cisco.comIn this example, the VoiceXML document passes the complete e-mail address including domain name, for example, "johnd@cisco.com":
dial-peer voice 5 mmoipsession target mailto:$e$Related Commands
session target (POTS dial peer)
To designate loopback calls from a POTS dial peer, use the session target command in dial-peer configuration mode. To reset to the default, use the no form of this command.
session target loopback:compressed | loopback:uncompressed
no session target
Syntax Description
loopback:compressed
All voice data is looped back in compressed mode to the source.
loopback:uncompressed
All voice data is looped back in uncompressed mode to the source.
Defaults
No loopback calls are designated.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use this command to test the voice transmission path of a call. The loopback point depends on the call origin and the loopback type selected.
Examples
The following example loops back the traffic from the dial peer in compressed mode:
dial-peer voice 10 potssession target loopback:compressedRelated Commands
dial-peer voice
Enters dial-peer configuration mode and specifies the method of voice-related encapsulation.
session target (VoATM dial peer)
To specify a network-specific address for a specified VoATM dial peer, use the session target command in dial-peer configuration mode. To reset to the default, use the no form of this command.
Cisco 3600 Series Routers
session target interface pvc {name | vpi/vci | vci}
no session target
Cisco MC3810 Multiservice Access Concentrators
session target {serial | atm} interface pvc {word | vpi/vci | vci} cid
no session target
Cisco 7200 Series Routers
session target atm slot/port pvc {word | vpi/vci | vci} cid
no session target
Syntax Description
Defaults
Command is enabled with no IP address or domain name defined.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use the session target command to specify a network-specific address or domain name for a dial peer. Whether you select a network-specific address or a domain name depends on the session protocol that you select. The syntax of this command complies with the simple syntax of mailto: as described in RFC 1738.
Use the session target loopback command to test the voice transmission path of a call. The loopback point depends on the call origin and the loopback type selected.
This command applies to on-ramp store-and-forward fax functions.
You must enter the session protocol aal2-trunk dial-peer configuration command before you can specify a CID for a dial peer for VoATM on the Cisco MC3810 multiservice access concentrator and Cisco 7200 series router.
Note
Examples
The following example configures a session target for VoATM on a Cisco MC3810 multiservice access concentrator. The session target is sent to ATM interface 0 for a PVC with a VCI of 20.
dial-peer voice 12 voatmdestination-pattern 13102221111session target atm0 pvc 20The following example delivers fax-mail to multiple recipients:
dial-peer voice 10 mmoipsession target marketing-information@mailer.example.comAssuming that mailer.example.com is running sendmail, you can put the following information into its /etc/aliases file:
marketing-information:john@example.com,fax=+14085551212@sj-offramp.example.com
The following example configures a session target for VoATM on the Cisco 3600 series. The session target is sent to ATM interface 0, and is for a PVC with a VPI/VCI of 1/100.
dial-peer voice 12 voatmdestination-pattern 13102221111session target atm1/0 pvc 1/100Related Commands
session target (VoFR dial peer)
To specify a network-specific address for a specified VoFR dial peer, use the session target command in dial-peer configuration mode. To reset to the default, use the no form of this command.
Cisco 2600 Series and Cisco 3600 Series Routers
session target interface dlci [cid]
no session target
Cisco MC3810 Multiservice Access Concentrators
session target interface dlci [cid]
no session target
Cisco 7200 Series Routers
session target interface dlci
no session target
Syntax Description
Defaults
The default for this command is enabled with no IP address or domain name defined.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use the session target command to specify a network-specific address or domain name for a dial peer. Whether you select a network-specific address or a domain name depends on the session protocol you select. The syntax of this command complies with the simple syntax of mailto: as described in RFC 1738.
The session target loopback command is used for testing the voice transmission path of a call. The loopback point depends on the call origin and the loopback type selected.
For VoFR dial peers, the cid option is not allowed when the cisco-switched option for the session protocol command is used.
Examples
The following example configures a session target for Voice over Frame Relay on a Cisco MC3810 with a session target on serial port1 and a DLCI of 200:
dial-peer voice 11 vofrdestination-pattern 13102221111session target serial1 200The following example configures serial interface 1/0, DLCI 100 as the session target for VoFR dial peer 200 (an FRF.11 dial peer) on a Cisco 2600 series or Cisco 3600 series router, starting from global configuration mode and using the FRF.11 session protocol:
dial-peer voice 200 vofrdestination-pattern 13102221111called-number 5552150session protocol frf11-trunksession target serial 1/0 100 20The following example delivers fax-mail to multiple recipients:
dial-peer voice 10 mmoipsession target marketing-information@mailer.example.comAssuming that mailer.example.com is running sendmail, you can put the following information into its /etc/aliases file:
marketing-information:john@example.com,fax=+14085551212@sj-offramp.example.com
Related Commands
session target (VoIP dial peer)
To designate a network-specific address to receive calls from a VoIP dial peer, use the session target command in dial-peer configuration mode. To reset to the default, use the no form of this command.
Cisco 1751, Cisco 3725, Cisco 3745, Cisco AS5300
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] host-name | enum:table-num | loopback:rtp | ras | sip-server}
no session target
Cisco 2600 Series, Cisco 3600 Series, Cisco AS5350, Cisco AS5400, Cisco AS5850, Cisco MC3810
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] host-name | enum:table-num | loopback:rtp | ras | settlement provider-number | sip-server}
no session target
Cisco AS5800
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] host-name | enum:table-num | loopback:rtp}
no session target
Syntax Description
Defaults
Enabled, with no IP address or domain name defined.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use this command to specify a network-specific destination for a dial peer to receive calls from the current dial peer. You can select an option to define a network-specific address or domain name as a target, or you can select one of several methods to automatically determine the destination for calls from the current dial peer.
Use the session target dns command with or without the specified macros. Using the optional macros can reduce the number of VoIP dial-peer session targets that you must configure if you have groups of numbers associated with a particular router.
The session target enum command instructs the dial peer to use a table of translation rules to convert the dialed number identification service (DNIS) number into a number in E.164 format. This translated number is sent to a DNS server that contains a collection of URLs. These URLs identify each user as a destination for a call and may represent various access services, such as SIP, H.323, telephone, fax, e-mail, instant messaging, and personal web pages. Before assigning the session target to the dial peer, configure an ENUM match table with the translation rules using the voice enum-match-table command in global configuration mode. The table is identified in session target enum as table-num.
Use the session target loopback command to test the voice transmission path of a call. The loopback point depends on the call origin.
Use the session target ras command to specify that the RAS protocol is being used to determine the IP address of the session target.
In Cisco IOS Release 12.1(1)T the session target command configuration cannot combine the target of RAS with the settle-call command.
If the session target type is settlement when the VoIP dial peers are configured for a settlement server, the provider-number parameter in the session target and settle-call commands should be identical.
Use the session target sip-server command to name the global SIP server interface as the destination for calls from this dial peer. You must first define the SIP server interface by using the sip-server command in SIP user-agent configuration mode. Then you can enter the session target sip-server option for each dial peer instead of having to enter the entire IP address for the SIP server interface under each dial peer.
Examples
The following example creates a session target using DNS for a host named "voice_router" in the domain cisco.com:
dial-peer voice 10 voipsession target dns:voice_router.cisco.comThe following example creates a session target using DNS with the optional $u$. macro. In this example, the destination pattern ends with four periods (.) to allow for any four-digit extension that has the leading numbers 1310555. The optional macro $u$. directs the gateway to use the unmatched portion of the dialed number—in this case, the four-digit extension—to identify a dial peer. As in the preceding example, the domain is "cisco.com."
dial-peer voice 10 voipdestination-pattern 1310555....session target dns:$u$.cisco.comThe following example creates a session target using DNS, with the optional $d$. macro. In this example, the destination pattern has been configured for 13105551111. The optional macro $d$. directs the gateway to use the destination pattern to identify a dial peer in the "cisco.com" domain.
dial-peer voice 10 voipdestination-pattern 13105551111session target dns:$d$.cisco.comThe following example creates a session target using DNS, with the optional $e$. macro. In this example, the destination pattern has been configured for 12345. The optional macro $e$. directs the gateway to do the following: reverse the digits in the destination pattern, add periods between the digits, and use this reverse-exploded destination pattern to identify the dial peer in the "cisco.com" domain.
dial-peer voice 10 voipdestination-pattern 12345session target dns:$e$.cisco.comThe following example creates a session target using an ENUM table. It indicates that calls made using dial peer 101 should use the preferential order of rules in enum match table 3.
dial-peer voice 101 voipsession target enum:3The following example creates a session target using RAS:
dial-peer voice 11 voipdestination-pattern 13105551111session target rasThe following example creates a session target using settlement:
dial-peer voice 24 voipsession target settlement:0Related Commands
session transport
To configure a VoIP dial peer to use Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) as the underlying transport layer protocol for Session Initiation Protocol (SIP) messages, use the session transport command in dial-peer configuration mode. To reset to the default, use the no form of this command.
session transport {udp | tcp}
no session transport {udp | tcp}
Syntax Description
udp
The SIP dial peer uses the UDP transport layer protocol. This is the default.
tcp
The SIP dial peer uses the TCP transport layer protocol.
Defaults
UDP
Note
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
Use the show sip-ua status command to ensure that the transport protocol that you set using the session transport command matches the protocol set using the transport command. This command is used in dial-peer configuration mode to specify the SIP transport method, either UDP or TCP.
Examples
The following example shows a VoIP dial peer configured to use UDP as the underlying transport layer protocol for SIP messages:
dial-peer voice 102 voipsession transport udpset
To create a fault-tolerant or non-fault-tolerant session set with the client or server option, use the set command in backhaul session-manager configuration mode. To delete the set, use the no form of this command.
set set-name {client | server} {ft | nft}
no set set-name {client | server} {ft | nft}
Syntax Description
Defaults
No default behavior or values
Command Modes
Backhaul session-manager configuration
Command History
Usage Guidelines
Multiple session groups can be associated with a session set.
For signaling backhaul, session sets should be configured to operate as clients.
A session set cannot be deleted unless all session groups associated with the session set are deleted first.
Examples
The following example sets the client set named "set1" as fault-tolerant:
Router(config-bsm)# set set1 client ftset pstn-cause
To map an incoming PSTN cause code to a Session Initiation Protocol (SIP) error status code, use the set pstn-cause command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.
set pstn-cause value sip-status value
no set pstn-cause
Syntax Description
pstn-cause value
PSTN cause code. Range is from 1 to 127
sip-status value
SIP status code that is to correspond with the PSTN cause code. Range is from 400 to 699.
Defaults
The default mappings defined in the following table are used:
Command Modes
SIP user-agent configuration
Command History
Usage Guidelines
A PSTN cause code can be mapped only to one SIP status code at a time.
Examples
The following example maps a SIP status code to correspond to a PSTN cause code:
Router(config)# sip-uaRouter(config-sip-ua)# set pstn-cause 111 sip-status 400Router(config-sip-ua)# exitRelated Commands
set sip-status
Sets an incoming SIP error status code to a PSTN release cause code.
set sip-status
To map an incoming Session Initiation Protocol (SIP) error status code to a PSTN cause code, use the set sip-status command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.
set sip-status value pstn-cause value
no set sip-status
Syntax Description
sip-status value
SIP status code. Range is from 400 to 699.
pstn-cause value
PSTN cause code that is to correspond with the SIP status code. Range is from 1 to 127.
Defaults
The default mappings defined in the following table are used:
Command Modes
SIP user-agent configuration
Command History
Usage Guidelines
A SIP status code can be mapped to many PSTN cause codes. For example, 503 can be mapped to 34, 38, and 58.
Examples
The following example maps a PSTN cause code to correspond to a SIP status code:
Router(config)# sip-uaRouter(config-sip-ua)# set sip-status 400 pstn-cause 16Related Commands
settle-call
To force a call to be authorized with a settlement server that uses the address resolution method specified in the session target command, use the settle-call command in dial-peer configuration mode. To ensure that no authorization is performed by a settlement server, use the no form of this command.
settle-call provider-number
no settle-call provider-number
Syntax Description
Defaults
No default behavior or values.
Command Modes
Dial-peer configuration
Command History
12.1(1)T
This command was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco AS5300.
Usage Guidelines
With the session target command, a dial peer can determine the address of the terminating gateway through the ipv4, dns, ras, and settlement keywords.
If the session target is not settlement, and the settle-call provider-number argument is set, the gateway resolves address of the terminating gateway using the specified method and then requests the settlement server to authorize that address and create a settlement token for that particular address. If the server cannot authorize the terminating gateway address suggested by the gateway, the call fails.
Do not combine the session target types ras and settle-call. Combination of session target types is not supported.
Examples
The following example sets a call to be authorized with a settlement server that uses the address resolution method specified in the session target:
dial-peer voice 10 voipdestination-pattern 1408.......session target ipv4:172.22.95.14settle-call 0Related Commands
settlement
To enter settlement configuration mode and specify the attributes specific to a settlement provider, use the settlement command in global configuration mode. To disable the settlement provider, use the no form of this command.
settlement provider-number
no settlement provider-number
Syntax Description
Defaults
0
Command Modes
Global configuration
Command History
12.0(4)XH1
This command was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco AS5300.
12.1(1)T
This command was integrated into Cisco IOS Release 12.1(1)T.
Usage Guidelines
The variable provider-number defines a particular settlement provider. For Cisco IOS Release 12.1, only one clearinghouse per system is allowed, and the only valid value for provider-number is 0.
Examples
This example enters settlement configuration mode:
settlement 0Related Commands
settlement roam-pattern
To configure a pattern that must be matched to determine if a user is roaming, use the settlement roam-pattern command in global configuration mode. To delete a particular pattern, use the no form of this command.
settlement provider-number roam-pattern pattern {roaming | no roaming}
no settlement provider-number roam-pattern pattern {roaming | no roaming}
Syntax Description
provider-number
Digit defining the ID of particular settlement server. The only valid entry is 0.
pattern
User account pattern.
roaming | no roaming
Whether a user is roaming.
Defaults
No default pattern
Command Modes
Global configuration
Command History
12.1(1)T
This command was introduced on the Cisco 2600 series, Cisco 3600 series, and Cisco AS5300.
Usage Guidelines
Multiple roam patterns can be entered on one gateway.
Examples
The following example configures a pattern that determines if a user is roaming:
settlement 0 roam-pattern 1222 roamsettlement 0 roam-pattern 1333 noroamsettlement roam-pattern 1444 roamsettlement roam-pattern 1555 noroamRelated Commands
roaming (settlement)
Enables the roaming capability for a settlement provider.
settlement
Enters settlement configuration mode.
sgcp
To start and allocate resources for the Simple Gateway Control Protocol (SGCP) daemon, use the sgcp command in global configuration mode. To terminate all calls, release all allocated resources, and kill the SGCP daemon, use the no form of this command.
sgcp
no sgcp
Syntax Description
This command has no arguments or keywords.
Defaults
The SGCP daemon is not enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
When the SGCP daemon is not active, all SGCP messages are ignored.
When you enter the no sgcp command, the SGCP process is removed.
Note
Examples
The following example enables the SGCP daemon:
sgcpThe following example disables the SGCP daemon:
no sgcpRelated Commands
sgcp call-agent
To define the IP address of the default Simple Gateway Control Protocol (SGCP) call agent in the router configuration file, use the sgcp call-agent command in global configuration mode. To remove the IP address of the default SGCP call agent from the router configuration, use the no form of this command.
sgcp call-agent ipaddress [:udp port]
no sgcp call-agent ipaddress
Syntax Description
ipaddress
IP address or hostname of the call agent.
:udp port
(Optional) UDP port of the call agent.
Defaults
No IP address is configured.
Command Modes
Global configuration
Command History
Usage Guidelines
This command defines the IP address of the default SGCP call agent to which the router sends an initial RSIP (Restart In Progress) packet when the router boots up. This is used for initial bootup only before the SGCP call agent contacts the router acting as the gateway.
When you enter the no sgcp call-agent command, only the IP address of the default SGCP call agent is removed.
Examples
The following example enables SGCP and specifies the IP address of the call agent:
sgcpsgcp call-agent 209.165.200.225Related Commands
sgcp graceful-shutdown
To block all new calls and gracefully terminate all existing calls (wait for the caller to end the call), use the sgcp graceful-shutdown command in global configuration mode. To unblock all calls and allow new calls to go through, use the no form of this command.
sgcp graceful-shutdown
no sgcp graceful-shutdown
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Once you issue this command, all requests for new connections (CreateConnection requests) are denied. All existing calls are maintained until users terminate them, or until you enter the no sgcp command. When the last active call is terminated, the SGCP daemon is terminated, and all resources allocated to it are released.
Examples
The following example blocks all new calls and terminates existing calls:
sgcp graceful-shutdownRelated Commands
sgcp max-waiting-delay
To set the Simple Gateway Control Protocol (SGCP) maximum waiting delay to prevent restart avalanches, use the sgcp max-waiting-delay command in global configuration mode. To reset to the default, use the no form of this command.
sgcp max-waiting-delay delay
no sgcp max-waiting-delay delay
Syntax Description
Defaults
3,000 ms
Command Modes
Global configuration
Command History
Examples
The following example sets the maximum wait delay value to 40 ms:
sgcp max-waiting-delay 40Related Commands
sgcp modem passthru
To enable Simple Gateway Control Protocol (SGCP) modem or fax pass-through, use the sgcp modem passthru command in global configuration mode. To disable SGCP modem or fax pass-through, use the no form of this command.
sgcp modem passthru {ca | cisco | nse}
no sgcp modem passthru {ca | cisco | nse}
Syntax Description
ca
Call-agent-controlled modem upspeed-method violation message.
cisco
Cisco-proprietary upspeed method based on the protocol.
nse
NSE-based modem upspeed method.
Defaults
SGCP modem or fax pass-through is disabled by default.
Command Modes
Global configuration.
Command History
Usage Guidelines
You can use this command for fax pass-through because the answer tone can come from either modem or fax transmissions. The upspeed method is the method used to dynamically change the codec type and speed to meet network conditions.
If you use the nse option, you must also configure the sgcp tse payload command.
Examples
The following example configures SGCP modem pass-through using the call-agent upspeed method:
sgcp modem passthru caThe following example configures SGCP modem pass-through using the proprietary Cisco upspeed method:
sgcp modem passthru ciscoThe following example configures SGCP modem pass-through using the NSE-based modem upspeed:
sgcp modem passthru nsesgcp tse payload 110Related Commands
sgcp quarantine-buffer disable
To disable the Simple Gateway Control Protocol (SGCP) quarantine buffer, use the sgcp quarantine-buffer disable command in global configuration mode. To reenable the SGCP quarantine buffer, use the no form of this command.
sgcp quarantine-buffer disable
no sgcp quarantine-buffer disable
Syntax Description
This command has no arguments or keywords.
Defaults
The SGCP quarantine buffer is enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
The SGCP quarantine buffer is the mechanism for buffering the SGCP events between two notification-request (RQNT) messages.
Examples
The following example disables the SGCP quarantine buffer:
sgcp quarantine-buffer disableRelated Commands
sgcp request retries
To specify the number of times to retry sending notify and delete messages to the Simple Gateway Control Protocol (SGCP) call agent, use the sgcp request retries command in global configuration mode. To reset to the default, use the no form of this command.
sgcp request retries count
no sgcp request retries
Syntax Description
count
Number of times that a notify and delete message is retransmitted to the SGCP call agent before it is dropped. Range is from 1 to 100. Default is 3.
Defaults
3 times
Command Modes
Global configuration
Command History
Usage Guidelines
The actual retry count may be different from the value you enter for this command. The retry count is also limited by the call agent. If there is no response from the call agent after 30 seconds, the gateway does not retry anymore, even though the number set using the sgcp request retries command has not been reached.
The router stops sending retries after 30 seconds, regardless of the setting for this command.
Examples
The following example configures the system to send the sgcp command 10 times before dropping the request:
sgcp request retries 10Related Commands
sgcp request timeout
To specify how long the system should wait for a response to a request, use the sgcp request timeout command in global configuration mode. To reset to the default, use the no form of this command.
sgcp request timeout timeout
no sgcp request timeout
Syntax Description
timeout
Time to wait for a response to a request, in milliseconds. Range is from 1 to 10000. Default is 500.
Defaults
500 ms
Command Modes
Global configuration
Command History
Usage Guidelines
This command is used for "notify" and "delete" messages, which are sent to the SGCP call agent.
Examples
The following example configures the system to wait 40 ms for a reply to a request:
sgcp request timeout 40Related Commands
sgcp restart
To trigger the router to send a Restart in Progress (RSIP) message to the Simple Gateway Control Protocol (SGCP) call agent indicating that the T1 controller is up or down so that the call agent can synchronize with the T1 controller, use the sgcp restart command in global configuration mode. To reset to the default, use the no form of this command.
sgcp restart {delay delay | notify}
no sgcp restart {delay delay | notify}
Syntax Description
delay delay
Restart delay, in milliseconds. Range is from 0 to 600. Default is 0.
notify
Restarts notification upon the SGCP/digital interface state transition.
Defaults
0 ms
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to send RSIP messages from the router to the SGCP call agent. RSIP messages are used to synchronize the router and the call agent. RSIP messages are also sent when the sgcp command is entered to enable the SGCP daemon.
You must enter the notify option to enable RSIP messages to be sent.
Examples
The following example configures the system to wait 40 ms before restarting SGCP:
sgcp restart delay 40The following example configures the system to send an RSIP notification to the SGCP call agent when the T1 controller state changes:
sgcp restart notifyRelated Commands
sgcp retransmit timer
To configure the Simple Gateway Control Protocol (SGCP) retransmission timer to use a random algorithm, use the sgcp retransmit timer command in global configuration mode. To reset to the default, use the no form of this command.
sgcp retransmit timer {random}
no sgcp retransmit timer {random}
Syntax Description
Defaults
The SGCP retransmission timer does not use a random algorithm.
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to enable the random algorithm component of the retransmission timer. For example, if the retransmission timer is set to 200 ms, the first retransmission timer is 200 ms, but the second retransmission timer picks up a timer value randomly between either 200 or 400. The third retransmission timer picks up a timer value randomly of 200, 400, or 800 as shown below:
•
•
•
•
•
After 30 seconds, the retransmission timer no longer retries.
Examples
The following example sets the retransmission timer to use a random algorithm:
sgcp retransmit timer randomRelated Commands
sgcp timer
To configure how the gateway detects the Real-Time Transport Protocol (RTP) stream lost, use the sgcp timer command in global configuration mode. To reset to the default, use the no form of this command.
sgcp timer {receive-rtcp timer | rtp-nse timer}
no sgcp timer {receive-rtcp timer | rtp-nse timer}
Syntax Description
Defaults
receive-rtcp: 5 ms
rtp-nse: 200 ms
Command Modes
Global configuration
Command History
Usage Guidelines
The RTP NSE timer is used for proxy ringing (the ringback tone is provided at the originating gateway).
Examples
The following example sets the RTPCP transmission interval to 100 ms:
sgcp timer receive-rtcp 100The following example sets the NSE timeout to 1000 ms:
sgcp timer rtp-nse 1000Related Commands
sgcp tse payload
To enable Inband Telephony Signaling Events (TSE) for fax and modem operation, use the sgcp tse payload command in global configuration mode. To reset to the default, use the no form of this command.
sgcp tse payload type
no sgcp tse payload type
Syntax Description
Defaults
0 (disabled)
Command Modes
Global configuration
Command History
Usage Guidelines
Because this command is disabled by default, you must specify a TSE payload type.
If you set the sgcp modem passthru command to the nse value, then you must configure this command.
Examples
The following example sets Simple Gateway Control Protocol (SGCP) modem pass-through using the NSE-based modem upspeed and the Inband Telephony Signaling Events payload value set to 110:
sgcp modem passthru nsesgcp tse payload 110Related Commands
