cc/td/doc/product/software/ios113ed/ios113p
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring the Cisco AS5300 for Voice Service Provider Features
Service Provider VoIP Feature Overview
Gateway RAS Implementation
AAA Accounting
Interactive Voice Response
ISDN Redirect Number Support
Rotary Call Pattern
T1 CAS
Gatekeeper Feature Descriptions
HSRP Support
E.164 Address Support
Technology Prefixes
Gatekeeper and Gateway Internetworking Configuration
Sample Gatekeeper Configuration
Sample Gateway Configuration
Command Reference
Gatekeeper Commands
Gateway Commands
Debug Commands
Reference Information
Gatekeeper and Gateway Functional Description
Gatekeeper Functionality
List of Terms
Related Documentation
Cisco Connection Online
CD-ROM/WWW

Configuring the Cisco AS5300 for Voice Service Provider Features


This document is an addendum to the Voice over IP for the Cisco AS5300 Software Configuration Guide. The new features are described and also the tasks and commands required to configure these features. The Service Provider feature set is supported in Cisco IOS Release 11.3(6)NA2 and later.


Caution

Cisco IOS Release 11.3(6)NA2 requires VCWare Version 2.4. Cisco IOS Releases 11.3(7)NA and 12.0(3)T will require VCWare Version 2.5.


This document contains the following sections:

Service Provider VoIP Feature Overview
Gatekeeper Feature Descriptions
Gatekeeper and Gateway Internetworking Configuration
Reference Information

Service Provider VoIP Feature Overview

The Cisco AS5300 Voice Service Provider Features include enhancements made to the functionality and configuration of both the gateway and the VoIP gatekeeper. The architecture of these features provides the Quality of Service (QoS), stability, and functionality necessary for carrier class real-time IP communications services.

This document contains a basic description of the gateway and gatekeeper features required to implement the applications to run VoIP in a service provider environment. The features address the needs of the service provider to offer security, billing, scaling, and reliability.

The Cisco gateway functionality and gatekeeper functionality work in concert to provide the ITU-T H.323 infrastructure. Therefore, the two main components in the Cisco voice architecture that interoperate to enable the service provider feature set are:

Refer to "VoIP PSTN Signaling Architecture" section for a graphical description of the gateway and gatekeeper internetworking functionality.

To help understand the overall implication of which features affect which portion of the internetworking environment, these features are described in two different categories:

Gatekeepers can manage a zone and provide bandwidth management, and address resolution services to the gateways when present in the network.

Gateways can terminate a call from the PSTN and provides user admission control using Interactive Voice Response (IVR) and provide accounting records for the call. The gateway also can direct the call to the destination, or can terminate the call from another gateway and send the call to the PSTN. The gateway (in this document) refers to the Cisco AS5300 Access Server with voice cards and the VoIP image. Gateways may also be referred to as VoIP gateways.


Note      See the "Gatekeeper and Gateway Functional Description" section for a brief description of how gateways and gatekeepers interoperate.



Figure 1   VoIP
PSTN Signaling Architecture

Gatekeeper Features

The gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the gatekeeper and to locate another gatekeeper. The gatekeeper provides logic variables for proxies or gateways in a call path to provide connectivity with the Public Switched Telephone Network (PSTN), to improve Quality Of Service (QoS), and to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into Domain Naming System (DNS), or via Cisco IOS configuration options.


Note      For complete information about the gatekeeper functionality, refer to the Cisco Product Documentation at the following Cisco Connection Online location:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113na/1137na/mcm_cfg.htm


In addition to the Cisco IOS Release 11.3NA functionality described in documentation in the above URL, the gatekeeper has been enhanced with two important new features:

Allows a standby gatekeeper to assume the role of a failed gatekeeper.

Enables inter-zone call routing using E.164 addresses.


Note      Refer to Gatekeeper Feature Descriptionsfor the description of each feature. Command Reference describes the new commands for these features.


The Cisco routers performing the access server functionality for the gatekeeper are:

Information on these routers is also available at the documentation URL on the previous page.

Gateway Features

The gateway capability is the ability of the Cisco AS5300 to function as an H.323 endpoint. Therefore, the gateway provides: admission control, address lookup and translation, and accounting services.

User configuration and implementation of these features all takes place while setting up and configuring the gatekeeper and the gateway. See "Gatekeeper and Gateway Internetworking Configuration".

Descriptions of each gateway feature and the commands added for the Cisco IOS Release 11.3(6)NA2 follow.

Gateway RAS Implementation

RAS is the acronym for Registration, Admission, and Status. The RAS signaling function performs registration, admissions, status, and disengage procedures between the VoIP gateway and gatekeeper.

Two new fields have been added to the dial-peer entry. The gateway relies on Cisco IOS command line interface commands, outside of gateway configuration mode, to configure handling of the AAA servers. See "Sample Gateway Configuration".

RAS Command Fields

The following changes have been made to the gateway to enable the RAS implementation on the H.323 gateway.

Two new fields are added to the dial-peer entry:

technology prefix

The technology prefix field is applicable to the dial-peer of the "voip" encapsulation type. This field is used to indicate to the gatekeeper the type of service that the outbound call is requesting. For a complete description of the technology prefix see the "Technology Prefixes" section.

session target

The session target field of the VoIP dial-peer indicates the address of the remote gateway where the call is terminated. If RAS (Request, Admission, and Status) Protocol is used, the session target field is used to indicate that a gatekeeper needs to be consulted in order to translate an E164 address to an IP address.

Command Mode

dial peer configuration

Example

A Gateway must register with a gatekeeper. If a gatekeeper is not available, the gateway will periodically attempt discovery until one is available.

When a gatekeeper is discovered, the gateway registers its aliases and call signaling address with it. At this point, the gateway is able to accept calls.

If HSRP is not configured on the gatekeeper, the gateway detects when a gatekeeper is offline. For example, if the gateway detects that a gatekeeper (the gatekeeper with which it registered) is offline, the gateway will attempt to rediscover, and will accept no new RAS calls until discovery is complete. Active calls will not be affected.

The RAS state machine operates in the Request/Reject/Confirm mode. The gateway issues a Request message to the gatekeeper. The expected response from the gatekeeper is either a Confirm message or a Reject Message.

In simple terms, the gateway employs an intelligent backoff and retry mechanism to handle transient gatekeepers or network failures.

AAA Accounting

The feature AAA represents Authentication, Authorization, and Accounting features which are required in the VoIP gateway. The standard Cisco AAA accounting functionality is enhanced to collect digits during the call processing process. Processes such as:

The AAA authentication feature permits RADIUS to be used to authenticate users (typically incoming calls) on the gateway. It is normally used with IVR to check the legitimacy of a prospective gateway user based on an account number (collected by IVR) or based on answer number identification, (ANI).


Note      For a complete description of the Cisco standard AAA feature, refer to the CCO web site located at URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/aaalists.htm


Authentication

Authentication is based on RADIUS and is performed on the gateway (as opposed to the gatekeeper).

User account and PIN information is collected by the IVR application and is passed to the AAA interface. The AAA interface then makes a RADIUS authentication request with the given information and returns to the IVR application with status of success or failure.

RADIUS is an IETF protocol based on UDP. It functions by exchanging a set of attribute/value pairs between the client, here a VoIP gateway and a RADIUS server. Standard RADIUS server implementations include CiscoSecure, Cisco UCP, Livingston, and Merit.

Authorization

An authenticated user is authorized. There is no authorization of specific user capabilities for the service provider voice applications.

Accounting

Accounting uses a basic start-stop method and standard RADIUS attributes where possible. Attributes that cannot be mapped to standard RADIUS are packed into the Acct-Session-Id attribute field as '/' separated ASCII string.

Data items are collected for each call leg that gets created on the gateway. A call leg is the internal representation of a connection to the gateway. Each call that is made through the gateway consists of two call legs: an incoming and an outgoing call leg. The call leg information that is emitted by the gateway(s) can be correlated by their connection ID, which is the same for all call legs of a connection.


Caution

If you are using H.323 accounting and are also using Cisco Secure NT, then Cisco Secure version 2.1.8.4 or higher is required.


Standard RADIUS Attributes

The standard RADIUS attributes supported are:

Nonstandard RADIUS Attributes

The nonstandard RADIUS attributes are packed into the Acct-Session-Id are:

RADIUS Accounting with Overloaded Session ID

In order to take advantage of standard RADIUS implementations that do not support vendor specific attributes a new method is defined which embeds the unsupported information elements in the RADIUS Acct-Session-id. The Acct-Session-id field has a maximum length of 256 characters. It is defined to contain the RADIUS account session id which is a unique identifier that links accounting records associated with the same login session for a user. The internal representation of this field is long. Therefore, the value of this Session ID can become very large as the number of sessions on a router increases.

In order to support additional fields, following string is the format for this field:

<session id>/<call leg setup time>/<gateway id>/<connection id>/<call origin>/
<call type>/<connect time>/<disconnect time>/<disconnect cause>/<remote ip address>

Field  Description 

session id

The standard RADIUS account session ID

call leg setup time

The Q.931 setup time for this connection in NTP format.

gateway id

The name of the underlying gateway. Name string is of form
"gateway.domain_name"

connection id

A unique global identifier used to correlate call legs that belong to the same end to end call. The field consists of 4 long words (128 bits). each long word is displayed in hexadecimal value and separated by a space character.

call origin

Indicates origin of the call relative to the gateway. Possible values are "originate" and "answer."

call type

Indicates call leg type. Possible values are: "Telephony" and "VoIP."

connect time

The Q.931 connect time for this call leg in NTP format.

disconnect time

The Q.931 disconnect time for this call leg in NTP format.

disconnect cause

Documented in Q.931 specification. Can be in the range of 1 to 160.

remote IP address

Address of the remote gateway port where the call is connected.

Note Support for remote IP address field was introduced with Cisco IOS  Release 11.3(7)NA.

Usage Guidelines

NTP time formats are displayed as: %H:%M:%S.%k %Z %tw %tn %td %Y where:

Note that because of the limited size of the session id string, it is not possible to embed very many information elements in it. Therefore, this feature supports only a limited set of accounting information elements. For implementations that would like to take advantage of more information elements, Cisco's VSA implementation is recommended.


Example 1   Start Record
Client-Id = 172.29.248.123
NAS-Port-Type = 0
User-Name = "4004"
Called-Station-Id = "+111"
Calling-Station-Id = "+222"
Acct-Status-Type = Start
User-Service-Type = Login-User
Acct-Session-Id = "4/23:21:14.078 UTC Sat Jul 18 1998/ak3620-1.cisco.com/859BF275 D7C80001 0 3AFF4/originate/VoIP///"
Acct-Delay-Time = 0

Example 2   Stop Record
Client-Id = 172.29.248.123
NAS-Port-Type = 0
User-Name = "4004"
Called-Station-Id = "+111"
Calling-Station-Id = "+222"
Acct-Status-Type = Stop
User-Service-Type = Login-User 
Acct-Session-Id = "4/23:21:14.078 UTC Sat Jul 18 1998/ak3620-1.cisco.com/859BF275 D7C80001 0 3AFF4/originate/VoIP/23:21:14.093 UTC Sat Jul 18 1998/23:21:23.084 UTC Sat Jul 18 1998/4/123.45.67.890" Acct-Input-Octets = 8340 
Acct-Output-Octets = 8900
Acct-Input-Packets = 417
Acct-Output-Packets = 445
Acct-Session-Time = 9
Acct-Delay-Time = 0

Example 3   Update Record
Client-Id = 172.29.248.123
NAS-Port-Type = 0
User-Name = "4004"
Called-Station-Id = "+111"
Calling-Station-Id = "+222"
Acct-Status-Type = 3
User-Service-Type = Login-User
Acct-Session-Id = "4/21:54:17.052 UTC Mon Jul 20
1998/ak3620-1.cisco.com/BF1AC9CA 8DE60006 0 5ED24/originate/VoIP///"
Acct-Delay-Time = 0

Syslog Accounting

The syslog accounting option exports the information elements associated with each call leg through a system log message which can be captured by a syslog daemon that is present on the network. The syslog output consists of the following:

<server timestamp> <gateway id> <message number> : <message label> : <list of AV pairs>

Field  Description 

server timestamp

The timestamp created by the server when it receives the message to log.

gateway id

The name of the gateway emitting the message.

message number

The number assigned to the message by the gateway.

message label

Is a string used to identify the message category.

list of AV pairs

Is a string consisting of <attribute name> <attribute value> pairs separated by commas.

Example

%VOIPAAA-5-VOIP_CALL_HISTORY:CallLegType 2,ConnectionId 300094C0 60E0F3A0 60C894C0 60C90000,
SetupTime 22:35:22.023UTC Tue Aug 11 1998, PeerAddress 999, PeerSubAddress , DisconnectCause 10  ,DisconnectText normal call clearing., ConnectTime 22:35:24.027 UTC Tue Aug 11 1998,
DisconnectTime 22:35:29.028 UTC Tue Aug 11 1998, CallOrigin 1, ChargedUnits 0, InfoType 2,TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0

New AAA Commands

The following new Cisco IOS Release 11.3(6)NA2 commands are designed for configuring the Service Provider Voice over IP AAA functionality.

See the Command Reference and check the appropriate command in "Gateway Commands".


Note      For additional information about the standard AAA functionality see Cisco IOS Release 11.3(T) Software Configuration New Features. (AAA is also referred to as Security Services)
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt1/inde x.htm


Sample AAA Accounting Configuration

The Cisco IOS software AAA accounting user interface can be configured to use the H.323 method as follows:

The authentication command line creates a method list named H.323 with RADIUS being its only member.

Also note that the accounting command line looks like a regular RADIUS accounting command line for connection accounting. Connection accounting has to be globally enabled using this command line. Start-stop or stop only methods may be used.

Step  Command  Purpose 
1
5300> enable

Password: <password>

5300# 

Enter enable mode.

Enter the password.

You have entered enable mode when the prompt changes to 5300#.

2
5300# config term
Enter configuration commands, one per line. End
with CNTL/Z.
5300(config)#

Enter global configuration mode. You have entered global configuration mode when the prompt changes to 5300(config)#.

3
5300(config)# aaa new-model

Initiates the AAA script.

4
5300(config)# aaa authentication login h323 radius

Configures the router to use the H.323 method list for authentication purposes.

5
5300(config)# aaa accounting connection h323 start-stop radius

Tells the system to use connection based accounting and the H.323 service.

6
5300(config)# radius-server host 171.69.58.104 auth-port 165 acct-port 1646

This command sets the server host IP address, and the ports for both the authentication service and the accounting service.

7
5300(config)# radius-server key testing123

Tests the connection accounting service.

8
5300(config)# end

Ends the configuration session.

Tips



aaa new-model
aaa authentication local-override
aaa authentication login default radius
!
gw-accounting h323
!
radius-server host 10.90.1.1 auth-port 1645 acct-port 1646
radius-server key xxx

Interactive Voice Response

This application provides basic Interactive Voice Response (IVR) capabilities necessary to collect caller Personal Identification Number (PIN), passwords, and destination phone numbers. IVR consists of simple voice prompting and digit collection to collect information from the caller for the purpose of authenticating the user and to identify the destination.

"Simple" IVR allows the use of one of several interactive voice response scripts which are embedded in Cisco IOS software. The ability to modify the embedded scripts is not yet provided. However, the audio files (for the prompts) can be modified for the user.

The user receives a voice prompt instruction to enter a specific type of information, for example, a PIN number. After playing the voice prompt, the IVR feature starts the process of collecting some number of touch tones (digit collection).

The IVR application specifies a sequence of voice prompts and touch-tone collection instructions. IVR applications can be assigned to specific ports, or can be invoked based on DNIS. An IP/PSTN gateway can have several different IVR applications to accommodate many different gateway services. The IVR applications can be customized to present different interfaces to the caller. The functionality includes the ability to:

IVR Application Field

The application field is used to associate an application with an incoming call. This field is applicable to the dial-peer of the "pots" encapsulation type only. The application field, in the inbound dial-peer, is used to indicate the application that this incoming call should be delivered to. Examples of applications entered in this field are the IVR scripts. See "IVR Script Description".

ANI Authorization

ANI authorization initially takes place with the ANI as the account number. Based on authentication of the ANI and DNIS for the call, the user is either denied service (with an appropriate voice message) or prompted for an account number and PIN if authentication fails. If authentication succeeds (or subsequent authentication with the supplied account/PIN succeeds), the user is prompted for the destination phone number and the call is placed.

See "IVR Script Description".

IVR Script Description

The IVR scripts available are displayed below. Audio files are provided by Cisco, however it is recommended that you record your own audio file to be used with these scripts.


Note      Use the copy command to copy your audio file (.au file) to your Flash and the audio-prompt load command will read it into RAM. See "audio-prompt load".


To obtain a complete description of each use the show call application voice [<app-name>| summary] command and insert the desired script name in the <app-name> field. The output displays a description of each script.

A brief description of the IVR scripts follow:

Authenticates the call with ANI and DNIS, collects the destination data and makes the call.

Authenticates the call with ANI and DNIS, collects the destination data but if authentication fails, it collects the account and password.

Same as clid_authen, but uses a NULL password when authenticating rather than DNIS.

Same as clid_authen_collect, but uses a NULL password (does not use DNIS, or collect it).

This application interacts with the redialer and collects digits from it. For example, collect account number, and destination number. When placing the call to H.323, the set of fields in the call info structure are entered, destination, account.

Support for this script was introduced with Cisco IOS Release 11.3(7)NA.

This script is similar to clid_authen_col_npw, but it allows two retries (3 tries total) for entering the account and password. For each of the two retries, it plays a special retry message.

Support for this script was introduced with Cisco IOS Release 11.3(7)NA.

This is similar to clid_col_npw_3, but it does not collect a PIN number. Instead, it uses the collected account number with a NULL password for authentication.

Message Flow for clid_col_npw_3

The message progression for the clid_col_npw_3 IVR script is exactly the same as clid_authen_col_npw except if authentication with the collected (account and PIN number) failed, the old script just played a failure message (auth_failed.au) and then hung up.

After the first two failures, the new script will play auth_fail_retry.au, and collect the account and PIN numbers again. The caller can interrupt the message by entering digits for the account number. Entering the PIN number will be prompted with the same message as the first try.

If authentication fails the third time, it will play auth_fail_final.au, and then hang up.

This script plays the following prompts:

Asks caller to enter account number the first time.

Played after first two failures, asks user to re-enter account number.

Asks caller to enter PIN number.

Asks caller to enter destination phone number.

Informs caller that authorization failed 3 times.

Two of these audio files first introduced with Cisco IOS Release 11.3(7)NA:

Message Flow for clid_col_npw_npw

This call application tries to authenticate using (ani, NULL) as the (userid, user password) pair. If that fails, it collects the account number and authenticates with (account, NULL). It allows three tries for entering the account number before failing the call. If authentication succeeds, it plays a prompt to collect the destination number.

This IVR script plays the following .au files:

Asks the caller to enter account number the first time.

Plays after first two failures, asks user to re-enter account number.

Asks the caller to enter destination phone number.

Informs the caller that authorization has failed three times.

IVR Script Examples

The supported IVR scripts are described below as shown using the show call application voice <app name> command:

show call application voice clid_authen
sblab115>show call application voice clid_authen
Application clid_authen has 8 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
State collect_dest has 3 actions and 5 events
    Do Action IVR_ACT_TONE. tone=8
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_fail
    If Event IVR_EV_TIMEOUT do action IVR_ACT_TONE
          and goto state collect_fail count=0
State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:auth_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State collect_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:collect_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing

show call application voice clid_authen_collect
sblab115>show call application voice clid_authen_collect
Application clid_authen_collect has 10 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_account.au
            allowInt=1, pContent=0x60E4C564
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_pin has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_pin.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=pin
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_TIMEOUT goto state get_pin count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_destination.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:auth_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
 
sblab115>show call application voice clid_authen_collect
Application clid_authen_collect has 10 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_account.au
            allowInt=1, pContent=0x60E4C564
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_pin has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_pin.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=pin
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_TIMEOUT goto state get_pin count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_destination.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:auth_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing

show call application voice clid_authen_npw
sblab115>show call application voice clid_authen_npw                            
Application clid_authen_npw has 8 states with 0 calls active                    
  State start has 1 actions and 5 events                                        
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=NULL               
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK             
          and goto state start                                                  
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest                         
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail                       
  State end has 1 actions and 3 events                                          
    Do Action IVR_ACT_END.                                                      
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY         
          and do nothing                                                        
  State collect_dest has 4 actions and 7 events                                 
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:enter_destination.au                                     
            allowInt=1, pContent=0x0                                            
    Do Action IVR_ACT_ABORT_KEY. abortKey=*                                     
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#                         
    Do Action IVR_ACT_COLLECT_DIALPLAN.                                         
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_PLAY_COMPLETE do nothing                                    
    If Event IVR_EV_ABORT goto state collect_dest                               
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call                      
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_fail                       
    If Event IVR_EV_TIMEOUT goto state collect_fail count=0                     
  State place_call has 1 actions and 4 events                                   
    Do Action IVR_ACT_PLACE_CALL.                                               
            destination=  called=                                               
            calling=      account=                                              
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_UP goto state active                                   
    If Event IVR_EV_CALL_FAIL goto state place_fail                             
  State active has 0 actions and 2 events                                       
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
  State authenticate_fail has 1 actions and 2 events                            
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:auth_failed.au                                           
            allowInt=0, pContent=0x0                                            
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
  State collect_fail has 1 actions and 2 events                                 
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:collect_failed.au                                        
            allowInt=0, pContent=0x0                                            
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
  State place_fail has 1 actions and 2 events                                   
    Do Action IVR_ACT_PLAY_FAILURE_TONE.                                        
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
                                                                                
show call application voice clid_authen_col_npw
Application clid_authen_col_npw has 10 states with 0 calls active               
  State start has 1 actions and 5 events                                        
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=NULL               
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK             
          and goto state start                                                  
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest                         
    If Event IVR_EV_AAA_FAIL goto state get_account                             
  State end has 1 actions and 3 events                                          
    Do Action IVR_ACT_END.                                                      
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY         
          and do nothing                                                        
  State get_account has 4 actions and 7 events                                  
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:enter_account.au                                         
            allowInt=1, pContent=0x0                                            
    Do Action IVR_ACT_ABORT_KEY. abortKey=*                                     
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#                         
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+                    
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin                          
            patName=account                                                     
    If Event IVR_EV_ABORT goto state get_account                                
    If Event IVR_EV_PLAY_COMPLETE do nothing                                    
    If Event IVR_EV_TIMEOUT goto state get_account count=0                      
    If Event IVR_EV_PAT_COL_FAIL goto state get_account                         
  State get_pin has 4 actions and 7 events                                      
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:enter_pin.au                                             
            allowInt=1, pContent=0x0                                            
    Do Action IVR_ACT_ABORT_KEY. abortKey=*                                     
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#                         
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+                        
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate                     
            patName=pin                                                         
    If Event IVR_EV_PLAY_COMPLETE do nothing                                    
    If Event IVR_EV_ABORT goto state get_account                                
    If Event IVR_EV_TIMEOUT goto state get_pin count=0                          
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin                             
  State authenticate has 1 actions and 5 events                                 
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin            
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest                         
    If Event IVR_EV_TIMEOUT do nothing count=0                                  
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail                       
  State collect_dest has 4 actions and 8 events                                 
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:enter_destination.au                                     
            allowInt=1, pContent=0x0                                            
    Do Action IVR_ACT_ABORT_KEY. abortKey=*                                     
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#                         
    Do Action IVR_ACT_COLLECT_DIALPLAN.                                         
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_PLAY_COMPLETE do nothing                                    
    If Event IVR_EV_ABORT goto state collect_dest                               
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0                     
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call                      
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest                       
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0                     
  State place_call has 1 actions and 4 events                                   
    Do Action IVR_ACT_PLACE_CALL.                                               
            destination=  called=                                               
            calling=      account=                                              
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
    If Event IVR_EV_CALL_UP goto state active                                   
    If Event IVR_EV_CALL_FAIL goto state place_fail                             
  State active has 0 actions and 2 events                                       
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
  State authenticate_fail has 1 actions and 2 events                            
    Do Action IVR_ACT_PLAY.                                                     
            URL: flash:auth_failed.au                                           
            allowInt=0, pContent=0x0                                            
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing                                       
  State place_fail has 1 actions and 2 events                                   
    Do Action IVR_ACT_PLAY_FAILURE_TONE.                                        
    If Event IVR_EV_DEFAULT goto state end                                      
    If Event IVR_EV_CALL_DIGIT do nothing 

show call application voice fax_hop_on_1
sblab115>show call application voice fax_hop_on_1
Application fax_hop_on_1 has 8 states with 0 calls active
  State start has 2 actions and 5 events
    Do Action IVR_ACT_PLAY.
            URL: flash:redialer_tone.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern init_seq is \*\*
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_PAT_COL_SUCCESS goto state collect_account
            patName=init_seq
    If Event IVR_EV_PLAY_COMPLETE do nothing
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State collect_account has 2 actions and 3 events
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state init_seq
            patName=account
  State init_seq has 1 actions and 3 events
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern init_seq is \*\*
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state collect_dest
            patName=init_seq
  State collect_dest has 2 actions and 3 events
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern destination is .+
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=destination
  State authenticate has 1 actions and 4 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=NULL
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state place_call
    If Event IVR_EV_TIMEOUT do nothing count=0
  State place_call has 1 actions and 3 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=dnis  called=account
            calling=destination      account=account
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing

clid_col_npw_3
sblab160#show call app voice clid_col_npw_3
Application clid_col_npw_3 has 12 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=NULL
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL:flash:enter_account.au
            allowInt=1, pContent=0x60F66AD0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_account_retry has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL:flash:auth_fail_retry.au
            allowInt=1, pContent=0x60F87454
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_pin has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL:flash:enter_pin.au
            allowInt=1, pContent=0x60F6E178
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=pin
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_TIMEOUT goto state get_pin count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state fail_count
  State fail_count has 1 actions and 5 events
    Do Action IVR_ACT_COUNT. maxCount = 3
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_COUNT_LIMIT goto state authenticate_fail
    If Event IVR_EV_COUNT_OK goto state get_account_retry
    If Event IVR_EV_TIMEOUT do nothing count=0
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL:flash:enter_destination.au
            allowInt=1, pContent=0x60F75C10
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL:flash:auth_fail_final.au
            allowInt=0, pContent=0x60F92304
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
clid_col_npw_npw
sblab160#show call app voice clid_col_npw_npw
Application clid_col_npw_npw has 11 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=NULL
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL:flash:enter_account.au
            allowInt=1, pContent=0x60F66AD0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_account_retry has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL:flash:auth_fail_retry.au
            allowInt=1, pContent=0x60F87454
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=NULL
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state fail_count
  State fail_count has 1 actions and 5 events
    Do Action IVR_ACT_COUNT. maxCount = 3
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_COUNT_LIMIT goto state authenticate_fail
    If Event IVR_EV_COUNT_OK goto state get_account_retry
    If Event IVR_EV_TIMEOUT do nothing count=0
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL:flash:enter_destination.au
            allowInt=1, pContent=0x60F75C10
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL:flash:auth_fail_final.au
            allowInt=0, pContent=0x60F92304
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing

Fax Hop On/Off

Fax hop on/off is a specialized IVR application to support the use of redialer boxes in fax applications. Redialers are small units which connect between a fax machine and a telephone line, intercept the phone number dialed by the fax machine, and then place an outgoing call to another phone number (in this case, that of the voice gateway) and then forward the destination number intercepted from the fax machine to the gateway when prompted. Optionally, an account number can be included to identify the caller's organization for authentication and billing purposes.

IVR Commands

New Cisco IOS commands are available to deal with IVR functionality. These commands are entered when the dial peer is being configured. The commands are as follows:

See "Gateway Commands" for details information regarding these commands.

ISDN Redirect Number Support

The purpose of this feature is to support the redirecting call feature of the VoIP gateway. The redirecting number is an optional field of the Q.931 Setup message.

When a local exchange carrier (LEC) switch detects an incoming call that is destined for a busy or nonanswering party, the switch formulates a Q.931 Setup message with redirecting number field set to the original destination number, and sends it to the gateway. The called party number of the setup message will be set to one of the service access numbers dialed number identification service (DNIS) of the gateway.

If a redirect number is present on an incoming call, then it is used in place of the destination number (DNIS).

Dial Peer Configuration Restrictions for ISDNRedirect

The dial peer configuration for ISDN redirect involves setting up two audio scripts.

Incoming Dial Peer

To process incoming ISDN voice calls, incoming dial peers need to be configured. The dialed number identification service (DNIS) number of the incoming call is used to match the DNIS number field of the incoming dial peer. The direct-inward-dial flag of the dial peer determines whether a second dial tone is given to the caller to collect the target destination number. For this Cisco service provider feature, the DNIS is set to the access phone number of the Gateway, and the direct-inward-dial flag is set to TRUE.

Outgoing Dial Peer

The outgoing dial peer is selected based on the DNIS number of the incoming call. The outgoing dial peer indicates the session target of the outgoing call.

ISDNRedirect Call Flow Example

Rotary Call Pattern

The Rotary Calling Pattern feature provides the ability to route an incoming call arriving via a telephony interface back out via another telephony interface under certain circumstances. This is primarily used to provide reliable service during network failures. Call establishment via Rotary Call Pattern will be supported via rotary group support of dial peers, where multiple dial peers may match a given destination phone number and will be selected in sequence. Support for Rotary Call Pattern of calls active at the time of the network failure will not be provided in the first release.

Before Cisco IOS Release 11.3(6)NA2, if you wanted the system to search through a number of destinations, when a given number is dialed, you needed to configure those dial peers with the same destination pattern. Now with the Rotary Call Pattern feature, if you want the destinations to be tried in a certain order, you can assign preference. Use the preference command when configuring the dial peers to reflect that order.

Rotary Feature Functionality

If there are several dial peers that match a particular destination pattern, the system attempts to place a call to the one with the highest preference. If the call cannot be completed because of a system outage, for example, the gatekeeper or gateway cannot be contacted, the Rotary feature performs the following tasks:

If there are equal priority dial peers, the order is determined randomly.


Note      The hunting algorithm precedence is configurable. See the preference command in "Gateway Commands".


T1 CAS

Channel associated signaling (CAS) is the transmission of signaling information within the voice channel. In addition to receiving and placing calls, T1 CAS provides the receipt and capture of dialed number identification (DNIS) and automatic number identification (ANI) information. This particular information (DNIS and ANI) is used to support authentication and other functions that use this information.

This feature allows the support of E&M signaling on the T1 interface. Various types of CAS signaling are available in the T1 world. The most common forms of CAS signaling are loop-start, ground-start, and E&M. CAS signaling is often referred to as robbed-bit-signaling because user bandwidth is being `robbed' by the network for other purposes.

Service Provider Application

The service provider application for T1 CAS includes connectivity to the public network using T1 CAS from the Cisco AS5300 to the end office switch. In this configuration, the Cisco AS5300 captures the Dialed Number or called party number information and passes it along to the upper level applications, for IVR script selection, modem pooling, and other applications. Service Providers also require access to calling party number, ANI, for user identification, for billing account number, and in the future, more complicated call routing.

Service Providers implementing Voice over IP include traditional voice carriers, new voice and data carriers, and existing Internet Service Providers. Some of these service providers may use subscriber side lines for their Voice over IP connectivity to the PSTN, others will use tandem-type service provider connections.

T1 CAS Key Features

The new functionality of T1 CAS for voice includes all the T1 CAS and E1/R2 signaling already supported for the Cisco AS5300 in data applications, with the addition of dialed number and calling party number captured whenever available.

The implementation of this feature supports the following T1 CAS signaling systems for VoIP application:

E&M signaling is normally used for trunks. It is normally the only way that a CO switch can provide two-way dialing with Direct Inward Dialing. In all the E&M protocols, off-hook is indicated by A=B=1 and on-hook is indicated by A=B=0. If dial pulse dialing is used, the A and B bits are pulsed to indicate the addressing digits. The are several further important subclasses of E&M robbed-bit signaling:

In the original Wink Start protocol, the terminating side responds to an off-hook from the originating side with a short wink (transition from on-hook to off-hook and back again). This wink tells the originating side that the terminating side is ready to receive addressing digits. After receiving addressing digits, the terminating side then goes off-hook for the duration of the call.The originating endpoint maintains off-hook for the duration of the call.

In Feature Group D Wink Start with Wink Acknowledge protocol, the terminating side responds to an off-hook from the originating side with a short wink (transition from on-hook to off-hook and back again) just as in the original Wink Start. This wink tells the originating side that the terminating side is ready to receive addressing digits. After receiving addressing digits, the terminating side then provides another wink (called an Acknowledgment Wink) that tells the originating side that the terminating side has received the dialed digits. The terminating side then goes off-hook to indicate connection. This last indication can be due to an indication that the ultimate called endpoint has answered. The originating endpoint maintains off-hook for the duration of the call.

In the Immediate Start protocol, the originating side does not wait for a wink before sending addressing information. After receiving addressing digits, the terminating side then goes off-hook for the duration of the call. The originating endpoint maintains off-hook for the duration of the call.

Ground Start Signaling was developed to aid in resolving glare when two sides of the connection tried to go off-hook at the same time. This is a problem with Loop Start because the only way to indicate an incoming call from the network to the CPE using loop start was to ring the phone. The 6 second ring cycle left a lot of time for glare to occur. Ground Start Signaling gets around this problem by providing an immediate seizure indication from the network to the CPE. This indication tells the CPE that a particular channel has an incoming call on it. Ground Start is a little more difficult to describe than E&M in that the A and B bits do not track each other (that is, A is not necessarily equal to B). When the Central Office delivers a call, it "seizes" a channel (goes off-hook) by setting the A bit to 0. The Central Office equipment also simulates ringing by toggling the B bit. The terminating equipment goes off-hook when it is ready to answer the call. Digits are usually not delivered for incoming calls.

Channelized T1 Robbed Bit Features

Internet Service Providers can provide switched 56 kbps access to their customers using the Cisco AS5300. The subset of T1 CAS (Robbed Bit) supported features are listed as follows:

Supervisory: Line Side

Supervisory: Trunk Side

Informational: Line Side

Informational: Trunk Side

T1 CAS User Interface

Because T1 CAS is not new to the voice and telephony industry, existing Cisco documentation describes the functionality.

The cas-group (controller t1) command has been modified to reflect two service types. See Gateway Commands.

See the following Cisco CCO URLs for supporting documentation.

End user interface resembles the end user interface for T1 CAS for Cisco AS5300 MICA dial.


Note      T1 CAS fgd is asymmetric. When calling the switch, we only generate DNIS. When receiving form the CO, we get both ANI and DNIS.


Sample Configuration

The sample configuration is only intended as an example of how to use the commands to configure T1 CAS. It is not an example of a complete configuration for setting up the entire signaling for a telco network.


Note      For additional software configuration examples using T1 signaling, see "Configuring Channelized T1 or E1" for software configuration instructions. These examples show how to configure the access server for channelized T1 or E1 lines. This is a reference to the Voice Over IP for the Cisco AS5300 Configuration Examples.

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/5300swbk/5300bas.htm


Configuring Service Provider T1 CAS

The following sample configuration is an example of how to configure the voice ports as a cas-group for the channelized T1 lines.

Step  Command  Purpose 
1.
5300> enable
Password: <password>
5300# 

Enter enable mode.

Enter the password.

You have entered enable mode when the prompt changes to 5300#.

2.
5300# config term
Enter configuration commands, one per line. End
with CNTL/Z.
5300(config)#

Enter global configuration mode. You have entered global configuration mode when the 5300# prompt changes to 5300(config)#.

3.
5300(config)# controller t1 0

Enter controller configuration mode to configure your controller port. The controller ports are labeled 0 through 3 on the Quad T1/PRI and E1/PRI cards.

4.
5300(config-controller)# framing esf

Enter your telco's framing type.

5.
5300(config-controller)# clock source line primary

Enter the clock source for the line. Configure other lines as clock source secondary or internal. Note that only one PRI can be clock source primary and one PRI can be clock source secondary.

6.
5300(config-controller)# linecode b8zs

Enter your telco's line code type.

7.
5300(config-controller)# cas-group 1 timeslots 1-24  type e&m-fgb dtmf dnis

Configure all channels for E&M, FXS, and SAS analog signaling. Enter 1-24 for T1. If E1, enter 1-31.

Signaling types include e&m-fgb, e&m-fgd, e&m-immediate-start, fxs-ground-start, fxs-loop-start, sas-ground-start, and sas-loop-start.

You must use the same type of signaling that your central office uses.

For E1 using the Anadigicom converter, use cas e&m-fgb signaling.

8.
5300(config-controller)# controller t1 1
5300(config-controller)# framing esf
5300(config-controller)# linecode b87s
5300(config-controller)# clock source line secondary
5300(config-controller)# cas-group 2 timeslots 1-24 type e&m-fgb

Repeat steps 3 to 7 to configure each additional controller (there are four). In this example, note that the controller number is 1, instead of 0. The clock source is secondary, instead of primary. The cas-group is 2, instead of 1.

9.
5300(config-controller)# controller T1 2
5300(config-controller)# clock source internal
5300(config-controller)# cas-group 0 timeslots 1-24 type e&m-fgd mf ani-dnis

Repeat steps 3 to 7 to configure each additional controller (there are four).

10.
5300(config-controller)# controller T1 3
5300(config-controller)# clock source internal

Repeat steps 3 to 7 to configure each additional controller (there are four).

11.
5300(config-controller)# Ctrl-Z 

Return to enable mode.

12.
5300(config-controller)# dial-peer voice 3070 pots
 destination-pattern +30...
 port 0:1
 prefix 30

Enter the dial peer configuration mode to configure a POTS peer.
Specify destination pattern for this POTS peer.

13.
5300(config-controller)# dial-peer voice 4080 pots
 destination-pattern +40...
 direct-inward-dial
 port 1:1
 prefix 40

Specify destination pattern, and direct inward dial for each POTS peer.

14.
5300(config-controller)# dial-peer voice 1050 pots
 destination-pattern +10...
 direct-inward-dial
 prefix 50

Specify the destination pattern and the direct inward dial for the dial peer.

15.
5300(config-controller)# dial-peer voice 2060 pots
 destination-pattern +20...
 direct-inward-dial
 prefix 60

Specify the destination pattern and the direct inward dial for the dial peer.

16.
5300(config-controller)# dial-peer voice 5050 voip
 answer-address 10...
 destination-pattern +50...

Specify the destination pattern and the direct inward dial for the dial peer.

17.
5300(config-if)# Ctrl-Z 
5300#
%SYS-5-CONFIG_I: Configured from console by console

Return to enable mode.

This message is normal and does not indicate an error.

Verify

To verify your controller is up and running and no alarms have been reported:

5300# sh cont t1 2
 T1 2 is up.
   No alarms detected.
   Version info of slot 0:  HW: 2, Firmware: 16, PLD Rev: 0
 
 Manufacture Cookie Info:
  EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42,
  Board Hardware Version 1.0, Item Number 73-2217-4,
  Board Revision A0, Serial Number 06467665,
  PLD/ISP Version 0.0, Manufacture Date 14-Nov-1997.
 
   Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
   Data in current interval (269 seconds elapsed):
    0 Line Code Violations, 0 Path Code Violations
      0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
      0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Note the following:

Tips

If you are having trouble:

Make sure the show controller t1 output is not reporting alarms or violations.

Gatekeeper Feature Descriptions

The two main features of the gatekeeper that have been enhanced to support internetworking with the gateway are:

Brief descriptions of these features follow.


Note      See the "Command Reference" section for a complete description of the new gatekeeper Cisco IOS commands used to configure the gatekeeper features.


HSRP Support

Gatekeeper HSRP (Hot Standby Router Protocol) support consists of elements in both the gateway and gatekeeper functions in the router. The gateway periodically retries its registration when it detects a possible gatekeeper failure, in order to register itself with the backup gatekeeper. Although it is a backup, the gatekeeper operates in a passive mode in which it does not accept registrations, and becomes active when it is notified by HSRP that it will become the primary gatekeeper.


Note      See the "Command Reference" section for a complete description of the new gatekeeper Cisco IOS commands used to configure the gatekeeper features.


Configuring Gatekeepers for Hot Standby

Cisco gatekeepers can be configured to use HSRP so that when one gatekeeper fails, the standby gatekeeper assumes its role.


Step 1   Select one interface on each gatekeeper which will serve as the HSRP interface and configure these two interfaces so that they belong to the same HSRP group and have different priorities. The one with the higher priority will be the active gatekeeper, the other assumes the standby role.

Step 2   Make a note of the virtual HSRP IP address shared by both.

Step 3   Configure the gatekeepers so that this HSRP virtual IP address is the RAS address for all local zones.

Step 4   Ensure that the gatekeeper mode configurations on both routers are identical.

Tips



Sample Gatekeeper HSRP Configuration

In this example, Ethernet 0 is used as the HSRP interface on both gatekeepers and the gatekeeper is configured using either a Cisco 3620 or Cisco 3640 modular access router. The three stages of the sample gatekeeper HSRP configuration are displayed in the proceeding tables:

Task List

Note      Enter configuration commands, one per line. End with CNTL/Z, or press the End key.


Configure the Primary Gatekeeper

Step  Command  Purpose 
1.
36xx# config term

Enter configuration mode.

2.
36xx(config-if)# int e0

Enter interface configuration mode for interface e0.

3.
36xx(config-if)# standby 1 ip 172.21.127.55

Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55.

4.
36xx(config-if)# standby 1 timers 5 15

Set hello timers to 5 seconds, hold timer to
15 seconds.

5.
36xx(config-if)# standby 1 priority 110

Sets standby priority to 110.

6.
36xx(config-if)# end

End the configuration of the primary gatekeeper.

Configure the Backup Gatekeeper

Step  Command  Purpose 
1.
36xx# config term.

Enter configuration mode.

2.
36xx(config-if)# int e0

Enter interface configuration mode for interface e0.

3.
36xx(config-if)# standby 1 ip 172.21.127.55

Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55.

4.
36xx(config-if)# standby 1 timers 5 15

Set the hello timers for 5 sec and the hold timer for 15 sec.

5.
36xx(config-if)# end

End the configuration of the backup gatekeeper.


Note      The configurations are identical except that gk2 has no standby priority configuration, so it assumes the default priority of 100. This means that gk1 has a higher priority.


Configure Identical Gatekeeper Modes on Both Gatekeeper 1 and Gatekeeper 2

Step  Command  Purpose 

 

On Gatekeeper gk1

 

1.
36xx# config term

Enter configuration mode.

2.
36xx(config)# g

Enter gatekeeper configuration mode.

3.
36xx(config-gk)# zone local gk-sj cisco.com 172.21.127.55

Define local zone using HSRP virtual address as gatekeeper's RAS address.

Note At this point, various other gatekeeper configuration are also performed which are not specific to the HSRP configuration. After all required gatekeeper tasks are performed. Continue.
4.
36xx(config-gk)# no shut

Allow various other gatekeeper mode configurations to bring up the
gatekeeper.

 

On Gatekeeper gk2

 

1.
36xx# config t

Enter configuration mode.

2.
36xx(config-gk)# gatekeeper

Enter gatekeeper config mode.

3.
36xx(confi-gk)# zone local gk-sj cisco.com 172.21.127.55

Define local zone using HSRP virtual address as gatekeeper's RAS address.

Note This uses the same gkname and address as on gk1.
4.
36xx(config-gk)# no shut

Allow various other gatekeeper mode configurations to bring up the
gatekeeper.


Note      The bring-up command no shut is issued on both gatekeepers, primary and secondary.


Tips

If you issue a show gatekeeper status command on the two gatekeepers, you will see on gk1:

Gatekeeper State: UP

However, if this command is issued on gk2, you will see:

Gatekeeper State: HSRP STANDBY

E.164 Address Support

There are two types of addresses used in H.323 destination calls.

The Cisco IOS Release 11.3(2)NA software feature Multimedia Conference Manager dealt primarily with H.323-ID addressing in interzone calls. With the new prefix commands, the administrator can now also configure interzone routing when calls are made using E164 addresses.


Note      To refer to the Multimedia Conference Manager, see the Cisco CCO product documentation web site at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113na/1137na/mcm_cfg.htm


H.323 ID Addresses

When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve "bob@cisco.com," the source endpoint's gatekeeper finds the gatekeeper for "cisco.com," and sends it the Location Request (LRQ) for target address "bob@cisco.com." The destination gatekeeper looks in the registration database, sees "bob" registered, so returns the appropriate IP address to get to bob.

E.164 Addresses

When using E164 addresses, call routing is handled through means of zone prefixes and "gateway-type" or technology prefixes.

Zone Prefixes

The zone prefixes (typically area codes) serve the same purpose as the domain names in the H.323-ID address space.

For instance, if our local gatekeeper has been configured with the knowledge that zone prefix "212......" (that is, any address beginning "212" and followed by 7 arbitrary digits) is handled by gatekeeper "gk-ny":

router(config-gk)# zone prefix gk-ny 212.......

then when the local gatekeeper is asked to admit a call to destination address "2125551111", it knows to send the Location Request to gk-ny.

However, when the query gets to gk-ny, gk-ny still needs to resolve the address so that the call can be sent to its final destination. There may actually be an H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny will return the IP address for that endpoint. However, the probability is that the E.164 address belongs to a non-H.323 device (for example, a telephone or an H.320 terminal). Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge of whom the address belongs to. It needs to be able to select a gateway which can be used to reach the non-H.323 device. This is where the technology prefixes (or "gateway-type") becomes useful.

Technology Prefixes

The network administrator selects technology prefixes (tech-prefixes) to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers with these prefixes. For example, voice gateways may register with tech-prefix "1#," H.320-gateways with tech-prefix "2#," voicemail-gateways with "3#," and so on. More than one gateway may register with the same type prefix. When that happens, the gatekeeper makes a random selection among gateways of the same type.

The caller, who knows the type of device they are trying to reach, can now prepend a tech-prefix to the destination address to indicate the type of gateway to use to get to the destination.

Example:

The caller might ask for 1#2125551111 if they know that the address 2125551111 is for a telephone and the tech-prefix for voice gateways is "1#." When the voice gateway receives the call for 1#2125551111, it strips off the tech-prefix and bridges the next leg of the call to the telephone at 2125551111.

In cases where the call scenario is:

telephone -----> voice-gw1 -----> voice-gw2 ----->telephone

(PSTN) (H.323) (PSTN)

voice-gw1 can be configured (using the dial-peer command) to prepend the voice tech-prefix "1," so that the use of technology prefixes is completely transparent to the caller.


Note      Technology prefixes are transmitted (as part of the called_number) to the destination gateway. Therefore, the customer must configure the dial-peers at the destination gateway to match on the technology prefix.


There are a couple of interesting features in the implementation of the gw-type-prefix command.


Note      See "Command Reference" on page 48for a description of the technology prefix related commands.


Default Technology

If the majority of calls hop off on a particular type of gateway, the gatekeeper can be configured to use that type of gateway as the default type, so that callers no longer have to prepend a tech-prefix on the address. For example, if what you use in your network are mostly voice gateways, and you have configured all your voice gateways to register with tech-prefix 1, you can configure your gatekeeper to use "1#" gateways as the default:

router(config-gk)# gw-type-prefix 1# default-technology

Now a caller no longer needs to prepend "1#" to use a voice gateway. Any address that does not contain an explicit tech-prefix will be routed to one of the voice gateways which registered with "1#."

With this default-technology definition, suppose a caller asks the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it will route the call to one of its local "1#" voice gateways, so the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it sends a Location Request for 2125551111 to gk-ny. This requires that gk-ny also be configured with some default gateway type prefix, and that its voice gateways be registered with that prefix.

Force Technology Prefix Hop-off

The other gateway-type feature is the ability to force a hop-off to a particular zone. Normally, when an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper resolves the destination address by first looking for the tech-prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address resolves to a remote zone, the entire address, including both technology and zone prefixes, is sent to the remote gatekeeper in a Location Request. That remote gatekeeper then uses the tech-prefix to decide which of its gateways to hop off.

The zone-prefix determines the routing to a zone, when there, the tech-prefix determines the gateway in that zone. See "zone prefix" for a description of the command.

This behavior can be overridden by associating a forced hop-off zone with a particular tech-prefix. What this does is force the call to the specified zone, regardless of what the zone-prefix in the address is.

A hypothetical example to demonstrate a forced hop-off follows:you are in the 408 area code (San Jose) and you want calls to the 212 area code to hop-off in New York via VoIP to save costs but you do not have any gateway in New York. However you do have a H.323 gateway in Denver and to hop-off from Denver is cheaper than to locally hop-off from San Jose. In this case, you would define the gateway-type prefix 212 for H.323 gateways to always be forced to the Denver zone.

Technology Prefixes

Technology prefixes are used to distinguish between gateways having specific capabilities within a given zone. They are handled specially because the technology prefix is ignored during the zone selection process and then examined for gateway selection within the zone. This requires that the prefix be ignored during the zone selection process. Technology prefixes have been designed to enable the use of E.164 address routing. E.164 is an International Telecommunications Union (ITU) specification for the ISDN international telephone numbering plan, which has traditionally only been used in telephone networks.

The gateway technology prefix is set up using the following new commands.

See "Command Reference" for a description of the technology prefix related commands. The technology prefixes are transmitted (as part of the called_number) to the destination gateway. Therefore, the customer must configure the dial-peers at the destination gateway to match on the technology prefix.

Gatekeeper and Gateway Internetworking Configuration

All of the Service Provider for VoIP features are configured when setting up the gatekeeper and gateway internetworking configuration. The example configurations provided in this documentation are supplied for reference only.

Configuration Prerequisites

Before you can configure your Cisco AS5300 for Service Provider Features, ensure you have the following installed:

These configuration tasks are based on the assumption that all necessary tasks and configurations have been performed as described in the document Voice Over IP for the Cisco AS5300 Universal Access Server Software Configuration Guide, which includes the following topics:


Note      The Voice over IP for the Cisco AS5300 is located on the CCO web site at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip5300/index.htm.


SNMP MIBS Supporting QoV and QoS

The SNMP MIBS are available on CCO. The CISCO-VOICE-DIAL-CONTROL-MIB supports the QoV and QoS of VoIP calls. Refer to the online support reference listed at the following location:

Sample Gatekeeper Configuration

This sample gatekeeper configuration uses the E.164 address routing configuration and is based on the following assumptions:

The command syntax for each step uses these domain names and therefore are given for descriptive purposes only. Be sure to determine the local and remote gatekeeper domain names, and the appropriate IP addresses, prior to starting your own configuration.

The command syntax for each step uses these domain names and therefore are given for descriptive purposes only. Be sure to determine the local and remote gatekeeper domain names, and the appropriate IP addresses, before starting your own configuration.

It is recommended that the gatekeeper ID should be in the form of gkname.domainname. This is to avoid ambiguity when a gatekeeper communicates with other gatekeepers in another domain.


Note      This is sample configuration and is only intended as an example of how to use the zone-prefix and gw-type-prefix commands when configuring gatekeepers. It is not an example of a complete configuration of the gatekeeper.


On the gatekeeper for San Jose:

The gatekeeper is enabled by entering the following commands:

Command Mode

Gatekeeper Configuration:


Step 1   Initiate configuration mode.

36xx# config term

Step 2   Enter gatekeeper configuration mode.

36xx(config)# gatekeeper

Step 3   Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-sj" and the domain name is "cisco.com". Enter:

zone local gk-sj cisco.com


Note Although domain names are not used for Voice over IP calls using E.164 address, this is a mandatory argument for the zone local command.


Step 4   Notify the gatekeeper that gatekeeper "gk-ny" manages the "212" area code so that calls to E.164 addresses beginning with 212 should be sent to "gk-ny" (at 172.21.127.27) Enter:

zone remote gk-ny cisco.com 172.21.127.27

Step 5   Define the accessibility for local zone "gk-sj." This states that the calls originating in any (default) zone, "gk-sj" should offer "direct" (unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call. Enter:

zone access gk-sj default direct


Note The "." character is used as a wildcard character when specifying the area code and phone numbers in the configuration.


Step 6   Configure the gatekeeper to handle the 408 area code. Enter:

zone prefix gk-sj 1408.......

Step 7   Notify the gatekeeper that gatekeeper "gk-ny" manages the 212 area code, so that calls to E.164 addresses beginning with 1212 should be sent to "gk-ny" (at 172.21.127.27). Enter:

zone prefix gk-ny 1212.......

Step 8   Define a gateway technology prefix "3#" and stipulate that any calls to addresses beginning with this technology prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix is. Enter:

gw-type-prefix 3# hopoff gk-sj

Step 9   Define a gateway technology prefix "4#". The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing unresolveable addresses. Enter:

gw-type-prefix 4# default-technology

On the gatekeeper for New York:
Command Mode

Gatekeeper configuration


Step 1   To initiate the configuration mode, enter:

config term

Step 2   Enter the gatekeeper configuration mode:

gatekeeper

Step 3   Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-ny" and the domain name is "cisco.com."

zone local gk-ny cisco.com


Note Although domain names are not used for Voice over IP calls using E.164 addresses, this is a mandatory argument for the zone local command.


Step 4   Notify the gatekeeper about a remote gatekeeper called "gk-sj" which is located at IP address 172.21.1.48.

zone remote gk-sj cisco.com 172.21.1.48

Step 5   Define the accessibility for local zone "gk-ny." This states that the calls originating in any (default) zone, "gk-ny" should offer "direct" (that is, unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call.

zone access gk-ny default direct


Note The "." character is used as a wildcard character when specifying the area code and phone numbers in the configuration.


Step 6   Configure the gatekeeper to handle the 1212 area code.

zone prefix gk-ny 1212.......

Step 7   Notify the "gk-ny" gatekeeper that manages the 408 area code, so that calls to E.164 addresses beginning with 1408 should be sent to "gk-sj" (at 172.21.1.48).

zone prefix gk-sj1408......

Step 8   Define a gateway technology prefix "3#" and stipulate that any calls to addresses beginning with this tech prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix.

gw-type-prefix 3# hopoff gk-ny

Step 9   Define a gateway technology prefix "4#." The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing otherwise, unresolveable addresses.

gw-type-prefix 4# default-technology

Comments:

Continuing with this example in San Jose suppose we have gateways registering with gk-sj as follows:

gw-sj2 configured to register with tech prefix 2#
gw-sj3 configured to register with tech prefix 3#
gw-sj4 configured to register with tech prefix 4#

Similarly, in New York, gateways are configured to register with gk-ny as follows:

gw-ny2 configured to register with tech prefix 2#
gw-ny3 configured to register with tech prefix 3#
gw-ny4 configured to register with tech prefix 4#

Given the above configuration, in San Jose, a call is presented to the gatekeeper (gk-sj) with the following target address:

Example 1—Target address 2#12125551212

gk-sj recognizes that 2# is a tech prefix (it was not configured as such, but because gw-sj2 registered with it, the gatekeeper now treats 2# as a tech prefix) strips that and is left with "12125551212." This is matched against the zone prefixes, and is a match for 1212......., so gk-sj knows that gk-ny handles this. It forwards the whole address "2#12125551212" over to gk-ny, who also looks at the tech prefix 2#, and routes this to gw-ny2.

Example 2—Target address 12125551212

gk-sj checks this against known tech prefixes, no match. Checks against zone prefixes, matches on 1212....... for gk-ny, so routes this to gk-ny. gk-ny does not have any local registrations for this address, and there is no tech prefix on the address, but his default prefix is 4# and gw-ny4 is registered with 4#, so the call gets routed to gw-ny4.

Example 3—Target address 3#12125551212

Because this contains the tech prefix of 3# and that is defined as a local-hopoff prefix, gk-sj just routes this to gw-sj3, despite the fact that it contains a zone-prefix for New York.

Example 4—Target address 16505551212

gk-sj looks for a technology prefix match, and fails. Looks for a zone-prefix match and fails again. But succeeds in finding a default gateway prefix of 4#. And succeeds when gw-sj4 is registered with 4#. So, the call gets sent routed out on gw-sj4.

Sample Gateway Configuration

This is an example of the configuration steps required to allow the internetworking functionality between the VoIP gateway and the gatekeeper.

See "Gateway Commands" for detailed information about the commands used in this sample configuration.


Note      Enter configuration commands, one per line. End by pressing the <control> key, and then press <z> key.


To Enable the Gateway
Command Mode

Configuration


Step 1   To enable the gateway, enter the following commands:

5300# config term

5300-1(config)# gateway


Note To disable the gateway, use the no gateway command in configuration mode. If active calls exist, the gateway cannot be disabled.


Step 2   Configure the interface. Only one interface is allowed to be the gateway interface.

The user can select either the interface that is connected to the gatekeeper, or a loopback interface. The interface that is connected to the gatekeeper is usually a LAN interface (That is, Fast Ethernet, Ethernet, FDDI, or Token-Ring). In this example, the fast Ethernet interface is used.

Step 3   Enable the interface as an H.323 Gateway VoIP Interface.

An interface is identified as a Gateway VoIP interface when the following commands are entered in the interface in configuration mode:

5300-1(config)#

%SYS-5-CONFIG_I: Configured from console by console

5300-1(config)# int fa0

5300-1(config-if)# h323 voip interface


Note To indicate that this interface is no longer a gateway VoIP interface, use the no prefix.


Step 4   Specify an H.323 ID for this interface.

An H.323 ID specifies the ID used by this gateway when this gateway communicates with the gatekeeper. Usually, this H.323 ID is the name given to the gateway with the gatekeeper domain name appended.

For example, if the name of this gateway is voip1, and this gateway is in the domain called vm1lab, then the H.323 ID will be voip1@vm1lab.

Step 5   To specify the gateway H.323 ID, use the following command:

5300-1(config)#

%SYS-5-CONFIG_I: Configured from console by console

5300-1(config)# int fa0

5300-1(config-if)# h323-gateway voip h323-id voip1@vm1lab


Note To disable the H.323 ID, use the no prefix.


Step 6   Specify a technology prefix.

A technology prefix is used to identify a type of service that this gateway is capable of providing.

For example, if this gateway is connected to a Voice Mail server, and if the technology prefix that indicates voice mail service is "7#", then the following command will specify this service:


5300-1(config)#

%SYS-5-CONFIG_I: Configured from console by console

5300-1(config)# int fa0

5300-1(config-if)# h323-gateway voip tech-prefix 7#

To disable a technology prefix, use the no prefix.


Note      If a gateway is capable of handling multiple services, specify each service with a tech-prefix command.


Step 7   Identify a gatekeeper. The specified gatekeeper ID must exactly match the gatekeeper ID in the gatekeeper configuration.

This is an optional command to identify the name of the gatekeeper that this gateway wants to communicate to. If this command is not given, the gateway will use multicast to find the gatekeeper.

The syntax of this command follows:

h323 voip id <name_of_the_gatekeeper> [multicast | ipaddr A.B.C.D [port <number>]

For example:

    (a). Identify a gatekeeper id and use multicast:

5300-1# conf t
5300-1(config)# int fa0
5300-1(config-if)# h323 voip id gk1.vm1lab multicast

    (b). Identify a gatekeeper id and use a unicast address:

5300-1# conf t
5300-1(config)# int fa0
5300-1(config-if)# h323 voip id gk1.vm1lab ipaddr 10.10.10.1

    (c). Identify a gatekeeper id and specify both unicast address and port:

5300-1# conf t
5300-1(config)# int fa0
5300-1(config-if)# h323 voip id gk1.vm1lab ipaddr 10.10.10.1 port 1719

Step 8   To find the current registration status of the gateway, use the following show command:

5300-1# sh gateway

Gateway voip1@vm1lab is not registered to any gatekeeper

If the gateway is not registered with any gatekeeper, the show command will indicate the above status. If the gateway is registered with a gatekeeper, the show command will indicate:

5300-1# sh gateway

Gateway voip1@vm1lab  is registered to gatekeeper gk1.vm1lab

Step 9   Determine the dial peer change.

This is an example of a dial-peer that uses RAS

5300-1# sh dial-peer vo 1234

VoiceOverIpPeer1234

The following display is shown:

        tag = 1234, destination-pattern = 1234',
        answer-address = ',
        group = 1234, Admin state is up, Operation state is up,
        incoming called-number = ', connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = ras',
        technology prefix: 8#
        ip precedence = 0, UDP checksum = disabled,
        session-protocol = cisco, req-qos = controlled-load, 
        acc-qos = best-effort, 
        fax-rate = voice, codec = g729r8, 
        Expect factor = 10, Icpif = 30,
        VAD = enabled, Poor QOV Trap = disabled,
        Connect Time = 0, Charged Units = 0,
        Successful Calls = 0, Failed Calls = 0,
        Accepted Calls = 0, Refused Calls = 0,
        Last Disconnect Cause is "",
        Last Disconnect Text is "",
        Last Setup Time = 0.

Miscellaneous Notes

The differences between this dial-peer and a normal VoIP dial-peer are:

Command Reference

This section contains the command reference pages for the new commands, and also commands which have changed since Cisco IOS Release 11.3(2)NA.

This section documents commands for the following:

This section uses the following text conventions:

Convention  Meaning  Comments 

Boldface

Commands and keywords you enter literally as shown

offset-list

Italics

Variables for which you supply values

command type interface

You replace the variable with the type of interface.

In contexts that do not allow italics, such as online help, arguments are enclosed in angle brackets (< >).

Square brackets ([ ])

Optional elements

command [abc]

abc is optional (not required), but you can choose it.

Vertical bars ( | )

Separated alternative elements

command [ abc | def ]

You can choose either abc or def, or neither, but not both.

Braces ({ })

Required choices

command { abc | def }

You must use either abc or def, but not both.

Braces and vertical bars within square brackets ([ { | } ])

A required choice within an optional element

command [ abc { def | ghi } ]

You have three options:

  • nothing
  • abc def
  • abc ghi

Caret character (^)

Control key

The key combinations ^D and Ctrl-D are equivalent: Both mean hold down the Control key while you press the D key. Keys are indicated in capital letters, but are not case sensitive.

A string

A nonquoted set of characters

For example, when setting an SNMP community string to public, do not use quotation marks around the string; otherwise, the string will include the quotation marks.

System prompts

Denotes interactive sessions, indicates that the user enters commands at the prompt

The system prompt indicates the current command mode. For example, the prompt Router (config) # indicates global configuration mode.

Screen font

Terminal sessions and information the system displays

Display output from commands, or software configuration examples.

Angle brackets (< >)

Nonprinting characters such as passwords

For example, name the gatekeeper <city><domainname> for easy identification.

Exclamation points (!) at the beginning of a line

A comment line

Comments are sometimes displayed by the Cisco IOS software.

Gatekeeper Commands

The following gatekeeper commands first appeared in Cisco IOS Release 11.3(6)NA2.

arq reject-unknown-prefix

The arq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.

arq reject-unknown-prefix
no arq reject-unknown-prefix

Syntax Description

This command has no arguments or keywords.

Default

no arq reject-unknown-prefix.

Command Mode

Gatekeeper configuration

Usage Guidelines

This command first appeared in the Cisco IOS Release 11.3(6)NA.

You can use the arq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) for a destination E.164 address which does not match any configured zone prefixes.

When an endpoint or gateway initiates an H.323 call, it sends an ARQ to its gatekeeper. The gatekeeper uses the configured list of zone prefixes to determine to which zone the call should be directed. If the called address does not match any known zone prefixes, the gatekeeper will attempt to hairpin the call out through a local gateway with a matching technology prefix. If this is not the desired behavior, then use the arq reject-unknown-prefix command to mandate that such calls should be rejected.

This command is typically used either to restrict local gateway calls to a known set of prefixes, or to deliberately fail such calls so that an alternate choice on a gateway's rotary dial-peer can be selected.

Example

The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:

zone local gk408 cisco.com
zone remote gk415 cisco.com 172.21.139.91
zone prefix gk408 1408.......
zone prefix gk415 1415.......

In the above example, the gatekeeper manages a zone containing gateways to the 408 area code, and it knows about a peer gatekeeper with gateways to the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone.

If an endpoint wishes to make a call to the 408 area code, the call will be routed out through a local gateway. If the call is to the 415 area code, it will be directed to the gk415 zone and hop off on a gateway there. But if a call is made to, say, the 212 area code, it will also be directed to a local gateway in the gk408 zone.

Now if you add the command:

arq reject-unknown-prefix

when a call is made to the 212 area code, it is now rejected because the destination address does not match any configured prefixes.

gw-type-prefix

To configure a technology prefix in the gatekeeper, use the gw-type-prefix command. To remove the technology prefix, use the no form of the command.

gw-type-prefix type-prefix[hopoff gkid][default-technology]
[[
gw ipaddr ipaddr [port ]] ...]
no gw-type-prefix type-prefix [hopoff gkid] [default-technology]
[[gw ipaddr ipaddr [ port ]] ...]

Syntax Description

type-prefix

A technology prefix is recognized and is stripped before checking for the zone prefix. It is strongly recommended that you select technology prefixes that do not lead to ambiguity with zone prefixes. Do this by using the # character to
terminate technology prefixes, for example, 3#.

hopoff gkid

(Optional) Use this option to specify the gatekeeper or zone where the call is to hop off, regardless of the zone prefix in the destination address. The gkid
argument refers to a zone previously configured using the zone local or zone remote comment.

default-technology

(Optional) Gateways registering with this prefix option are used as the default for routing any addresses that are otherwise unresolved.

gw ipaddr ipaddr [port]

(Optional) Use this option to indicate that the gateway is incapable of registering technology prefixes. When it registers, it adds the gateway to the group for this type-prefix, just as if it had sent the technology prefix in its registration. This parameter can be repeated to associate more than one gateway with a technology prefix.

Default

No technology prefix is defined.

Command Mode

Gatekeeper configuration

Usage Guidelines

This command first appeared in Cisco Release 11.3(6)NA2.

Related Command

zone prefix.

Example

The following example specifies 4# as the default technology prefix:

gw-type-prefix 4# default-technology

lrq reject-unknown-prefix

The lrq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.

lrq reject-unknown-prefix
no lrq reject-unknown-prefix

Syntax Description

This command has no arguments or keywords.

Default

No lrq reject-unknown-prefix.

Command Mode

Gatekeeper configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA.

You can use the lrq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes.

When the gatekeeper receives a Location Request asking about an E.164 address, it matches the target address against the list of configured zone prefixes. If the address matches a zone prefix, the behavior is unambiguous and well-defined:

However. if the target address does not match any known local or remote zone prefixes, then the default behavior is to attempt to service the call using one of the local zones. This default behavior may not be suitable for all sites, so the lrq reject-unknown-prefix command allows you to force the gatekeeper to reject such requests.

Example

The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:

zone local gk408 cisco.com
zone local gk415 cisco.com
zone prefix gk408 1408.......
zone prefix gk415 1415.......
lrq reject-unknown-prefix

In the above example, the gatekeeper manages two zones, one with gateways with interfaces in the 408 area code, and one with gateways in the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone. Now say some other zone had been erroneously configured to route calls to the 212 area code to this gatekeeper. When the Location Request arrives, this gatekeeper fails to match the area code, and so the LRQ is rejected.

However, if this was your only site that had any gateways in it, and you wanted your other sites to route all calls requiring gateways to this gatekeeper, then you would undo the reject command:

no lrq reject-unknown-prefix

Now, with this command entered, when the gatekeeper receives an LRQ for the address 12125551234, it will attempt to find an appropriate gateway in either one of the zones gk408 or gk415 to service the call.

show gatekeeper gw-type-prefix

To display the gateway-type prefix table, use the show gatekeeper gw-type-prefix EXEC command.

show gatekeeper gw-type-prefix

Command Mode

Privileged EXEC (also known as Enable mode)

Usage Guidelines

This command first appeared in the Cisco IOS Release 11.3 NA.

Sample Output

The following is sample output from the show gatekeeper gw-type-prefix command:

router# show gatekeeper gw-type-prefix
(GATEWAYS-TYPE PREFIX TABLE
================================
Prefix: 3#*    (Hopoff- gk408)

Prefix: 4#*    (Default gateway-technology)
 Static Configured Gateways:
    
Prefix: 7#*    (Hopoff gk408)
 Static Configured Gateways:
    1.1.1.1:1720
    2.2.2.2:1720
            Field       Description         Prefix:

     The tech-prefix defined with the gw-type-prefix command.

       (Hopoff gk408)

     Calls specifying tech-prefix 3# or 7# will always be routed to zone gk408, regardless of the actual zone-prefix in the destination address.

       (Default gateway-technology)

     The address associated with the technology prefix is a gateway used as the default for routing any addresses that are otherwise unresolveable.

       Static Configured Gateways:

     Lists all IP addresses and port numbers of statically configured gateways.

    

show gatekeeper status

To show overall gatekeeper status that includes authorization and authentication status, zone status, and so on, use the show gatekeeper status EXEC command.

show gatekeeper status

Syntax Description

This command has no arguments or keywords.

Command Mode

Privileged EXEC (also known as Enable mode)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 NA.

Sample Display

The following is sample output from the show gatekeeper status command:

router# show gatekeeper status

Gatekeeper State: UP
Zone Name: gk-px4.cisco.com
Accounting: DISABLED
Security: DISABLED

Field  Description 

Gatekeeper State

  • UP is operational.
  • DOWN is administratively shut down.
  • INACTIVE is administratively enabled, that is, the no shutdown command has been issued but no local zones have been configured.
  • HSRP STANDBY indicates the gatekeeper is on hot standby and will take over if the currently active gatekeeper fails.

Zone Name

Zone name.

Accounting

Authorization and accounting status.

Security

Security status.

show gatekeeper zone prefix

To display the zone prefix table, use the show gatekeeper zone prefix EXEC command.

show gatekeeper zone prefix

Command Mode

Privileged EXEC (also known as Enable mode)

Usage Guidelines

This command first appeared in the Cisco IOS Release 11.3 NA.

Sample Output

The following is sample output from the show gatekeeper zone prefix command:

5300# show gatekeeper zone prefix
      ZONE PREFIX TABLE
      =================
GK-NAME               E164-PREFIX
-------               -----------
gk.zone13             212.......
gk.zone14             415.......

gk.zone14 408.......

Field  Description 

GK-NAME

The gatekeeper name.

E164-PREFIX

The E.164 prefix and a dot that acts as a wildcard for matching each remaining number in the telephone number.

zone local

To specify a zone controlled by a gatekeeper, use the zone local gatekeeper configuration command. To remove a zone controlled by a gatekeeper, use the no form of this command. This command can also be used to change the IP address used by the gatekeeper.

zone local gatekeeper-name domain-name [rasIPaddress]
no zone local gatekeeper-name domain-name

Syntax Description

gatekeeper-name

 

The gatekeeper's name or zone name. This is usually the fully domain-qualified host name of the gatekeeper. For example, if the domain-name is cisco.com, the gatekeeper-name might be gk1.cisco.com. However, if the gatekeeper is controlling multiple zones, the gatekeeper-name for each zone should be some unique string that has a mnemonic value.

domain-name

The domain name served by this gatekeeper.

rasIPaddress

The IP address of one of the interfaces on the gatekeeper. When the gatekeeper responds to gatekeeper discovery messages, it signals the endpoint or gateway to use this address in future communications. Setting this address for one local zone makes it the address used for all local zones.

Default

No local zone is defined.


Note      The gatekeeper cannot operate without at least one local zone definition. Without local zones, the gatekeeper goes to an inactive state when the no shutdown command is issued.


Command Mode

Gatekeeper configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 NA.

Multiple local zones can be defined. The gatekeeper manages all configured local zones. Intrazone and interzone behavior remains the same (zones are controlled by the same or different gatekeepers.)

Only one rasIPaddress argument can be defined for all local zones. You cannot configure each zone to use a different RAS IP address. If you define this in the first zone definition, you can omit it for all subsequent zones, which automatically pick up this address. If you set it in a subsequent zone local command, it also changes the RAS address of all previously configured local zones. After it is defined, you can change it by re-issuing any zone local command with a different rasIPaddress argument.

If the rasIPaddress argument is an HSRP virtual address, it automatically puts the gatekeeper into HSRP mode. In this mode, the gatekeeper assumes STANDBY or ACTIVE status according to whether the HSRP interface is on STANDBY or ACTIVE status.

You cannot remove a local zone if there are endpoints or gateways registered in it. To remove the local zone, shut down the gatekeeper first, which forces unregistration.

Multiple zones are controlled by multiple logical gatekeepers on the same Cisco IOS release.

Example

The following example creates a zone controlled by a gatekeeper in the domain called cisco.com:

zone local gk1.cisco.com cisco.com

Related Commands

show gatekeeper zone statue
zone remote

zone prefix

To configure the gatekeeper with knowledge of its own and any remote zone's prefixes, use the zone prefix gatekeeper configuration command. To remove knowledge of zone prefixes, use the no form of this command.

zone prefix gatekeeper-name e164-prefix
no zone prefix gatekeeper-name e164-prefix

Syntax Description

gatekeeper-name

 

The name of a local or remote gatekeeper, which must have been defined using the zone local or zone remote command.

e164-prefix

An E.164 prefix in standard form followed by dots (.) that each represent a
number in the E.164 address.

For example, 212....... is matched by 212 and any seven numbers.

Default

No knowledge of its own or any other zone's prefix is defined.

Command Mode

Gatekeeper configuration

Usage Guidelines

Although a dot representing each digit in an E.164 address is the preferred configuration method, you may also enter an asterisk (*) to match any number of digits.

A gatekeeper may handle more than one zone prefix, but a zone prefix cannot be shared by more than one gatekeeper. If you have defined a zone prefix as being handled by a gatekeeper, and now define it as being handled by a second gatekeeper, the second assignment will cancel the first.

When a zone handles several prefixes, all gateways in that zone constitute a common pool which can be used to hop off to any of those prefixes. You may however wish to partition your gateways by prefix, for instance you have a gateway which interfaces to the 408 area code, and another which interfaces to the 415 area code, and for cost reasons you want each gateway only to be used for calls to its area code. In that case, you can define several local zones on the gatekeeper, each responsible for a prefix, and have each gateway register to the zone handling its prefix. For example, you can define local zone gk-408 handling prefix 408....... and local zone gk-415 handling 415....... and have the gateway interfacing to the 408 area code register with gk-408, and the gateway with the 415 interface register to gk-415."

Related Commands

zone local
zone remote

Example

The following example matches the 212 area code and any seven digits as the zone prefix for gk-ny:

zone prefix gk-ny 212.......

zone remote

To statically specify a remote zone if DNS is unavailable or undesirable, use the zone remote gatekeeper configuration command. To remove the remote zone, use the no form of this command.

zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address
[port-number]
no zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address
[port-number]

Syntax Description

other-gatekeeper-name

Name of the remote gatekeeper.

other-domain-name

Domain name of the remote gatekeeper.

other-gatekeeper-ip-address

IP address of the remote gatekeeper.

port-number

(Optional) RAS signaling port number for the remote zone. Value ranges from 1 to 65535. If this is not set, the default is the well-known RAS port number 1719.

Default

No remote zone is defined. DNS will locate the remote zone.

Command Mode

Gatekeeper configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 NA.

All gatekeepers do not have to be in DNS. For those that are not, use the zone remote command so that the local gatekeeper knows how to access them. In addition, you may wish to improve call response time slightly for frequently accessed zones. If the zone remote command is configured for a particular zone, you do not need to make a DNS lookup transaction.

Example

The following example configures the local gatekeeper to reach targets of the form xxx.cisco.com by sending queries to the gatekeeper named sj3.cisco.com at IP address 1.2.3.4:

zone remote sj3.cisco.com cisco.com 1.2.3.4

Related Commands

show gatekeeper zone statue
zone local

Gateway Commands

The section contains the command reference pages for the new commands, developed during Cisco IOS Release 11.3(6)NA2 and 11.3(7)NA timeframe.

aaa authentication login h323 radius

The aaa authentication login h323 radius command is used to define a method list called H.323 with RADIUS as a method. Enter the no form of this command to restore the default.

authentication login h323 radius
no authentication login h323 radius
Syntax Description

This command has no key words or arguments.

Default

[no] authentication login h323 radius.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

This command line registers the H.323 method list (also referred to as h323 service) which has RADIUS as its only method in the router. The VoIP calls send all their authentication requests through the H.323 service. If this line does not exist in the router configuration VoIP authentication will not take place.

A significant difference in the usage of this command is that with Cisco IOS release 11.3(T) the name of the method list is flexible and can be changed by the user. However, when using method list for configuring AAA with the VoIP service provider software, the method list is a specific name that you should not change.

The way method lists work in Cisco IOS software is that a list is defined using the aaa authentication login h323 radius command, and is then applied to an interface. For voice authentication, we never apply this list to any interface. When enabled, using this command applies to all voice interfaces. The function of this command is activated through the IVR application.

aaa accounting connection h323

This command is used to define the accounting method list "H.323" with RADIUS as a method and with either stop-only or start-stop accounting options.

aaa accounting connection h323 {stop-only | start-stop} radius
no aaa accounting connection h323 {stop-only | start-stop} radius
Syntax Description

stop-only | start-stop

Start-only or stop-only accounting options.

radius

RADIUS is used as the method.

Default

[no] aaa accounting connection h323.

Example

aaa accounting connection h323 {none | start-stop | stop-only | wait-start} radius

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

The method list has to be called "h323" and is activated for all voice interfaces.

This command line tells the system to create a method list called H.323 which has start-stop radius as its method. The h323 method list is static and is applied by default to all voice interfaces if the gw-accounting h323 command is also activated.

application

The application command selects the session application for Interactive Voice Response. This command is entered during the configuration of the dial peers.

application name
Syntax Description

name

Indicates the name of the IVR script application the call should be handed to

Default

None. The call will be handed to the predefined session application.

Command Mode

Dial peer configuration mode

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Example:
application clid_authen_collect, CallID 90 got event IVR_EV-CALL_SETUP_IND
:
: ivr action: IVR_ACT_CALL_SETUP_ACK
:
: ivr action: IVR_ACT_CALL_PROCEEDING
:
: ivr action: IVR_ACT_CALL_CONNECT

: ivr action: IVR_ACT_CALL_PROCEEDING
:
: ivr action: IVR_ACT_CALL_CONNECT

audio-prompt load

Use the audio-prompt load command to refresh the .au (audio) file in the memory. This is the file which contains the announcement prompt for the caller. The router will only load the .au file when the script initially plays that prompt, or on the router restart. If the .au file is changed, the user must run this EXEC command to reread the file. This will generate an error message if the file is not accessible, or if there is a format error.

audio-prompt load name
Syntax Description

audio-prompt load

Initiates to load selected audio file from Flash memory into RAM.

name

Indicates the location of the .au file to load. It can be loaded from memory, Flash memory, or an ftp server. Presently, with Cisco IOS Release 11.3(6)NA2, the <URL> pointer refers to the directory where Flash memory is stored.

Default

None.

Command Mode

Privileged EXEC

Usage Guidelines

This command first appears in Cisco IOS Release 11.3(6)NA2.

  • The first time the IVR application plays a prompt, it reads it from the URL (or the specified location for the .au file, such as flash or tfp) into RAM. Then it plays it from RAM.
  • The router is up and running, using the clid_authen_collect script. The script is playing out the prompt from flash:enter_destination.au.
  • A sequence of events would be:
    • When the first caller is asked to enter their account and PIN numbers, the enter_account.au and enter_pin.au files will be loaded into RAM from Flash memory.
    • When the next call comes in, these prompts are played from the RAM copy.
    • If all callers enter valid account and PIN numbers, then the auth_failed.au file will not be loaded from Flash memory into RAM memory.
Example
audio-prompt load flash:enter_pin.au

cas-group (controller t1)

The cas-group command is used to configure a channel group for CAS signaling. The cas-group command is used to specify the channels/timeslots to be allocated for the CAS group and the CAS signaling type. Use the no form of this command to disable channel associated signaling for one or more timeslots.

Two new service type attributes (voice and data) have been added to the cas group command.

The command syntax is as follows:

cas-group channel timeslots range type signal [ [tone] [service] ]
no cas-group channel timeslots range type signal [ [tone] [service]

The service type are:

  • voice or data

For e&m-fgb and e&m fgd, there are also tone type:

  • dtmf or mf
  • dnis or ani-dnis
Default

The default tone type is dtmf

For these two CAS signaling types the tone type is always set to mf and dnis is always required. They can be used for both voice and data calls.

channel

Specifies a single channel group number, which can be between 0 and 23.

timeslots range

Specifies a timeslot range of values from 1 to 24.

type signal

Specifies the type of robbed bit signaling. Choose one of the following signal types to configure:

  • e&m-fgb dtmf [dnis]
    or
    e&m-fgb mf [dnis]—Specifies ear and mouth channel signaling with feature group B support, which includes the wink start protocol. You can further customize this feature by specifying dtmf [dnis] or mf [dinis].
  • e&m-fgd dtmf [dnis]
    or
    e&m-fgd mf [ani-dnis]—Specifies ear and mouth channel signaling with feature group D support, which includes the wink start protocol. ani-dnis means the CAS group is provisioned to collect ANI (answer number identification) and DNIS (dialed number identification).
  • e&m-immediate-start—Specifies ear and mouth channel signaling with immediate start support.
  • fxs-loop-start— Specifies Foreign Exchange Station loopstart signaling support.
  • fxs-ground-start—Specifies Foreign Exchange Station ground start signaling support.
  • sas-loop-start—Specifies Special Access Station loopstart signaling support.
  • sas-ground-start—Specifies Special Access Station ground start signaling support.

tone

specify dtmf or mf

service

specify voice or data

Command Mode

Controller configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2.

Use this command to enable an integrated modem to receive and transmit incoming and outgoing call signaling (such as on-hook and off-hook) through each T1 controller.

  • If you want to collect DNIS information on a T1 controller, you must manually configure it on the access server.
  • DNIS collection is performed only for E&M-fgb, and E&M-fgd.
  • To collect DTMF DNIS for E&M-fgb under a controller T1 configuration, issue the cas-group 0 timeslots 1-24 type e&m-fgb dtmf dnis command.
  • To collect MF DNIS for E&M-fgb, issue the cas-group 0 timeslots 1-24 type e&m-fgb mf dnis command.

By configuring DNIS as part of the cas-group command, the system can collect DNIS digits for incoming calls which can be directed as VoIP calls, or alternately can be redirected to specific modem pools setup for different customers or uses. To support modems you must be running MICA modems in the system and have at least 10% of your total modems in the default modem pool.

The following example configures the required signaling to support modem pooling and the digital number identification service (DNIS) over channelized T1 lines on a Cisco AS5300.

Example Configuration
router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router(config)# controller t1 0
router(config-controller)# cas-group 0 timeslots 1-24 type e&m-fgb dtmf dnis
router(config-controller)# exit
router(config)#
router(config)# modem-pool accounts1
router(config-modem-pool)# pool-range 30-50
router(config-modem-pool)# called-number 2000 max-conn 21
router(config-modem-pool)# exit
router(config)#

Note      T1 CAS fgd is asymmetric. When calling the switch, we only generate DNIS. When receiving form the CO, we get both ANI and DNIS.


gateway

To enable the H.323 VoIP gateway, use the gateway global configuration command. Use the no form of this command to unregister this gateway with the gatekeeper.

gateway
no gateway
Syntax Description

This command has no keywords or arguments.

Default

The gateway is unregistered.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Use the gateway command to enable H.323 VoIP gateway functionality. After you enable the gateway, it will attempt to discover a gatekeeper by using the H.323 RAS GRQ message.

  • If the gateway is enabled, the gateway will attempt to discover a gatekeeper by using the H.323 RAS GRQ message.
  • The Voip gateway is stopped by entering no gateway.
  • If no gateway voip is entered, the VoIP Gateway will unregister with the Gatekeeper via the H.323 RAS URQ message.

gw-accounting

The gw-accounting command is used to enable or disable gateway specific accounting.

gw-accounting [h323 | syslog]
no gw-accounting [h323 | syslog]
Syntax Description

Field  Description 

h323

H.323 method uses RADIUS to output accounting CDRs.

syslog

Syslog uses the system logging facility to output CDRs.

Default

[no] gw-accounting [h323 | syslog].

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

  • This command is used when configuring the AAA accounting application.
  • This command line defines a method for doing the accounting and enables the gateway to do the accounting. There are two accounting methods defined.
  • Both H.323 and Syslog can be enabled at the same time which causes CDRs to be generated in both methods.

h323-gateway voip h323-id

To configure the H.323 name of the gateway identifying this gateway to its associated gatekeeper, use the h323-gateway voip h.323-id interface configuration command. Use the no form of this command to disable this defined gatekeeper name.

h323-gateway voip h323-id interface-id
no h323-gateway voip h323-id interface-id
Syntax Description

interface-id

H.323 name (ID) used by this gateway when this gateway communicates with its associated gatekeeper. Usually, this ID is the name of the gateway with the gatekeeper's domain name appended to the end: name@domain-name.

Default

No gateway identification is defined.

Command Mode

Interface configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Example

The following example configures Ethernet interface 0.0 as the gateway interface. In this example, the gateway ID is GW13@cisco.com.

interface Ethernet0/0
 ip address 172.9.53.13 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id GK15.cisco.com ipaddr 172.9.53.15 1719
 h323-gateway voip h323-id GW13@cisco.com
 h323-gateway voip tech-prefix 13#
Related Commands

h323-gateway voip id
h323-gateway voip interface
h323-gateway voip tech-prefix 13#

h323-gateway voip id

To define the name and location of the gatekeeper for this gateway, use the h323-gateway voip id interface configuration command. Use the no form of this command to disable this gatekeeper identification.

h323-gateway voip id gatekeeper-id {ipaddr ip-address [port-number] | multicast}
no h323-gateway voip id gatekeeper-id {ipaddr ip-address [port-number] | multicast}
Syntax Description

gatekeeper-id

Indicates the H.323 identification of the gatekeeper. This value must exactly match the gatekeeper ID in the gatekeeper configuration. The recommended format is name.doman-name.

ipaddr

Indicates that the gateway will use an IP address to locate the gatekeeper

ip-address

Defines the IP address used to identify the gatekeeper.

multicast

Indicates that the gateway will use multicast to locate the gatekeeper.

Default

No gatekeeper identification is defined.

Command Mode

Interface configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

This command tells the H.323 gateway associated with this interface which H.323 gatekeeper to talk to and where to locate it. The gatekeeper ID configured here must exactly match the gatekeeper ID in the gatekeeper configuration.

Example

The following example configures Ethernet interface 0.0 as the gateway interface. In this example, the gatekeeper ID is GW15.cisco.com and its IP address is 172.9.53.15 (using port 1719).

interface Ethernet0/0
 ip address 172.9.53.13 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id GK15.cisco.com ipaddr 172.9.53.15 1719
 h323-gateway voip h323-id GW13@cisco.com
 h323-gateway voip tech-prefix 13#
Related Commands

h323-gateway voip h323-id
h323-gateway voip interface
h323-gateway voip tech-prefix 13#

h323-gateway voip interface

To configure this interface as an H.323 interface, use the h323-gateway voip interface interface configuration command. Use the no form of this command to disable H.323 functionality for this interface.

h323-gateway voip interface
no h323-gateway voip interface
Syntax Description

This command has no arguments or keywords.

Default

Disabled

Command Mode

Interface configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Example

The following example configures Ethernet interface 0.0 as the gateway interface. In this example, the h323-gateway voip interface command configures this interface as an H.323 interface.

interface Ethernet0/0
 ip address 172.9.53.13 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id GK15.cisco.com ipaddr 172.9.53.15 1719
 h323-gateway voip h323-id GW13@cisco.com
 h323-gateway voip tech-prefix 13#
Related Commands

h323-gateway voip h323-id
h323-gateway voip id
h323-gateway voip tech-prefix 13#

h323-gateway voip tech-prefix

To define the technology prefix that the gateway will register with the gatekeeper, use the h323-gateway voip tech-prefix interface configuration command. Use the no form of this command to disable this defined technology prefix.

h323-gateway voip tech-prefix prefix
no h323-gateway voip tech-prefix prefix
Syntax Description

prefix

Defines the numbers used as the technology prefix. Each technology prefix can contain up to 11 characters. Although not strictly necessary, a pound (#) symbol is frequently used as the last digit in a technology prefix. Valid characters 0 though 9, the pound (#) symbol, and the asterisk (*).

Default

Disabled

Command Mode

Interface configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

This command defines a technology prefix that the gateway will then register with the gatekeeper. Technology prefixes can be used as a discriminator so that the gateway can tell the gatekeeper that a certain technology is associated with a particular call (for example, 15# could mean a fax transmission), or it can be used like an area code for more generic routing. No standard currently defines what the numbers in a technology prefix mean. By convention, technology prefixes are designated by a pound (#) symbol as the last character.


Note      Cisco gatekeepers use the asterisk (*) as a reserved character. If you are using Cisco gatekeepers, do not use the asterisk as part of the technology prefix.


Example

The following example configures Ethernet interface 0.0 as the gateway interface. In this example, the technology prefix is defined as 13#.

interface Ethernet0/0
 ip address 172.9.53.13 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id GK15.cisco.com ipaddr 172.9.53.15 1719
 h323-gateway voip h323-id GW13@cisco.com
 h323-gateway voip tech-prefix 13#
Related Commands

h323-gateway voip id
h323-gateway voip interface
h323-gateway voip h323-id

preference

The preference command is used to indicate the preference order for matching dial peers in a rotary group. It is useful in selecting the desired dial peer when multiple dial peers are matched for a dial string. The no form of this command does not assign a prefrence.

Command Mode

dial-peer config mode

Syntax Description

preference <value>

Valuean integer value [0..10]

Default

No preference order is given.

value 0 [0 - 10]

(highest preference = 0)

Usage Guidelines

This command was first appeared in Cisco IOS Release 11.3(7)NA2.

  • Use this command with the Rotary Calling Pattern feature.
  • The hunting algorithm precedence is configurable.
  • For example, if you wish a call processing sequence to go to destination #A first, then destination B second, and third to destination C; you would assign preference (0 being the highest priority) to the destinations in the following order:
    • Preference 0 to A
    • Preference 1 to B
    • Preference 2 to C
Order Determination Examples

The following examples show different dial peer configurations using the preference command.

Example 1

Dialpeer        destpat         preference              session-target
1               4085271048      0 (highest)             jmmurphy-voip
2               408527          0                       sj-voip
3               408527          1 (lower)               backup-sj-voip
4               ..........      1                       0:D     (interface)
5               ..........      0                       anywhere-voip

If the destination number is 4085271048, the order of attempts will be 1,2,3,5,4.

Example 2

Dialpeer        destpat         preference 
1               408527          0
2               4085271048      1
3               4085271         0
4 ..............4085271.........0 

The number dialed is 4085271048, the order will be 2, 3, 4, 1.


Note      The default behavior is that the longest matching dial peer supersedes the preference value.


session target

The session target command is used to identify the IP address of the destination gatekeeper. The field indicating if the RAS protocol is being used has been added. Enter the no form of this command to restore the default condition.

session target ras
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] host-name | loopback:rtp |      loopback:compressed | loopback:uncompressed | ras}
no session target
Syntax Description

ipv4:destination-address

IP address of the dial peer.

dns:host-name

Indicates that the domain name server will be used to resolve the name of the IP address. Valid entries for this parameter are characters representing the name of the host device.

(Optional) You can use one of the following three wildcards with this keyword when defining the session target for VoIP peers:

  • $s$.—Indicates that the source destination pattern will be used as part of the domain name.
  • $d$.—Indicates that the destination number will be used as part of the domain name.
  • $e$.—Indicates that the digits in the called number will be reversed, periods will be added in-between each digit of the called number, and that this string will be used as part of the domain name.
  • $u$.—Indicates that the unmatched portion of the destination pattern (such as a defined extension number) will be used as part of the domain name.

loopback:rtp

Indicates that all voice data will be looped back to the originating source. This is applicable for VoIP peers.

loopback:compressed

Indicates that all voice data will be looped back in compressed mode to the originating source. This is applicable for POTS peers.

loopback:uncompressed

Indicates that all voice data will be looped-back in uncompressed mode to the originating source. This is applicable for POTS peers.

ras

Indicates that the Registration, Admission and Status (RAS) signaling function protocol is being used—meaning that a gatekeeper will be consulted to translate the E.164 address to an IP address.

Default

The default for this command is enabled with no IP address or domain name defined.

Command Mode

Dial-peer configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(1)T.

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 session target loopback command is used for testing the voice transmission path of a call. The loopback point will depend on the call origination and the loopback type selected.

The session target dns command can be used with or without the specified wildcards. Using the optional wildcards can reduce the number of VoIP dial peer session targets you need to configure if you have groups of numbers associated with a particular router.

Use the session target ras command to specify that the RAS protocol is being used to determine the IP address of the session target.

Examples

The following example configures a session target using DNS for a host, "voice_router," in the domain "cisco.com":

dial-peer voice 10 voip
 session target dns:voice_router.cisco.com

The following example configures a session target using DNS, with the optional $u$. wildcard. In this example, the destination pattern has been configured to allow for any four-digit extension, beginning with the numbers 1310222. The optional wildcard $u$. indicates that the router will use the unmatched portion of the dialed number—in this case, the four-digit extension, to identify the dial peer. As in the previous example, the domain is "cisco.com."

dial-peer voice 10 voip
 destination-pattern 1310222....
 session target dns:$u$.cisco.com

The following example configures a session target using dns, with the optional $d$. wildcard. In this example, the destination pattern has been configured for 13102221111. The optional wildcard $d$. indicates that the router will use the destination pattern to identify the dial peer in the "cisco.com" domain.

dial-peer voice 10 voip
 destination-pattern 13102221111
 session target dns:$d$.cisco.com

The following example configures a session target using DNS, with the optional $e$. wildcard. In this example, the destination pattern has been configured for 12345. The optional wildcard $e$. indicates that the router will reverse the digits in the destination pattern, add periods between the digits, and then use this reverse-exploded destination pattern to identify the dial peer in the "cisco.com" domain.

dial-peer voice 10 voip
 destination-pattern 12345
 session target dns:$e$.cisco.com

The following example configures a session target using RAS:

dial-peer voice 11 vofr
 destination-pattern 13102221111
 session target ras
Related Commands

destination-pattern
session protocol

show call application voice

The show call application voice command defines the names of the audio files the script will play, the operation of the abort keys, what prompts are used and caller interaction.

show call application voice [name | summary]
no show call application voice [name | summary]
Syntax Description

Field  Description 

name

The name of the desired IVR application.

summary

Enter this field to display a one line summary. If the command is entered without summary, a complete detailed description is displayed of the application.

Default
no show call application voice [name | summary]
Command Mode

Privileged EXEC (also called enable mode)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

  • If the name of a specific application is entered, it will give information about that application.
  • If the summary field is entered a one line summary will be displayed about each application.
  • If the command is entered without the summary field, a detailed description of the entered ivr application is displayed.

Example Output

show call application voice clid_authen_collect
sblab115>show call application voice clid_authen_collect
Application clid_authen_collect has 10 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing

State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_account.au
            allowInt=1, pContent=0x60E4C564
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_pin has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_pin.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=pin
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_TIMEOUT goto state get_pin count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_destination.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:auth_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
 
sblab115>show call application voice clid_authen_collect
Application clid_authen_collect has 10 states with 0 calls active
  State start has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK
          and goto state start
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_AAA_FAIL goto state get_account
  State end has 1 actions and 3 events
    Do Action IVR_ACT_END.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY
          and do nothing
  State get_account has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_account.au
            allowInt=1, pContent=0x60E4C564
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin
            patName=account
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_TIMEOUT goto state get_account count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_account
  State get_pin has 4 actions and 7 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_pin.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate
            patName=pin
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state get_account
    If Event IVR_EV_TIMEOUT goto state get_pin count=0
    If Event IVR_EV_PAT_COL_FAIL goto state get_pin
  State authenticate has 1 actions and 5 events
    Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_AAA_SUCCESS goto state collect_dest
    If Event IVR_EV_TIMEOUT do nothing count=0
    If Event IVR_EV_AAA_FAIL goto state authenticate_fail
  State collect_dest has 4 actions and 8 events
    Do Action IVR_ACT_PLAY.
            URL: flash:enter_destination.au
            allowInt=1, pContent=0x0
    Do Action IVR_ACT_ABORT_KEY. abortKey=*
    Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
    Do Action IVR_ACT_COLLECT_DIALPLAN.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_PLAY_COMPLETE do nothing
    If Event IVR_EV_ABORT goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
    If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call
    If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest
    If Event IVR_EV_TIMEOUT goto state collect_dest count=0
  State place_call has 1 actions and 4 events
    Do Action IVR_ACT_PLACE_CALL.
            destination=  called=
            calling=      account=
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
    If Event IVR_EV_CALL_UP goto state active
    If Event IVR_EV_CALL_FAIL goto state place_fail
  State active has 0 actions and 2 events
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State authenticate_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY.
            URL: flash:auth_failed.au
            allowInt=0, pContent=0x0
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing
  State place_fail has 1 actions and 2 events
    Do Action IVR_ACT_PLAY_FAILURE_TONE.
    If Event IVR_EV_DEFAULT goto state end
    If Event IVR_EV_CALL_DIGIT do nothing

show gateway

The show gateway command is used to display the current gateway status.

show gateway
no show gateway
Syntax Description

This command has no keywords or arguments.

Default

no show gateway

Command Mode

Privileged EXEC (also called enable mode)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Example Output
gte-as5300-2#show gateway
 Gateway  voip2@vm1lab  is registered to Gatekeeper gk1.vm1lab

tech-prefix

The tech-prefix command is used to specify a particular technology prefix be prepended to the destination pattern of a specific dial peer. Use the no form of this command to disabled the defined technology prefix for this dial peer.

tech-prefix number
no tech-prefix number
Syntax Description

number

Defines the numbers used as the technology prefix. Each technology prefix can contain up to 11 characters. Although not strictly necessary, a pound (#) symbol is frequently used as the last digit in a technology prefix. Valid characters 0 though 9, the pound (#) symbol, and the asterisk (*).

Default

No technology prefix is defined.

Command Mode

Dial-peer configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Technology prefixes are used to distinguish between gateways having specific capabilities within a given zone. In the exchange between the gateway and the gatekeeper, the technology prefix is used to select a gateway after the zone has been selected. Use the tech-prefix command to define technology prefixes.

Technology prefixes can be used as a discriminator so that the gateway can tell the gatekeeper that a certain technology is associated with a particular call (for example, 15# could mean a fax transmission), or it can be used like an area code for more generic routing. No standard defines what the numbers in a technology prefix mean; by convention, technology prefixes are designated by a pound (#) symbol as the last character.

In most cases, there is a dynamic protocol exchange between the gateway and the gatekeeper that enables the gateway to inform the gatekeeper about technology prefixes and where to forward calls. If, for some reason, that dynamic registry feature is not in effect, you can statically configure the gatekeeper to query the gateway for this information by configuring the gw-type-prefix command on the gatekeeper. Use the show gatekeeper gw-type-prefix to display how the gatekeeper has mapped the technology prefixes to local gateways.


Note      Cisco gatekeepers use the asterisk (*) as a reserved character. If you are using Cisco gatekeepers, do not use the asterisk as part of the technology prefix.


Example Output

The following example defines a technology prefix of 14# for the specified dial peer. In this example, the technology prefix means that the H.323 gateway will ask the RAS gatekeeper to direct calls using the technology prefix of 14#.

dial-peer voice 10 voip
 destination-pattern 14...
 tech-prefix 14#
Related Commands

gw-type-prefix
show gatekeeper gw-type-prefix

Debug Commands

This section describes the following debug commands:

debug cch323 h225

The debug cch323 h225 command provides the trace of the state transition of the H.225 state machine based on the processed events. The no form of this command disables debugging output.

debug cch323 h225
no debug cch323 h225
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

State Descriptions

The state definitions of the different states of the H.225 state machine are as follows:

  • H225_IDLE—This is the initial state of the H.225 state machine. The H.225 state machine is in this state before issuing a call setup request ( for the outbound IP call case) or ready to receive an incoming IP call.
  • H225_SETUP—This is the call setup state. The state machine transitions to this state after sending out a call setup request, or after the reception of an incoming call indication.
  • H225_ALERT—This is the call alerting state. The state machine transitions to this state after sending the alerting message or after the reception of an alerting message from the peer.
  • H225_CALLPROC—This is the call proceeding state.
  • H225_ACTIVE—This is the Call connected state. In this state, the call is active. The state machine transitions to this state after sending the connect message to the peer or after the reception of the connect message from the peer.
  • H225_WAIT_FOR_ARQ—This is the state where the H.225 state machine is waiting for the completion of the ARQ process from the RAS state machine.
  • H225_WAIT_FOR_DRQ—This is the state where the H.225 state machine is waiting for the completion of the DRQ process from the RAS state machine.
  • H225_WAIT_FOR_H245—This is the state where the H.225 state machine is waiting for the success or failure from the H.245 state machine.
Events Description

The event definitions of the different events of the H.225 state machine are as follows:

  • H225_EVENT_NONE— No event.
  • H225_EVENT_ALERT—This event indicates the H.225 state machine to send an alerting message to the peer.
  • H225_EVENT_ALERT_IND—This event indicates the H.225 state machine that an alerting message is received from the peer.
  • H225_EVENT_CALLPROC—This event indicates the H.225 state machine to send a call proceeding message to the peer
  • H225_EVENT_CALLPROC_IND—This event indicates the H.225 state machine that a call proceeding message is received from the peer.
  • H225_EVENT_REJECT—This event indicates the H.225 state machine to reject the call setup request from the peer.
  • H225_EVENT_REJECT_IND—This event indicates the H.225 state machine that a call setup request to the peer is rejected.
  • H225_EVENT_RELEASE—This event indicates the H.225 state machine to send a release complete message to the peer.
  • H225_EVENT_RELEASE_IND—This event indicates the H.225 state machine that a release complete message is received from the peer.
  • H225_EVENT_SETUP—This event indicates the H.225 state machine to send a setup message to the peer.
  • H225_EVENT_SETUP_IND—This event indicates the H.225 state machine that a setup message is received from the peer.
  • H225_EVENT_SETUP_CFM—This event indicates the H.225 state machine to send a connect message to the peer.
  • H225_EVENT_SETUP_CFM_IND—This event indicates the H.225 state machine that a connect message from the peer.
  • H225_EVENT_RAS_SUCCESS—This event indicates the H.225 state machine that the pending RAS operation is successful.
  • H225_EVENT_RAS_FAILED—This event indicates the H.225 state machine that the pending RAS operation failed.
  • H225_EVENT_H245_SUCCESS—This event indicates the H.225 state machine that the pending H.245 operation is successful.
  • H225_EVENT_H245_FAILED—This event indicates the H.225 state machine that the pending H.245 operation failed.
Example
20:59:17:Set new event H225_EVENT_SETUP
20:59:17:H225 FSM:received event H225_EVENT_SETUP while at state H225_IDLE
20:59:17:Changing from H225_IDLE state to H225_SETUP state
20:59:17:cch323_h225_receiver:received msg of type SETUPCFM_CHOSEN
20:59:17:H225 FSM:received event H225_EVENT_SETUP_CFM_IND while at state 
H225_SETUP
20:59:17:Changing from H225_SETUP state to H225_ACTIVE state
20:59:17:Set new event H225_EVENT_H245_SUCCESS
20:59:17:H225 FSM:received event H225_EVENT_H245_SUCCESS while at state 
H225_ACTIVE
20:59:20:Set new event H225_EVENT_RELEASE
20:59:20:H225 FSM:received event H225_EVENT_RELEASE while at state 
H225_ACTIVE
20:59:20:Changing from H225_ACTIVE state to H225_WAIT_FOR_DRQ state
20:59:20:Set new event H225_EVENT_RAS_SUCCESS
20:59:20:H225 FSM:received event H225_EVENT_RAS_SUCCESS while at state 
H225_WAIT_FOR_DRQ
20:59:20:Changing from H225_WAIT_FOR_DRQ state to H225_IDLE state

debug cch323 h245

The debug cch323 h245 command provides the trace of the state transition of the H.245 state machine based on the processed events. The no form of this command disables debugging output.

debug cch323 h245
no debug cch323 h245
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

The H.245 state machines include the following three state machines:

  • Master Slave Determination state machine
  • Capability Exchange state machine
  • Open Logical Channel state machine
State Definitions

The definitions are listed:

  • H245_MS_NONE— This is the initial state of the master slave determination state machine.
  • H245_MS_WAIT—In this state, a Master Slave Determination message is sent, waiting for the reply.
  • H245_MS_DONE— The result is in.
  • H245_CAP_NONE—This is the initial state of the capabilities exchange state machine.
  • H245_CAP_WAIT—In this state, a cap exchange message is sent, waiting for reply.
  • H245_CAP_DONE—The result is in.
  • H245_OLC_NONE—This is the initial state of the open logical channel state machine.
  • H245_OLC_WAIT: OLC message sent, waiting for reply.
  • H245_OLC_DONE: OLC done.
Event definitions
  • H245_EVENT_MSD—Send MSD message
  • H245_EVENT_MS_CFM—Send MSD acknowledge message
  • H245_EVENT_MS_REJ—Send MSD reject message
  • H245_EVENT_MS_IND— Received MSD message
  • H245_EVENT_CAP—Send CAP message
  • H245_EVENT_CAP_CFM—Send CAP acknowledge message
  • H245_EVENT_CAP_REJ—Send CAP reject
  • H245_EVENT_CAP_IND—Received CAP message
  • H245_EVENT_OLC—Send OLC message
  • H245_EVENT_OLC_CFM—Send OLC acknowledge message
  • H245_EVENT_OLC_REJ—Send OLC reject message
  • H245_EVENT_OLC_IND—Received OLC message
Example Output
20:58:23:Changing to new event H245_EVENT_MSD
20:58:23:H245 MS FSM:received event H245_EVENT_MSD while at state 
H245_MS_NONE
20:58:23:changing from H245_MS_NONE state to H245_MS_WAIT state
20:58:23:Changing to new event H245_EVENT_CAP
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP while at state 
H245_CAP_NONE
20:58:23:changing from H245_CAP_NONE state to H245_CAP_WAIT state
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_MS_DETERMINE_INDICATION
20:58:23:Changing to new event H245_EVENT_MS_IND
20:58:23:H245 MS FSM:received event H245_EVENT_MS_IND while at state 
H245_MS_WAIT
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_CAP_TRANSFER_INDICATION
20:58:23:Changing to new event H245_EVENT_CAP_IND
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_IND while at state 
H245_CAP_WAIT
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_MS_DETERMINE_CONFIRM
20:58:23:Changing to new event H245_EVENT_MS_CFM
20:58:23:H245 MS FSM:received event H245_EVENT_MS_CFM while at state 
H245_MS_WAIT
20:58:23:changing from H245_MS_WAIT state to H245_MS_DONE state
0:58:23:cch323_h245_receiver:received msg of type M_H245_CAP_TRANSFER_CONFIRM
20:58:23:Changing to new event H245_EVENT_CAP_CFM
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_CFM while at state 
H245_CAP_WAIT
20:58:23:changing from H245_CAP_WAIT state to H245_CAP_DONE state
20:58:23:Changing to new event H245_EVENT_OLC
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC while at state
H245_OLC_NONE
20:58:23:changing from H245_OLC_NONE state to H245_OLC_WAIT state
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_UCHAN_ESTABLISH_INDICATION
20:58:23:Changing to new event H245_EVENT_OLC_IND
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_IND while at state 
H245_OLC_WAIT
20:58:23:cch323_h245_receiver:received msg of type M_H245_UCHAN_ESTAB_ACK
20:58:23:Changing to new event H245_EVENT_OLC_CFM
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_CFM while at state 
H245_OLC_WAIT
20:58:23:changing from H245_OLC_WAIT state to H245_OLC_DONE state

debug cch323 ras

The debug cch323 ras command provides the trace of the state transition of the RAS state machine based on the processed events.The no form of this command disables debugging output.

debug cch323 ras
no debug cch323 ras
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

RAS operates in two state machines. One global state machine controls the overall RAS operation of the Gateway. The other state machine is a per call state machine that controls the active calls.

State definitions

The state definitions of the different states of the RAS state machine follow:

  • CCH323_RAS_STATE_NONE—This is the initial state of the RAS state machine.
  • CCH323_RAS_STATE_GRQ—The state machine is in the GRQ state. In this state, the gateway is in the process of discovering a gatekeeper.
  • CCH323_RAS_STATE_RRQ—The state machine is in the RRQ state. In this state, the gateway is in the process of registering with a gatekeeper.
  • CCH323_RAS_STATE_IDLE—The global state machine is in the idle state.
  • CCH323_RAS_STATE_URQ—The state machine is in the URQ state. In this state, the gateway is in the process of unregistering with a gatekeeper.
  • CCH323_RAS_STATE_ARQ—The per call state machine is in the process of admitting a new call.
  • CCH323_RAS_STATE_ACTIVE—The per call state machine is in the call active state.
  • CCH323_RAS_STATE_DRQ—The per call state machine is in the process of disengaging an active call.
Event Definitions

These are the event definitions of the different states of the RAS state machine:

  • CCH323_RAS_EVENT_NONE—Nothing
  • CCH323_RAS_EVENT_GWUP—Gateway is coming up
  • CCH323_RAS_EVENT_GWDWN—Gateway is going down
  • CCH323_RAS_EVENT_NEWCALL:—New call
  • CCH323_RAS_EVENT_CALLDISC—Call disconnect
  • CCH323_RAS_EVENT_GCF—Received GCF
  • CCH323_RAS_EVENT_GRJ—Received GRJ
  • CCH323_RAS_EVENT_ACF—Received ACF
  • CCH323_RAS_EVENT_ARJ—Received ARJ
  • CCH323_RAS_EVENT_SEND_RRQ—Send RRQ
  • CCH323_RAS_EVENT_RCF—Received RCF
  • CCH323_RAS_EVENT_RRJ—Received RRJ
  • CCH323_RAS_EVENT_SEND_URQ—Send URQ
  • CCH323_RAS_EVENT_URQ—Received URQ
  • CCH323_RAS_EVENT_UCF—Received UCF
  • CCH323_RAS_EVENT_SEND_UCF—Send UCF
  • CCH323_RAS_EVENT_URJ—Received URJ
  • CCH323_RAS_EVENT_BCF—Received BCF
  • CCH323_RAS_EVENT_BRJ—Received BRJ
  • CCH323_RAS_EVENT_DRQ—Received DRQ
  • CCH323_RAS_EVENT_DCF—Received DCF
  • CCH323_RAS_EVENT_SEND_DCF—Send DCF
  • CCH323_RAS_EVENT_DRJ—Received DRJ
  • CCH323_RAS_EVENT_IRQ—Received IRQ
  • CCH323_RAS_EVENT_IRR—Send IRR
  • CCH323_RAS_EVENT_TIMEOUT—Message timeout
Example Output
20:58:49:Changing to new event CCH323_RAS_EVENT_SEND_RRQ
cch323_run_ras_sm:received event CCH323_RAS_EVENT_SEND_RRQ while at CCH323_RAS_STATE_IDLE state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_RRQ state
cch323_ras_receiver:received msg of type RCF_CHOSEN
cch323_run_ras_sm:received event CCH323_RAS_EVENT_RCF while at CCH323_RAS_STATE_RRQ state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_NEWCALL while at CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_ARQ
cch323_ras_receiver:received msg of type ACF_CHOSEN
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_ACF while at 
CCH323_RAS_STATE_ARQ state
20:58:59:cch323_percall_ras_sm:changing to new state 
CCH323_RAS_STATE_ACTIVE
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_CALLDISC while
at CCH323_RAS_STATE_ACTIVE state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_DRQ
cch323_ras_receiver:received msg of type DCF_CHOSEN
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_DCF while at
CCH323_RAS_STATE_DRQ state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_IDLE
20:59:04:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_IRR while at 
CCH323_RAS_STATE_ACTIVE state
20:59:04:cch323_percall_ras_sm:changing to new state 
CCH323_RAS_STATE_ACTIVE

debug h225

Use the debug h225 command to display additional information about the actual contents of H.225 RAS messages. Use the no form of this command to disable debug output.

debug h225 {asn1 | events}
no debug voip aaa
Syntax Description

asn1

Indicates that only the ASN.1 contents of any H.225 message sent or received will be displayed.

events

Indicates that key Q.931 events that occur when placing a H.323 call from one gateway to another will be displayed.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2

Both versions of the debug H225 command display information about H.225 messages. H.225 messages are used to exchange RAS information between gateways and gatekeepers as well as to exchange Q.931 information between gateways.

The debug h225 events command displays key Q.931 events that occur when placing a H.323 call from one gateway to another. Q.931 events are carried in H.225 messages. This command enables you to monitor Q.931 state changes such as setup, alert, connected, and released.


Note      Although the debug information includes the hexadecimal output of the entire H.225 message, only the key state changes are decoded.


The debug h225 asn1command displays the ASN.1 contents of any H.225 message sent or received that contains ASN.1 content. Not all H.225 messages contain ASN.1 content. Some messages contain both Q.931 information and ASN.1 information; if you enter this command, only ASN.1 information will be displayed.

Sample Output

The following sample output for the debug h225 events command shows a call being placed from gateway GW13 to gateway GW14. Before the call was placed, the gateway exchanged RAS messages with the gatekeeper. Because RAS messages do not contain Q.931 information, these messages do not appear in this output.

3640GW.13# debug h225 events
H.225 Event Messages debugging is on
3640GW.13#

*Mar  2 02:47:14.689:      H225Lib::h225TConn:connect in progress on socket [2]
*Mar  2 02:47:14.689:      H225Lib::h225TConn:Q.931 Call State is initialized to be [Null].
*Mar  2 02:47:14.697:Hex representation of the SETUP TPKT to send.0300004D080200DC05040380C0A36C0991313323313333303070099131342331343330307E0026050080060008914A000102004B1F5E5D8990006C0000000005BF7454000C0700000000000000
*Mar  2 02:47:14.701:
*Mar  2 02:47:14.701:      H225Lib::h225SetupRequest:Q.931 SETUP sent from socket [2]
*Mar  2 02:47:14.701:      H225Lib::h225SetupRequest:Q.931 Call State changed to [Call Initiated].
*Mar  2 02:47:14.729:Hex representation of the received TPKT03000021080280DC013401017E0012050340060008914A000100000109350E2B28
*Mar  2 02:47:14.729:
*Mar  2 02:47:14.729:      H225Lib::h225RecvData:Q.931 ALERTING received from socket [2]
*Mar  2 02:47:14.729:      H225Lib::h225RecvData:Q.931 Call State changed to [Call Delivered].
*Mar  2 02:47:17.565:Hex representation of the received TPKT03000034080280DC07040380C0A37E0023050240060008914A0001000109350E2B2802004B1F5E5D8990006C0000000005BF7454
*Mar  2 02:47:17.569:
*Mar  2 02:47:17.569:      H225Lib::h225RecvData:Q.931 CONNECT received from socket [2]
*Mar  2 02:47:17.569:      H225Lib::h225RecvData:Q.931 Call State changed to [Active].
*Mar  2 02:47:23.273:Hex representation of the received TPKT0300001A080280DC5A080280107E000A050500060008914A0001
*Mar  2 02:47:23.273:
*Mar  2 02:47:23.273:      H225Lib::h225RecvData:Q.931 RELEASE COMPLETE received from socket [2]
*Mar  2 02:47:23.273:      H225Lib::h225RecvData:Q.931 Call State changed to [Null].
*Mar  2 02:47:23.293:Hex representation of the RELEASE COMPLETE TPKT to send.0300001A080200DC5A080280107E000A050500060008914A0001
*Mar  2 02:47:23.293:
*Mar  2 02:47:23.293:      H225Lib::h225TerminateRequest:Q.931 RELEASE COMPLETE sent from socket [2]. Call state changed to [Null].
*Mar  2 02:47:23.293:      H225Lib::h225TClose:TCP connection from socket [2] closed

The following output shows the same call being placed from gateway GW13 to gateway GW14 using the debug h225 asn1 command. The output is very long but you can track the following information:

  • The admission request to the gatekeeper.
  • The admission confirmation from the gatekeeper.
  • The ASN.1 portion of the H.225/Q.931 setup message from the calling gateway to the called gateway.
  • The ASN.1 portion of the H.225/Q.931 setup response from the called gateway, indicating that the call has proceeded to alerting state.
  • The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been connected.
  • The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been released.
  • The ANS.1 portion of the H.225 RAS message from the calling gateway to the gatekeeper, informing it that the call has been disengaged.
  • The ASN.1 portion of the H.225 RAS message from the gatekeeper to the calling gateway, confirming the disengage request.
  • The ASN.1 portion of the H.225/Q.931 release complete message sent from the called gateway to the calling gateway.
3640GW.13# debug h225 asn1
H.225 ASN1 Messages debugging is on
3640GW.13#

value RasMessage ::= admissionRequest :
*Mar  2 02:48:18.445:  {
*Mar  2 02:48:18.445:    requestSeqNum 03320,
*Mar  2 02:48:18.445:    callType pointToPoint :NULL,
*Mar  2 02:48:18.445:    callModel direct :NULL,
*Mar  2 02:48:18.445:    endpointIdentifier "60D6BA4C00000001",
*Mar  2 02:48:18.445:    destinationInfo 
*Mar  2 02:48:18.445:    {
*Mar  2 02:48:18.445:      e164 :"14#14300"
*Mar  2 02:48:18.445:    },
*Mar  2 02:48:18.449:    srcInfo 
*Mar  2 02:48:18.449:    {
*Mar  2 02:48:18.449:      e164 :"13#13300"
*Mar  2 02:48:18.449:    },
*Mar  2 02:48:18.449:    bandWidth 0640,
*Mar  2 02:48:18.449:    callReferenceValue 0224,
*Mar  2 02:48:18.449:    conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:18.449:    activeMC FALSE,
*Mar  2 02:48:18.449:    answerCall FALSE
*Mar  2 02:48:18.449:  }
*Mar  2 02:48:18.449:25800CF7 00F00036 00300044 00360042 00410034 00430030 00300030 00300030
00300030 00310103 80470476 33010380 46046633 40028000 E04B1F5E 5D899000
72000000 0005C067 A400
29000CF7 40028000 0109350E 06B80077 
value RasMessage ::= admissionConfirm :
*Mar  2 02:48:18.469:  {
*Mar  2 02:48:18.469:    requestSeqNum 03320,
*Mar  2 02:48:18.469:    bandWidth 0640,
*Mar  2 02:48:18.469:    callModel direct :NULL,
*Mar  2 02:48:18.469:    destCallSignalAddress ipAddress :
*Mar  2 02:48:18.469:      {
*Mar  2 02:48:18.469:        ip '0109350E'H,
*Mar  2 02:48:18.469:        port 01720
*Mar  2 02:48:18.469:      },
*Mar  2 02:48:18.469:    irrFrequency 0120
*Mar  2 02:48:18.473:  }
*Mar  2 02:48:18.473:value H323-UserInformation ::= 
*Mar  2 02:48:18.481:{
*Mar  2 02:48:18.481:  h323-uu-pdu 
*Mar  2 02:48:18.481:  {
*Mar  2 02:48:18.481:    h323-message-body setup :
*Mar  2 02:48:18.481:      {
*Mar  2 02:48:18.481:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:18.481:        sourceInfo 
*Mar  2 02:48:18.481:        {
*Mar  2 02:48:18.481:          terminal 
*Mar  2 02:48:18.481:          {
*Mar  2 02:48:18.481:          },
*Mar  2 02:48:18.481:          mc FALSE,
*Mar  2 02:48:18.481:          undefinedNode FALSE
*Mar  2 02:48:18.481:        },
*Mar  2 02:48:18.481:        activeMC FALSE,
*Mar  2 02:48:18.481:        conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:18.481:        conferenceGoal create :NULL,
*Mar  2 02:48:18.485:        callType pointToPoint :NULL,
*Mar  2 02:48:18.485:        sourceCallSignalAddress ipAddress :
*Mar  2 02:48:18.485:          {
*Mar  2 02:48:18.485:            ip '00000000'H,
*Mar  2 02:48:18.485:            port 00
*Mar  2 02:48:18.485:          }
*Mar  2 02:48:18.485:      }
*Mar  2 02:48:18.485:  }
*Mar  2 02:48:18.485:}
*Mar  2 02:48:18.485:00800600 08914A00 0102004B 1F5E5D89 90007200 00000005 C067A400 0C070000
00000000 00
value H323-UserInformation ::= 
*Mar  2 02:48:18.525:{
*Mar  2 02:48:18.525:  h323-uu-pdu 
*Mar  2 02:48:18.525:  {
*Mar  2 02:48:18.525:    h323-message-body alerting :
*Mar  2 02:48:18.525:      {
*Mar  2 02:48:18.525:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:18.525:        destinationInfo 
*Mar  2 02:48:18.525:        {
*Mar  2 02:48:18.525:          mc FALSE,
*Mar  2 02:48:18.525:          undefinedNode FALSE
*Mar  2 02:48:18.525:        },
*Mar  2 02:48:18.525:        h245Address ipAddress :
*Mar  2 02:48:18.525:          {
*Mar  2 02:48:18.525:            ip '0109350E'H,
*Mar  2 02:48:18.525:            port 011050
*Mar  2 02:48:18.525:          }
*Mar  2 02:48:18.525:      }
*Mar  2 02:48:18.525:  }
*Mar  2 02:48:18.525:}
*Mar  2 02:48:18.525:value H323-UserInformation ::= 
*Mar  2 02:48:22.753:{
*Mar  2 02:48:22.753:  h323-uu-pdu 
*Mar  2 02:48:22.753:  {
*Mar  2 02:48:22.753:    h323-message-body connect :
*Mar  2 02:48:22.753:      {
*Mar  2 02:48:22.753:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:22.753:        h245Address ipAddress :
*Mar  2 02:48:22.753:          {
*Mar  2 02:48:22.753:            ip '0109350E'H,
*Mar  2 02:48:22.753:            port 011050
*Mar  2 02:48:22.753:          },
*Mar  2 02:48:22.753:        destinationInfo 
*Mar  2 02:48:22.753:        {
*Mar  2 02:48:22.753:          terminal 
*Mar  2 02:48:22.753:          {
*Mar  2 02:48:22.753:          },
*Mar  2 02:48:22.757:          mc FALSE,
*Mar  2 02:48:22.757:          undefinedNode FALSE
*Mar  2 02:48:22.757:        },
*Mar  2 02:48:22.757:        conferenceID '4B1F5E5D899000720000000005C067A4'H
*Mar  2 02:48:22.757:      }
*Mar  2 02:48:22.757:  }
*Mar  2 02:48:22.757:}
*Mar  2 02:48:22.757:value H323-UserInformation ::= 
*Mar  2 02:48:27.109:{
*Mar  2 02:48:27.109:  h323-uu-pdu 
*Mar  2 02:48:27.109:  {
*Mar  2 02:48:27.109:    h323-message-body releaseComplete :
*Mar  2 02:48:27.109:      {
*Mar  2 02:48:27.109:        protocolIdentifier { 0 0 8 2250 0 1 }
*Mar  2 02:48:27.109:      }
*Mar  2 02:48:27.109:  }
*Mar  2 02:48:27.109:}
*Mar  2 02:48:27.109:value RasMessage ::= disengageRequest :
*Mar  2 02:48:27.117:  {
*Mar  2 02:48:27.117:    requestSeqNum 03321,
*Mar  2 02:48:27.117:    endpointIdentifier "60D6BA4C00000001",
*Mar  2 02:48:27.117:    conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:27.121:    callReferenceValue 0224,
*Mar  2 02:48:27.121:    disengageReason normalDrop :NULL
*Mar  2 02:48:27.121:  }
*Mar  2 02:48:27.121:3C0CF81E 00360030 00440036 00420041 00340043 00300030 00300030 00300030
00300031 4B1F5E5D 89900072 00000000 05C067A4 00E020
400CF8
value RasMessage ::= disengageConfirm :
*Mar  2 02:48:27.133:  {
*Mar  2 02:48:27.133:    requestSeqNum 03321
*Mar  2 02:48:27.133:  }
*Mar  2 02:48:27.133:value H323-UserInformation ::= 
*Mar  2 02:48:27.133:{
*Mar  2 02:48:27.133:  h323-uu-pdu 
*Mar  2 02:48:27.133:  {
*Mar  2 02:48:27.133:    h323-message-body releaseComplete :
*Mar  2 02:48:27.133:      {
*Mar  2 02:48:27.133:        protocolIdentifier { 0 0 8 2250 0 1 }
*Mar  2 02:48:27.133:      }
*Mar  2 02:48:27.133:  }
*Mar  2 02:48:27.133:}
*Mar  2 02:48:27.133:05000600 08914A00 01
.

debug ras

Use the debug voip ccapi command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in ITU-T specification H.225. Use the no form of this command to disable debug output.

debug ras
no debug ras
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Use the debug ras command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in ITU-T specification H.225.

Sample Output

In the following output, gateway GW13.cisco.com sends a RAS registration request message (RRQ) to gatekeeper GK15.cisco.com at IP address 172.9.53.15. GW13.cisco.com then receives a registration confirmation (RCF) message from the gatekeeper. If there is no response, it could mean that the gatekeeper is offline or improperly addressed. If you receive a reject message (RRJ), it could mean that the gatekeeper is unable to handle another gateway or that the registration information is incorrect.

3640GW.13#debug ras 
*Mar 13 19:53:34.231:      RASlib::ras_sendto:msg length 105 from
                            172.9.53.13:8658 to 1.9.53.15:1719
*Mar 13 19:53:34.231:      RASLib::RASSendRRQ:RRQ (seq# 36939) sent
                            to 172.9.53.15
*Mar 13 19:53:34.247:      RASLib::RASRecvData:successfully rcvd
                            message of length 105 from 172.9.53.15:1719
*Mar 13 19:53:34.251:      RASLib::RASRecvData:RCF (seq# 36939) rcvd
                            from [172.9.53.15:1719] on sock [0x6168356C 

debug voip aaa

The debug voip aaa command is used to enable or disable debugging messages for gateway aaa to be output to the system console.

debug voip aaa
no debug voip aaa
Syntax Description

This command has no keywords or arguments.

Command Mode

global exec

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

debug voip ccapi

The debug voip ccapi command is used for debugging the call control API.

debug voip ccapi
no debug voip ccapi
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Sample Output
sblab160#show debug
voip:
  voip ccAPI function enter/exit debugging is on
Oct  9 17:39:20.267:cc_api_call_setup_ind (vdbPtr=0x60ED5134,
callInfo={called=3001, calling=4004, fdest=0 peer_tag=1},
callID=0x6104B374)
Oct  9 17:39:20.275:cc_process_call_setup_ind (event=0x60D45CF0) handed
call to app "sess"
Oct  9 17:39:20.279:ccAppInitialize (name=App for callId  3
, appHandle=0x6103DD44)
Oct  9 17:39:20.279:ccCallSetContext (callID=0x3, context=0x6103DD3C)
Oct  9 17:39:20.279:ccCallSetupAck (callID=0x3)
Oct  9 17:39:20.279:ccGenerateTone (callID=0x3 tone=8)
Oct  9 17:39:20.279:ccCallApp (callID=0x3)
Oct  9 17:39:20.279:ccCallSetContext (callID=0x3, context=0x60DC4594)
00:11:31:%RADIUS-6-SERVERALIVE:Radius server 171.69.184.73 is
responding
again (previously dead).
Oct 9 17:39:22.808:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:23.069:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:23.399:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=5, mode=0)
Oct  9 17:39:23.652:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:24.041:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=0, mode=0)
Oct  9 17:39:24.294:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=0, mode=0)
Oct  9 17:39:24.294:ccCallAppReturn (callID=0x3)
Oct  9 17:39:24.294:ccCallApp (callID=0x3)
Oct  9 17:39:24.294:ccCallSetContext (callID=0x3, context=0x6105DC90)
Oct  9 17:39:24.294:ccCallProceeding (callID=0x3, prog_ind=0x0)
Oct  9 17:39:24.294:ccCallSetupRequest (peer=0x60FE4068, dest=,
params=0x6105DB70 mode=0, *callID=0x60D50978)
Oct  9 17:39:24.294:callingNumber=4004, calledNumber=115100,
redirectNumber=
Oct  9 17:39:24.294:accountNumber=, finalDestFlag=0,
guid=3c85.5d28.2861.0004.0000.0000.000a.8dfc
Oct  9 17:39:24.294:peer_tag=115
Oct  9 17:39:24.294:ccIFCallSetupRequest:(vdbPtr=0x60D4A268, dest=,
callParams={called=115100, calling=4004, fdest=0, voice_peer_tag=115},
mode=0x0)
Oct  9 17:39:24.294:ccCallSetContext (callID=0x4, context=0x6105DD78)
Oct  9 17:39:26.350:cc_api_call_alert(vdbPtr=0x60D4A268, callID=0x4,
prog_ind=0x8, sig_ind=0x0)
Oct  9 17:39:26.350:ccCallAlert (callID=0x3, prog_ind=0x8, sig_ind=0x0)
Oct  9 17:39:26.350:ccConferenceCreate (confID=0x60D509C8, callID1=0x3,
callID2=0x4, tag=0x0)
Oct  9 17:39:26.350:cc_api_bridge_done (confID=0x1, srcIF=0x60D4A268,
srcCallID=0x4, dstCallID=0x3, disposition=0, tag=0x0)
Oct  9 17:39:26.350:cc_api_bridge_done (confID=0x1, srcIF=0x60ED5134,
srcCallID=0x3, dstCallID=0x4, disposition=0, tag=0x0)
Oct  9 17:39:26.350:cc_api_caps_ind (dstVdbPtr=0x60D4A268,
dstCallId=0x4,srcCallId=0x3, caps={codec=0x7, fax_rate=0x7F, vad=0x3})
Oct  9 17:39:26.350:cc_api_caps_ind (dstVdbPtr=0x60ED5134,
dstCallId=0x3,srcCallId=0x4, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.350:cc_api_caps_ack (dstVdbPtr=0x60ED5134,
dstCallId=0x3,srcCallId=0x4, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.350:cc_api_caps_ack (dstVdbPtr=0x60D4A268,
dstCallId=0x4,srcCallId=0x3, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.430:cc_api_call_connected(vdbPtr=0x60D4A268,
callID=0x4)
Oct  9 17:39:26.430:ccCallConnect (callID=0x3)
Oct  9 17:39:26.430:ccCallAppReturn (callID=0x3)
Oct  9 17:39:26.430:ccCallSetContext (callID=0x4, context=0x6103DD3C)
Oct  9 17:39:30.683:cc_api_call_disconnected(vdbPtr=0x60D4A268,
callID=0x4, cause=0x10)
Oct  9 17:39:30.683:ccCallDisconnect (callID=0x4, cause=0x10 tag=0x0)
Oct  9 17:39:30.683:ccConferenceDestroy (confID=0x1, tag=0x0)
Oct  9 17:39:30.687:cc_api_bridge_done (confID=0x1, srcIF=0x60D4A268,
srcCallID=0x4, dstCallID=0x3, disposition=0 tag=0x0)
Oct  9 17:39:30.727:cc_api_call_disconnect_done(vdbPtr=0x60D4A268,
callID=0x4, disp=0, tag=0x0)
Oct  9 17:39:30.727:cc_api_bridge_done (confID=0x1, srcIF=0x60ED5134,
srcCallID=0x3, dstCallID=0x4, disposition=0 tag=0x0)
Oct  9 17:39:30.727:ccCallDisconnect (callID=0x3, cause=0x10 tag=0x0)
Oct  9 17:39:30.779:cc_api_call_disconnect_done(vdbPtr=0x60ED5134,
callID=0x3, disp=0, tag=0x0)
00:11:42:%LINK-3-UPDOWN:Interface Serial0:18, changed state to down

debug voip ivr

The debug voip ivr command is used to debug the IVR application. IVR debug messages will be displayed when a call is being actively handled by the IVR scripts. Error output should only occur if something is not working or an error condition has been raised. States output supplies information about the current status of the IVR script and the different events which are occurring in that state.

debug voip ivr [states | error | all]
no debug voip ivr [states | error | all]
Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

There are two types of messages:

  • Error—These messages should only be displayed if an error occurred.
  • States—These debug messages will display a lot of information about how IVR is handling each call.

Reference Information

The following information is supplied as background information only. It is intended to supplement basic understanding for these features and is not all inclusive on the subject matter.

Gatekeeper and Gateway Functional Description

Understanding the interrelationship between gatekeepers and gateways is needed when you perform the tasks involved with the software configuration for internetworking between the two. The functionality of the major voice network components is described below.

Gatekeepers

Gatekeepers are optional nodes that manage other nodes in an H.323 network. Other nodes communicate with the gatekeeper using the RAS protocol.

These nodes attempt to register with a gatekeeper on startup. When they wish to communicate with another endpoint, they request admission to the call, using a symbolic alias for the endpoint name such as an E.164 address or an e-mail ID. If the gatekeeper decides the call can proceed, it returns a destination IP address to the originating endpoint. This IP address cannot be the actual address of the target endpoint, and it can be an intermediate address. Finally, a gatekeeper and its registered endpoints exchange status information.

Gatekeeper Zones

H.323 endpoints are grouped together in zones. Each zone has one gatekeeper that manages all of the endpoints in the zone. A zone is an administrative convenience similar to a DNS domain. (Because a zone is, by definition, the area of control of a gatekeeper, you will find the terms "zone name" and "gatekeeper name" used synonymously in this document.)

H.323 Terminals

An H.323 terminal is an endpoint in the LAN that provides for real-time, two-way communications with another H.323 terminal or gateway. This communication consists of control, indications, audio, moving color video pictures, or data between the two terminals. A terminal may provide audio only; audio and data; audio and video; or audio, data, and video.

Gateways

Gateways allow H.323 terminals and routers to communicate with terminals running other protocols. They provide protocol conversion between terminals and routers running different types of protocols. A gateway is the point at which a circuit-switched call is encoded and repackaged into IP packets.

An H.323 gateway is an endpoint on the LAN that provides real-time two-way communications between H.323 terminals on the LAN and other ITU-T terminals in the WAN, or to another H.323 gateway.

Gatekeeper Functionality

The following sections describe the main features and functionality of a gatekeeper in an H.323 network:

Zone and Subnet Configuration

A zone is the set of H.323 nodes controlled by a single gatekeeper. Gatekeepers co-existing on a network may be configured so that they register endpoints from different subnets.

Endpoints attempt to discover a gatekeeper, and consequently what zone they are members of, by using the RAS message protocol. The protocol supports a discovery message that may be sent multicast or unicast.

If the message is sent multicast, the endpoint registers nondeterministically with the first gatekeeper to respond. To enforce predictable behavior, where endpoints on certain subnets are assigned to specific gatekeepers, you can use the zone subnet command to define the subnets that constitute a given gatekeeper's zone. Any endpoint on a subnet that is not enabled for the gatekeeper will not be accepted as a member of that gatekeeper's zone. If the gatekeeper receives a unicast discovery message from such an endpoint, it will send an explicit reject, but if the message was received multicast, the gatekeeper simply ignores it.

Terminal Name Registration

Gatekeepers recognize one of two types of terminal aliases, or terminal names:

  • H.323 identifiers (IDs), which are arbitrary, case-sensitive text strings
  • E.164 addresses, which are telephone numbers

If an H.323 network deploys interzone communication, each terminal should at least have a fully-qualified e-mail name as its H.323 ID. For example, bob@cisco.com. The domain name of the e-mail ID should be the same as the configured domain name for the gatekeeper of which it is to be a member. As in the previous example, the domain name would be cisco.com.

Interzone Communication

To allow endpoints to communicate between zones, gatekeepers must be able to determine which zone an endpoint is in and locate the gatekeeper responsible for that zone. If DNS is available, you can associate a DNS domain name to each gatekeeper.

Endpoint Identification via RADIUS

Version 1 of the H.323 specification does not provide a mechanism for authenticating registered endpoints. No credential information is passed. However, by enabling authorization, authentication and accounting (AAA) on the gatekeeper and configuring for RADIUS, you can achieve a rudimentary form of identification.

If you enable this feature, the gatekeeper attempts to use the registered aliases along with a password, and do an authentication transaction to a RADIUS server. The registration will only be accepted if RADIUS successfully authenticates the name.

The gatekeeper can be configured to use a default password for all users. It can also be configured to recognize a password separator character that allows users to piggyback their passwords onto H.323-ID registrations by using it to separate the ID and password fields.

Accounting via RADIUS

If you enable AAA on the gatekeeper, the gatekeeper will emit an accounting record each time an endpoint registers or unregisters, or each time a call is admitted or disconnected.

List of Terms

AAA—Authentication, Authorization, and Accounting. AAA is a suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.

ANI—Answer number Indication. The calling number (number of calling party).

ARQ—Admission request.

CAS—Channel associated signaling

CCAPI—Call Control Applications Programming Interface.

CEI—European Channelized TDM with 32 channels of 64 kHz each

CLI—Command line interface

CO—Central office

CPE—Customer premises equipment. Terminating equipment, such as terminals, telephones, and modems, supplied by the telephone company, installed at the customer sites, and connected to the telephone company network.

CSM—Call switching module.

Dial peer—An addressable call endpoint. In Voice over IP, there are two types of dial peers: POTS and VoIP.

DNS—Domain name system is used to address translation to convert H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to assist in the location of remote gatekeepers and to reverse-map raw IP addresses to host names of administrative domains.

DNIS—Dialed number identification service. The destination number.

DSP—Digital signal processor

E.164—The international public telecommunications numbering plan. A standard set by ITU-T which addresses telephone numbers.

E&M—Ear and mouth RBS signalling

Endpoint—An H.323 terminal or gateway. An endpoint can call and be called. It generates and/or terminates the information stream.

Gatekeeper—A gatekeeper maintains a registry of devices in the multimedia network. The devices register with the gatekeeper at startup, and request admission to a call from the gatekeeper.

The gatekeeper is an H.323 entity on the LAN that provides address translation and control access to the LAN for H.323 terminals and gateways. The gatekeeper may provide other services to the H.323 terminals and gateways, such as bandwidth management and locating gateways.

Gateway—A gateway allows H.323 terminals to communicate with non-H.323 terminals by converting protocols. A gateway is the point at which a circuit-switched call is encoded and repackaged into IP packets.

An H.323 gateway is an endpoint on the LAN that provides real-time two-way communications between H.323 terminals on the LAN and other ITU-T terminals in the WAN, or to another H.323 gateway.

H.323—An International Telecommunication Union (ITU-T) standard that describes packet-based video, audio, and data conferencing. H.323 is an umbrella standard that describes the architecture of the conferencing system, and refers to a set of other standards (H.245, H.225.0, and Q.931) to describe its actual protocol.

H.323 RAS—Registration, admission, and status. The RAS signaling function performs registration, admissions, bandwidth changes, status and disengage procedures between the VoIP gateway and the gatekeeper.

HSRP—Hot Standby Routing Protocol. HSRP is a Cisco proprietary protocol which provides a redundancy mechanism when more than one router is connected to the same segment/subnet of an Ethernet/FDDI/Token Ring network.

ITU-T—Telecommunication standardization sector of ITU.

IVR—Integrated voice response. When someone dials in, respond with a prompt to get a pin number, and so on.

LEC—Local exchange carrier.

LRQ—Location request.

MCU—Multipoint control unit

Multicast—A process of transmitting PDUs from one source to many destinations. The actual mechanism (that is, IP multicast, multi-unicast, etc.) for this process may be different for LAN technologies.

Multipoint-unicast—A process of transferring PDUs (Protocol Data Units) where an endpoint sends more than one copy of a media stream to different endpoints. This may be necessary in networks which do not support multicast.

node—An H.323 entity that uses RAS to communicate with the gatekeeper. For example, an endpoint such as a terminal, proxy, or gateway.

PDU—Protocol Dara Units, used by bridges to transfer connectivity information.

POTS—Plain Old Telephone Service. Basic telephone service supplying standard single line telephones, telephone lines, and access to the Public Switched Telephone Network.

PSTN—Public Switched Telephone Network. PSTN refers to the local telephone company.

QoS—Quality of Service, which refers to the measure of service quality provided to the user.

RAS—Registration, Admission, and Status protocol. This is the protocol that is used between endpoints and the gatekeeper to perform management functions.

RBS—Robbed Bit Signaling

RRQ—Registration request.

SPI—Service provider interface.

TCL—Tool command language.

TDM—Time division multiplexing. Technique in which information from multiple channels can be allocated bandwidth on a single wire based on preassigned time slots. Bandwidth is allocated to each channel regardless of whether the station has data to transmit.

VoIP—Voice over IP. The ability to carry normal telephone-style voice over an IP-based internet with POTS-like functionality, reliability, and voice quality. VoIP is a blanket term which generally refers to Cisco's standards based (H.323, etc.) approach to IP voice traffic.

VTSP—Voice telephony service provider.

Zone—A collection of all terminals (tx), gateways (GW), and Multipoint Control Units (MCU) managed by a single gatekeeper (GK). A Zone includes at least one terminal, and may or may not include gateways or MCUs. A Zone has only one gatekeeper. A Zone may be independent of LAN topology and may be comprised of multiple LAN segments which are connected using routes or other devices.


Note      For a list of other internetworking terms, see the Internetworking Terms and Acronyms document that accompanied your access server. This book is also available on product CD-ROM and the Cisco Connection Online URL at: http://www.cisco.com/univercd/home/home.htm.


Related Documentation

You can supplement this addendum with Release Notes for Cisco AS5300 for Cisco IOS Release 11.3 T, which documents the release from which this special release is derived. For additional information, refer to the sections "Cisco Connection Online" on page 115 and "CD-ROM/WWW" on page 115.

Online Documentation

The most up-to-date documentation can be found on the Web via Cisco Connection Online (CCO) and on the latest Documentation CD-ROM. These electronic documents might contain updates and modifications made after the paper documents were printed. For information on CCO, refer to the "Cisco Connection Online" section later in this document. For more information on to the CD-ROM, refer to the "Documentation CD-ROM" section later in this document.

Cisco AS5300 Documentation

The following Cisco AS5300 documents are available:

  • Cisco AS5300 Universal Access Server Hardware Installation Guide
  • Cisco AS5300 Universal Access Server Software Configuration Guide
  • New and Changed Cisco IOS Commands for the Cisco AS5300
  • Modem information
  • Regulatory compliance and safety information
  • Documentation for spare parts
  • Upgrading Cisco AS5300 Voice over IP Feature Card VCWare

This documentation can be found on CCO and on the Documentation CD-ROM:

  • On Cisco Connection Online (CCO), the path is Software & Support: Cisco Documentation: Access Servers and Access Routers: Access Servers: Cisco AS5300.

On the Documentation CD-ROM, the path is Access Servers and Access Routers: Access Servers: Cisco AS5300.

Cisco IOS Software Documentation

For more information on the Cisco IOS software documentation, see the Release Notes for Cisco AS5300 for Cisco IOS Release 11.3 T.

  • On CCO, click Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 11.3.

For Product Bulletins on CCO, the path is as follows: Products and Ordering: More Information: Product Bulletins. In the Software area, under Cisco IOS 11.3, click on the bulletin you wish to see. The Product Bulletin for Cisco IOS Release 11.3 NA is No. 762.

  • On the Documentation CD-ROM, go to Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 11.3.

The following are some of the types of Cisco IOS Release 11.3 documents:

  • Feature descriptions, Configuration Guides, Command References
  • Cisco IOS 11.3T New Features
  • Product-Specific Release Notes
  • Cisco IOS Software Release Caveats

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

To access the feature modules on CCO, follow this path:

Products and Ordering, Cisco Documentation: Cisco IOS Software Configuration: Cisco IOS Release 11.3: Cisco IOS 11.3T New Features

To access the feature modules on the documentation CD-ROM, follow this path:

Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 11.3: Cisco IOS 11.3T New Features

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.


Note      If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.


CD-ROM/WWW

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Sep 4 09:27:28 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.