Prepaid Services
Available Languages
Table Of Contents
Internally Managed Prepaid Services Theory
Debit Card Application Overview
Debit Card Application Functional Call Flow
Internally Managed Prepaid Services Architecture
Hardware and Software Requirements
Internally Managed Prepaid Services Application
Internally Managed Prepaid Services Configuration Guidelines
Loading TCL IVR Scripts and Storing Sound Files
Configuring Call Application Parameters
Configuring RADIUS and VSA Parameters
Internally Managed Prepaid Services Call Example
Originating Gateway Debug Output
Terminating Gateway Debug Output
OSP for Clearinghouse Services Theory
OSP Clearinghouse Operation and Call Flow
OSP Hardware and Software Requirements
Memory and Software Requirements
OSP for Clearinghouse Services Application
Defining Gateway Identity Parameters
Configuring Settlement Parameters
Configuring Incoming and Outgoing Dial Peers
Common Problems with Settlement Configuration
Configuring OSP on the Originating Gateway
Configuring OSP on the Terminating Gateway
Prepaid Services
1
10/1/2001
This document was created.
2
4/12/2002
Note added to Step 5 of "OSP Clearinghouse Operation and Call Flow."
Prepaid services enable Internet telephony service providers (ITSPs) to offer calling card services that customers can pay for in advance. Prepaid services can be managed in two ways:
•
Through an internally managed network infrastructure
•
In an ITSP internal network infrastructure, prepaid services are implemented through a debit card application that works in conjunction with the following:
•
•
•
•
This combination of services enable you (as a carrier) to authorize voice calls and debit individual user accounts in real time at the edges of a Voice over IP (VoIP) network without requiring external service nodes. If you rely on an OSP clearinghouse to manage prepaid services, you configure your voice gateway to register with an OSP server. (OSP is designed to offer billing and accounting record consolidation for voice calls that traverse ITSP boundaries.) Third-party clearinghouses with an OSP server can offer services such as route selection, call authorization, call accounting, and intercarrier settlements, including all the complex rating and routing tables necessary for efficient and cost-effective interconnections.
In this document, we discuss how to design and implement a prepaid services solution that is managed either through your internal network infrastructure or through an OSP clearinghouse. This document contains the following sections:
•
•
•
•
Prepaid Services Overview
Prepaid services can be managed either internally within the infrastructure of your own network, or through the services of an OSP clearinghouse. Depending on the needs of your particular network, you can use one or both of these solutions to provide and manage prepaid services.
The key to providing internally managed prepaid services is the Cisco Systems debit card application, which coordinates the functionality of four separate applications: IVR, AAA, RADIUS, and a third-party billing system. IVR provides the customer interface; AAA and RADIUS form the infrastructure to provide authentication and billing; and IVR, AAA, and RADIUS communicate with the third-party billing system through vendor-specific attributes (VSAs).
OSP is used for inter carrier interconnect authorization and accounting, enabling carriers to admit and bill for each VoIP call accepted from another service provider. This capability is critical to toll-bypass applications, specifically international wholesale voice, because the terminating carrier must deliver the call to the Public Switched Telephone Network (PSTN), incurring a fee that must be funded out of the settlement payment from the originating carrier. Because of OSP, you can employ reliable third-party clearinghouses to handle VoIP call termination while leveraging the bandwidth efficiencies and tariff arbitrage advantages that are inherent in IP.
Internally Managed Prepaid Services Theory
The following sections describe the theory of internally managed prepaid services:
•
•
•
Debit Card Application Overview
The key to managing prepaid services internally within your own network is the Cisco debit card application. The debit card application integrates the functionality of IVR, AAA, RADIUS, and a third-party billing system. The IVR software infrastructure uses Tool Command Language (TCL) IVR scripts, dynamically combining prerecorded audio files to play the time, date, and dollar amount of remaining credit. AAA security services, in combination with a RADIUS server, provide the infrastructure for both authentication and accounting. The integrated third-party billing system maintains per-user credit balance information. RADIUS VSAs are used with AAA to communicate with the third-party billing system.
With Cisco IOS Release 12.1 and later releases, the debit card application offers the following functionality to support internally managed prepaid services:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
IVR and TCL IVR Scripts
The debit card application uses IVR as the mechanism at the voice gateway to present a customized interface to prepaid services customers. The IVR application provides simple voice prompting and digit collection to gather caller information for authenticating users and identifying destination telephone numbers.
IVR uses TCL scripts and audio files to provide voice prompting and digit collection. TCL scripts contain both executable files and audio files that interact with the system software. When a TCL IVR script is activated by an incoming call, the C code is activated in run-time mode and performs the work of these executables. Examples of the executables used by TCL IVR scripts include:
•
•
•
As of Cisco IOS Release 12.1 and later releases, TCL IVR scripts and audio files are stored on an external TFTP server for dynamic access by the voice gateways. The scripts are loaded into RAM and remain resident as long as the gateway remains active.
New TCL IVR scripts are being developed on a continuous basis. Table 1 lists the TCL IVR scripts that are included in Cisco IOS Release 12.2. Table 2 lists some of the TCL IVR scripts that can be loaded externally.
Cisco provides a set of professionally recorded audio prompts (IVR audio files) in a number of different languages. New audio prompts are being developed on a continuous basis. Table 3 and Table 4 list some of the IVR audio files available as of Cisco IOS Release 12.1.
You can find TCLWare (TCL scripts) and audio files at the following URL:
http://www.cisco.com/cgi-bin/tablebuild.pl/tclware
AAA and RADIUS
The debit card application uses AAA security services as the infrastructure with which to provide authentication and accounting services. AAA is an architectural framework for configuring a set of three independent security functions: authentication, authorization, and accounting. Authentication is the way a user is identified prior to being allowed access to services. Authorization provides a method for remote access control. Accounting provides a method for collecting and sending security server information used for billing, auditing, and reporting data such as user identities and start and stop times.
Typically, AAA works in tandem with a RADIUS server. (TACACS does not support prepaid services.) RADIUS uses Internet Engineering Task Force (IETF) standard, vendor-specific, and vendor-proprietary attributes to define specific AAA elements in a user profile that are stored on the RADIUS database. RADIUS and AAA authenticate, authorize, and perform accounting functions by associating attribute/value (AV) pairs with the appropriate user. For internally managed prepaid services, AAA works in tandem with IVR to enable voice gateways to interact with a RADIUS security server to authenticate users (typically incoming calls) and to perform accounting services.
Authentication
The gateway normally uses AAA in conjunction with IVR to check the legitimacy of a prospective gateway user based on an account number collected by IVR, or based on ANI. When the gateway uses AAA with IVR, the IVR application collects the user account and PIN information and then passes it to the AAA interface. The AAA interface makes a RADIUS authentication request with the given information, and, based on the information received from the RADIUS server, forwards either a pass or fail message to the IVR application.
Accounting
The RADIUS server collects basic start-stop connection accounting data during the accounting process for each call leg created on the gateway. The RADIUS server can be configured to collect accounting data using one of two methods:
•
•
Note
The various call leg start and stop records generated by the gateway can be organized by their Connection ID, which is the same for all call legs of a connection. The Connection ID is a 128-bit field displayed in hexadecimal format that can vary in appearance. In the examples cited in this document, 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 billing application uses the Connection ID to generate all the information needed for accurate and timely billing.
Start records by definition cannot contain the time connection details required for billing by time; these details are contained in the stop records. (All RADIUS billing information pertaining to the call is contained in the stop records.) However, some deployments choose to use start/stop records so that they will know when a call was terminated abnormally and thus has no stop record. Start records, in conjunction with update records, provide a more accurate and deterministic real-time measurement technique for identifying when a call started than do stop-only records. Start-stop records are also useful when packets get lost. Stop-only accounting records are configured if RADIUS network traffic or storage needs are an issue. Update records can be obtained from Cisco routers by using the aaa accounting update global configuration command.
Call Detail Records
For debit-card networks, the voice gateways can send accounting data in the form of call detail records (CDRs) to the RADIUS server in one of two ways:
•
•
If the gateway sends a CDR and does not receive a response from the RADIUS server within a certain period of time, it will produce duplicate CDRs and deliver them to the RADIUS server. For example, the gateway will send duplicate CDRs if it does not receive a timely response from the RADIUS server acknowledging receipt of the original record. The only difference in these duplicate CDRs is in the attribute/value (AV) pair Acct-Delay-Time (attribute 41). The first value for Acct-Delay-Time is 0; when duplicate records are created, the Acct-Delay-Time value is incremented in each subsequent record. All other fields in the duplicate CDRs remain the same. The particular billing application is responsible for discarding these duplicate records.
VSAs
VSAs are defined as Attribute 26 of the IETF standard group of AV pairs. For the RADIUS server to receive accounting information from the gateway using Attribute 26, the gateway must be configured to recognize RADIUS VSAs. After you configure the gateway to recognize VSAs, the RADIUS server will no longer overload the Acct-Session-ID attribute. Instead, the information elements in the overloaded Acct-Session-ID attribute will be captured in separate VSAs.
The following example shows the value string for a typical VSA:
Attribute 26 23 0000000967146833The string elements are described as follows:
•
•
•
–
–
•
Table 5 lists the VSAs used by Cisco voice products and describes their formats and purposes.
Table 6 lists the RADIUS codes that identify the kind of packet RADIUS is sending. Table 7 lists RADIUS return codes, which you can define by using TCL IVR scripts as long as the RADIUS server is configured to understand which response or return message is required.
Debit Card Application Functional Call Flow
The following list describes a high-level call flow sequence for a debit card application. The actual call flow varies, depending on the parameters passed to the application and also on the features that are available on the RADIUS billing system that is being used. Figure 1 through Figure 5 provide a detailed flow diagram of this process.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Figure 1 Debit Card Application Call Flow (Part 1)
Figure 2 Debit Card Application Call Flow (Part 2)
Figure 3 Debit Card Application Call Flow (Part 3)
Figure 4 Debit Card Application Call Flow (Part 4)
Figure 5 Debit Card Application Call Flow (Part 5)
Internally Managed Prepaid Services Architecture
The architecture for a network designed to manage prepaid services from within its own infrastructure can vary depending on the relative locations of the voice gateways. Figure 6 illustrates an architectural model in which the FTP/TFTP severs are local to the gateways and the RADIUS server is centralized. Both FTP/TFTP and RADIUS servers can be centralized or geographically dispersed, depending on the nature of the packet telephony network involved.
Figure 6 Internally Managed Prepaid Services Network Topology
The billing and accounting components of prepaid services consist of VoIP gateways, TCL IVR scripts, audio files, a TFTP server, and an integrated, third-party, RADIUS-based billing system.
Hardware and Software Requirements
The following sections describe the hardware and software requirements to support internally managed prepaid services:
•
Network Devices
Given the network topology shown in Figure 6, you need the following devices to support internally managed prepaid services:
•
•
•
•
System Platform Requirements
The IVR and debit card applications are supported on the following Cisco platforms:
•
•
•
Cisco IOS Software and VCWare Requirements
To support prepaid services, the Cisco devices in your network must have the following versions of Cisco IOS software and VCWare installed:
•
•
Note
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/iosrn/vcwrn/vcwrmtrx.htm
Memory
To support prepaid services, the Cisco devices in your network must have the following minimum memory installed:
•
•
Internally Managed Prepaid Services Application
The following sections describe the application of prepaid services:
•
•
Internally Managed Prepaid Services Configuration Guidelines
This section gives general configuration guidelines. To configure a typical voice gateway to support internally managed prepaid services, perform the following tasks:
•
•
•
Loading TCL IVR Scripts and Storing Sound Files
You can use a Cisco.com password, to download the most recent TCL IVR scripts and audio files from the following URL:
http://www.cisco.com/cgi-bin/tablebuild.pl/tclware
After you have downloaded the scripts and audio files, you need to load them onto the TFTP server so that they will be available for the voice gateway. When you unzip the TCLWare bundle into the /tftpboot directory of the TFTP server, the various TCL and audio files will be positioned in the recommended subdirectory hierarchy. Table 8 gives the recommended directory structure.
After you have downloaded the TCL IVR scripts and audio files into the appropriate subdirectories on the TFTP server, you are ready to configure your voice gateway to support prepaid services.
The following example shows how the TCL script is loaded into DRAM on the voice gateway.
pmeas1(config)# call application voice debit tftp://mojo/tcl/debitcard.tclLoading tcl/debitcard.tcl from 10.19.21.101 (via Ethernet0): !!!![OK—16098/31744 bytes]This command instructs the gateway to load the TCL call application script debitcard.tcl from the /tftpboot/tcl subdirectory on the machine mojo and refer to it with the tag debit. The debit card application will then be available for association with an incoming dial peer and its corresponding destination number. When a user calls the number configured on that dial peer in the originating gateway, the debit card application is activated. After the application is loaded, it is available in the gateway and remains available until you enter the no form of the command or reboot the gateway. If this gateway is rebooted, the debitcard.tcl script will be loaded automatically.
You must receive successful feedback when loading the TCL script. If the application fails to load properly, it will not function and the entire debit card procedure will fail. Failure to load the debit card script is indicated by output such as the following:
pmeas1(config)# call application voice debit tftp://mojo/tcl/debitcard.tcl%Error opening tftp://mojo/tcl/debitcard.tcl (Timed out)Sep 30 09:41:00.565 UTC: %IVR-3-NOSCRIPT: Could not open IVR scripttftp://mojo/tcl/debitcard.tclerrno=66568=If you receive an error message similar to the one shown while trying to load the application, you must remedy that situation before you continue. The following example shows how to fix a failed call application load.
pmeas1(config)# show running-config...clock timezone PST -7ip subnet-zerono ip domain-lookupip domain-name cisco.comip name-server 192.168.8.69ip name-server 192.168.0.21!cns event-service servercall application voice debit tftp://mojo/tcl/derbitcard.tcl...pmeas01(config)#pmeas01(config)# call app voice debit tftp://mojo/tcl/debitcard.tcl^% Invalid input detected at '^' marker.pmeas01(config)#pmeas01(config)# no call application voice debitDeleting TCL IVR App: debit with urltftp://mojo/tcl/debitcard.tclpmeas01(config)#pmeas01(config)# call app voice debit tftp://mojo/tcl/debitcard.tclLoading tcl/debitcard.tcl from 10.19.21.101 (via FastEthernet0): !!!![OK—16098/31744 bytes]To fix a failed call application load, you must first remove the failed script. In this example, the script that failed to load properly is still displayed in the show running-config output. If you try to reload the application script with the same keyword (debit) before removing the failed script, you will be unsuccessful. In this example, the first attempt to reload the script is unsuccessful because the failed script was not removed. The output indicates that the keyword debit is still in use.
Scripts can fail to load for various reasons, but the most common reason is that there is a problem reaching the application file. Make sure you can manually reach the directory path (by using Telnet from the voice gateway) in which the application is located.
Configuring Call Application Parameters
At this point, if your prepaid services network was fully configured, a call to 555-1200 would return the built-in IVR response, "No prompts available." The TCL call application script begins the IVR process, but because no configuration parameters detail the location of the audio files, it defaults to the embedded audio file noPromptPrompt, as illustrated in the following output from the debug voip ivr all command:
4w1d: $ $ta_PromptCmd() url=Tcl_GetVar2() [flash:enter_account.au]4w1d: $ $ta_PromptCmd() Get prompt url=[flash:enter_account.au] name=[enter_account.au]4w1d: $ $ta_PromptCmd() >>mc_createFromFileUrl4w1d: $ $mc_createFromFileUrl (url:[flash:enter_account.au], name:[enter_account.au])::4w1d: mc_load can not open flash:enter_account.au. errno=2=No such file or directory4w1d: mc_load can not open flash:enter_account.au. errno=2=No such file or directory4w1d: $ $mc_createFromFileUrl(name[enter_account.au]) load failed.4w1d: $ $mc_createFromFileUrl(url[flash:enter_account.au]) load failed.4w1d: $ $mc_delete()::4w1d: $ $ta_PromptCmd() pArgs->content = 61D15750 noPromptPrompt;4w1d: $ $ta_PromptCmd() >> ccGetApp(pcapp)The call application parameters are contained in the configuration commands that govern the authentication parameters and location of the audio files. The following configuration example configures the UID and PIN lengths of the account number, and the location of the sets of language sound files used in the IVR scripts. This configuration is only necessary on originating gateways.
pmeas01(config)# call application voice debit uid-len 10pmeas01(config)# call application voice debit pin-len 4pmeas01(config)# call application voice debit language 1 enPlease make sure to use the corresponding set-location commandpmeas01(config)# call application voice debit set-location en 0 tftp://mojo/au/en/pmeas01(config)# call application voice debit language 2 chPlease make sure to use the corresponding set-location commandpmeas01(config)# call application voice debit set-location ch 0 tftp://mojo/au/ch/The first two commands configure the length of the UID and the PIN. The lengths for the PIN and UID appear in the configuration output only if they are different from the default values.
The last four commands label and store the audio files. The language 1 en and set-location en lines go together in a pair as do the language 2 ch and set-location ch lines, as mentioned in the feedback from the session output.
In this example, language 1 en references the choice of language (in this case, English) and set-location en defines the machine or path where the files can be found. The number tag corresponds to the number that the IVR prompt will request ("Please press 1 for English").
When a call is placed to the gateway, IVR looks in the audio file directory that was configured for the beginning IVR messages (en_welcome.au, en_lang_sel1.au and ch_lang_sel2.au). These three messages play the welcome message in English and the "select language" message in English and then Mandarin. Because these files must play to initiate the IVR process, they must be located in both language directories. In this case, because the set-location command for the Mandarin audio files was entered last (the call application voice debit set-location ch 0 tftp://mojo/au/ch/ command), the TCL application looks in the Chinese audio file subdirectory for the welcome message and the select language option messages. Placing a call to the gateway with the debug voip ivr all command enabled produces the following output and confirms the expected behavior. Important items are bolded for emphasis.
4d11h: App debit: Handling callID 584d11h: callingNumber=408, calledNumber=5710961, redirectNumber=4d11h: accountNumber=, finalDestFlag=0,guid=86db.7ca8.8c6c.0096.0000.0000.1729.90ac4d11h: peer_tag=14d11h: settlement_validate_token: cid(58), target=, tokenp=0x04d11h: :/acceptCall/4d11h: Accepting CallID=584d11h: :/getVariable/4d11h: :/setVariable/!language type set to 14d11h: ta_SetVariableCmd.4d11h: :/getVariable/4d11h: :/setVariable/!language type set to 24d11h: ta_SetVariableCmd.4d11h: :/getVariable/4d11h: :/setVariable/!long pound enabled4d11h: ta_SetVariableCmd.4d11h: :[callID]4d11h: :/puts/4d11h: cid( 58) app running state select_language4d11h: ta_PlayPromptCmd() 4d11h4d11h: ta_PlayPromptCmd. CallID=584d11h: $ $pc_mc_makeDynamicS() calloc mcDynamicS_t4d11h: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/en_welcome.au], name:[en_welcome.au])::4d11h: $ $mc_getFromUrlName() en_welcome.au on ram mc_waitq_delete: mc=619219A4mc_waitq_unlink: elm=61D88ECCmc_waitq_unlink: prompt_free=2D2F4 prompt_active=0mc_waitq_delete: prompt_free=2D2F4 prompt_active=65844d11h: $ $du_get_vpPromptName() OK###4d11h: $ $du_mcDynamicS_silence() ms_int 1000 postSilence 10004d11h: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/en_lang_sel1.au], name:[en_lang_sel1.au])::4d11h: $ $mc_getFromUrlName() en_lang_sel1.au on ram mc_waitq_delete: mc=61D8EFA 8mc_waitq_unlink: elm=61DA3090mc_waitq_unlink: prompt_free=291A8 prompt_active=6584mc_waitq_delete: prompt_free=291A8 prompt_active=A6D04d11h: $ $du_get_vpPromptName() OK###4d11h: $ $du_mcDynamicS_silence() ms_int 1000 postSilence 10004d11h: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/ch_lang_sel2.au],name: [ch_lang_sel2.au])::4d11h: $ $mc_getFromUrlName() ch_lang_sel2.au on ram mc_waitq_delete: mc=61D8F070mc_waitq_unlink: elm=61CD1EA0mc_waitq_unlink: prompt_free=2537C prompt_active=A6D0mc_waitq_delete: prompt_free=2537C prompt_active=E4FCThe debug output indicates that the IVR application is looking in the Chinese language subdirectory of the TFTP server for the English language audio files. This scenario is the proper behavior and the output is derived from a successful call.
After the IVR variables are correctly configured, the next step is to associate the debit card application with an incoming POTS dial peer.
Configuring Dial Peers
The debit card TCL application is initiated dynamically by reference to a POTS dial peer in the originating voice gateway. By matching a certain dialed number to a POTS dial peer, the debit card application begins a TCL application referenced in the dial peer. The following example shows a POTS dial peer configured for the originating gateway:
dial-peer voice 555 potsdestination-pattern 5551200application debitport 0:DIn this example, if a user called the number 555-1200, it would match the configured POTS dial peer and activate the TCL application with the keyword debit, provided that the application exists and is reachable according to the application access commands configured in the gateway. The keyword debit is a tag given to the actual TCL script (debitcard.tcl) stored on the TFTP server.
You can display all the TCL scripts available in a gateway with the following show command:
pmeas11# show call application voice summaryname descriptionsession Basic app to do DID, or supply dialtone.fax_hop_on Script to talk to a fax redialerclid_authen Authenticate with (ani, dnis)clid_authen_collect Authenticate with (ani, dnis), collect if that failsclid_authen_npw Authenticate with (ani, NULL)clid_authen_col_npw Authenticate with (ani, NULL), collect if that failsclid_col_npw_3 Authenticate with (ani, NULL), and 3 tries collectingclid_col_npw_npw Authenticate with (ani, NULL) and 3 tries without pwSESSION Default system session applicationdebit tftp://mojo/tcl/debitcard.tclTo display an application in its entirety, use the appropriate name of the application instead of the summary keyword. For example, the show call application voice debit privileged EXEC command would display the debitcard.tcl script.
The following example shows a VoIP dial peer configured for the terminating gateway:
dial-peer voice 514 voipdestination-pattern 1514.......session target ipv4:10.10.12.23dial-peer voice 213 voipdestination-pattern 1213.......session target ipv4:10.20.120.14VoIP dial peers associate a number dialed to a network destination—in this case an IP address. The terminating gateway VoIP dial peer need not be associated with an application.
Configuring AAA
In order for the debit card application to work with the RADIUS server to collect the appropriate connection accounting information, you must at least configure the aaa new-model global configuration command on your voice gateways. The following example configures AAA to use RADIUS on the gateways. The same configuration is used on both the originating and terminating gateways.
aaa new-modelaaa authentication login h323 group radiusaaa authentication login NONE noneaaa authorization exec h323 group radiusaaa accounting connection h323 start-stop group radiusline con 0login authentication NONEgw-accounting h323 vsaIn this example, AAA is enabled and a named list called h323 defines that RADIUS should be used to provide authentication, authorization, and accounting. The named list NONE enables network administrators to log in to the console port and bypass authentication. CDRs will be delivered to the RADIUS server using the VSA method.
Configuring RADIUS and VSA Parameters
In the following example, both the originating and terminating gateways are configured to support RADIUS. The same configuration is used on both gateways. (Note that you must enable AAA before you can configure any RADIUS parameters.)
radius-server host 172.22.42.49 auth-port 1645 acct-port 1646radius-server key testing123radius-server vsa send accountingradius-server vsa send authenticationIn this example, the first command configures the IP address of the RADIUS server and the ports on which the gateway expects the RADIUS server to be listening. The authentication and accounting ports are the default ports for Cisco gateways. The second command configures the password used for authenticating the RADIUS server. The last two commands enable the use of VSAs for H.323 authentication and accounting.
Configuring NTP
You must configure NTP in order to pass time stamps that are synchronized between the gateways and servers. To instruct the gateway to synchronize its time-of-day clock with an NTP server, use the ntp server ip-address global configuration command. For test purposes, to enable one of the gateways to act as the authoritative NTP server, issue the ntp master global configuration command. Then other gateways can synchronize with the master by pointing to the master in their configurations with the ntp server ip-address global configuration command.
The clocks on Cisco routers, however, are typically stratum-8 clocks as opposed to stratum-1 and stratum-2 NTP servers. Stratum 8 clocks are not considered accurate enough to keep time for a production network.
Internally Managed Prepaid Services Call Example
This section contains sample debug output from a successful internally managed prepaid services call. In this example, a pair of gateways are used to make a debit card call with a MindCTI RADIUS back-end billing system performing the AAA. This example shows the behavior and characteristics of the debit card application. Basic voice connectivity has been established, so this example does not verify the call control system. However, we have set some billing debug commands so that you will be able to see how IVR and AAA operate. The two debug sessions described in the following sections are the output received for a successful call, then long pound, then another successful call:
•
•
Originating Gateway Debug Output
The following debug commands were activated on the originating gateway:
debug voip ivr alldebug radiusdebug aaa authenticationdebug aaa authorizationdebug aaa accountingIn the following output, a call was placed through a PBX. The number that the PBX sends out is configurable—the PBX in this example was configured to send the area code for San Jose (408).
Note
pmeas11#1w6d: AAA: parse name=<no string> idb type=-1 tty=-11w6d: AAA/MEMORY: create_user (0x61BEFB38) user='408' ruser='5550961' port='' rem_addr='408/5710961' authen_type=NONE service=H323_VSA priv=01w6d: AAA/ACCT/CONN: Found list "h323"These lines refer to the AAA accounting list in the gateway:
1w6d: AAA/ACCT/CONN/START User 408, Port , Location "unknown"1w6d: AAA/ACCT/CONN/START User 408, Port ,task_id=81 start_time=939938654 timezone=PST service=connection protocol=h3231w6d: AAA/ACCT: user 408, acct type 1 (397058159): Method=radius (radius)1w6d: RADIUS: ustruct sharecount=21w6d: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas11."1w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: added cisco VSA 26 len 23 "h323-call-origin=answer"1w6d: RADIUS: added cisco VSA 27 len 24 "h323-call-type=Telephony"1w6d: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:03:46.180 PST Thu Oct 14 1999"1w6d: App debit: Handling callID 1421w6d: callingNumber=408,In the following output, all the call setup variables are listed, both standard IETF RADIUS attributes and VSAs. The start record is for the answer telephony call leg (call leg 1). IVR is shown beginning next.
calledNumber=5710961, redirectNumber=1w6d: accountNumber=, finalDestFlag=0,guid=86db.7ca8.8c6c.016e.0000.0000.4665.55a01w6d: peer_tag=11w6d: RADIUS: Initial Transmit id 19 172.22.42.52:1646, Accounting-Request, len2781w6d: Attribute 4 6 AC1627581w6d: Attribute 61 6 000000001w6d: Attribute 1 5 3430381E1w6d: Attribute 30 9 353731301w6d: Attribute 31 5 343038281w6d: Attribute 40 6 00000001 //start record1w6d: Attribute 6 6 000000011w6d: Attribute 26 31 0000000921196833 //h323-gw-id1w6d: Attribute 26 49 00000009182B6833 //h323-conf-id1w6d: Attribute 26 31 000000091A196833 //answer1w6d: Attribute 26 32 000000091B1A6833 //telephony1w6d: Attribute 26 56 0000000919326833 //setup time1w6d: Attribute 44 10 303030301w6d: Attribute 41 6 00000000In this output, English is set as language number 1 and Chinese is set as language number 2:
1w6d: settlement_validate_token: cid(142), target=, tokenp=0x01w6d: :/acceptCall/1w6d: Accepting CallID=1421w6d: :/getVariable/1w6d: :/setVariable/1w6d: ta_SetVariableCmd. language type set to 11w6d: :/getVariable/1w6d: :/setVariable/1w6d: ta_SetVariableCmd. language type set to 2The long-pound feature is enabled, which means the user can press the pound symbol to make another call without needing to be reauthenticated:
1w6d: :/getVariable/1w6d: :/setVariable/1w6d: ta_SetVariableCmd. long pound enabledThe welcome message is loaded from the /tftpboot/au/ch subdirectory of the TFTP server and copied into RAM and played:
1w6d: :[callID]1w6d: :/puts/1w6d: cid( 142) app running state select_language1w6d: ta_PlayPromptCmd() 1w6d1w6d: ta_PlayPromptCmd. CallID=1421w6d: $ $pc_mc_makeDynamicS() calloc mcDynamicS_t1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/en_welcome.au], name:[en_welcome.au])::The prompt, "Select 1 for English," is loaded and played:
1w6d: $ $mc_getFromUrlName() en_welcome.au on ram mc_waitq_delete: mc=619219A4mc_waitq_unlink: elm=61CD27B0mc_waitq_unlink: prompt_free=A433B prompt_active=0mc_waitq_delete: prompt_free=A433B prompt_active=65841w6d: $ $du_get_vpPromptName() OK###1w6d: $ $du_mcDynamicS_silence() ms_int 1000 postSilence 10001w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/en_lang_sel1.au], name:[en_lang_sel1.au])::The Chinese prompt, "Select 2 for Chinese," is loaded and played:
1w6d: $ $mc_getFromUrlName() en_lang_sel1.au on ram mc_waitq_delete: mc=61D8EFA8mc_waitq_unlink: elm=61D82198mc_waitq_unlink: prompt_free=A01EF prompt_active=6584mc_waitq_delete: prompt_free=A01EF prompt_active=A6D01w6d: $ $du_get_vpPromptName() OK###1w6d: $ $du_mcDynamicS_silence() ms_int 1000 postSilence 10001w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/ch/ch_lang_sel2.au], name:[ch_lang_sel2.au])::After the language is chosen, IVR begins the authentication process by loading and playing the "Enter card number" prompt. Now that the IVR application knows that the chosen language is English, it goes to the /au/en subdirectory for the files:
1w6d: $ $mc_getFromUrlName() ch_lang_sel2.au on ram mc_waitq_delete: mc=61D8F070...1w6d: $ $pc_mc_makeDynamicS() calloc mcDynamicS_t1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_enter_card_num.au],name:[en_enter_card_num.au])::1w6d: $ $mc_getFromUrlName() en_enter_card_num.au on ram mc_waitq_delete: mc=61921618The script returns a success upon matching the card number against the database:
1w6d: pcapp CallID 142 returning PCAPP_MATCHED. string=00007012341w6d: $ $pcapp_finished() >>pcapp_return()1w6d: $ $pcapp_finished() >>ms_delete()The following RADIUS records concern the authentication phase of the call:
1w6d: cid(142) ta_get_event returning collect success1w6d: :[called]1w6d: :/puts/1w6d: cid( 142) app running state second_authorize1w6d: :/ani/1w6d: :[authorize]1w6d: authorization1w6d: account=000070 the account number is broken out into uid1w6d: password=1234 and pin numbers1w6d: destination= destination is blank because it has not yet been entered1w6d: password=12341w6d: AAA: parse name=<no string> idb type=-1 tty=-11w6d: AAA/MEMORY: create_user (0x61C27260) user='000070' ruser='' port='' rem_addr='408/5255233' authen_type=ASCII service=LOGIN priv=01w6d: unknown AAA/AUTHOR/EXEC (1758884971): Port='' list='h323' service=EXEC1w6d: AAA/AUTHOR/EXEC: unknown (1758884971) user='000070'1w6d: unknown AAA/AUTHOR/EXEC (1758884971): found list "h323"1w6d: unknown AAA/AUTHOR/EXEC (1758884971): Method=radius (radius)The call is assigned a conference ID. This number will be consistent through all call legs of this call. It is used to identify records concerning the same call.
1w6d: RADIUS: authenticating to get author data1w6d: RADIUS: ustruct sharecount=21w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: Initial Transmit id 21 172.22.42.52:1645, Access-Request, len 1211w6d: Attribute 4 6 AC1627581w6d: Attribute 61 6 000000001w6d: Attribute 1 8 303030301w6d: Attribute 26 49 00000009182B68331w6d: Attribute 30 9 353235351w6d: Attribute 31 5 343038021w6d: Attribute 2 18 7B8D23641w6d: RADIUS: Received from id 21 172.22.42.52:1646, Access-Accept, len 76The following RADIUS VSAs are received from the RADIUS server in response to the authentication request. The user credit amount is kept in the RADIUS database and is accessed in real time at the time of the call. The h323-credit-amount will be played to the caller via the TCL IVR scripts. The script will build the amount $32.91 from (thirty) and (two) and (dollars) and (ninety) and (one) and (cents). The credit amount shows up as a minus so that credit spent on a call will be added to the total until the credit amount reaches 0. Note that not all attributes returned are supported.
1w6d: Attribute 26 26 0000000967146833 h323-return-code1w6d: Attribute 26 30 000000096B186833 h323-preferred-lang1w6d: Attribute 26 33 00000009651B6833 h323-credit-amount1w6d: Attribute 26 23 000000096D116269 unsupported VSA1w6d: Attribute 26 25 000000096E136375 unsupported VSA1w6d: RADIUS: saved authorization data for user 61C4C2D0 at 61C4C3E41w6d: RADIUS: cisco AVPair ":h323-return-code=0"1w6d: RADIUS: cisco AVPair ":h323-preferred-lang=en"1w6d: RADIUS: cisco AVPair ":h323-credit-amount=-32.91"1w6d: RADIUS: unrecognized cisco VS option 1091w6d: RADIUS: Bad attribute (unsupported attribute): type 26 len 23 data 0x91w6d: RADIUS: unrecognized cisco VS option 1101w6d: RADIUS: Bad attribute (unsupported attribute): type 26 len 25 data 0x9After authentication is passed, the system prompts for the destination number:
1w6d: AAA/AUTHOR (3803615862): Post authorization status = PASS_ADD...1w6d: cid( 142) app running state get_dest1w6d: :/getVariable/1w6d: ta_PlayPromptCmd() 1w6d1w6d: ta_PlayPromptCmd. CallID=1421w6d: $ $du_get_vpPromptName() OK###1w6d: $ $du_mcDynamicS_silence() ms_int 1000 postSilence 10001w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_enter_dest.au], name:[en_enter_dest.au])::The "Enter destination" prompt is loaded and played and the user enters the destination number. The destination string entered is 555-5233.
1w6d: $ $mc_getFromUrlName() en_enter_dest.au on ram mc_waitq_delete: mc=61D9F560...1w6d: pcapp CallID 142 returning PCAPP_MATCHED. string=5555233...1w6d: cid(142) ta_get_event returning collect success1w6d: :[callID]1w6d: :/puts/1w6d: cid( 142) app running state second_authorize1w6d: :/ani/1w6d: :[authorize]1w6d: authorizationAuthorization is performed for the particular destination:
1w6d: account=000070same UID and PIN as deserved in CDR for the first call.1w6d: password=12341w6d: destination=5555233Now the destination is added:
1w6d: AAA: parse name=<no string> idb type=-1 tty=-11w6d: AAA/MEMORY: create_user (0x61C27260) user='000070' ruser='' port='' rem_addr='408/5555233' authen_type=ASCII service=LOGIN priv=01w6d: unknown AAA/AUTHOR/EXEC (1758884971): Port='' list='h323' service=EXEC1w6d: AAA/AUTHOR/EXEC: unknown (1758884971) user='000070'1w6d: unknown AAA/AUTHOR/EXEC (1758884971): found list "h323"The AAA authorization list configured in the router is found. The user is authorized for a call to 555-5233 and the time left for this destination is returned as 20900 seconds (5 hours, 48 minutes, and 20 seconds).
1w6d: unknown AAA/AUTHOR/EXEC (1758884971): Method=radius (radius)1w6d: RADIUS: authenticating to get author data1w6d: RADIUS: ustruct sharecount=21w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: Initial Transmit id 21 172.22.42.52:1645, Access-Request, len 1211w6d: Attribute 4 6 AC1627581w6d: Attribute 61 6 000000001w6d: Attribute 1 8 303030301w6d: Attribute 26 49 00000009182B68331w6d: Attribute 30 9 353235351w6d: Attribute 31 5 343038021w6d: Attribute 2 18 7B8D23641w6d: RADIUS: Received from id 21 172.22.42.52:1646, Access-Accept, len 761w6d: Attribute 26 26 00000009671468331w6d: Attribute 26 30 00000009661868331w6d: RADIUS: saved authorization data for user 61C27260 at 61C4C4E41w6d: RADIUS: cisco AVPair ":h323-return-code=0"1w6d: RADIUS: cisco AVPair ":h323-credit-time=20900"1w6d: AAA/AUTHOR (1758884971): Post authorization status = PASS_ADDIn the following output, the authorized user is prompted with the remaining time available (5 hours and 48 minutes) for a call to the specified destination:
1w6d: ta_PlayPromptCmd. CallID=1421w6d: $ $pc_mc_makeDynamicS() calloc mcDynamicS_t1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_you_have.au], name:[en_you_have.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_five.au], name:[en_five.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_hours.au], name:[en_hours.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_and.au], name:[en_and.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_forty.au], name:[en_forty.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_eight.au], name:[en_eight.au])::...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_minutes.au], name:[en_minutes.au])::The following RADIUS debug output is the start packet, call leg 2, for the active call. The VSAs, spelled out at the top of this section, deliver call details to the RADIUS server.
1w6d: Placing call for callID 142 to destination=55552331w6d: placecall CallID 142 got event CC_EV_CALL_HANDOFF1w6d: Matched peers(1)1w6d: placecall pc_setupPeer cid(142), destPat(5555233), matched(1), prefix(), peer(61C2BD34)1w6d: placecall cid(142) state change PC_CS_INIT to PC_CS_CALL_SETTING...1w6d: RADIUS: ustruct sharecount=21w6d: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas11."1w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: added cisco VSA 26 len 26 "h323-call-origin=originate"1w6d: RADIUS: added cisco VSA 27 len 19 "h323-call-type=VoIP"1w6d: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:04:54.450 PST Thu Oct 14 1999"1w6d: RADIUS: Initial Transmit id 22 172.22.42.52:1646, Accounting-Request, len2791w6d: Attribute 4 6 AC1627581w6d: Attribute 61 6 000000001w6d: Attribute 1 8 303030301w6d: Attribute 30 9 353235351w6d: Attribute 31 5 343038281w6d: Attribute 40 6 000000011w6d: Attribute 6 6 000000011w6d: Attribute 26 31 00000009211968331w6d: Attribute 26 49 00000009182B68331w6d: Attribute 26 34 000000091A1C68331w6d: Attribute 26 27 000000091B1568331w6d: Attribute 26 56 00000009193268331w6d: Attribute 44 10 303030301w6d: Attribute 41 6 000000001w6d: RADIUS: Received from id 22 172.22.42.52:1646, Accounting-response, len 461w6d: Attribute 26 26 0000000967146833In the following output, the user presses the pound symbol 543 seconds (9 minutes and 3 seconds) into the call:
1w6d: cid(142) ta_get_event returning active1w6d: :[callID]1w6d: :/puts/1w6d: cid( 142) app running state active1w6d: :/startTimer/1w6d: Wait for 21380 seconds Now the timer starts for the call1w6d: cid(142) ta_get_event returning digit1w6d: ta_StartTimerCmd(): ta_get_event [digit]1w6d: :/startTimer/1w6d: Wait for 20837 seconds the long pound is pressed 543 seconds into the call1w6d: cid(142) ta_get_event returning longpound1w6d: ta_StartTimerCmd(): ta_get_event [longpound]The following output is the stop record for the first call. Notice the conf-id for comparison. We know it is a stop record because it has connect-time, disconnect-time, and disconnect-cause (only present in stop records) and it is type "originate VoIP" (call leg 2).
1w6d: RADIUS: ustruct sharecount=11w6d: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas11."1w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: added cisco VSA 26 len 26 "h323-call-origin=originate"1w6d: RADIUS: added cisco VSA 27 len 19 "h323-call-type=VoIP"1w6d: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:04:54.450 PST Thu Oct 14 1999"1w6d: RADIUS: added cisco VSA 28 len 50 "h323-connect-time=14:05:02.260 PST ThuOct 14 1999"1w6d: RADIUS: added cisco VSA 29 len 53 "h323-disconnect-time=14:05:34.740 PST Thu Oct 14 1999"1w6d: RADIUS: added cisco VSA 30 len 24 "h323-disconnect-cause=10"1w6d: RADIUS: added cisco VSA 31 len 20 "h323-voice-quality=0"1w6d: RADIUS: added cisco VSA 23 len 30 "h323-remote-address=10.10.1.15"1w6d: :[callID]1w6d: :/puts/1w6d: cid( 142) app running state first_authorize1w6d: :/ani/1w6d: :[authorize]1w6d: authorization1w6d: account=0000701w6d: password=12341w6d: destination=In the following output, the next call is authorized. Notice that the conf-id is the same as the first call. It is, in effect, the same session. A new credit amount is given and a prompt is made for a new destination. This call proceeds in the same manner as the previous one.
1w6d: AAA: parse name=<no string> idb type=-1 tty=-11w6d: AAA/MEMORY: create_user (0x61C67F20) user='000070' ruser='' port='' rem_addr='408' authen_type=ASCII service=LOGIN priv=01w6d: unknown AAA/AUTHOR/EXEC (3696672751): Port='' list='h323' service=EXEC1w6d: AAA/AUTHOR/EXEC: unknown (3696672751) user='000070'1w6d: unknown AAA/AUTHOR/EXEC (3696672751): found list "h323"1w6d: unknown AAA/AUTHOR/EXEC (3696672751): Method=radius (radius)1w6d: RADIUS: authenticating to get author data1w6d: RADIUS: ustruct sharecount=21w6d: RADIUS: added cisco VSA 24 len 41"h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"...1w6d: RADIUS: saved authorization data for user 61C67F20 at 620157E01w6d: RADIUS: cisco AVPair ":h323-return-code=0"1w6d: RADIUS: cisco AVPair ":h323-preferred-lang=en"1w6d: RADIUS: cisco AVPair ":h323-credit-amount=-33.75"...1w6d: $ $mc_createFromFileUrl (url:[tftp://mojo/au/en/en_enter_dest.au], name:[en_enter_dest.au])::1w6d: $ $mc_getFromUrlName() en_enter_dest.au on ram mc_waitq_delete: mc=61D9F560...1w6d: prompt and collect app got callID 142...1w6d: $ $mc_make_packets_DQ()::1w6d: $ $mc_make_packets_DQ() post pak silence = 10001w6d: $ $mc_make_packets_DQ() mc:61D9F560 name:en_enter_dest.au1w6d: $ $mc_make_packets_DQ() count: 36 ##...1w6d: pcapp CallID 142 returning PCAPP_MATCHED. string=5554094...1w6d: cid(142) ta_get_event returning collect success...1w6d: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas11."1w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: added cisco VSA 26 len 26 "h323-call-origin=originate"1w6d: RADIUS: added cisco VSA 27 len 19 "h323-call-type=VoIP"1w6d: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:05:58.760 PST Thu Oct 14 1999"...1w6d: ta_StartTimerCmd(): ta_get_event [digit]1w6d: :/startTimer/1w6d: Wait for 20794 secondsThe following output is another stop record created at the termination of the second call. Connect and disconnect times are sent to the RADIUS server.
1w6d: AAA/ACCT: user 408, acct type 1 (953168740): Method=radius (radius)1w6d: RADIUS: ustruct sharecount=11w6d: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas11."1w6d: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"1w6d: RADIUS: added cisco VSA 26 len 23 "h323-call-origin=answer"1w6d: RADIUS: added cisco VSA 27 len 24 "h323-call-type=Telephony"1w6d: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:03:46.180 PST Thu Oct 14 1999"1w6d: RADIUS: added cisco VSA 28 len 50 "h323-connect-time=14:03:46.200 PST ThuOct 14 1999"1w6d: RADIUS: added cisco VSA 29 len 53 "h323-disconnect-time=14:07:36.320 PST Thu Oct 14 1999"1w6d: RADIUS: added cisco VSA 30 len 24 "h323-disconnect-cause=10"1w6d: RADIUS: added cisco VSA 31 len 20 "h323-voice-quality=0"1w6d: cid(142) incoming disconnected1w6d: cid(0) ta_get_event returning incoming disconnected1w6d: TCL script eval for callID 142 completed. code=OK1w6d: incoming disconnected1w6d: RADIUS: Initial Transmit id 29 172.22.42.52:1646, Accounting-Request, len...1w6d: AAA/MEMORY: free_user (0x61BEFB38) user='408' ruser='5550961' port='' rem_addr='408/5554094' authen_type=NONE service=H323_VSA priv=0sj7_pmeas11#Terminating Gateway Debug Output
The following debug commands were activated on the terminating gateway:
debug radiusdeb aaa authenticationdebug aaa authorizationdebug aaa accountingThe following debug output shows the activity on the terminating gateway for the activities and calls described in the previous debug output. Because IVR is not running on the terminating gateway, we have restricted debug data to AAA and RADIUS.
The important items in this output are those that compare the times and billing amounts to the originating gateway records. From this output you can see that the records collected from either gateway are sufficient to generate accurate billing records.
Notice in the following output that the conf-ID values match. There is a 2-second difference, however, in the setup times. This delay reflects the time it took to make the call setup.
sj7_pmeas01#Oct 14 14:05:22.600 PST: AAA: parse name=<no string> idb type=-1 tty=-1Oct 14 14:05:22.600 PST: AAA/MEMORY: create_user (0x61C024B0) user='408' ruser='5255233' port='' rem_addr='408/5555233' authen_type=NONE service=H323_VSA priv=0Oct 14 14:05:22.600 PST: AAA/ACCT/CONN: Found list "h323"Oct 14 14:05:22.600 PST: AAA/ACCT/CONN/START User 408, Port , Location "unknown"Oct 14 14:05:22.600 PST: AAA/ACCT/CONN/START User 408, Port ,task_id=56 start_time=939938722 timezone=PST service=connection protocol=h323Oct 14 14:05:22.600 PST: AAA/ACCT: user 408, acct type 1 (2416182195): Method=radius (radius)Oct 14 14:05:22.600 PST: RADIUS: ustruct sharecount=2Oct 14 14:05:22.600 PST: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas01."Oct 14 14:05:22.604 PST: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"Oct 14 14:05:22.604 PST: RADIUS: added cisco VSA 26 len 23 "h323-call-origin=answer"Oct 14 14:05:22.604 PST: RADIUS: added cisco VSA 27 len 19 "h323-call-type=VoIP"Oct 14 14:05:22.604 PST: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:04:56.620 PST Thu Oct 14 1999"The following information displayed is the start record for call leg 4 (originate Telephony):
Oct 14 14:05:22.756 PST: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas 01."Oct 14 14:05:22.756 PST: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"Oct 14 14:05:22.756 PST: RADIUS: added cisco VSA 26 len 26 "h323-call-origin=originate"Oct 14 14:05:22.756 PST: RADIUS: added cisco VSA 27 len 24 "h323-call-type=Telephony"Oct 14 14:05:22.756 PST: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:04:56.770 PST Thu Oct 14 1999"Oct 14 14:05:22.756 PST: RADIUS: Initial Transmit id 155 172.22.42.52:1646,Accounting-Request, len 281Oct 14 14:05:22.756 PST: Attribute 4 6 AC16275AOct 14 14:05:22.756 PST: Attribute 61 6 00000000Oct 14 14:05:22.756 PST: Attribute 1 5 3430381EOct 14 14:05:22.756 PST: Attribute 30 9 35323535Oct 14 14:05:22.756 PST: Attribute 31 5 34303828Oct 14 14:05:22.756 PST: Attribute 40 6 00000001Oct 14 14:05:22.756 PST: Attribute 6 6 00000001Oct 14 14:05:22.756 PST: Attribute 26 31 0000000921196833Oct 14 14:05:22.756 PST: Attribute 26 49 00000009182B6833Oct 14 14:05:22.756 PST: Attribute 26 34 000000091A1C6833Oct 14 14:05:22.756 PST: Attribute 26 32 000000091B1A6833Oct 14 14:05:22.756 PST: Attribute 26 56 0000000919326833Oct 14 14:05:22.760 PST: Attribute 44 10 30303030Oct 14 14:05:22.760 PST: Attribute 41 6 00000000Oct 14 14:05:22.772 PST: RADIUS: Received from id 155 172.22.42.52:1646,Accounting-response, len 46Oct 14 14:05:22.772 PST: Attribute 26 26 0000000967146833The connect time is approximately 1 second after call leg 2.
Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 33 len 23 "h323-gw-id=sj7_pmeas01."Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 24 len 41 "h323-conf-id=86DB7CA8 8C6C016E 0 466555A0"Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 26 len 23 "h323-call-origin=answer"Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 27 len 19 "h323-call-type=VoIP"Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 25 len 48 "h323-setup-time=14:04:56.620 PST Thu Oct 14 1999"Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 28 len 50 "h323-connect-time=14:05:03.780 PST Thu Oct 14 1999"The disconnect time is about 2 seconds after call leg 2. The time of the call (disconnect-time minus connect-time) is 32.48 seconds for call leg 2 and 33.12 seconds for call leg 3 (a 0.640-second difference between call leg 2 and call leg 3).
Oct 14 14:06:02.885 PST: RADIUS: added cisco VSA 29 len 53 "h323-disconnect-time=14:05:36.900 PST Thu Oct 14 1999"OSP for Clearinghouse Services Theory
Packet telephony service providers interested in expanding their geographic coverage have been faced with limited options. To help alleviate this problem, Cisco has implemented the Open Settlement Protocol (OSP), a client/server protocol defined by the ETSI TIPHON standards organization. OSP is designed to offer billing and accounting record consolidation for voice calls that traverse ITSP boundaries; it also allows service providers to exchange traffic with other service providers without establishing multiple bilateral peering agreements.
Because of OSP, you can employ a reliable third-party clearinghouse to handle VoIP call termination while leveraging the bandwidth efficiencies and tariff arbitrage advantages that are inherent in IP. You can use a clearinghouse as both a technical and business bridge; by signing on with such an organization and using OSP, you can extend service beyond the boundaries of your own network and immediately access the entire clearinghouse network of affiliated service providers.
OSP Background
In the time-division multiplexing (TDM) circuit-switched world, interconnecting carriers calculated settlements based on minutes used in circuits exchanged between their switches, often exchanging Signaling System 7 (SS7) information and voice paths. Call authorization was based on the physical demarcation point; if a call arrived, it was deemed "authorized." This scenario required a stable business relationship except in the case of international traffic, where third-party wholesale carriers often provided such services.
VoIP service providers have adapted to such arrangements by terminating calls on the PSTN and reoriginating the call on a circuit switch. However, such an approach limits the cost-effectiveness of currently available packet telephony. Even interconnection between VoIP networks was problematic—solutions were usually tightly integrated with the proprietary and nonstandard implementations of H.323 protocols by individual vendors.
OSP avoids this problem. By allowing gateways to transfer accounting and routing information securely, this protocol provides common ground between VoIP service providers.
Third-party clearinghouses with an OSP server can offer route selection, call authorization, call accounting, and intercarrier settlements, including all the complex rating and routing tables necessary for efficient and cost-effective interconnections. Cisco has worked with a variety of leading OSP clearinghouses to ensure interoperability with their OSP server applications. OSP-based clearinghouses provide the least cost and the best route selection algorithms based on a variety of parameters their subscriber carriers provide, including cost, quality, and specific carrier preferences. Prepaid calling services, click-to-dial, and clearinghouse settlements can be offered over the same packet infrastructure.
OSP Clearinghouses Benefits
The OSP clearinghouse solution gives virtually all VoIP providers the worldwide calling reach they require. This service can be used separately or in conjunction with internally managed prepaid calling services. The benefits of using an OSP clearinghouse include the following:
•
•
•
•
•
•
•
•
•
•
OSP Clearinghouse Operation and Call Flow
The following list describes a high-level call flow sequence for an OSP clearinghouse application:
1.
2.
3.
4.
Note
5.
Note
6.
7.
At the end of the call, both the originating and terminating gateways send usage indicator reports (CDRs) to the OSP server. The usage indicator reports contain the call detail information that the OSP server uses to provide settlement service between the originating and terminating service providers.
Figure 7 illustrates a call flow for a typical call settled by a clearinghouse server.
Figure 7 Typical Call Flow for OSP Clearinghouse Application
OSP Architecture
Figure 8 shows an OSP architecture model where all inter-ISP calls are routed and settled by an OSP server. Intra-ISP calls are routed and billed in the typical postpaid or prepaid model.
Figure 8 OSP Architecture Model
OSP Hardware and Software Requirements
The following sections describe the hardware and software requirements to support OSP:
•
System Platform Requirements
OSP is supported on the following Cisco platforms:
•
•
•
Memory and Software Requirements
An OSP server must meet the following memory and software requirements:
•
•
•
•
•
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/iosrn/vcwrn/vcwrmtrx.htm
Hardware Components
To implement OSP clearinghouse services, you must deploy the following devices:
•
•
•
The following are OSP server vendors:
•
•
•
•
•
Note
OSP for Clearinghouse Services Application
The following sections describe the application of OSP clearinghouse services:
OSP Configuration Guidelines
Configuring a Cisco router or access server to register with an online TransNexus Phase 1 OSP server consists of the tasks described in the following sections:
•
•
•
•
The specific configuration parameters may be different from those shown, depending on the OSP server with which you are registering.
Defining Gateway Identity Parameters
OSP servers typically locate gateways and clients using DNS. For this reason, you need to make sure that the voice gateway can locate the OSP server and other IP resources using DNS. The following example shows how to configure the domain name in which the gateway resides and identify a DNS server in that domain:
ip domain-name cisco.comip name-server 172.22.30.32In this example, both the domain name and DNS are identified. Typically, the ip domain-lookup global configuration command is enabled by default in Cisco routers and gateways.
When you have configured the ip domain-name and the ip name-server commands and confirmed that the ip domain-lookup command is enabled, the gateway can refer to the OSP server by its domain name.
Note
Using Network Time Protocol
The OSP server requires accurate time stamps from gateways in order to rate calls adequately. Unless the gateway time-of-day clock (not to be confused with the system controller clock) is within a certain tolerance range (minutes) of the OSP server clock, token validation will fail. Gateways, servers, and other IP devices can synchronize their time-of-day clocks with each other through the NTP. As with DNS, a hierarchy of NTP servers is available on the Internet. Any gateway with access to the Internet can point to an available NTP server for accurate time-of-day synchronization. A list of stratum-2 NTP servers is at the following URL:
http://www.eecis.udel.edu/~mills/ntp/clock2.htm
To configure a Cisco gateway to synchronize its time to an authoritative NTP source, use the ntp server ip-address global configuration command. Although not required for simple time synchronization, the ntp global configuration command can be used to configure a variety of other NTP parameters, as shown in Table 9.
NTP time formats are displayed in the following format, which is described in Table 10:
%H:%M:%S.%k %Z %tw %tn %td %Y
Enabling the debug ntp adjustments command is a quick way to learn if your gateway is communicating with the configured NTP server. An example follows:
Router# debug ntp adjustmentsNTP clock adjustments debugging is onRouter#00:27:12: NTP: adj(-0.000000317), rem. offset = 0.000000000, adj = -0.00000031700:27:13: NTP: adj(-0.000000838), rem. offset = 0.000000000, adj = -0.00000083800:27:14: NTP: adj(-0.000000842), rem. offset = 0.000000000, adj = -0.00000084200:27:15: NTP: adj(-0.000000933), rem. offset = 0.000000000, adj = -0.00000093300:27:16: NTP: adj(-0.000001029), rem. offset = 0.000000000, adj = -0.00000102900:27:17: NTP: adj(-0.000000290), rem. offset = 0.000000000, adj = -0.000000290You can use the show clock privileged EXEC command to confirm the correct time.
Configuring the PKI
To configure the Public Key Infrastructure (PKI) for secured communication between the gateway and the OSP server, perform the tasks described in the following sections:
•
Generating an RSA Key Pair
The following example shows you how to generate an RSA key pair. When you enter the following command, you will receive the following feedback from the gateway:
Router(config)# crypto key generate rsaThe name for the keys will be: Group10_B.cisco.comChoose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.How many bits in the modulus [512]:Pressing Enter at this prompt will generate a 512-bit key. The system confirms that the RSA keys have been generated by displaying the following output:
Generating RSA keys ...[OK]Configuring the Enrollment Parameters
The following example shows how to configure the enrollment parameters:
Router(config)# crypto ca identity transnexusRouter(ca-identity)# enrollment url http://enroll.transnexus.com:2378Router(ca-identity)# enrollment retry count 3Router(ca-identity)# enrollment retry period 1Router(ca-identity)# no enrollment mode raIn this example, the crypto ca identity command places the router in CA identity configuration mode and matches the OSP parameters to the identity tag transnexus. The next three commands configure the enrollment URL of the OSP server and retry parameters. The fifth command makes sure you are not in resource authority configuration mode.
Obtaining the CA Certificate
The following example shows you how to obtain a CA certificate:
Router(config)# crypto ca authenticate ospserverAfter you enter this command, you will receive the following feedback from the gateway:
Certificate has the following attributes:Fingerprint: 96D254B4 0AEF4F23 7A545BF9 70DC4D17% Do you accept this certificate? [yes/no]: Y <To accept this certificate, you type "Y" here.>The keyword must be the same as the one used when declaring the CA with the crypto ca identity command (in this example, ospserver).
Enrolling with the OSP Server
The following example shows you how to enroll your voice gateway with the OSP server:
Router(config)# crypto ca enroll ospserverAfter you enter this command, the system will prompt you for a series of responses. All of the responses that you should enter are in bold type in the following output.
%% Start certificate enrollment ..% Create a challenge password. You will need to verbally provide thispassword to the CA Administrator in order to revoke your certificate.For security reasons your password will not be saved in the configuration.Please make a note of it.Password: xxxx <You enter your password here.>Re-enter password: xxxx <You re-enter your password here.>% The subject name in the certificate will be: Group10_B.cisco.com% Include the router serial number in the subject name? [yes/no]: Y% The serial number in the certificate will be: 006CE956% Include an IP address in the subject name? [yes/no]: YInterface: Ethernet 0Request certificate from CA? [yes/no]: Y% Certificate request sent to Certificate Authority% The certificate request fingerprint will be displayed.% The 'show crypto ca certificate' command will also show the fingerprintWait here for the feedback below:(config)# Fingerprint: 24D05F87 1DE1D0C9 4DF974D1 7AE064C611:15:12: %CRYPTO-6-CERTRET: from Certificate AuthorityIf you do not get the CERTRET feedback, your enrollment most likely has failed. If you continue without a proper certificate, you will not be able to register. After you receive a certificate, verify the presence of the certificate by displaying your running configuration using the show running-config privileged EXEC command.
Router# show running-configCurrent configuration:!version 12.0service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname ogw!enable secret level 14 5 $1$gB9t$cNIAO.XGbV/2ebLeiYXPc.enable secret 5 $1$W1Wx$KtFgICn0Q7X8BbxwFnR991!clock timezone GMT 0ip subnet-zeroip domain-name cisco.com!crypto ca identity transnexusenrollment url http://10.100.1.3crypto ca certificate chain transnexuscertificate AFADA65D4DF416847B6B284AB197146E30820231 3082019A A0030201 02021100 AFADA65D 4DF41684 7B6B284A B197146E300D0609 2A864886 F70D0101 04050030 6E310B30 09060355 04061302 55533110300E0603 55040813 0747656F 72676961 31183016 06035504 0A130F54 72616E734E657875 732C204C 4C433114 30120603 55040B13 0B446576 656C6F70 6D656E74311D301B 06035504 03131454 52414E53 4E455855 53204245 54412043 412031301E170D39 39303332 39323235 3235395A 170D3030 30333239 32323532 35395A3072317030 0D060355 04051306 36434232 31413017 06092A86 4886F70D 010908130A31302E 3130302E 312E3130 1A06092A 864886F7 0D010902 160D6F67 772E636973636F2E 636F6D30 2A060355 04031423 5B747261 6E736E65 7875732E 636F6D2047574944 3D313030 20435349 443D3430 30305D30 5C300D06 092A8648 86F70D01.01010500 034B0030 48024100 C871D5F7 8529C9AE 9E7BC554 C5510B75 A66C9E78405FECDB 60896552 80106C8F 7F7F9B3B 89A50D55 0578881D 3672CCFE 9BB5E51547D03E95 CE4CC0F1 3DC20593 02030100 01A30F30 0D300B06 03551D0F 0404030205A0300D 06092A86 4886F70D 01010405 00038181 00256D3C 087E8005 74D057590B9924B2 842675D5 C37A913C A2E16AC1 B146161C DFF7F96A 0053DCFC F5E1E22DE51D4C82 9A97D2E8 B38E5CE0 902CEFE1 13181486 5929DF21 B882775E 830563A2D15C61DE 0EFDC39D 334ECD0D E826E953 1C37ED56 2DA5D765 5B9949E6 1D33E3CEFB3E2818 78355CDF 4A9A6118 52B6FF48 D07A6DEB 33quitcertificate ca 01713082024C 308201B5 02020171 300D0609 2A864886 F70D0101 04050030 6E310B3009060355 04061302 55533110 300E0603 55040813 0747656F 72676961 3118301606035504 0A130F54 72616E73 4E657875 732C204C 4C433114 30120603 55040B130B446576 656C6F70 6D656E74 311D301B 06035504 03131454 52414E53 4E45585553204245 54412043 41203130 1E170D39 39303332 32313334 3630395A 170D303030333231 31333436 30395A30 6E310B30 09060355 04061302 55533110 300E060355040813 0747656F 72676961 31183016 06035504 0A130F54 72616E73 4E657875732C204C 4C433114 30120603 55040B13 0B446576 656C6F70 6D656E74 311D301B06035504 03131454 52414E53 4E455855 53204245 54412043 41203130 819F300D06092A86 4886F70D 01010105 0003818D 00308189 02818100 B1B8ACFC D78F0C950258D164 5B6BD8A4 6F5668BD 50E7524B 2339B670 DC306537 3E1E9381 DE2619B44698CD82 739CB251 91AF90A5 52736137 658DF200 FAFEFE6B 7FC7161D 89617E5E4584D67F F018EDAB 2858DDF9 5272F108 AB791A70 580F994B 4CA54F08 38C32DF5B44077E8 79830F95 96F1DA69 4CAE16F2 2879E07B 164F5F6D 02030100 01300D06092A8648 86F70D01 01040500 03818100 2FDCB580 C29E557C 52201151 A8DB5F47C06962D5 8FDA524E A69DE3EE C3FE166A D05C8B93 2844CD66 824A8859 974F22E046F69F7E 8027064F C19D28BC CA750E4E FF2DD68E 1AA9CA41 8BB89C68 7A61E9BF49CBE41E E3A42B16 AAEDAEC7 D3B4F676 4F1A817B A5B89ED8 F03A15B0 39A6EBB90AFA6968 17A9D381 FD62BBB7 A7D379E5quit...ntp clock-period 17182503ntp server 10.100.1.3endYou should find two large blocks of hex strings similar to the ones shown. One block is a representation of the OSP server certificate and the other represents the key from the certificate authority. The presence of both keys is an indication (although not a guarantee) that the registration has occurred correctly.
Configuring Settlement Parameters
The following example shows you how to configure settlement parameters on your gateway:
Router(config)# settlement 0Router(config-settlement)# type ospRouter(config-settlement)# url https://192.168.152.17:8444/Router(config-settlement)# response-timeout 20Router(config-settlement)# device-id 1039928734Router(config-settlement)# customer-id 805311438Router(config-settlement)# no shutdownThe first command places the router in settlement configuration mode. The next five commands configure the settlement parameters, including the settlement URL. Notice that settlement is using the SSL protocol (denoted by https://) as the transport mechanism. The device ID and customer ID are both Transnexus-specific.
Configuring Incoming and Outgoing Dial Peers
The incoming POTS dial peer on the originating gateway is associated with the session application that initiates the OSP activities. The following example shows how to configure the incoming POTS dial peer on the originating gateway:
Router(config)# dial-peer voice 1 potsRouter(config-dial-peer)# application sessionRouter(config-dial-peer)# incoming called-number 1415.......Router(config-dial-peer)# port 1/0/0The first command opens the dial-peer configuration mode and defines the tag number of the dial peer you are configuring. The application session command associates the session application with the call. The last two commands configure general POTS dial-peer parameters.
The outbound VoIP dial peer on the originating gateway has a session target of settlement, which directs the call to the OSP server. The following example shows how to configure the outbound VoIP peer on the originating gateway:
Router(config)# dial-peer voice 10 voipRouter(config-dial-peer)# destination-pattern 1219.......Router(config-dial-peer)# session target settlementThe first command opens dial-peer configuration mode and defines the tag number of the dial peer you are configuring. The session target settlement command sends the call to the OSP server. The other commands configure general VoIP dial peer parameters.
The VoIP dial peer on the terminating gateway matches the outgoing VoIP dial peer on the originating gateway and must also point to the settlement session target. The following example shows how to configure the inbound VoIP and outbound POTS dial peers on the terminating gateway:
Router(config)# dial-peer voice 10 voipRouter(config-dial-peer)# application sessionRouter(config-dial-peer)# incoming called-number 1415.......Router(config-dial-peer)# session target settlement:0Router(config-dial-peer)# exitRouter(config)# dial-peer voice 1 potsRouter(config-dial-peer)# incoming called-number 1219.......Router(config-dial-peer)# port 1/0/0The first command opens the dial-peer configuration mode and defines the tag number of the inbound VoIP dial peer you are configuring. The application session command associates the session application with the call. The session target settlement command identifies the settlement server.
The dial-peer voice 1 pots command defines the outbound POTS dial peer and defines its tag number. The last two commands configure general POTS dial peer parameters.
OSP Troubleshooting Tips
In general, the following commands are useful in debugging an OSP installation:
•
•
•
•
•
Common Problems with Settlement Configuration
The following sections describe common problems with OSP configurations.
Settlement Database Not Set Up Properly
Problem: Calls are routed through a settlement server, but the originating gateway gets no response, or negative response.
Solution: Check with the settlement provider to make sure the router is properly registered with that provider. Router registration with the settlement provider is normally done outside of OSP.
TCL IVR Script Not Called
Problem: TCL IVR script is not used on the originating gateway or terminating gateway.
Solution: You can configure a TCL IVR script for the dial peer using the application name dial peer configuration command or you can use the show call application voice summary command to list all the available scripts on the router:
router# show call application voice summaryname descriptionsession Basic app to do DID, or supply dialtone.fax_hop_on Script to talk to a fax redialerclid_authen Authenticate with (ani, dnis)clid_authen_collect Authenticate with (ani, dnis), collect if that failsclid_authen_npw Authenticate with (ani, NULL)clid_authen_col_npw Authenticate with (ani, NULL), collect if that failsclid_col_npw_3 Authenticate with (ani, NULL), and 3 tries collectingclid_col_npw_npw Authenticate with (ani, NULL) and 3 tries without pwSESSION Default system session applicationNo Destination Pattern Set
Problem: The inbound POTS dial peer on the originating gateway has no destination pattern set.
Solution: Because some PBX devices do not pass along the calling number in the setup message, the router uses the destination pattern number or answer-address as an alternative, and calling number is a required field for settlement.
No Session Target Settlement Set on Originating Gateway
Problem: The outbound VoIP dial peer of the originating gateway does not have the session target configured for settlement.
Note
Solution: Configure the session target settlement [provider-number] command.
No VoIP Inbound Dial Peer on Terminating Gateway
Problem: The terminating gateway has no VoIP inbound dial peer. Because the settlement token in the incoming setup message from the originating gateway cannot be validated, the terminating gateway rejects the call.
Solution: Create an inbound dial peer with the session target settlement [provider-number] command.
No Application Attribute on Terminating Gateway
Problem: The terminating gateway has an inbound dial peer configured, but with no application attribute. The default session application (SESSION) processes the call, but it does not support settlement.
Solution: Configure the application application name attribute in the inbound dial peer.
Terminating Gateway Not Synchronized with Settlement Server
Problem: The terminating gateway clock is not synchronized with the settlement server. The terminating gateway rejects the call because it is too soon or too late to use the settlement token in the incoming setup message.
Solution: Use the ntp or clock set command to synchronize the clocks between the terminating gateway and the settlement server.
Settlement Provider Not Running
Problem: The settlement provider on the originating gateway or terminating gateway is not running. No settlement transaction processing is allowed unless the provider is running.
Solution: Enable settlement using the no shutdown command in settlement configuration mode. Use the show settlement command to verify the provider status.
Router and Server Not Using SSL to Communicate
Problem: The router cannot use SSL to communicate with the server because the server URL should be "https" not "http."
Solution: Configure a secured URL using "https."
Problem: The router cannot use SSL to communicate with the server because the certificates of the server or router were not properly obtained.
Solution: Check the certificate enrollment process for both the server and the router.
Multiple Dial Peers Have Random Order
Problem: The originating gateway has multiple dial peers for the same called number, and settlement is never used. The order for rotary dial peers is random unless a dial peer preference is specified. The dial peer with lower preference is chosen first.
Solution: Define dial peer preference using the preference number command.
H.323 Setup Connection Timeout
Problem: The originating gateway cannot successfully set up a call with the first terminating gateway that is returned from the OSP server. The problem occurs when a gateway attempts to set up the call with the terminating gateways in the order they are received. If for some reason the H.323 call setup is not successful, there is a 15-second default timeout before the next terminating gateway on the list is contacted.
Solution: Tune the H.323 call setup timeout by using the h225 timeout command:
voice class h323 1h225 timeout tcp establish <value 0 to 30 seconds>dial-peer voice 919 voipapplication sessiondestination-pattern 919555....voice-class codec 1voice-class h323 1session target settlementOSP Problem Isolation
If you are having trouble isolating the problems that are occurring with settlement, perform the following tasks:
•
•
•
•
•
•
•
OSP Configuration Examples
The following sections show configuration examples for OSP gateways:
•
•
Configuring OSP on the Originating Gateway
The following example shows an originating gateway configured to register with an OSP server:
Note
version 12.1service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname Group2_A!boot system flash c3640-js56i-mz_120-4_XH.binenable password pme123!clock timezone PST -7ip subnet-zeroip domain-name cisco.comip name-server xxx.156.128.1ip name-server xxx.156.128.10!cns event-service server!crypto ca identity transnexus! Certificate authority identity parametersenrollment retry count 3enrollment url http://enroll.transnexus.com:2378! Clearinghouse server addresscrypto ca certificate chain transnexus! The following 2 blocks of characters are a hexadecemal representation of the! certificates present on the gateway.certificate 73A39A2746B2BFFC373AF35B70F427CC30820246 308201AF A0030201 02021073 A39A2746 B2BFFC37 3AF35B70 F427CC300D06092A 864886F7 0D010104 0500306E 310B3009 06035504 06130255 533110300E060355 04081307 47656F72 67696131 18301606 0355040A 130F5472 616E734E65787573 2C204C4C 43311430 12060355 040B130B 44657665 6C6F706D 656E74311D301B06 03550403 13145452 414E534E 45585553 20424554 41204341 2031301E170D3939 31303132 31353430 33345A17 0D303031 30313231 35343033 345A308187318184 300D0603 55040513 06413137 30443030 1A06092A 864886F7 0D010908130D3230 392E3234 2E313431 2E333430 1F06092A 864886F7 0D010902 161247726F757032 5F412E63 6973636F 2E636F6D 30360603 55040314 2F5B7472 616E736E65787573 2E636F6D 20475749 443D3130 37333734 36393333 20435349 443D383035333131 3433385D 305C300D 06092A86 4886F70D 01010105 00034B00 3048024100E288FF 7C275A55 5C375387 99FB9682 7BFC554C F2DFA453 BFFD88AB 657C0FD57FC510BA 13DDEB99 DF7E5FAA 5BE5952E B974F8DB 1B333F2C D4C5689D 61812121DB020301 0001A30F 300D300B 0603551D 0F040403 0205A030 0D06092A 864886F70D010104 05000381 81007D83 08924EFD F2139D01 504FAC21 35108FCF 083D9DA7495649F6 6D1E28A6 1A687F1C CAF5BDBD 37E8E8A1 54401F4A 73BBFB05 786E01BCAF966529 AC92648B 2A4B9FEC 3BFFEBF8 81A116B5 4D3DAA93 7E4C24FB E3624EB3D630C232 D016149D 427557A1 F58F313E F92F9E9D ADBA3873 92EBF7F0 861E0413F81CD5C0 E4E18A03 2FA2quitcertificate ca 01713082024C 308201B5 02020171 300D0609 2A864886 F70D0101 04050030 6E310B3009060355 04061302 55533110 300E0603 55040813 0747656F 72676961 3118301606035504 0A130F54 72616E73 4E657875 732C204C 4C433114 30120603 55040B130B446576 656C6F70 6D656E74 311D301B 06035504 03131454 52414E53 4E45585553204245 54412043 41203130 1E170D39 39303332 32313334 3630395A 170D303030333231 31333436 30395A30 6E310B30 09060355 04061302 55533110 300E060355040813 0747656F 72676961 31183016 06035504 0A130F54 72616E73 4E657875732C204C 4C433114 30120603 55040B13 0B446576 656C6F70 6D656E74 311D301B06035504 03131454 52414E53 4E455855 53204245 54412043 41203130 819F300D06092A86 4886F70D 01010105 0003818D 00308189 02818100 B1B8ACFC D78F0C950258D164 5B6BD8A4 6F5668BD 50E7524B 2339B670 DC306537 3E1E9381 DE2619B44698CD82 739CB251 91AF90A5 52736137 658DF200 FAFEFE6B 7FC7161D 89617E5E4584D67F F018EDAB 2858DDF9 5272F108 AB791A70 580F994B 4CA54F08 38C32DF5B44077E8 79830F95 96F1DA69 4CAE16F2 2879E07B 164F5F6D 02030100 01300D06092A8648 86F70D01 01040500 03818100 2FDCB580 C29E557C 52201151 A8DB5F47C06962D5 8FDA524E A69DE3EE C3FE166A D05C8B93 2844CD66 824A8859 974F22E046F69F7E 8027064F C19D28BC CA750E4E FF2DD68E 1AA9CA41 8BB89C68 7A61E9BF49CBE41E E3A42B16 AAEDAEC7 D3B4F676 4F1A817B A5B89ED8 F03A15B0 39A6EBB90AFA6968 17A9D381 FD62BBB7 A7D379E5quit!voice-port 1/0/0!voice-port 1/0/1!voice-port 1/1/0!voice-port 1/1/1!dial-peer voice 1 pots! The incoming pots dial peer on the originating gateway is associated! with the session application that initiates the OSP activities.application sessiondestination-pattern 9549204port 1/0/0!dial-peer voice 10 voipdestination-pattern 7671234session target ipv4:10.24.141.35!dial-peer voice 101 voip! The outgoing VoIP dial peer has a session target of settlement, which directs the call! to the OSP server.application sessiondestination-pattern 1Tsession target settlement!process-max-time 200settlement 0type osp! The settlement parameters include the URL to the settlement server; in this case,! using SSLurl https://10.144.152.17:8444/device-id 1073746933customer-id 805311438no shutdown!interface Ethernet0/0no ip addressno ip directed-broadcastshutdown!interface Ethernet0/1description flat management networkip address 10.24.141.34 255.255.255.240no ip directed-broadcast!ip classlessip route 0.0.0.0 0.0.0.0 10.24.141.33no ip http server!line con 0exec-timeout 0 0transport input noneline aux 0speed 115200line vty 0 4exec-timeout 0 0password pme123no login!ntp clock-period 17180168ntp source Ethernet0/1! NTP parameters are pointing to a Stratum 2 NTP serverntp server 209.24.141.33endConfiguring OSP on the Terminating Gateway
The following example shows a terminating gateway configured to support OSP.
Note
version 12.1service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname Group2_B!enable password pme123!clock timezone PST -7ip subnet-zeroip domain-name cisco.comip name-server xxx.156.128.1ip name-server xxx.156.128.10!cns event-service server!crypto ca identity transnexus! Certificate authority identity parametersenrollment retry count 3enrollment url http://enroll.transnexus.com:2378crypto ca certificate chain transnexuscertificate 017230820264 308201CD 02020172 300D0609 2A864886 F70D0101 04050030 6E310B3009060355 04061302 55533110 300E0603 55040813 0747656F 72676961 3118301606035504 0A130F54 72616E73 4E657875 732C204C 4C433114 30120603 55040B130B446576 656C6F70 6D656E74 311D301B 06035504 03131454 52414E53 4E45585553204245 54412043 41203130 1E170D39 39303332 32313334 3631345A 170D303030333231 31333436 31345A30 8185310B 30090603 55040613 02555331 10300E0603550408 13074765 6F726769 61311830 16060355 040A130F 5472616E 734E657875732C20 4C4C4331 31302F06 0355040B 13285472 616E736E 65787573 20536574746C656D 656E7420 53657276 65722044 6576656C 6F706D65 6E743117 3015060355040313 0E747261 6E736E65 7875732E 636F6D30 819F300D 06092A86 4886F70D01010105 0003818D 00308189 02818100 AF4E4E7A 7AE56E12 8526027B 4FAA7E1607710217 72EF63B9 8C0CAD75 C40724FE 71779746 937C8499 0EE9B19E FE7E76D012A9FD09 DA7FE092 979FA5C6 066F6FAB 3614229A A352708E 87BE67A0 B7D1B8F12238DCD7 E1D5D538 E632974E 2B15A124 E72BEBCA 054A7000 43090FF6 A62E05DD86452268 12EA8BF9 D7E63996 116426D5 02030100 01300D06 092A8648 86F70D0101040500 03818100 7DDBBA3F 2EF28952 6458090A E005C659 F26D690C 3CEB89A3B4C4BF49 8CA7B624 EF75AA02 3C723BCD 028C04FF 191EE516 49AE9092 CADED3F9D652EE75 E0BCF22E EBA6908F BD7D8248 F19F3BCE D06B0A26 5FADFA19 1C5E97216BCD8EFA 249DD629 5024EA19 5B2B0732 CE5DF1DD 7758EB41 B3F3FE1C D0E34AAA5E3CA3D2 9FEA6CA2quitcertificate ca 01713082024C 308201B5 02020171 300D0609 2A864886 F70D0101 04050030 6E310B3009060355 04061302 55533110 300E0603 55040813 0747656F 72676961 3118301606035504 0A130F54 72616E73 4E657875 732C204C 4C433114 30120603 55040B130B446576 656C6F70 6D656E74 311D301B 06035504 03131454 52414E53 4E45585553204245 54412043 41203130 1E170D39 39303332 32313334 3630395A 170D303030333231 31333436 30395A30 6E310B30 09060355 04061302 55533110 300E060355040813 0747656F 72676961 31183016 06035504 0A130F54 72616E73 4E657875732C204C 4C433114 30120603 55040B13 0B446576 656C6F70 6D656E74 311D301B06035504 03131454 52414E53 4E455855 53204245 54412043 41203130 819F300D06092A86 4886F70D 01010105 0003818D 00308189 02818100 B1B8ACFC D78F0C950258D164 5B6BD8A4 6F5668BD 50E7524B 2339B670 DC306537 3E1E9381 DE2619B44698CD82 739CB251 91AF90A5 52736137 658DF200 FAFEFE6B 7FC7161D 89617E5E4584D67F F018EDAB 2858DDF9 5272F108 AB791A70 580F994B 4CA54F08 38C32DF5B44077E8 79830F95 96F1DA69 4CAE16F2 2879E07B 164F5F6D 02030100 01300D06092A8648 86F70D01 01040500 03818100 2FDCB580 C29E557C 52201151 A8DB5F47C06962D5 8FDA524E A69DE3EE C3FE166A D05C8B93 2844CD66 824A8859 974F22E046F69F7E 8027064F C19D28BC CA750E4E FF2DD68E 1AA9CA41 8BB89C68 7A61E9BF49CBE41E E3A42B16 AAEDAEC7 D3B4F676 4F1A817B A5B89ED8 F03A15B0 39A6EBB90AFA6968 17A9D381 FD62BBB7 A7D379E5quit!voice-port 1/0/0description ma bell 954 9173!voice-port 3/0/0input gain 14!voice-port 3/0/1!voice-port 3/1/0!voice-port 3/1/1!!dial-peer voice 1 potsapplication clid_authen_collectincoming called-number 9549172port 3/0/0!dial-peer voice 767 potsdestination-pattern 7......port 3/0/0prefix 7!dial-peer voice 513 pots! The outgoing pots dial peer is associated with the default application and! does not need an OSP application association.destination-pattern 1513.......port 3/0/0!dial-peer voice 1513 voip! The incoming VoIP dial peer, which matches the outgoing VoIP dial peer on! the originating gateway, must also point to a session target of settlement.application sessionincoming called-number 1513.......session target settlement!dial-peer terminator #process-max-time 200settlement 0type ospurl https://10.144.152.17:8444/device-id 1140855798customer-id 805311438no shutdown!interface Ethernet0/0no ip addressno ip directed-broadcastshutdown!interface Serial0/0no ip addressno ip directed-broadcastno ip mroute-cacheshutdown!interface Ethernet0/1description Transnexus enrollmentip address 10.24.141.35 255.255.255.240no ip directed-broadcast!ip classlessip route 0.0.0.0 0.0.0.0 10.24.141.33ni ip http server!line con 0exec-timeout 0 0transport input noneline aux 0line vty 0 4no login!ntp clock-period 17180148ntp source Ethernet0/1ntp server 10.24.141.33end
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)