|
|
Whereas the infrastructure of the TDM-based PSTN essentially has billing mechanisms built in, VoIP networks require their own reliable billing mechanisms to account for call start and stop times across the various call legs, or definable sections of a call's path. Where multiple service providers are involved in a Cisco Wholesale Voice Solution, tools and applications that cross SP boundaries become essential. These are known as shared support services, and have a major role in ensuring that billing is performed correctly and call time records are apportioned appropriately among the various SPs involved in a call's transit.
This chapter discusses issues that are essential to understanding these shared services, and provides configuration examples. The features available in the H.323 standard for packet telephony provide for billing from the GW by using the accounting component of AAA/RADIUS capabilities.
This chapter presents the following major topics related to billing:
In addition, management applications become critically important when networks become large. See the following for an overview of how to install and use such systems:
Figure 3-1 illustrates the relationship between originating and terminating GWs, their shared GK, and a RADIUS server. In effect, during a call setup both GWs communicate with the RADIUS server and the GK, in addition to each other. (See Figure 3-2.)
The following discussion draws from the following document:
Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers, at the following URL:
http://www.cisco.com/warp/public/cc/so/cuso/sp/sms/acct/caaaf_cg.htm
 |
Note Refer to the above website for more detail and configurations. However, more current provisioning information related to RADIUS attribute fields is presented in the following discussion. |
The accounting features in the AAA framework of the Cisco IOS software aid in the development of third-party billing systems, specifically for voice-enabled access servers and routers. Although AAA represents authentication, authorization, and accounting, only the accounting element of AAA and the RADIUS A/V (attribute/value) pairs generated through its use are addressed here. This Cisco IOS software and RADIUS accounting feature is required in VoIP gateways for producing accurate and timely billing and usage information.
Cisco IOS accounting for voice uses standard RADIUS attributes where possible. There are two fundamental accounting methods. For an explanation and recommendations, see Methods to Enable VoIP Accounting on Gateways to Support Billing. Essential to billing is the call leg, one of four discrete paths from one PSTN subscriber to another. Figure 3-2 illustrates the four call legs between the ingress and egress PSTN:
1. First ingress leg, from the PSTN subscriber to the originating GW
2. First egress leg, from the originating GW to the VoIP network
3. Second ingress leg, from the VoIP network to the terminating GW
4. Second egress leg, from the terminating GW to the PSTN subscriber
Data are collected for each call leg that is created on the GW. A call leg is the internal representation of a connection to the GW. Each connection that is made through the GW consists of two call legs: an incoming (answer) and an outgoing (originate) call leg. A connection using an originating and a terminating GW has four separate call legs (answer telephony, originate VoIP, answer VoIP, and originate telephony). When start-stop accounting is used, there is a separate start record and stop record for each call leg. This implies that a call generated between two voice-enabled routers will generate four discrete start records and four discrete stop records for each call connected, all having the same connection (or conference) ID (refer to Table 1, Standard Supported RADIUS Attributes, in Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers). The various call-leg records for a single end-to-end call can be correlated through the VSA conf_id (conference ID; attribute name = h323_conf_id) field, a 128-bit field in hexadecimal format.
Call start and stop records are sent to the RADIUS host from each GW. Each call leg generates start, update, and stop records, and each record has information specific to its call leg. Each leg reports the NTP (Network Time Protocol) time for each of the following states:
 |
Caution Although the start record for each leg may be useful for diagnostic purposes, do not use it for billing. As a general rule on GWs, Cisco recommends that you bill at call legs 2 and 3, using the stop record. This will cover approximately 90% of the cases. However, circumstances will arise that require billing at other parts of the network, depending on the path a call must make before it terminates. |
|
Note NTP is discussed in Using Network Time Protocol (NTP). |
AAA accounting in Cisco IOS software for voice calls can be configured to record either start-stop or stop-only records. The start-stop option creates a record for each call leg at the start of a call and at the end of the same call. The stop-only option just creates the records for all call legs at the end of each call. If stop-only accounting is configured, then the number of records generated for one call would be four (a stop record for each of the four call legs). The various call leg start and stop records generated by the GWs can be organized by their conference ID, which is the same for all call legs of a connection. Using the connection ID value as the glue, a billing application can generate all the information needed for accurate and timely billing.
Figure 3-3 illustrates the call leg events and recommended billing interval for RADIUS billing.
There are four fundamental steps to configuring AAA in a configuration session:
2. Define the accounting methods.
4. Establish key files on the RADIUS server.
The above and other issues are covered under the following topics:
For an example configuration, see Configuring a Gateway for Prepaid Card Service. Before proceeding to that section, it will be beneficial to understand issues related to voice prompts and billing, as discussed in the following:
The following Cisco IOS commands are designed for configuring the service provider voice over IP accounting and billing functionality.
This configuration defines the accounting method list "h323" with RADIUS as a protocol and with either stop-only or start-stop accounting options. The method list must be called h323 and is activated for all voice interfaces. This command tells the system to use a method list called h323, which has start-stop or stop-only radius as its method. The h323 method list is static and is applied by default to all voice interfaces.
|
Note The group command is required. |
For a complete description of Cisco accounting commands and their parameters, see Accounting Commands under Authentication, Authorization, and Accounting at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_r/srprt1/index.htm
The above is part of the Cisco IOS Security Command Reference, Release 12.1.
For details on using the AAA accounting commands, refer to Cisco IOS AAA Accounting Commands in Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers, at the following URL:
http://www.cisco.com/warp/public/cc/so/cuso/sp/sms/acct/caaaf_cg.htm.
Debug and troubleshooting commands are provided there also, in addition to the following topics:
There are two ways to enable accounting on GWs to support billing. Until Cisco IOS Release 12.0(7)T, the Cisco specific parameters were overloaded into RADIUS attribute 44, Acct-Session-ID. Attributes that cannot be mapped to standard RADIUS are "packed" into the Acct-Session-Id attribute field (attribute 44) as a "/" (forward slash) delimited ASCII string. The older method has been superseded by a newer, recommended method: using vendor-specific attributes, or VSAs. Both methods are discussed below.
Attribute 44 carries a limited amount of information. Enabling attribute 26 makes a larger set of information available for communication. In releases later than Cisco IOS Release 12.0(7)T, the overloaded Acct-Session-ID method continues to be the GW's default behavior, but you can configure the GW to enable VSAs. (VSAs are platform-independent and comply with voice platforms supported by Cisco.) When you enable accounting, this default behavior is enabled.
To enable gateway-specific VSAs, use the commands radius-server and gw-accounting in global configuration mode. The two fundamental steps are as follows:
1. Enable the GW to recognize and use VSAs as defined by RADIUS attribute 26. This establishes communication between the GW and the server.
2. Enable GW-specific accounting.
The option h323 configures standard H.323 accounting by means of standard IETF RADIUS attributes. This enables call data records (CDRs) to be generated for voice calls. The option vsa enables H.323 accounting through RADIUS vendor specific attributes.
|
Note The command gw-accounting also provides a syslog option. The syslog keyword configures the system logging facility to output accounting information in the form of a system log message. For more information about this type of accounting, see Enabling Syslog Accounting 3-11. |
The above commands are discussed in greater detail in Configuring a Gateway for AAA.
In order to take advantage of standard RADIUS implementations that do not support vendor-specific attributes (VSAs), a method was defined that embedded the unsupported information elements in the RADIUS Acct-Session-Id field (RADIUS value 44 per RFC 2139). The Acct-Session-Id field has a maximum length of 256 bytes. It was defined to contain ten slash-separated fields, one of which is the RADIUS connection-id, which is a unique identifier that links accounting records associated with the same login session for a user. The internal representation of the connection-id field is 128 bits in hex format. This string can vary in appearance. In the examples cited in the CDR section of the Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers, the connection-id is of the form 3C5AEAB9 95C80008 0 587F34 (one 4-octet string, a space, one 4-octet string, a space, a zero, a space, and one 3-octet string). The overloaded Acct-Session-Id field also contains connect and disconnect times, remote IP address, and disconnect cause.
In order to support these additional fields, the following string format for the Acct-Session-Id field is used:
This method is used with RADIUS call leg billing in a postpaid calling-card scenario, not in a prepaid scenario. The reason for this is that the GW does not receive an ACK from the RADIUS server.
|
Note For descriptions of the above, refer to Overloaded Acct-Session-Id Field Descriptions in Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers. |
To enable the gateway to recognize and use VSAs defined by attribute 26, use the gw-accounting h323 vsa command. After you enable VSAs, the Acct-Session-Id is no longer overloaded because the information sent in the session ID is captured in VSAs.
For more information on using VSAs with a RADIUS server, refer to the following:
RADIUS Vendor-Specific Attributes Voice Implementation Guide, Version 3.1, at
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.htm
Figure 3-4 illustrates a subsection of GK zone NA-GK. The following example establishes AAA billing on US-GW1. There are three basic activities:
Configure the following on all GWs that must communicate with a RADIUS server. Required and optional commands are so indicated.
First establish authenticated communication between the GW and the server. This allows the RADIUS server to recognize and use VSAs.
|
Note See AAA Accounting Commands
3-5. For details related to RADIUS implementations, refer to Configuring RADIUS at the following
URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt2/scdrad.htm |
Step 2 Configure the router to use the H.323 protocol list for authentication purposes.
Following authentication, exec permits all necessary interactions.
Step 3 Define the accounting method list "h323" with RADIUS as a method. Here start-stop accounting will be used. The method list must be called h323 and is activated for all voice interfaces—provided the gw-accounting h323 command is also activated.
The command connection is critical.
Step 4 [Optional] Define a threshold time, in seconds, after which the router assumes that the RADIUS server is dead. After the threshold is exceeded, the router alerts an administrator that there is a security problem. Here we use 120 seconds (the default).
Step 5 Establish the IP address of the RADIUS server host, as well as the (well-known) ports for both the authentication and accounting services. The ports must match those of the RADIUS server.
Step 6 Configure the radius-server key secret. This establishes the shared secret text string that is used between the GW and the server. Here our example key is lab.
Step 7 [Optional] Specify the number of times (retries) the GW transmits each RADIUS request to the server before giving up. The default is three.
Step 8 [Optional] Specify the number of seconds (seconds) the GW waits for a reply to a RADIUS request before retransmitting the request.
Step 9 [Optional] Specify the number of minutes (minutes) that a RADIUS server failing to respond to authentication requests is passed over by requests for RADIUS authentication.
Step 10 Apply lockout prevention (see Step 2) to the vty ports:
After communication is established, configure the GW to use vendor-specific RADIUS attributes.
Step 2 Enable VSA authentication.
Now use the command gw-accounting to establish H.323 accounting on the GW. Cisco recommends that you run the latest supported Cisco IOS software on all GWs. However, to cover all possible scenarios with a variety of IOS releases, Cisco recommends that you establish all three of the following options in the sequence below.
|
Note For the most current features, refer to Enhancements to the Session Initiation Protocol for VoIP on Cisco
Access Platforms, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtsipgv2.htm |
Step 2 Establish H.323 accounting.
Step 3 Establish H.323 VSAs.
|
Note With Cisco IOS Release 12.1 an 11th field was added to the overloaded Acct-Session-ID list. This was to accommodate long-pound calls typical of card services. |
RADIUS applications vary, and are provided by a variety of vendors. Generally speaking, user keys and GW identities must reside in certain files in specified directories on the RADIUS server. This provides security for authentication. Check the installation instructions for your specific RADIUS application for the required locations and formats of these files.
However, to provide billing services, it is not sufficient to have only a standard RADIUS server. In order to support VoIP CDRs, billing partners must develop RADIUS applications that are customized to interact with Cisco GWs. Contact your Cisco account representative for developer support.
In order for the accounting records to include accurate connect and disconnect time records, Network Time Protocol (NTP) must be included in the router configuration. See Providing Network Timing through NTP.
For further information, including NTP time formats and links to useful sites, refer to Network Time Protocol (NTP) Usage Guidelines in Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers, at the following URL:
http://www.cisco.com/warp/public/cc/so/cuso/sp/sms/acct/caaaf_cg.htm
The Cisco IOS software can send syslog (system log) messages to one or more element management servers. Syslog messages are then collected by a standard UNIX or NT syslog daemon. These messages allow you to do the following:
The syslog accounting option exports the information elements associated with each call leg through a system log message that can be captured by a syslog daemon. The syslog output consists of the following:
|
Note This discussion is limited to RADIUS accounting (gw-accounting h323) only. |
For information on enabling syslog, see Task 2. Enabling Syslog, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm
The SNMP (Simple Network Management Protocol) traps that are generated by Cisco routers provide useful information such as the following:
The Cisco IOS software generates SNMP traps depending on the features that the Cisco IOS release supports. For information on enabling SNMP, see Task 3. Enabling SNMP at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm
You can also use a management information base (MIB) to manage RADIUS statistics on an AAA server. That SNMP version 2 MIB is located at the following URL:
ftp://ftp.cisco.com/pub/mibs/v2/CISCO-AAA-SERVER-MIB.my
For information about the MIB feature, refer to
Cisco AAA Server MIB and Additional Enhancements for the Cisco AS5300 and Cisco AS5800 Universal Access Servers, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dt_3asmb.htm
The above feature module discusses implementations of the Cisco AAA Server MIB to expand the RADIUS capabilities of the Cisco AS5300 series universal access servers.
For an example of these commands in configuration for a prepaid scenario, see Prepaid Card Services.
 |
Tip To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml |
In a VoIP environment involving multiple parties, the entity known as the clearinghouse is often the only way to handle call termination for the purpose of billing and settlement. Open Settlements Protocol (OSP) clearinghouses are third-party solutions that take advantage of OSP support in Cisco devices. This section discusses how to provision an OSP server to the GW.
|
Caution A special Cisco IOS image is required to support OSP. For the images required for each router type, see Release Notes for the Cisco Wholesale Voice Solution. |
|
Note For more information about OSP, refer to "Open Settlements Protocol (OSP) Clearinghouse Solution," Appendix A of the Cisco Wholesale Voice Solution Overview. |
The TransNexus OSP Nexus Server provides carrier-grade clearinghouse interdomain authentication, routing (brokering), and CDR collection. Administered through a Web browser, the OSP Nexus Server provides centralized management of call routing, secure enrollment of network devices (such as GWs, GKs, call agents, and proxy servers), as well as easy integration with external billing and provisioning systems. More information about TransNexus products is available at http://www.transnexus.com.
Network devices query the server for call routing and authorization information, and report usage details to the server. Clearinghouse operators then collect from the server information related to rating, billing, and settlement.
Recommended minimum hardware requirements are a Sun SPARCstation with a 300-MHz CPU and 512 MB of RAM. Solaris 7 or later is required.
The installation and maintenance of this product are the responsibility of the service provider in conjunction with the product's representatives.
Consider the following example. Figure 3-5 illustrates an OSP server that supports two independent zones, one belonging to a wholesale SP, the other to an ITSP. Billing software on the server is used to settle claims between the parties. Our example will look at the provisioning on the two GWs, AUS-GW1 and US-GW1.
|
Note Figure 2-17 illustrates an example call flow for RAS failover to an OSP server. |
An analysis of the following configurations illustrates key provisioning and features.
First look at AUS-GW1. Essentially the only items of interest in its configuration are the identity of the OSP server, the servers address, and the crypto certificates.
The settlement statement correlates the above destination pattern with the address of an OSP server.
|
Tip For details of configuring settlement on third-party servers, refer to Configuring Settlement for Packet Telephony, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_c/mcprt1/mcd4voip.htm |
The configuration of US-GW1 is essentially similar to the previous configuration.
|
Tip To avoid having to configure OSP on every GW, and to preserve the existing GK network, consider using back-to-back GWs, as discussed in Configuring Back-to-Back Gateways. For details, see Back-to-Back Gateway in an OSP Transit Zone. |
This section discusses the following:
In addition, the following commercial integrated billing applications are discussed briefly:
Figure 3-6 illustrates an example infrastructure required to support authorization and billing for prepaid calling card services.
For details related to configuring prepaid and OSP-based services, refer to Cisco Pre-Paid and OSP Configuration Guide, at the following URL:
http://www.cisco.com/warp/public/cc/so/cuso/sp/prepd_cg.htm
For background on the required audio files and their support components, see Provisioning Services to Support IVR.
Consider a simple example network consisting of a RADIUS server with IP address 172.19.49.2, a TFTP server with address 172.19.49.14, and a GW with address 172.19.49.166.
Apply the following example configuration to US-GW1 in global configuration mode. Refer also to the following:
|
Note For useful background information and tips, refer to Configuring Debit
Card for Packet Telephony at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_c/mcprt1/mcd3voip.htm |
However, the above document precedes TCL IVR 2.0, and some commands have since changed.
Step 2 Define an AAA RADIUS server.
Step 3 Define the accounting method list "h323" with RADIUS as a method. Here start-stop accounting will be used. The method list must be called h323 and is activated for all voice interfaces—if the gw-accounting h323 command is also activated.
Step 4 Assign a local reference name to the voice script for debit card (here arbitrarily called debit), and tell the GW where the TCL script is stored on the TFTP server.
Step 5 Establish parameters for the voice prompt. The next three line, respectively, refer to the file referenced as debit in Step 4.
a. Establish a length, in digits, for the user ID.
b. Establish an account-time remaining threshold, in seconds, at which a warning is activated.
Step 6 Make sure to use the corresponding set-location command.
Step 7 Enable gw-accounting features.
Step 8 Establish an IP address and ports for the RADIUS server.
Step 9 Configure the RADIUS server to be a slave to a master clock source (for example, 172.19.49.166). See Using Network Time Protocol (NTP).
The router will now synchronize automatically with the master clock.
The provisioning required to support postpaid card services is essentially the same as that required for prepaid, with the exception that real-time interaction is not required. Although CDRs are still created, no real-time interaction with the user is required. The following activities, however, do take place:
However, the above are all read-only activities: no records need to be updated until the call is completed.
MIND-iPhonEX is a web-based VoIP billing solution provided by MIND CTI. This integrated product performs caller authentication, authorization, and accounting in real time, and provides for the creation and management of prepaid calling cards, real-time call rating, and billing of credit customers. For more information about MIND CTI and their products, visit http://www.mindcti.com.
|
Caution MIND-iPhonEX does not support the use of the md5 hashed password. The md5 hashed password is required for H.235 security. |
In order to accommodate large numbers of customer accounts, MIND offers a UNIX real-time server (RTS). Multiple RTSs can be installed to provide load sharing and failover functionality, as required. In addition, to provide reliability and scalability, MIND -iPhonEX uses an Oracle database. Contact your MIND representative for the most current requirements, both hardware and software, of the RTS and database.
Cisco is not responsible for installing, provisioning, or maintaining MIND CTI's products.
Clarent Command Center can be used as part of the Cisco Wholesale Voice Solution to provide centralized billing, network management of user accounts, dynamic call routing, flexible call rating, and subscriber authentication. A centralized database provides a single point of administration for distributed networks. For more information about Clarent and their products, visit http://www.clarent.com
Among other features, Clarent Command Center provides the following billing options:
Clarent recommends that Clarent Command Center run on a dedicated NT server with a Pentium II processor (minimum 366 MHz) with at least 128 MB of RAM and a 4.3 GB hard drive. For current information and complete details, refer to Clarent Command Center Technical Reference, Release 3.1 or later, or contact a Clarent representative.
Cisco is not responsible for the installing, provisioning, or maintaining Clarent's products. Refer to Clarent Command Center Technical Reference, Release 3.1 or later for currrent information (including complete hardware and software requirements) on how to install, configure, and operate Clarent Command Center.
To support services that require interactive voice messaging, such as for a prepaid card service that requests a user's PIN number and notifies the user of the number of minutes remaining, several components require consideration.
These issues are discussed, respectively, in the following sections:
TFTP, a connectionless protocol based on UDP, is inherent in most UNIX systems. TFTP is used to transfer files between remote file systems and GWs with a minimum of interactive overhead—and security (thus the term "trivial"). In addition to hosting and delivering Cisco IOS images, a TFTP server has a significant role to play in a wholesaler's network where interactive voice prompts, often in multiple languages, are required. This section addresses the use of a TFTP server to host audio files.
You must begin by ensuring that the TFTP daemon is enabled and a tftpboot directory exists. Follow the steps below to enable TFTP on the server.
In order to upload or download a configuration file, the TFTP daemon (tftpd) must be enabled. If you are using the standard Sun software, verify that tftpd is enabled by completing the following steps:
Step 2 Using a text editor such as vi, edit the file /etc/inetd.conf file.
Step 3 Look in the file /etc/inetd.conf for the line that invokes tftpd. If the line is commented out [starts with a pound (#) as in the following example],
Use the text editor to remove the pound (#) sign so that only the following remains:
|
Note The argument -s indicates that this is a Solaris system. |
Step 4 Save the changes in the edited file and exit.
Step 5 At the UNIX prompt, enter the following command to display the process id number for the inetd configuration.
The system responds with something similar to the following:
The first number in the output is the process ID of the inetd process (in the above example, 119).
Step 6 You must restart the process by entering the following:
Step 7 Verify that TFTP is enabled by typing the following:
The output should be similar to the following:
If there is no output, tftpd is not enabled.
|
Note For additional information on TFTP, refer to the UNIX man pages on tftp and tftpd. |
The tftpboot directory can be used to save and store voice and configuration files that are loaded to a GW. By default, the tftpboot directory resides at the root of the host server file system. This ensures that a requesting system can find the directory easily and consistently. Look at the root directory to see if tftpboot exists. If it does not, follow the steps below to create the directory.
Step 2 The tftpboot directory must have the appropriate permissions. To ensure the correct permissions, modify them with the following command:
As a result, all users accessing the tftpboot directory will have read, write, and execute permissions.
The following illustrates how to enable the downloading of voice prompt files to a GW. You will need to enable TFTP access on each GW to which files are to be downloaded. This includes telling the GW the IP address of the machine on which the files are stored. Enter the privileged EXEC mode on the access router to enable the following steps.
|
Note For the above and following command, refer to the Cisco IOS Multiservice Command Reference for
a discussion of call application voice. Refer to http://www/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_r/mrd_a.htm and especially to http://www/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_r/mrd_a.htm#1023041 |
Step 2 Use the parameter uid-len to define the number of characters in the UID (user ID) for the designated application. This also passes that information to the call application.
|
Note The default value for uid-len is 10. The parameter pin-len (Personal ID Number length) is also available, with a default value of 4. |
Step 3 Use the parameter warning-time to define the number of seconds that a user is told to remain before the user's allows calling time runs out for a designated application. The following example shows a warning time of 30 seconds.
Step 4 Determine the language of the audio file. Valid entries are en (English), sp (Spanish), ch (Mandarin), and aa (all).
|
Note The number following language is arbitrary. For example, to assign Spanish as a second language, you could enter language 2 sp. |
Step 5 Determine the location, language, and category of the audio files for the designated call application, and pass that information to the application.
Interactive Voice Response (IVR) consists of simple voice prompting and digit collection to gather caller information for authenticating the user and identifying the destination. IVR applications can be assigned to specific ports or invoked based on DNIS. An IP PSTN gateway can have several different IVR applications to accommodate many different gateway services, and you can customize the IVR applications to present different interfaces to the different callers.
IVR uses Tool Control Language (TCL) scripts to gather information and to process accounting and billing. (When used together in Cisco applications, Cisco refers to the combination as Cisco TCL IVR.) For example, a Cisco TCL IVR script plays when a caller receives a voice-prompt instruction to enter a specific type of information, such as a PIN. After playing the voice prompt, the IVR application collects the predetermined number of touch tones (digit collection) and forwards the collected digits to a server for storage and retrieval. Call records can be kept and a variety of accounting functions performed.
Cisco provides a variety of scripts, among them the following:
|
Note To see all available scripts on a GW, enter the command show call application voice summary. |
The caller can interrupt the message by entering digits for the account number, which triggers the prompt to tell the caller to enter the PIN. If authentication fails the third time, the script plays the audio file auth_fail_final.au, and hangs up.
For more information about IVR, refer to the following documents at their respective URLS:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_c/mcprt1/mcd2voip.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/sw_conf/ios_121/0061ivr.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2.htm
http://www.cisco.com/warp/public/788/voip/voip_gw_ivr2.htm
TCL is an open-standard interpreted scripting language. (Version 8 is the most recent release.) Because TCL is an interpreted language, scripts written in TCL do not have to be compiled before they are executed. TCL provides a fundamental command set, which allows for standard functions such as flow control (if, then, else) and variable management. By design, this command set can be expanded by adding extensions to the language to perform specific operations.
Cisco has created a set of extensions, called TCL IVR commands, that allows users to create IVR scripts using TCL. Unlike other TCL scripts, which are invoked from a shell, TCL IVR scripts are invoked when a VoIP call comes into the gateway.
For more information about TCL and how to use the API to write new scripts, refer to the following document:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2.htm
It is one thing to consider provisioning and maintenance in the abstract, and quite another to implement provisioning and maintenance throughout a large network. Success and cost-effectiveness in large networks requires management, performance monitoring, and maintenance applications, of which a variety are discussed below. The following are discussed in this section:
CiscoWorks2000 Voice Manager (CVM) version 2.0.2 (see CiscoWorks2000 Voice Manager) is an element management system that provides the following features:
For information about CiscoWorks2000, see About CiscoWorks2000, below. To install CiscoWorks2000 Voice Manager, see Installing CiscoWorks2000 Voice Manager.
CiscoWorks2000 is a family of products that provide solutions targeted at WAN and LAN operations of enterprise networks. CVM and Cisco Info Center (CIC) (see Cisco Info Center) are members of this family. For details see CiscoWorks2000 at the following URL:
http://www.cisco.com/warp/public/44/jump/ciscoworks.shtml
A critical part of a service provider's operations support system (OSS) is performance and statistical reporting. (Other critical OSS components include billing, provisioning, fault management, and real-time monitoring.) Performance reporting facilitates the following important functions:
The following applications are discussed in this section:
CiscoWorks2000 Voice Manager (CVM) Release 2.0.2 is the application of choice for supporting performance and statistical reporting for the Cisco Wholesale Voice Solution. CVM is a client/server, web-based solution to managing the VoIP functionality of the Cisco 3600 series routers used in the solution. CVM allows you to do the following:
With respect to network performance, CVM provides the following reporting features:
CVM is not a device configuration tool. Devices supported by CVM must first be configured through the command-line interface (CLI) and have Simple Network Management Protocol (SNMP) enabled before they can be managed by CVM. (See Enabling SNMP.) You can then use CVM to modify the configuration of voice ports and create and manage local and network dial plans.
For additional information about SNMP, refer to the following:
http://www.cisco.com/cpress/cc/td/cpress/fund/ith2nd/it2452.htm
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm
CVM's support for SNMP includes trap viewing and forwarding. CVM 2.0.2 can receive and collect traps from GWs through SNMP. Traps can be forwarded to Cisco Info Center (CIC) for event correlation.
|
Note CVM is a stand-alone product that is not appropriate to the scaling needs of large-scale service providers. Although CVM can be used on a POP basis for small to medium service providers, it is not suitable for wholesale providers. It is used primarily with a polling application. In order to provide an effective distributed reporting solution, CVM requires integration with a third-party partner. |
See Installing CiscoWorks2000 Voice Manager.
Cisco Info Center (CIC) is another member of the CiscoWorks2000 family. CIC provides the following features with respect to fault management and event correlation:
The most current version is Release 2.0. For additional information, see Cisco Info Center 2.0 Release at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/info_ctr/2_0_0/index.htm
See Installing Cisco Info Center.
Cisco Internet Performance Manager (IPM) is a performance management application that can monitor the performance of a service provider's network. Cisco IPM provides the following features related to network performance:
The most current version of Cisco IPM is Release 2.3. Release notes, an installation guide, a user guide, and FAQs are available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ipmcw2k/cipm23/index.htm
Overviews, data sheets, product bulletins, and an IP tutorial are available at the following URL:
http://www.cisco.com/warp/public/cc/pd/wr2k/nemo/prodlit/index.shtml
For information about SAA, refer to Network Monitoring Using Cisco Service Assurance Agent, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/fun_c/fcprt3/fcd301d.htm
To install the latest version, see Installing Cisco Internet Performance Manager.
Cisco and Ecosystem Partner Trinagy, Inc. (http://www.trinagy.com) have collaborated to develop a new performance reporting tool for H.323-based VoIP networks. The product, called Voice Over IP ReportPack v. 1.1, provides seven reports that focus on GW devices and groups of GW devices. The groups are typically named Gateway, Gateway Group, Customer, and Region, but the user can customize the names and grouping structure. Each of the seven reports can be applied to the four groupings of data, for a total of 28 reports. The seven reports types are as follows:
Each report contains a selection table with the names of network devices or groups of network devices, with columns of data displayed in table format. Tabular data can also be displayed graphically, with more detail about a selected GW.
See Installing Trinagy Voice Over IP ReportPack 1.1.
CiscoWorks2000 Voice Manager 2.0.2, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/voicemgr/cvm2x/cvm202/index.htm
|
Note The following steps refer to documents at the above URL. The information provided there is applicable to version 2.0.2. However, in the discussion that follows, the application is referred to generically as CVM 2.0. |
Step 2 Refer to the following online document at the CiscoWorks2000 Voice Manager 2.0 website:
CiscoWorks2000 Voice Manager 2.0 Installation and User Guide.
Step 3 Refer to the following chapter in the above document:
"Overview of CiscoWorks2000 Voice Manager 2.0"
Step 4 Refer to the section "Planning for CVM," and understand the subsection Prerequisites. Before you can use CVM to manage your voice network, you will need to do the following for all of the devices you want to manage:
a. Have network access to the devices.
b. Enable Telnet on all the devices.
c. Enable SNMP on all the devices.
d. Ensure that GKs to be added to CVM are running the appropriate Cisco IOS release.
e. Know the IP address of the devices.
Step 5 Proceed to the following section, Determining Requirements.
Step 2 Refer to the following chapter in the above document:
"Installing CiscoWorks2000 Voice Manager 2.0"
Step 3 Determine your platform. CVM supports two platforms: Windows NT and Solaris.
Step 4 Refer to the section "System Requirements" in the document you selected in Step 2. Note the requirements for your platform and make sure you meet those requirements.
|
Caution Service Pack 5 is required for Windows NT installations. |
|
Note Unless otherwise noted, requirements are minimum requirements, but may be entirely satisfactory. |
Step 5 Proceed to the following section, Installing CVM.
Step 2 Refer to the following chapter in the above document:
"Installing CiscoWorks2000 Voice Manager 2.0"
Step 3 Follow the instructions in the above chapter to install the necessary software from your CVM installation CD.
Step 4 For background, read the remainder of the chapter you selected in Step 2.
Step 5 Proceed to the following section, Starting CVM.
Step 2 Refer to the following chapter in the above document:
"Getting Started with CiscoWorks2000 Voice Manager 2.0"
Step 3 Refer to the section "Starting CVM" in the above chapter, and follow the instructions there.
Step 4 You will now need to configure CVM to poll. Proceed to the following section, Configuring CVM to Poll.
Step 2 Refer to the following chapter in the above document:
"Getting Started with CiscoWorks2000 Voice Manager 2.0"
Step 3 Refer to the section User Interface in the above chapter, and learn about Views and Device Trees.
|
Note You will need to select VoIP View to see VoIP-enabled devices that have been added to CVM. You will not need to create a group, because groups are required only for VoIP networks whose routers are not managed by a gatekeeper |
Step 4 Select VoIP View.
Step 5 Use drag-and-drop to add the GWs and GKs in your configuration to the selected view.
Adding GWs is similar to adding routers. You will first need to enable Telnet and SNMP, and configure the session timeout to a nonzero value for all vty lines.
Step 2 Refer to the following chapter in the above document:
"Using CiscoWorks2000 Voice Manager 2.0 to Manage Devices"
Step 3 Refer to the section "Routers" in the above chapter, and follow the commands listed there to do the following:
|
Note CVM searches the GWs and automatically detects the type of voice interfaces enabled on them, placing the devices in the appropriate view. The GWs will appear in the All Router view as well. |
Step 2 Refer to the following chapter in the above document:
"Using CiscoWorks2000 Voice Manager 2.0 to Manage Devices"
Step 3 Refer to the section "Routers" in the above chapter, and follow the commands listed there to do the following:
a. Select the GK to which you wish to add the GW.
b. Enter the following values for the GW: IP address, (SNMP) community string read, community string write.
c. Enter the following values for the terminal server on which CVM resides: IP address, port, login username.
d. Enter the following passwords for the GW: login, enable, secret.
Step 4 To accomplish the above, follow Steps 1 through 5 under the section "Adding a Router."
Step 5 Continue with Steps 6 through 10 in the above section, to finish adding the device to the Device Tree Hierarchy.
Step 6 For each device that you want to add, repeat Steps 1 through 10 under the section "Adding a Router."
You can use CVM to manage dial plans, as shown in the following steps.
Step 2 Refer to the following chapter in the above document:
"Using CiscoWorks2000 Voice Manager 2.0 to Manage Dial Plans"
Step 3 Become familiar with the information in the above chapter. You can create and modify both local (POTS) and network (VoIP) dial plans.
This discussion concerns the latest release of Cisco Info Center, Release 3.0.1. Information about all CIC releases is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/info_ctr/
For requirements and installation, refer to Release Notes for Cisco Info Center 3.0.1, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/info_ctr/3_0_1/notes301.htm
Refer to "Supported Hardware and Software" in the above document.
Refer to "CIC 3.0.1 Installation Instructions" in the above document.
The latest version is Release 2.3. (See Cisco Internet Performance Manager.) The following discussion relates to Internetwork Performance Monitor, Release 2.3, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ipmcw2k/cipm23/ipm23ig/index.htm
Read "Preparing to Install IPM, "at the above website. Instructions are also provided for upgrading from previous releases of Cisco IPM.
Cisco IPM runs on Solaris and Windows platforms. Depending on your platform, see either "Installing IPM on Solaris" or "Installing the IPM Client on Window"s at the above website.
The application runs on a UNIX workstation and requires two other Trinagy applications: Trinagy TREND 3.6.1 or later, and Trinagy TRENDweb 3.2. In addition, Perl 5.6 or later must be installed before Voice Over IP ReportPack v. 1.1 is installed. Perl creates the necessary directory structure, and can be downloaded from http://www.perl.com.
|
Note Contact your Trinagy representative or Cisco account representative for the most current hardware and software requirements. |
The acquisition and installation of this reporting tool are beyond the scope of this document. Trinagy provides their own documentation to install and use TREND and the ReportPack application. For further information, please contact your Trinagy representative or Cisco account representative.
Posted: Tue Jan 21 06:42:46 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
