Table Of Contents
Service Provider Features for Voice over IP
Gatekeeper and Gateway Functional Description
Endpoint Identification via RADIUS
Service Provider VoIP Feature Overview
RADIUS Accounting with Overloaded Session ID
Message Flow for clid_col_npw_3
Message Flow for clid_col_npw_npw
Dial Peer Configuration Restrictions for ISDN Redirect
ISDN Redirect Call Flow Scenario
Gatekeeper Feature Descriptions
Configuring Gatekeepers for Hot Standby
Force Technology Prefix Hop-off
Configuring the VoIP Gatekeeper and Gateway
Sample Gatekeeper HSRP Configuration
Sample Gatekeeper Configuration
aaa accounting connection h323
aaa authentication login h323 radius
show gatekeeper gw-type-prefix
Service Provider Features for Voice over IP
Feature Summary
The Cisco voice Service Provider features include enhancements made to the functionality and configuration of both the gateway and the Voice over IP (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 H.323 VoIP gateway in addition to features required to implement the applications to run VoIP in a service provider environment. The features address the service provider needs to offer security, billing, scaling, and reliability.
The VoIP gateway is a high performance H.323-compliant gateway optimized for VoIP applications. Supporting up to two T1/E1 digital channels, it connects with existing telephones and fax machines through the Public Switched Telephone Network (PSTN), key systems, and PBXs, making the process of placing calls over the IP network transparent to users.
The gateway capability allows the access device to function as an H.323 endpoint. Therefore, the gateway provides admission control, address lookup and translation, and accounting services.
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 PSTN, to improve 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.htmBenefits
•
•
•
•
•
Restrictions
•
•
•
•
•
Platforms
This feature is supported on the following platforms:
•
•
•
Supported MIBs and RFCs
This feature supports the CISCO-VOICE-DIAL-CONTROL-MIB and the SNMP MIBs. The CISCO-VOICE-DIAL-CONTROL-MIB supports the QoV and QoS of VoIP calls. The SNMP MIBs are available on CCO. Refer to the online support reference listed at the following location:
•
•
•
•
•
•
•
•
List of Terms
AAA—authentication, authorization, and accounting. AAA is a suite of network security services that provides the primary framework through which access control can be set up on your Cisco router or access server.
ANI—Automatic number identification.
ARQ—Admission request.
CAS—Channel associated signaling.
CCAPI—Call control applications programming interface.
CEI—European channelized time division multiplexing (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 (VoIP), there are two types of dial peers: POTS and VoIP.
DNS—Domain name system used to address translation to convert H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to assist in the location of remote gatekeepers and to reverse-map raw IP addresses to host names of administrative domains.
DNIS—Dialed number identification service (the called number).
DSP—Digital signal processor.
DTMF—Dual tone multi-frequency.
E.164—The international public telecommunications numbering plan. A standard set by ITU-T that addresses telephone numbers.
E&M—Ear and mouth RBS signaling.
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 that 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, it responds with a prompt to get a personal identification number (PIN), and so on.
LEC—Local exchange carrier.
LRQ—Location request.
MCU—Multipoint control unit
MF—Multifrequency tones are made of six frequencies that provide 15 two frequency combinations for indication digits 0-9 and KP/ST signals.
multicast—A process of transmitting PDUs from one source to many destinations. The actual mechanism (that is, IP multicast, multi-unicast, and so forth) for this process might be different for LAN technologies.
multipoint-unicast—A process of transferring PDUs (Protocol Data Units) where an endpoint sends more than one copy of a media stream to different endpoints. This might be necessary in networks which do not support multicast.
node—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 data units. Used by bridges to transfer connectivity information.
POTS—Plain old telephone service. Basic telephone service supplying standard single line telephones, telephone lines, and access to the PSTN.
PSTN—Public Switched Telephone Network. PSTN refers to the local telephone company.
QoS—Quality of service, which refers to the measure of service quality provided to the user.
RAS—Registration, Admission, and Status protocol. Protocol 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 (for example, H.323) 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 can include gateways or multipoint control units (MCUs). A zone has only one gatekeeper. A zone may be independent of LAN topology and can be comprised of multiple LAN segments which are connected using routes or other devices.
Note
Functional Description
This section provides an overview of how gatekeepers and gateways work together.
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:
•
•
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.
The balance of this section provides detailed information on the following topics:
•
•
•
•
•
Service Provider VoIP Feature Overview
The Service Provider features for VoIP 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 gateway functionality and gatekeeper functionality work in concert to provide the ITU-T H.323 infrastructure. Therefore, the two main components in the voice architecture that interoperate to enable the service provider feature set are:
•
•
Refer to "VoIP PSTN Signaling Architecture" 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 voice-capable platform with voice cards and the VoIP image. Gateways may also be referred to as VoIP gateways.
Note
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 PSTN, to improve QoS, and to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into DNS, or via software configuration options.
Note
In addition to the Cisco IOS Release 11.3NA functionality described in documentation on CCO, 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
The routers performing the access server functionality for the gatekeeper are:
•
•
Gateway Features
The gateway capability is the ability of the voice-capable platform to function as an H.323 endpoint. Therefore, the gateway provides the following 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 the section "Configuring the VoIP Gatekeeper and Gateway."
Descriptions of each gateway feature and the commands follow.
Gateway RAS Implementation
RAS is a signaling function that 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 the section "This is an example of the configuration steps required to allow the internetworking functionality between the VoIP gateway and the gatekeeper.."
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:
•
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 "The gateway technology prefix is set up using the following new commands:."
•
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 E.164 address to an IP address. (For example, if an IP address is used: session target ipv4:A.B.C.D. If DNS is used: session target dns: gateway@domain. If Gatekeeper is used: session target ras.)
•
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 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 Functionality
The AAA features are required in the VoIP gateway. The standard AAA functionality is enhanced to collect digits during the call processing process. Processes such as:
•
•
This AAA 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
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.
Note
Standard RADIUS Attributes
The standard RADIUS attributes supported are:
•
•
•
•
•
•
•
Nonstandard RADIUS Attributes
The nonstandard RADIUS attributes that are packed into the Acct-Session-Id attribute field are:
•
•
•
•
•
•
•
•
•
RADIUS Accounting with Overloaded Session ID
To take advantage of standard RADIUS implementations that do not support vendor specific attributes a new method is defined that 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.
To support additional fields, following 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>
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 address1
Address of the remote gateway port where the call is connected.
1 Support for remote ip address field was introduced with Cisco IOS Release 11.3(7)NA.
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 can advantage of more information elements, Cisco's VSA implementation is recommended.
The following examples illustrate the use of the Acct-Session-Id field:
Example 1 Start Record
Client-Id = 172.29.248.123NAS-Port-Type = 0User-Name = "4004"Called-Station-Id = "+111"Calling-Station-Id = "+222"Acct-Status-Type = StartUser-Service-Type = Login-UserAcct-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 = 0Example 2 Stop Record
Client-Id = 172.29.248.123NAS-Port-Type = 0User-Name = "4004"Called-Station-Id = "+111"Calling-Station-Id = "+222"Acct-Status-Type = StopUser-Service-Type = Login-UserAcct-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 = 8340Acct-Output-Octets = 8900Acct-Input-Packets = 417Acct-Output-Packets = 445Acct-Session-Time = 9Acct-Delay-Time = 0Example 3 Update Record
Client-Id = 172.29.248.123NAS-Port-Type = 0User-Name = "4004"Called-Station-Id = "+111"Calling-Station-Id = "+222"Acct-Status-Type = 3User-Service-Type = Login-UserAcct-Session-Id = "4/21:54:17.052 UTC Mon Jul 201998/ak3620-1.cisco.com/BF1AC9CA 8DE60006 0 5ED24/originate/VoIP///"Acct-Delay-Time = 0Syslog 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 on the network. The syslog output consists of the following:
<server timestamp> <gateway id> <message number> : <message label> : <list of AV pairs>
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 0AAA Commands
The following Cisco IOS commands are designed for configuring the Service Provider Voice over IP AAA functionality.
Refer to the "Command Reference" section for more information on VoIP AAA commands.
Note
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt1/
index.htm.
AAA is also referred to as Security Services.Interactive Voice Response
Service provider for VoIP includes 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 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 IVR 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 the "IVR Script Description" section for more information.
ANI Authorization
IVR scripts also utilize ANI authorization, which 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 the "IVR Script Description" section for more information.
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
To obtain a complete description of each script, 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 were 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 Samples
The supported IVR scripts are described below using the show call application voice app name command:
show call application voice clid_authen
voicelab>show call application voice clid_authenApplication clid_authen has 8 states with 0 calls activeState start has 1 actions and 5 eventsDo Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnisIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACKand goto state startIf Event IVR_EV_AAA_SUCCESS goto state collect_destIf Event IVR_EV_AAA_FAIL goto state authenticate_failState end has 1 actions and 3 eventsDo Action IVR_ACT_END.If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROYand do nothingState collect_dest has 3 actions and 5 eventsDo Action IVR_ACT_TONE. tone=8Do Action IVR_ACT_COLLECT_DIALPLAN.Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_DIAL_COL_SUCCESS goto state place_callIf Event IVR_EV_DIAL_COL_FAIL goto state collect_failIf Event IVR_EV_TIMEOUT do action IVR_ACT_TONEand goto state collect_fail count=0State place_call has 1 actions and 4 eventsDo Action IVR_ACT_PLACE_CALL.destination= called=calling= account=If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_UP goto state activeIf Event IVR_EV_CALL_FAIL goto state place_failState active has 0 actions and 2 eventsIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingState authenticate_fail has 1 actions and 2 eventsDo Action IVR_ACT_PLAY.URL: flash:auth_failed.auallowInt=0, pContent=0x0If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingState collect_fail has 1 actions and 2 eventsDo Action IVR_ACT_PLAY.URL: flash:collect_failed.auallowInt=0, pContent=0x0If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingState place_fail has 1 actions and 2 eventsDo Action IVR_ACT_PLAY_FAILURE_TONE.If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingshow call application voice clid_authen_collect
voicelab>show call application voice clid_authen_collectApplication clid_authen_collect has 10 states with 0 calls activeState start has 1 actions and 5 eventsDo Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnisIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACKand goto state startIf Event IVR_EV_AAA_SUCCESS goto state collect_destIf Event IVR_EV_AAA_FAIL goto state get_accountState end has 1 actions and 3 eventsDo Action IVR_ACT_END.If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROYand do nothingState get_account has 4 actions and 7 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_account.auallowInt=1, pContent=0x60E4C564Do 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 endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_PAT_COL_SUCCESS goto state get_pinpatName=accountIf Event IVR_EV_ABORT goto state get_accountIf Event IVR_EV_PLAY_COMPLETE do nothingIf Event IVR_EV_TIMEOUT goto state get_account count=0If Event IVR_EV_PAT_COL_FAIL goto state get_accountState get_pin has 4 actions and 7 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_pin.auallowInt=1, pContent=0x0Do 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 endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_PAT_COL_SUCCESS goto state authenticatepatName=pinIf Event IVR_EV_PLAY_COMPLETE do nothingIf Event IVR_EV_ABORT goto state get_accountIf Event IVR_EV_TIMEOUT goto state get_pin count=0If Event IVR_EV_PAT_COL_FAIL goto state get_pinState authenticate has 1 actions and 5 eventsDo Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pinIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_AAA_SUCCESS goto state collect_destIf Event IVR_EV_TIMEOUT do nothing count=0If Event IVR_EV_AAA_FAIL goto state authenticate_failState collect_dest has 4 actions and 8 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_destination.auallowInt=1, pContent=0x0Do 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 endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_PLAY_COMPLETE do nothingIf Event IVR_EV_ABORT goto state collect_destIf Event IVR_EV_TIMEOUT goto state collect_dest count=0If Event IVR_EV_DIAL_COL_SUCCESS goto state place_callIf Event IVR_EV_DIAL_COL_FAIL goto state collect_destIf Event IVR_EV_TIMEOUT goto state collect_dest count=0State place_call has 1 actions and 4 eventsDo Action IVR_ACT_PLACE_CALL.destination= called=calling= account=If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_UP goto state activeIf Event IVR_EV_CALL_FAIL goto state place_failState active has 0 actions and 2 eventsIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingState authenticate_fail has 1 actions and 2 eventsDo Action IVR_ACT_PLAY.URL: flash:auth_failed.auallowInt=0, pContent=0x0If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingState place_fail has 1 actions and 2 eventsDo Action IVR_ACT_PLAY_FAILURE_TONE.If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingsblab115>show call application voice clid_authen_collectApplication clid_authen_collect has 10 states with 0 calls activeState start has 1 actions and 5 eventsDo Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnisIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACKand goto state startIf Event IVR_EV_AAA_SUCCESS goto state collect_destIf Event IVR_EV_AAA_FAIL goto state get_accountState end has 1 actions and 3 eventsDo Action IVR_ACT_END.If Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROYand do nothingState get_account has 4 actions and 7 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_account.auallowInt=1, pContent=0x60E4C564Do 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 endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_PAT_COL_SUCCESS goto state get_pinpatName=accountIf Event IVR_EV_ABORT goto state get_accountIf Event IVR_EV_PLAY_COMPLETE do nothingIf Event IVR_EV_TIMEOUT goto state get_account count=0If Event IVR_EV_PAT_COL_FAIL goto state get_accountState get_pin has 4 actions and 7 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_pin.auallowInt=1, pContent=0x0Do 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 endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_PAT_COL_SUCCESS goto state authenticatepatName=pinIf Event IVR_EV_PLAY_COMPLETE do nothingIf Event IVR_EV_ABORT goto state get_accountIf Event IVR_EV_TIMEOUT goto state get_pin count=0If Event IVR_EV_PAT_COL_FAIL goto state get_pinState authenticate has 1 actions and 5 eventsDo Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pinIf Event IVR_EV_DEFAULT goto state endIf Event IVR_EV_CALL_DIGIT do nothingIf Event IVR_EV_AAA_SUCCESS goto state collect_destIf Event IVR_EV_TIMEOUT do nothing count=0If Event IVR_EV_AAA_FAIL goto state authenticate_failState collect_dest has 4 actions and 8 eventsDo Action IVR_ACT_PLAY.URL: flash:enter_destination.auallowInt=1, pContent=0x0Do Action IVR_ACT_ABORT_KEY. abortKey=*Do Action IVR_ACT_TERMINATION_KEY. terminationKey=#
Guest
