Table Of Contents
Settlements for Packet Voice, Phase 2
Feature Overview
Roaming
PKI Multiple Roots
Benefits
Restrictions
Related Features and Technologies
Related Documents
Supported Platforms
Supported Standards, MIBs, and RFCs
Prerequisites
Configuration Tasks
Configuring the Public Key Infrastructure
Configuring the Originating Gateway
Configuring the Settlement Provider
Configuring the Inbound POTS Dial Peer
Configuring the Outbound VoIP Dial Peer
Configuring the Terminating Gateway
Configuring the Settlement Provider
Configuring the Inbound VoIP Dial Peer
Configuring the Outbound POTS Dial Peer
Verifying Settlement Configuration
Configuring Settlement with Roaming
Configuring Settlement with Multiple Roots
Configuring Settlement with Suggested Route
Configuration Examples
Example Configuration of Settlement on the Originating Gateway
Example Configuration of Settlement on the Terminating Gateway
Example Configuration of Settlement with Roaming
Example Configuration of Settlement with Multiple Roots
Comprehensive Configuration Guidelines
Settle-call and Session Target
Actions When Session Target is "Settlement"
Actions When Session Target is IP/DNS
Actions When Session Target is RAS with No Token
Actions When Session Target is RAS with Token
Actions When Receiving Inbound Calls
Troubleshooting Tips
Common Problems when Setting up Settlement
Problem Isolations
Command Reference
connection-timeout
crypto ca authenticate
crypto ca trusted-root
customer-id
device-id
encryption
max-connection
response-timeout
retry-delay
retry-limit
roaming (dial-peer mode)
roaming (settlement mode)
session target (VoIP)
session-timeout
settle-call
settlement
settlement roam-pattern
show crypto ca roots
show settlement
shutdown/no shutdown
token-root-name
type
url
Debug Commands
debug voip ivr settlement
debug voip settlement all
debug voip settlement enter
debug voip settlement error
debug voip settlement exit
debug voip settlement misc
debug voip settlement network
debug voip settlement security
debug voip settlement transaction
Glossary
Settlements for Packet Voice, Phase 2
Feature History
Release
|
Modification
|
12.0(4)XH
|
This feature was introduced.
|
12.0(7)T
|
This feature was implemented into the 12.0(7)T release.
|
12.1(3)T
|
Two new features, Roaming and Mulitple Roots were added.
|
12.1(5)T
|
Support for the Cisco AS5800 universal access server was added.
|
This feature is also known as "Settlement Plus Roaming and PKI Multiple Roots on Cisco Access Platforms."
The Cisco Settlement Plus Roaming and PKI Multiple Roots feature is introduced in Cisco IOS Release 12.1(1)T. These features are new additions to the Open Settlement Protocol (OSP) which was previously released in Cisco IOS Release 12.0(4)XH and 12.0(7)T. The feature overview describes both new features in the following sections:
•
Roaming
• PKI Multiple Roots
This document includes the following sections:
• Feature Overview
• Benefits
• Restrictions
• Related Features and Technologies
• Related Documents
• Supported Platforms
• Supported Standards, MIBs, and RFCs
• Prerequisites
• Configuration Tasks
• Configuration Examples
• Comprehensive Configuration Guidelines
• Common Problems when Setting up Settlement
• Command Reference
• Debug Commands
• Glossary
Feature Overview
This is the second release of Cisco's Open Settlement Protocol (OSP) features. Some settlement vendors have required roaming users to be authenticated and accounted for by the settlement clearinghouse. Therefore, this IOS Release 12.1.(1) introduces two new features, roaming and multiple roots.
What is settlement? When you make a telephone call, the cost charged can be divided between different carriers involved in the completion of the call. Settlement is the method used to divide the cost between carriers. Traditionally, settlement agreements have been arranged between the carriers in a pairwise fashion. With the advance of voice and video conferencing over IP, pairwise settlement agreements have become cumbersome. A number of companies have entered the market offering settlement on a subscription basis. As a result, the settlement process becomes a more manageable, many-to-one system, with a set of public interfaces that service providers must implement.
The Cisco gateway-based settlement protocol (OSP) interacts between carriers to create a single authentication at initialization. The authentication is the basis for the establishment of a secure communication channel between the settlement system and the infrastructure component. This channel then allows the following three types of transactions to be handled.
•Call routing—The settlement system can either accept a gateway endpoint from the requestor or assign one for the requester.
•Call authorization—Based on the terminating endpoint address, the settlement system determines whether the requesting gateway is permitted to originate calls for the terminating gateway. If the call is authorized, the settlement system generates a token that allows the terminating gateway to accept the call.
•Call detail reporting—Each endpoint in a call leg reports when the call stops, along with the usual call details. The settlement system reconciles the different reports of the calling and called parties and generates billing information. Call details are reported on a call-by-call basis.
Figure 1 shows a typical gateway based settlement network topology. A voice or fax call is originated and routed through the gateway (Cisco AS5300 access server, or Cisco 2600 or 3600 series routers) to a database server (RADIUS, TACACS+) for user authentication and intra-ISP call accounting. Using TCL IVR interactive voice response scripts to gather and manipulate the caller's data, the gateway forwards the call to the settlement server, which authorizes the call and adds settlement details in a token. The call, now carrying its unique settlement token, passes through the originating gateway to the terminating gateway. The terminating gateway uses TCL IVR to validate the settlement token and forwards the call to the receiving telephone or fax machine.
Note For a complete description of the Cisco Interactive Voice Respons (IVR) software feature, refer to the online documentation located in Cisco Connection Online (CCO).
When the call is completed, both the terminating and originating gateways communicate the call details to the settlement server. The settlement server then reconciles the information it receives about the call from both gateways.
Figure 1
Gateway-Based Settlement
Roaming
A caller is roaming when dialing into a gateway which is not the home gateway. A home gateway belongs to the user's service provider. Usually, the subscriber is billed with additional charges when making roaming calls The settlement server and the service provider need to know when a caller is or is not roaming in order to create accurate billing statements.
A roaming caller has to be authenticated before the call can go through the gateway. Both AAA and the settlement server can authenticate a roaming user. If AAA fails to authenticate a roaming caller, the roaming call has to be routed to a settlement server. If the settlement server can not authenticate the caller, the call is terminated.
The roaming feature is configured by the following:
•Setting the roaming patterns to determine if a caller is roaming
•Setting the roaming capability in the settlement provider
•Setting the roaming capability in the dial peer
•Forcing a call to be routed via a settlement server in a dial peer
Roaming User Identification
The gateway can specify a list of patterns to be matched with a user's account number to see if that user is roaming or not. The user enters the account number and PIN as part of the interaction with the TCL IVR prompts.
The roaming patterns are configured using the Global configuration mode command settlement roam-pattern. See settlement roam-pattern.
For additional information about the IVR or AAA and the E.164 addressing scheme, refer to the following Cisco IOS documents:
•Cisco Interactive Voice Response
•Service Provider Features for Voice over IP
Roaming Settlement Provider
Some settlement providers want to know if a user is roaming so the appropriate charge is applied to the user's account. Some settlement providers do not distinguish between local and roaming users.
The settlement provider interested in roaming users is configured with the roam command in the Settlement submode. See "Command Reference" on page 42.
If a user is roaming and the settlement provider is also enabled for roaming, the gateway sends the user's account number and PIN to the settlement server so that the user could be properly authenticated.
Roaming Dial Peer
A gateway can dictate if a particular outbound dial peer can terminate roaming calls or local calls only. This can be configured with the no roam command. See Command Reference.
•The default of the dial peer is not to support roaming. Therefore, this feature must be explicitly enabled in the dial peer.
•The gateway allows a roaming call to go through only if both the dial peer associated with that call and the settlement provider support roaming. In other words, a call fails if the dial peer has roaming enabled but the settlement provider doesn't. A call also fails if the settlement provider has roaming enabled but the dial peer does not.
Dial Peer Settlement Option
The command settle-call forces the call to go through a settlement server regardless of the session target type. If the session target type is ipv4, dns or RAS, the gateway resolves the terminating gateway address using one of these methods and asks the settlement server to authorize that terminating gateway. (TGW).
Note In Cisco IOS Release 12.1(1)T the session target command configuration can not combine the target of RAS with the settle-call command option. When configuring the VoIP dial peers for a settlement server, if session target type is settlement, the provider-number parameter in session target and settle-call should be identical.
The restrictions and behaviors associated with use of the settle-call command with outbound dial peers are described in another section of this document. See "Common Problems when Setting up Settlement" section for examples of the gateway behavior using different session target types and the settle-call flag.
PKI Multiple Roots
Cisco devices have the capability to share public keys using digital certificates. Digital certificates are normally issued by trusted third parties, who are called certificate Authorities (CA). Every participating router should enroll its public key with the CA server. During enrollment the Certificate Administrator (human) will manually verify if the requesting router is authentic and grant the certificate (some CA servers have the capability to authenticate the routers automatically).
A certificate has many fields which include a serial number, fingerprint and expiry date. Certificate can get revoked before its expiry because of key compromise or an other security reasons. The CA server maintains a list of revoked certificates, which is called Certificate Revocation List (CRL). Routers can be configured not to accept a peer certificate that is revoked. Router downloads CRL from the CA server for this purpose.
Cisco routers use a proprietary protocol CEP (Certificate Enrollment Protocol) to communicate with the CA server. The CA server should understand CEP.
The Multiple Roots feature is based on the Cisco security and public key infrastructure (PKI) technology. For in depth information about Security, see the Cisco Security Configuration Guide.
The multiple roots feature allows a settlement server to use one certificate for a Secure Socket Layer (SSL) handshake and a different certificate for token signing.
•For SSL handshake with the settlement server, the gateway uses the certificate obtained through the CLI command crypto ca identity name.
•For token verification, the gateway can use one of the root certificates configured with the command crypto ca trusted-root name.
•To specify which root certificate is used for token validation, use the command token-root-name in the settlement submode.
Note For a description of these new commands, see the "Command Reference" on page 42.
Benefits
•Enables Cisco Access platforms to provide Open Settlement Protocol (OSP) to Internet service providers
•Gives Internet service providers the ability to bid for the originating and terminating fee because the settlement software complies with OSP
•Offers a single authentication for the actual gateway or platform at initialization time
•Provides a secure interface between the settlement client and server
•Offers a choice of languages; therefore, the ISP can specify the currency with which to perform the transaction
Restrictions
•The Cisco Settlement for Packet Telephony feature requires Cisco IOS Release 12.1(1)T and the correct version of VCWare that is compatible with this version of the Cisco IOS software.
•The settlement feature cannot be enabled on dial peers that use RAS as the session target.
•The settlement software is offered only in crypto images and therefore is under export controls.
Related Features and Technologies
The Settlement for Packet Voice feature is dependent upon the interoperability of the following features:
•Interactive Voice Response (IVR)
The IVR feature uses audio files that manage the voice prompting and digit collection to gather caller information for authenticating the user and identifying the destination.
Refer to the Cisco Connection Online for Cisco IOS Release 12.0(7)T software features for the documentation.
•Certification Authority Interoperability
Ensure that this feature is functioning properly and configured as described in the task list. See "Configuration Tasks" on page 8. Additional configuration information is available in the Certification Authority Interoperability feature documentation on Cisco Connection Online (CCO).
Related Documents
Cisco Customer Documentation:
•Voice Features for Cisco 3600 Series Routers
•Certification Authority Interoperability
•Cisco Security Configuration Guide
•Cisco IP Security and Encryption Overview
Other Documentation:
•Token Card and Cisco Secure Authentication Support
•The SSL Protocol Version 3.0 as amended SSL 3.0 Errata of August 26, 1996
Supported Platforms
•Cisco AS5300 universal access servers
•Cisco AS5800 universal access servers
•Cisco 2600 series routers
•Cisco 3600 series routers
Supported Standards, MIBs, and RFCs
Standards
European Telecommunication Standards Institute (ETSI) Technical Specification (TS) 101 321
MIBS
No new or modified MIBSs are supported by this feature.
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites
•Ensure that your access platform has the following memory requirement:
16 MB Flash and 64 MB DRAM memory minimum.
•In Cisco IOS Release 12.0(4)XH or later release, both the originating and terminating gateways must be using the Integrated Voice Response TCL IVR scripts to perform settlement successfully. If a terminating gateway that is not configured with a TCL script receives settlement calls, it will not recognize the tokens added to those calls by the settlement server; therefore, those calls will pass through without being audited or charged.
•Ensure that the correct version of VCWare is downloaded to the Cisco AS5300 and Cisco Access Path platforms.
•Before configuring the settlement feature, you must have configured the Public Key Infrastructure (PKI) for secured communication between the access platform (or router) and the settlement server. For detailed information about Certificates and secure devices see the Cisco IOS Release 12.0 documentation titled Certification Authority Interoperability.
•Requires Cisco IOS Release 12.1(5)T for Cisco AS5800 support.
Note The Cisco AS5800 universal access server uses portware, not VCWare, with its modems.
Configuration Tasks
Before starting the settlement server configuration tasks, ensure that the Cisco Enrollment Protocol (CEP) router has obtained a security certificate. For detailed information, see the Certification Authority Interoperability documentation in the Cisco IOS Release 12.0 documentation set, or go to the online version.
Configuring Settlement for Packet Voice on Cisco access servers requires the following tasks:
• Configuring the Public Key Infrastructure
• Configuring the Originating Gateway
– Configuring the Settlement Provider
– Configuring the Inbound POTS Dial Peer
– Configuring the Outbound VoIP Dial Peer
• Configuring the Terminating Gateway
– Configuring the Settlement Provider
– Configuring the Inbound VoIP Dial Peer
– Configuring the Outbound POTS Dial Peer
• Configuring Settlement with Roaming
• Configuring Settlement with Multiple Roots
• Configuring Settlement with Suggested Route
Note When configuring a voice port use the following configuration designations:
For the Cisco AS5300 access server, port designation is port.
For the Cisco AS5800 access server, port designation is shelf/slot/port.
Configuring the Public Key Infrastructure
Note Ensure that you have secure communication between the access platform or router and the settlement server.
To configure the Public Key Infrastructure (PKI) use the following commands:
| |
Command
|
Purpose
|
Step 1
|
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#no crypto ca id name
|
Clears the old CA identity if a previous one exists.
|
Step 3
|
Router(config)#crypto key zeroize rsa
|
Clears the existing RSA key.
|
Step 4
|
Router(config)#hostname router-name
|
Configures the router's host name if this has not been done already.
|
Step 5
|
Router(config)#ip domain-name domain-name
|
Configures the router's IP domain name.
|
Step 6
|
Router(config)#ip host CA-hostname CA-ipaddress
|
Enters the CA host name and IP address.
|
Step 7
|
Router(config)#crypto ca identity name
|
Declares a Certification Authority (CA) name. For example, the tag-name could be fieldlabs.cisco.com
This command puts you into the ca-identity mode.
|
Step 8
|
Router(ca-identity)#enrollment url url
|
The /cgi-bin/pkiclient.exe file is the default cgi script that Cisco IOS software assumes. The script path should be given in the URL if it is different from the default.
Note The URL should have the format http://CA-hostname where CA-hostname is previously configured in the step above.
|
Step 9
|
Router(ca-identity)#enrollment retry count number
Optional
|
Specifies how many times the router will poll the CA server for the certificate status when the certificate requests are pending.
Note The router sends the certificate request only once. Then it periodically polls the CA server until the certificate is granted or denied, or until the retry count exceeds the retry count configured.
|
Step 10
|
Router(ca-identity)#enrollment retry period minutes
Optional
|
Specifies the interval between subsequent polls.
Default = 1 minute.
Note This is the two subsequent polls for certificate status. The router does not send another certificate request. It merely polls for the status as long as the CA server returns the certificate status as pending. Or until the retry count is reached.
Note After specifying a certificate, the router waits to receive a certificate from the CA. If the router doesn't receive a certificate within a period of time (the retry period), the router will send another certificate request.
|
Step 11
|
|
Exits CA-identify configuration mode.
|
Step 12
|
Router(config)#crypto ca authenticate name
|
Obtains the CA's public key. Use the same name that you used when declaring the CA with the crypto ca identity command.
|
Step 13
|
Router(config)#crypto key generate rsa
|
Generates the RSA key pair.
|
Step 14
|
Router(config)#crypto ca enroll name
|
Obtains the router certificate for all your RSA key pairs.
Note This command requires you to create a challenge password that is not saved with the configuration. This password is required if your certificate is revoked, so remember this password.
Note If your router reboots after you issued the crypto ca enroll command but before you received the certificate, you must reissue the command.
|
Configuring the Originating Gateway
Three tasks are actually involved in configuring the originating gateway:
•Configure the settlement provider so that the gateway knows where to direct the call authorization and call detail record.
•Configure the inbound POTS dial peer so that a TCL application will process the call (only TCL applications can settle the call).
•Configure the outbound VoIP dial peer so that the gateway will settle the call if necessary.
Configuring the Settlement Provider
To configure the service provider to authorize calls, use the following commands:
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#settlement number
|
Enters the Settlement configuration mode and configures the settlement provider number.
|
Step 3
|
Router(config-settlement)#type osp
|
Configures the settlement provider type.
|
Step 4
|
Router(config-settlement)#url url
|
Enters the settlement provider URL for the ISP hosting the settlement server.
Note This step can be repeated multiple times if the settlement provider has more than one service point.
|
Step 5
|
Router(config-settlement)#no shutdown
|
Brings up the settlement provider.
|
Note If you are configuring a TransNexus server, first enter the url <url>; then enter the customer-id and the device-id command.
Configuring the Inbound POTS Dial Peer
To configure the inbound POTS dial peer, enter the following commands:
Note In Step 3, do not use the default session application. The default "Session" application does not support settlement. Calls handled by the default session application are not routed to a settlement server. Settlement tokens are not validated in the default session application.
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#dial-peer voice number pots
|
Enters the dial-peer configuration mode to configure a POTS dial peer.
Note The number value of the dial-peer voice pots command is a tag that uniquely identifies the dial peer.
|
Step 3
|
Router(config-dial-peer)#application app name
|
Enters the application command; then enter the desired TCL script application name.
Note The application name must be the name of the TCL IVR script. If this application attribute is not configured, or if the POTS dial peer is not created, the default session application will process the call.
|
Step 4
|
Router(config-dial-peer)#destination-pattern
[+]string[T]
|
Configures the dial peer's destination pattern. Enter the number or pattern of the outbound called number.
The string is a series of digits that specify the E.164 or private dialing plan telephone number. Valid entries are the digits 0-9 and the letters A-D. The following special characters can be entered in the string:
•The plus symbol (+) can be used to indicate an E.164 standard number.
•The star character (*) and the pound sign (#) that appear on standard touch-tone dial pads can be used in any dial string. However, these characters cannot be used as leading characters in a string (for example, *650).
•The period (.) can be used as a trailing character, and is used as a wildcard character. Multiple periods as trailing characters indicate multiple wildcard digits, such as for the 789... wildcard.
•The comma (,) can be used only in prefixes, and is used to insert a one-second pause or delay.
The timer (T) character can be used to configure variable length dial plans.
|
Step 5
|
Router(config-dial-peer)#port port-number
|
Associates this voice-telephony dial peer with a specific voice port.
|
Configuring the Outbound VoIP Dial Peer
To configure the outbound VoIP dial peer, use the following commands:
| |
Command
|
Purpose
|
Step 1
|
Router(config)#dial-peer voice number voip
|
Enters the dial-peer configuration mode to configure the outbound VoIP dial peer.
|
Step 2
|
Router(config-dial-peer)# destination-pattern
[+]string[T]
|
Configurse the dial peer's destination pattern. Enter the number or pattern of the outbound called number.
The string is a series of digits that specify the E.164 or private dialing plan telephone number. Valid entries are the digits 0-9 and the letters A-D. The following special characters can be entered in the string:
•The plus symbol (+) can be used to indicate an E.164 standard number.
•The star character (*) and the pound sign (#) that appear on standard touch-tone dial pads can be used in any dial string. However, these characters cannot be used as leading characters in a string (for example, *650).
•The period (.) can be used as a trailing character, and is used as a wildcard character. Multiple periods as trailing characters indicate multiple wildcard digits, such as for the 789... wildcard.
•The comma (,) can be used only in prefixes, and is used to insert a one-second pause or delay.
The timer (T) character can be used to configure variable length dial plans
|
Step 3
|
Router(config-dial-peer)# session target settlement
[provider-number]
|
Enters settlement as the session target to resolve the terminating gateway address.
Note The provider-number value should match one of the number values previously configured in the task "Configuring the Settlement Provider" section .
|
Note The originating gateway's system clock must synchronize with the settlement server clock. Use the clock or ntp command to set the router clock.
Configuring the Terminating Gateway
Caution If the terminating gateway is not configured by using TCL IVR application scripts, the settlement tokens are bypassed, calls can get through, and settlement calls will not be audited; therefore, you will not be notified that the calls are not going through the billing service.
To configure the terminating gateway, complete the following tasks:
•Configure the Service Provider
•Configure the Inbound VoIP Dial Peer
•Configure the outbound POTS Dial Peer
Configuring the Settlement Provider
To configure the settlement provider, enter the following commands:
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#settlement number
|
Enters the Settlement configuration mode and configures the settlement provider number.
|
Step 3
|
Router(config-settlement)#type osp
|
Configures the settlement provider type.
|
Step 4
|
Router(config-settlement)#url url
|
Enters the settlement provider URL for the ISP hosting the settlement server.
Note This step can be repeated multiple times if the settlement provider has more than one service point.
|
Step 5
|
Router(config-settlement)#no shutdown
|
Brings up the settlement provider.
|
Note If you are configuring a TransNexus server, enter the url <url> command; then enter the customer-id and device-id command.
Configuring the Inbound VoIP Dial Peer
To configure the inbound VoIP dial peer, enter the following commands:
Note The default "Session" application does not support settlement. Calls handled by the default session application are not routed to a settlement server. Settlement tokens are not validated in the default session application.
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#dial-peer voice
number voip
|
Enters the dial-peer configuration mode to configure a VoIP dial peer.
|
Step 3
|
Router(config-dial-peer)#
application app-name
|
Enters the application command; then enter the desired TCL application name.
|
Step 4
|
Router(config-dial-peer)#
incoming called-number string
|
Specifies the telephone number of the voice port associated with this dial peer. Characters include wildcards to create the number or pattern.
|
Step 5
|
Router(config-dial-peer)# session
target settlement
[provider-number]
|
Enters settlement as the session target to resolve the terminating gateway address.
Note The <provider-number> value should match one of the <number> values previously configured in the "Configuring the Settlement Provider" section.
|
Configuring the Outbound POTS Dial Peer
To configure the outbound POTS dial peer, enter the following commands:
| |
Command
|
Purpose
|
Step 1
|
Router(config-settlement)#
dial-peer voice number pots
|
Enters the dial-peer configuration mode to configure the outbound POTS dial peer.
|
Step 2
|
Router(config-dial-peer)#
destination-pattern [+]string[T]
|
Configures the dial peer's destination pattern. Use the called number.
The string is a series of digits that specify the E.164 or private dialing plan telephone number. Valid entries are the digits 0-9 and the letters A-D. The following special characters can be entered in the string:
•The plus symbol (+) can be used to indicate an E.164 standard number.
•The star character (*) and the pound sign (#) that appear on standard touch-tone dial pads can be used in any dial string. However, these characters cannot be used as leading characters in a string (for example, *650).
•The period (.) can be used as a trailing character, and is used as a wildcard character. Multiple periods as trailing characters indicate multiple wildcard digits, such as for the 789... wildcard.
•The comma (,) can be used only in prefixes, and is used to insert a one-second pause or delay.
The timer (T) character can be used to configure variable length dial plans.
|
Step 3
|
Router(config-dial-peer)#port
port-number
|
Associates the voice-telephony dial peer with a specific voice port. Activate the voice port associated with this dial peer.
|
Note The terminating gateway system clock must synchronize with the settlement server clock. Use the clock or ntp command to set the router clock.
Verifying Settlement Configuration
Use the show running configuration command to verify your configuration. See Example of Settlement Configurations for Originating and Terminating Gateways.
Configuring Settlement with Roaming
To configure settlement with the roaming capability, three configuration tasks must be completed:
•On the originating gateway (OGW), configure the roaming patterns. See Table 1.
•On the OGW, turn on the roaming feature for the settlement provider configuration. See Table 2.
•On the OGW, turn on the roaming feature in the outbound dial peer servicing the numbers matching the roaming patterns. Table 3.
Table 1
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#settlement roam-pattern
pattern-roam
|
Defines the pattern for roaming account numbers. Enter multiple instances of this command to specify multiple patterns.
|
Step 3
|
Router(config-settlement)#exit
|
Exits the settlement submode.
|
Configure the Roaming Patterns on the OGW
Table 2
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#settlement number
|
Enters the Settlement mode and configure the settlement provider number.
|
Step 3
|
Router(config-settlement)#roaming
|
Enables the roaming capability on this provider.
|
Step 4
|
Router(config-settlement)#exit
|
Exits the Settlement submode.
|
Turn on the Roaming Feature for the Settlement Provider
Table 3
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#dial-peer voice number
voip
|
Enters the dial-peer configuration mode to configure a VoIP dial peer.
|
Step 3
|
Router(config-dial-peer)#roaming
|
Enables roaming on this dial peer.
|
Step 4
|
Router(config-dial-peer)#exit
|
Exits the dial-peer submode.
|
Turn on the Roaming Feature in the Outbound Dial Peer
See " Example Configuration of Settlement with Roaming," page 26.
Configuring Settlement with Multiple Roots
To configure the Multiple Roots capability, three configuration tasks must be completed:
•On the OGW, configure a settlement provider that uses one certificate for SSL and one certificate for token signing. See Table 4.
•On the TGW, configure the root certificate used by the server to sign the settlement token. See Table 5.
•On the TGW, specify which root certificate to validate the settlement token. See Table 6.
Table 4
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#settlement
provider-number
|
Enters settlement configuration mode for a specific provider.
|
Step 3
|
Router(config-settlement)#url URL
|
Enters the URL to the service point which uses two (2) different certificates for SSL and token.
|
Configure a Settlement Server with Multiple Roots on the OGW
Table 5
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#crypto ca trusted-root
root-name
|
Configures the root certificate the server uses to sign the settlement tokens.
|
Step 3
|
Router(ca-root)#root tftp
tftp-ipadress root-ca-file
|
Specifies where to obtain the root certificate file.
|
Step 4
|
Router(ca-root)#crypto ca authenticate
name
|
Starts downloading the root certificate file from the server.
|
Configure the Root Certificate for Token Validation on the TGW
Table 6
| |
Command
|
Purpose
|
Step 1
|
Router# configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)# settlement
provider-number
|
Enters settlement configuration mode for a specific provider.
|
Step 3
|
Router(config-settlement)#
token-root-name name
|
Specifies which root certificate the gateway uses to validate the token. The name must match the name of the certificate configured using either the crypto ca id name or the
crypto ca trusted-root name commands.
|
Define the Token Validation on the TGW
See "Example Configuration of Settlement with Multiple Roots" section.
Configuring Settlement with Suggested Route
The session target command in the dial peer dictates how the gateway resolves the terminating address to complete the call. Besides settlement, the gateway could use the ipv4 or dns options if it knows the exact address of the TGW, or it could use the ras option to consult a gatekeeper.
To force a call to be authorized by a settlement server, configure the following:
| |
Command
|
Purpose
|
Step 1
|
Router#configure terminal
|
Enters the global configuration mode.
|
Step 2
|
Router(config)#dial-peer voice number
voip
|
Enters the dial-peer configuration mode to configure a VoIP dial peer.
|
Step 3
|
Router(config-dial-peer)#settle-call
[provider-number]
|
Authorizes this call with a settlement provider.
|
Step 4
|
Router(config-dial-peer)#exit
|
Exits the dial-peer configuration mode.
|
Configuration Examples
Figure 2 shows example settlement configurations for both the originating and terminating gateways.
Note All IP addresses and patterns are examples only.
Figure 2 Example of Settlement Configurations for Originating and Terminating Gateways
See samples of screen output displays for running configurations:
• Example Configuration of Settlement on the Originating Gateway
• Example Configuration of Settlement on the Terminating Gateway
• Example Configuration of Settlement with Roaming
• Example Configuration of Settlement with Multiple Roots
Example Configuration of Settlement on the Originating Gateway
See the following output by using the running configuration command. Figure 2 is a graphic representation of the configuration.
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
destination-pattern 5551111
destination-pattern 5552222
session target settlement:0
ip address 172.22.65.131 255.255.255.224
ip route-cache same-interface
ip default-gateway 172.22.65.129
ip route 0.0.0.0 0.0.0.0 172.22.65.129
Example Configuration of Settlement on the Terminating Gateway
See the following output by using the running configuration command. See Figure 2 for a graphic representation of the configuration.
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
ip name-server 198.92.30.32
destination-pattern 5552222
incoming called-number 5552222
session target settlement:0
ip address 172.22.65.143 255.255.255.224
ip route-cache same-interface
ip default-gateway 172.22.65.129
ip route 0.0.0.0 0.0.0.0 172.22.65.129
snmp-server community public RO
Example Configuration of Settlement with Roaming
The following output is displayed when you enter the show running config command with roaming configured in the settlement server.
service timestamps debug datetime
service timestamps log datetime
no service password-encryption
enable secret 5 $1$lFSH$khsm3jB1lldHfXNlxqmaN1
ip host pkiserver 1.14.115.100
ip domain-name fieldlabs.cisco.com
ip name-server 172.16.1.4
isdn switch-type primary-5ess
isdn voice-call-failure 0
mta receive maximum-recipients 1024
crypto cisco algorithm des
crypto cisco algorithm 40-bit-des
crypto ca identity transnexus
enrollment retry count 100
enrollment retry period 2
enrollment url http://pkiserver:80
crypto ca certificate chain transnexus
3082024C 308201B5 02020171 300D0609 2A864886 F70D0101 04050030 6E310B30
09060355 04061302 55533110 300E0603 55040813 0747656F 72676961 31183016
06035504 0A130F54 72616E73 4E657875 732C204C 4C433114 30120603 55040B13
0B446576 656C6F70 6D656E74 311D301B 06035504 03131454 52414E53 4E455855
53204245 54412043 41203130 1E170D39 39303332 32313334 3630395A 170D3030
30333231 31333436 30395A30 6E310B30 09060355 04061302 55533110 300E0603
55040813 0747656F 72676961 31183016 06035504 0A130F54 72616E73 4E657875
732C204C 4C433114 30120603 55040B13 0B446576 656C6F70 6D656E74 311D301B
06035504 03131454 52414E53 4E455855 53204245 54412043 41203130 819F300D
06092A86 4886F70D 01010105 0003818D 00308189 02818100 B1B8ACFC D78F0C95
0258D164 5B6BD8A4 6F5668BD 50E7524B 2339B670 DC306537 3E1E9381 DE2619B4
4698CD82 739CB251 91AF90A5 52736137 658DF200 FAFEFE6B 7FC7161D 89617E5E
4584D67F F018EDAB 2858DDF9 5272F108 AB791A70 580F994B 4CA54F08 38C32DF5
B44077E8 79830F95 96F1DA69 4CAE16F2 2879E07B 164F5F6D 020301
