Cisco IOS Software Releases 11.3

Table of Contents

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.

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.

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.

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).

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.

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>

Example

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".

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.

Tips

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.

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

show call application voice clid_authen_collect