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

show call application voice clid_authen_npw

show call application voice clid_authen_col_npw

show call application voice fax_hop_on_1

clid_col_npw_3

clid_col_npw_npw

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.

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.

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.

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.

Verify

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

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.

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.

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

Configure the Primary Gatekeeper

Configure the Backup Gatekeeper

Configure Identical Gatekeeper Modes on Both Gatekeeper 1 and Gatekeeper 2

Tips

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

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

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.

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

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.

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

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:

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.

On the gatekeeper for San Jose:

The gatekeeper is enabled by entering the following commands:

Command Mode

Gatekeeper Configuration:

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

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.

To Enable the Gateway

Command Mode

Configuration

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.

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:

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

5300-1# sh gateway