Table Of Contents
PacketCable and Event Message Provisioning and Operations Guide
(Cisco BTS 10200 Softswitch Release 4.4.x)
Overview
New PacketCable-Based Features and Functions for Release 4.4.x
CMS, MGC, and FEID Values and Billing Support Parameters
AUEP and ICMP Ping Options
Cisco BTS 10200 Softswitch In the PacketCable Network
PacketCable-Based Interfaces
Additional Network Interfaces
Gate Coordination Functions
Security Interface Features
Event Message Feature
Billing Data Options
Description of the Event Message Feature
Event Message Generation Details and Content
Timestamp Support for Event Messages
Event Message Transport
Event Message Storage on the CA
Planning
Installing
Configuring
Provisioning Basic PacketCable and DQoS Features
Provisioning CMS Parameters
Provisioning the CMS (Interfaces to the CMTS and eMTA)
Provisioning DQoS Parameters for Codec Negotiation Service
Provisioning TGCP Interfaces to TGW
Provisioning the Keepalive AUEP and ICMP Ping Options (Release 4.4.x and Later)
Provisioning Security Interfaces
Provisioning Parameters for Secured Media
Provisioning Security Interfaces to the MTA
Provisioning Security Interfaces to the CMTS
Provisioning Security Interfaces to the TGW
Provisioning Security Interfaces to the RKS
Provisioning IPsec Security Associations and Ciphersuite Algorithms
Provisioning Event Messages
Provisioning Support for EM Transmission and Storage
Provisioning the System to Generate EMs for Billing
Provisioning Media_Alive Verification for EMs
Operating
Status Command
Manual Recovery and Transfer of Stored EMs
Recovering the Billing Files
Sending Billing Files to the RKS via FTP
Comparing Checksums
Viewing Media_Alive Verification for EMs
EM Generation Details and Content
EM Generation Details
EM Content
Measurements
Creating Reports and Displays of Measurements
Measurements for the DQoS Feature on COPS Interface
Measurements for the EM Feature
Events and Alarms
Events and Alarms Specific to PacketCable-Based Network Elements
Events and Alarms for the EM Feature
Events and Alarms for the Security Interface Feature
Announcements
References
Related Documents
Industry Standards
PacketCable and Event Message Provisioning and Operations Guide
(Cisco BTS 10200 Softswitch Release 4.4.x)
This document describes how the Cisco BTS 10200 Softswitch implements PacketCable-based interfaces and functions. It also provides provisioning and operating information for PacketCable features and event messages (EMs). It is intended for use by service provider management, system administration, and engineering personnel who are responsible for designing, installing, configuring, and maintaining networks that use the Cisco BTS 10200 Softswitch system in a PacketCable-based network.
Note 
All of the features and functions described in this document are applicable to both Release 4.4.0 and Release 4.4.1, unless specifically noted. Release 4.4.x refers to both Release 4.4.0 and 4.4.1.
Feature History
Release
|
Modification
|
Release 4.4.x
|
Document #OL-6017-02: Notes were added referring to the BTS 10200 Softswitch Provisioning Guide and the Cisco BTS 10200 Softswitch Command Line Interface Guide. The document title and introduction were enhanced for clarity.
OL-6017-01:
•This document was reorganized for enhanced usability.
•References to PacketCable specifications were updated to a level consistent with CW27.
•The CLI commands for CMS, MGC, CDB, and EM identification in the Call Agent profile (call-agent-profile) table were updated.
•Commands related to AUEP and ICMP ping functionality were added
•Provisioning examples were updated as needed.
•Information was added in the Installation section on IPSEC_ENABLED parameter.
•Clarified GATE-OPEN and GATE-CLOSE procedures.
|
Release 4.2
|
New rule was added in the IPsec Policy (ipsec-policy) table for source and destination identifiers.
Spelling of the token name MAX-DQOS-SESSIONS was corrected.
|
Release 4.1
|
TGCP and IP security support were added.
•Provisioning commands, feature descriptions, and user interfaces were updated.
•Compliance matrices were removed from the scope of this document—these are now provided by the Cisco account team.
•Operational information about EMs was moved to Appendix B of this document.
•Wording of BILLING_EM_RETRANS measurement was updated.
•Caution was emphasized for storage of EMs on local CA disk when transmission to RKS is unsuccessful.
•Descriptions of ciphersuite tokens was clarified.
|
Release 3.5
|
New alarms were added for Release 3.5.
Updates, corrections and clarifications were added to this document.
|
Release 3.3
|
The PacketCable feature was introduced, including COPS, NCS, DQoS and EM support.
|
Overview
This section provides technical information about the implementation of PacketCable features. It covers the following topics.
•New PacketCable-Based Features and Functions for Release 4.4.x
•Cisco BTS 10200 Softswitch In the PacketCable Network
•Security Interface Features
•Event Message Feature
Note In this document, embedded multimedia terminal adapter (eMTA) refers to eMTAs using PacketCable Network-Based Call Signaling (NCS) protocol.
New PacketCable-Based Features and Functions for Release 4.4.x
This section describes the PacketCable-based features that are new in Release 4.4.x of the Cisco BTS 10200 Softswitch.
CMS, MGC, and FEID Values and Billing Support Parameters
In Release 4.4.x, the CMS ID, MGC ID, and FEID default values are modified. The billing support token dependencies (CDB and EM) are also modified. These tokens belong to the Call Agent Profile (call-agent-profile) table.
AUEP and ICMP Ping Options
Release 4.4.x adds a provisionable option for controlling Internet Control Message Protocol (ICMP) pings from the Cisco BTS 10200 Softswitch to the eMTAs.
Note Each eMTA is provisioned in the Cisco BTS 10200 Softswitch database using the Media Gateway (mgw) table.
If an audit endpoint (AUEP) ping is sent from the Cisco BTS 10200 Softswitch and fails to get a response from the eMTA, the Cisco BTS 10200 Softswitch can then send out an ICMP ping to the eMTA to detect IP connectivity. The service provider can provision the system in any of the following ways:
•Disable both AUEP and ICMP ping.
•Enable AUEP ping but not ICMP ping.
•Enable sending of an AUEP ping followed (if AUEP is unsuccessful) with an ICMP ping.
The following operational functions apply to the AUEP/ICMP feature:
•The Cisco BTS 10200 Softswitch performs the pings to the first termination provisioned in the Media Gateway (mgw) table for the applicable MGW (eMTA).
•If the AUEP attempt to the MGW fails and the ICMP also fails (or is disabled), the Cisco BTS 10200 Softswitch considers the link to the applicable MGW to be inactive.
•Alarm: SIGNALING #68—If ICMP ping is enabled, the Cisco BTS 10200 Softswitch stores the ICMP ping result as a dynamic field in the mgw table. If the AUEP ping fails, the alarm is generated only after the ICMP ping completes, and the SIGNALING alarm #68 contains the message "ICMP ping <success/fail/in progress/not performed>."
•Status MGW—If ICMP ping is enabled, and if the status command is issued for the mgw table, the system response contains the message "ICMP ping status <success/fail/in progress/not performed>."
Note If the ICMP ping is disabled, or if the ICMP ping status is not performed, the system responses to both the alarm and status queries show the ICMP ping status as "not performed."
The procedure for provisioning this option is provided later in this document ("Provisioning the Keepalive AUEP and ICMP Ping Options (Release 4.4.x and Later)" section).
Cisco BTS 10200 Softswitch In the PacketCable Network
The Cisco BTS 10200 Softswitch is a class-independent network-switching element. In a PacketCable-based network, it functions as both a call management server (CMS) and a media gateway controller (MGC). It provides call control, call routing, and signaling for several types of multimedia terminal adapters (MTAs) and embedded MTAs (eMTAs), cable modem termination systems (CMTSs), and trunking gateways (TGWs) in PacketCable-based networks. It provides interfaces to record keeping servers (RKSs) and key distribution centers (KDCs). The Cisco BTS 10200 Softswitch also communicates with announcement servers, SS7-based signaling gateways, MGCP-based media gateways (MGWs), and Session Initiation Protocol (SIP) networks.
Figure 1 shows a typical network with PacketCable-based network elements and the applicable external interfaces of the Cisco BTS 10200 Softswitch. In the PacketCable-based network, the Cisco BTS 10200 Softswitch performs the functions of both the CMS and MGC. The Cisco BTS 10200 Softswitch also provides provisionable options for customizing the external interfaces.
Figure 1 Example of PacketCable-Based Network Architecture
PacketCable-Based Interfaces
The Cisco BTS 10200 Softswitch supports signaling on specific PacketCable-based interfaces shown in Figure 1. The following list summarizes the supported protocols for each of the links:
•CMS/MTA (NCS)—CMS to MTA interface for subscriber access
•CMS/CMTS (COPS)—CMS to CMTS interface for gate management
•CMS/RKS (EM over RADIUS)—CMS to Record Keeping Server (RKS) interface for EM-based billing functions
•MGC/RKS (EM over RADIUS)—MGC to RKS interface for EM-based billing functions
•CMS/CALEA (EM over RADIUS)—CMS to CALEA server (DF) interface (Note: DF = Delivery Function)
•MGC/TGW (TGCP)—MGC to trunking gateway (TGW) interface for TGW management (which allows calls to be connected between the PacketCable network and the PSTN)
Note For a description of Cisco BTS 10200 Softswitch support for CALEA, see the Cisco BTS 10200 Softswitch System Description. For provisioning procedures related to CALEA support, see the Cisco BTS 10200 Softswitch Provisioning Guide.
Note For information on compliance to specific paragraphs of PacketCable standards and ECNs, contact your Cisco account team.
Additional Network Interfaces
The following additional interfaces are not part of the PacketCable feature set, but they provide other important functions useful in the service provider network.
•Cisco BTS 10200 Softswitch/Signaling Gateway (SIGTRAN)—This interface allows calls to be made between the PacketCable network and the PSTN. The Call Agent (CA) of the Cisco BTS 10200 Softswitch interfaces to an Internet transfer point (ITP) signaling gateway (SG), for example, the Cisco 7500 series router. The ITP SG provides an SS7-based interface to the STP (PSTN).
•MGCP Interface—The Cisco BTS 10200 Softswitch communicates with MGCP-based TGWs that provide bearer path to the PSTN.
•SIP Interface—Session Initiation Protocol (SIP) signaling is used for the following two functions:
–Communications with another CMS
–Access to voice mail
•Cisco BTS 10200 Softswitch /office applications (SNMPv3 and CORBA over TCP/IP)—
This interface provides communication with Operations Support System (OSS) and office applications servers.
Gate Coordination Functions
The Cisco BTS 10200 Softswitch performs the gate coordination functions of a CMS, including the gate controller (GC), in the PacketCable environment. GC signaling is based on the COPS stack. Each CMTS informs the CMS when a gate is successfully opened or closed. Two gate coordination messages are used, GATE-OPEN and GATE-CLOSE. Gate coordination is required to avoid several theft-of-service scenarios, as described in Appendix K of the PacketCable Dynamic Quality-of-Service Specification, PKT-SP-DQOS-I07-030815, August 15, 2003.
Note For information on compliance to specific paragraphs of PacketCable standards and ECNs, contact your Cisco account team.
GATE-OPEN Process
The normal coordination process for GATE-OPEN signaling is illustrated in Figure 2:
1. During call setup, the Cisco BTS 10200 Softswitch requests the MTA to commit bearer-path resources.
2. The MTA sends a Commit message to the CMTS to request opening of the gate on the bearer path.
3. The CMTS opens the gate and sends a GATE-OPEN message to the Cisco BTS 10200 Softswitch.
4. The Cisco BTS 10200 Softswitch allows the call.
Figure 2 Gate Coordination Signaling Example (GATE-OPEN)
Note If the GATE-OPEN message arrives at the Cisco BTS 10200 Softswitch before it has sent a resource-commit request to the MTA, the Cisco BTS 10200 Softswitch tears down the call.
GATE-CLOSE Process
During a call, if the Cisco BTS 10200 Softswitch receives a GATE-CLOSE message from the CMTS, it allows the call to proceed on a best-efforts basis, without a guaranteed level of service. (It tears down the call only when one of the parties in the call goes on-hook.)
Security Interface Features
Note For information on compliance to specific paragraphs of PacketCable standards and ECNs, contact your Cisco account team.
The implementation of PKT-SP-SEC-I09-030728, PacketCable Security Specification, July 28, 2003, provides a security scheme for the voice-over-cable network based on a set of security protocols. These protocols, based on the documents listed below, provide authentication (to help prevent theft of bandwidth, denial-of-service attack, replay, and so forth) and enable message integrity, privacy, and confidentiality.
•IETF documents covering IP security (IPsec) architecture:
–RFC 2401, Security Architecture for the Internet Protocol, IETF (S. Kent, R. Atkinson), Internet Proposed Standard, November 1998.
–RFC 2406, IP Encapsulating Security Payload (ESP), IETF (D. Piper), Internet Proposed Standard, November 1998.
•IETF documents covering key management protocols—Internet Key Exchange (IKE) and Kerberos with extensions:
–RFC 2409, The Internet Key Exchange (IKE), IETF (D. Harkins, D. Carrel), Internet Proposed Standard, November 1998.
–RFC1510, The Kerberos Network Authentication Service (V5), IETF (J. Kohl, C. Neuman), September 1993, with updates presented in PKT-SP-SEC-I09-030728.
The Cisco BTS 10200 Softswitch performs the security functions of a call management server (CMS) and media gateway controller (MGC) in the PacketCable environment. It supports security in accordance with PKT-SP-SEC-I09-030728 for both signaling and media:
•Signaling security—For signaling from CMS to eMTA, CMS to CMTS, and MGC to TGW
•Media (bearer) security—For signaling between originating eMTA and terminating eMTA, which is facilitated by the CMS during call signaling setup.
The system supports IP security (IPsec) features for encryption and authentication on specific PacketCable-based interfaces (see Figure 1). There are two aspects to the security features, the security protocol itself (IPsec), and the key management (Kerberos or IKE). The following list summarizes the supported security type for each of the links:
•CMS/MTA (NCS)—IPsec/Kerberos
•CMS/CMTS (COPS)—IPsec/IKE
•CMS/RKS (EM over RADIUS)—IPsec/IKE
•MGC/RKS (EM over RADIUS)—IPsec/IKE
•CMS/CALEA (EM over RADIUS)—IPsec/IKE
•MGC/TGW (TGCP)—IPsec/IKE
As shown in Figure 1, there is no interface between the KDC and the Cisco BTS 10200 Softswitch. To ensure secure NCS signaling, the dynamic key exchange for IPsec security operation between the MTA and the Cisco BTS 10200 Softswitch is achieved as follows. (These procedures are described in the CableLabs document PacketCable Security Specification, PKT-SP-SEC-I09-030728, under "Kerberized IPsec" and other sections.)
•Manual key provisioning must be used to match data stored in the KDC with data stored in the Cisco BTS 10200 Softswitch (pre-setup).
•The MTA must contact the KDC to obtain the credentials to talk to the server, which is in this case the Cisco BTS 10200 Softswitch.
Note For information on compliance to specific paragraphs of PacketCable standards and ECNs, contact your Cisco account team.
Note See the "Installing" section regarding the requirement for setting the IPSEC_ENABLED parameter at the time of Cisco BTS 10200 Softswitch software installation.
Event Message Feature
This section describes Cisco BTS 10200 Softswitch support for the event message (EM) feature.
Billing Data Options
The Cisco BTS 10200 Softswitch has the ability to provision billing support using either of the following billing data generation methods:
•Call Detail Blocks (CDBs)—This is traditional post-call billing data, which is assembled into Call Detail Records (CDRs) by an external billing mediation system or billing server.
•PacketCable event messages (EMs)—This is real-time call data flow, which is transferred to an external Record Keeping Server (RKS) that assembles CDRs from the EMs.
The Cisco BTS 10200 Softswitch should be provisioned to generate either EMs or CDBs, but not both.
Caution Cisco strongly recommends that you provision the Cisco BTS 10200 Softswitch to generate either EMs or CDBs, but not both. Attempting to generate both types of records simultaneously can significantly degrade system performance. See the
"Provisioning the System to Generate EMs for Billing" section for provisioning details.
Note The contents of CDBs is outside the scope of this document. See the Cisco BTS 10200 Softswitch Billing Interface Guide for information about CDBs.
Description of the Event Message Feature
EMs are real time data records containing information about network usage and activities. (They must not be confused with system event messages that report events and sometimes trigger alarms.) EMs are used in PacketCable networks to collect resource usage data for billing purposes. In the PacketCable architecture EM generation is based on the half-call model. A single EM can contain a complete set of usage data or it might contain only part of the usage information.
The Record Keeping Server (RKS) is a PacketCable network element that receives EMs from network elements, such as the Call Management Server (CMS), Media Gateway Controller (MGC), and the Cable Modem Termination System (CMTS). The physical Cisco BTS 10200 Softswitch contains both CMS and MGC logical network elements. The EMs generated by both the CMS and MGC are sent to the RKS. The RKS correlates the information in multiple EMs and provides the complete record of service for a call, which is referred to as a Call Detail Record (CDR).
Note For information about EM-related operations on the Cisco BTS 10200 Softswitch, see to the "EM Generation Details and Content" section.
Figure 3 illustrates the PacketCable network elements that are involved in the EM process.
Figure 3 Event Message Interfaces
The EM related interfaces illustrated here are described as follows:
1. MGC to RKS—EMs generated by MGC (Cisco BTS 10200 Softswitch) are sent to RKS
2. CMS to RKS—EMs generated by CMS (Cisco BTS 10200 Softswitch) are sent to RKS
3. CMTS to RKS—EMs generated by CMTS are sent to RKS. The Cisco BTS 10200 Softswitch (MGC/CMS) is not involved
4. CMS to CMTS—CMS (Cisco BTS 10200 Softswitch) sends the Billing Correlation ID (BCID) to the CMTS using the DQoS GateSet message
5. CMS to MGC—An internal exchange of originating/terminating information such as BCID and FEID.
PacketCable EMs can support billing and settlement activities for single-zone architectures. The originating and terminating CMSs exchange unique Billing Correlation IDs (BCIDs) and Financial Entity IDs (FEIDs) for each half of the call. The originating CMS sends a BCID and an FEID in the INVITE message. The Cisco BTS 10200 Softswitch allocates the BCID for calls it originates or terminates. Along with the FEID, the BCID is used across network elements to reference calls. The FEID is provisioned on a system-wide basis (a single setting for the Cisco BTS 10200 Softswitch) as defined in the "Provisioning the System to Generate EMs for Billing" section.
Event Message Generation Details and Content
See the "EM Generation Details and Content" section for information on EM data.
Timestamp Support for Event Messages
The system-generated timestamps for EMs are based on the host operating system (OS) time and time zone. This data is not affected by CLI provisioning. The Solaris OS obtains the time automatically through network time protocol (NTP) services.
Caution Users should never attempt to modify the system date or time in their Cisco BTS 10200 Softswitch host machines while system components (CA, FS, EMS, and BDMS) are running. This could cause the system to have serious problems. Allow the Solaris OS to obtain the time automatically through NTP services.
Event Message Transport
The RADIUS transport protocol is used between the Cisco BTS 10200 Softswitch (CMS/MGC) and the RKS. EMs are sent to an RKS without waiting for acknowledgement of the previous message. The maximum number of pending ACK messages is 256.
EMs are first sent to the primary RKS and, after the specified number of retry attempts fail, they are sent to the secondary RKS. If one RKS is found to be unreachable, then the other RKS is considered for subsequent messages. If both the primary and secondary RKS become unreachable, the EMs are stored in an error file on the hard disk (as described in the "Event Message Storage on the CA" section) and a timer is started. When the timer expires, newly-arriving EMs will be sent to the primary RKS.
Note If EMs are being sent to the primary RKS, and the primary RKS goes down, the Cisco BTS 10200 Softswitch sends subsequent EMs to the secondary RKS. When the primary RKS comes back up, the Cisco BTS 10200 Softswitch will continue to send EMs to the secondary RKS. (It will not automatically begin sending them to the primary RKS.) Provisioning of timers and retry attempts is described in the "Provisioning Support for EM Transmission and Storage" section.
Note Remote Access Dial-In User Service (RADIUS) is a client/server protocol used for Authorization, Authentication, and Accounting (AAA). The RADIUS protocol is an industry standard for remote access AAA defined in a set of Internet Engineering Task Force (IETF) standards: RFC 2865 and RFC 2866.
Event Message Storage on the CA
Note For information on compliance to specific paragraphs of PacketCable standards and ECNs listed in this document, contact your Cisco account team.
EMs are stored in the network element (CA) that generates them until successful transfer to the RKS. Once receipt of the EMs is acknowledged by the RKS, they are deleted. The number of EMs generated by the Cisco BTS 10200 Softswitch depends on the number of calls processed. Multiple EMs are generated for each call. Depending on provisioning in the call-agent-profile table, and the type of call, EMs can be generated by the CMS or MGC (or both) within the CA. The exact storage requirement varies depending on the rate of EM generation and how long the Cisco BTS 10200 Softswitch is required to keep the records before transferring them to an RKS.
The Cisco BTS 10200 Softswitch generates and stores EMs with the following characteristics:
•EMs are generated in real time during a call. EMs contain timestamps with a granularity of 1 millisecond. The time interval between generation and transmission is not specified.
•The Cisco BTS 10200 Softswitch synchronizes with the network clock using NTP at least once per hour. The deviation of the clock in the Cisco BTS 10200 Softswitch remains within ± 100 milliseconds between NTP synchronizations.
•EMs that cannot be successfully transferred to the RKS due to loss of communication are stored in the /opt/BTSem directory on the CA. The system uses the file naming conventions specified in the PacketCable Event Messages Specification (PKT-SP-EM-I07-030815) for the stored EMs. The maximum EM file size, and the time limit on keeping a file open, are provisionable as described in the "Provisioning Support for EM Transmission and Storage" section. These files are not automatically deleted nor transferred out of the CA—the operator must transfer these files to the RKS when communication is restored. The procedure for doing this is provided in the "Manual Recovery and Transfer of Stored EMs" section.
Caution Event messages that cannot be successfully transferred to the RKS due to loss of communication are not automatically deleted nor transferred out of the CA.
You must transfer these files to the RKS when communication is restored.
The procedure for doing this is provided in the
"Manual Recovery and Transfer of Stored EMs" section.
•Each time an EM file is placed in local storage, the system checks current disk usage and takes the following actions:
–The system generates an alarm if the disk space allocated to EMs fills up to a certain level—
50% (Minor alarm), 70% (Major alarm), or 100% Critical alarm.
–When the critical condition is reached, and after raising the critical alarm, further EMs are dropped without any additional warning.
–When the critical condition is reached, the disk usage is monitored periodically (one time every minute) to check if disk space usage has decreased and EMs can be stored again.
Planning
Delivery of the features and functions described in this document requires interoperability with the network elements connected to the Cisco BTS 10200 Softswitch. See the "Component Interoperability" section in the Cisco BTS 10200 Softswitch Release Notes, which lists the specific peripheral platforms, functions, and software loads that have been tested by Cisco for interoperability with the Cisco BTS 10200 Softswitch.
Note The "Component Interoperability" section in the Cisco BTS 10200 Softswitch Release Notes is intended as a guide. Earlier or later releases of platform software might be interoperable and it might be possible to use other functions on these platforms. The list certifies only that the required interoperation of these platforms, the functions listed, and the protocols listed have been successfully tested with the Cisco BTS 10200 Softswitch.
Installing
Installation of Cisco BTS 10200 Softswitch software follows a standard process. For details, see the Application Installation Procedure in the Cisco BTS 10200 Softswitch documentation set. Of the three main PacketCable feature areas (DQoS, EM, and security), two of them (DQoS and EM) are always installed, and do not require the setting of any special flags during software installation. However, the third area (security) is not installed unless a special flag (IPSEC_ENABLED) is set in the opticall.cfg file during software installation.
Caution Cisco strongly recommends that you contact Cisco TAC if you believe that you may need to reinstall Cisco BTS 10200 Softswitch software in order to change the value of IPSEC_ENABLED.
Configuring
This section explains how to perform the following procedures:
•Provisioning Basic PacketCable and DQoS Features
•Provisioning Security Interfaces
•Provisioning Event Messages
Tip These tasks include examples of CLI commands that illustrate how to provision the specific feature. Most of these tables have additional tokens that are not included in the examples. For a complete list of all CLI tables, tokens, descriptions, valid ranges, and default values, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.
Note The command sequences shown in this section provide guidance on how to provision a new system. Therefore, in most cases the commands are "add" commands. If you are modifying previously-provisioned GWs, TGs, and so forth, use the "change" commands.
Provisioning Basic PacketCable and DQoS Features
This section describes how to provision the Cisco BTS 10200 Softswitch interfaces to connect to other PacketCable-based NEs, and how to select dynamic quality of service (DQoS) options. It includes the following tasks:
•Provisioning CMS Parameters
•Provisioning the CMS (Interfaces to the CMTS and eMTA)
•Provisioning DQoS Parameters for Codec Negotiation Service
•Provisioning TGCP Interfaces to TGW
•Provisioning the Keepalive AUEP and ICMP Ping Options (Release 4.4.x and Later)
Provisioning CMS Parameters
This section describes how to provision DQoS functionality for the CMS logical entity on the Cisco BTS 10200 Softswitch (Call Agent).
SUMMARY STEPS
1. Enable DQoS support—change call-agent-profile.
2. Set CMS timers in Call Agent Configuration (ca-config) table (optional, if using other than the default values)—change ca-config.
3. Set the local ringback flag, differential service code point (DSCP)/type of service (TOS) parameter, and maximum MGCP datagram sizes in the ca-config table (optional, if using other than the default values)—change ca-config.
Note The token values shown in this section are examples.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
CHANGE CALL-AGENT-PROFILE
Example:
change call-agent-profile id=CA146;
dqos-supp=y; description=BostonCA33
|
Enables DQoS support.
Tip The command is shown as change call-agent-profile ... . However, if the system responds that the call-agent-profile ID does not exist, reenter the command as add call-agent-profile.
|
Step 2
|
CHANGE CA-CONFIG
Example:
CHANGE CA-CONFIG TYPE=DQOS-T1-TIMER;
DATATYPE=INTEGER; VALUE=250;
CHANGE CA-CONFIG TYPE=DQOS-DS-SLACK-TERM;
DATATYPE=INTEGER; VALUE=30000;
CHANGE CA-CONFIG TYPE=DQOS-GATE-TIMER;
DATATYPE=INTEGER; VALUE=3;
|
Specifies values other than the defaults for individual CMS timers in the ca-config table. The applicable timers are DQOS-T1-TIMER, DQOS-T5-TIMER, DQOS-T7-TIMER, DQOS-T8-TIMER, DQOS-DS-SLACK-TERM, DQOS-US-
SLACK-TERM, and DQOS-GATE-TIMER.
Tip The default values for these timers may be adequate for your specific case. In each case, you can use the show command to find out how the parameter is currently set. See the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide for parameter definitions and valid ranges.
Tip The command is shown as change ca-config ... . However, if the system responds that the parameter does not exist, reenter the command as add ca-config.
|
Step 3
|
CHANGE CA-CONFIG
Example:
CHANGE CA-CONFIG TYPE=LOCAL-RINGBACK;
DATATYPE=BOOLEAN; VALUE=N;
CHANGE CA-CONFIG TYPE=COPS-DSCP-TOS;
DATATYPE=INTEGER; VALUE=240;
CHANGE CA-CONFIG TYPE=MAX-MGCP-DATAGRAM;
DATATYPE=INTEGER; VALUE=3900;
|
Specifies additional ca-config parameters that can be set to values other than the defaults.
Tip The default values for these parameters may be adequate for your specific case. In each case, you can use the show command to find out how the parameter is currently set. See the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide for parameter definitions and valid ranges.
Note The MAX-MGCP-DATAGRAM parameter specifies the maximum size of an MGCP message datagram (that may include one or more piggybacked messages) the Cisco BTS 10200 Softswitch could decode before discarding the rest of the message part. The default value of 4000 bytes is adequate for most applications, and Cisco does not recommend that you change this value unless you are deploying MGCP-based media gateways or MTAs that require larger datagram sizes.
|
Provisioning the CMS (Interfaces to the CMTS and eMTA)
This section describes how to provision the interfaces to the CMTS and eMTA nodes:
•CMTS—The Aggregation (aggr) table defines the parameters for the connected CMTS devices. These parameters are used by the COPS adapter to establish and terminate TCP connections to the CMTS.
•MTA (or eMTA)—The Cisco BTS 10200 Softswitch uses the Media Gateway Profile (mgw-profile), mgw, and termination tables to establish and terminate connections to the eMTAs. The supported MGCP variant is NCS.
–The mgw-profile table provides templates for defining each type of eMTA by hardware vendor. It identifies the specifications and settings necessary for communications between the Cisco BTS 10200 Softswitch (which functions as the CMS) and each type of eMTA. A mgw-profile ID must be created in this table before entries can be added to the mgw table. Several tokens have values that can be overwritten after the Cisco BTS 10200 Softswitch (CMS) queries the eMTA for supported capabilities. If the eMTA returns a value different from the value originally provisioned in the Cisco BTS 10200 Softswitch, the returned value automatically replaces the originally provisioned value.
–The mgw table holds information about each eMTA managed by the Cisco BTS 10200 Softswitch (CMS). The eMTA can be uniquely addressed by domain name, an IP address, or the TSAP address.
–The termination table holds information about each endpoint in eMTAs managed by the CMS. Termination events and signals are grouped into packages, which are groupings of events and signals supported by a particular type of endpoint, such as an eMTA endpoint. One or more packages can exist for a given endpoint-type.
SUMMARY STEPS
1. Create the CMTS and enable DQoS support—add aggr.
2. Create the profile for eMTA and specify the appropriate parameters—add mgw-profile.
3. Verify that all parameters affecting eMTAs are properly populated, either by default or by the operator—show mgw-profile.
4. Modify parameters affecting eMTAs, if necessary—change mgw-profile.
5. Create the specific eMTA, associate it with the applicable CMTS, and set appropriate parameters—add mgw.
6. Add the line termination for an eMTA—add termination.
7. Bring the eMTA into service—control mgw.
8. Equip the termination and place it in service— equip/control subscriber-termination.
Note The token values shown in this section are examples.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
ADD AGGR
Example:
add aggr id=cmts777;
tsap-addr=ADDRESS123.cisco.com;
dqos-supp=Y;
|
Creates the CMTS (aggregation device) and enables DQoS support.
Note The TSAP-ADDR can be a DNS or IP address. If you enter a DNS address, it must be a fully qualified domain name (FQDN).
Caution DQoS is disabled (DQOS-SUPP=N) by default. Set this value to Y to enable DQoS.
|
Step 2
|
ADD MGW-PROFILE
Example:
add mgw-profile id=mgwprofile777;
mgcp-version=MGCP-1-0; mgcp-variant=NCS-1-0;
mgcp-default-pkg=LINE;
mgcp-conn-id-at-gw-supp=n;
|
Creates the mgw-profile for this type of eMTA, and specifies values for the optional parameters.
Tip The default values for these parameters may be adequate for your specific case. In each case, you can use the show command to find out how the parameter is currently set. See the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide for parameter definitions and valid ranges.
|
Step 3
|
SHOW MGW-PROFILE
Example:
show mgw-profile id=mgwprofile777;
Verify that the following values are present:
vendor=Cisco [or applicable vendor name]
mgcp-version=MGCP-1-0
mgcp-variant=NCS-1-0
mgcp-default-pkg=LINE
codec-neg-supp=y
pc-mptime-supp=y
mgcp-xdlcx-supp=n
domain-name-caching-supp=y
mgcp-conn-id-at-gw-supp=y
|
Shows the provisioned values for the parameters in the mgw-profile table.
|
Step 4
|
CHANGE MGW-PROFILE
Example:
change mgw-profile id=mgwprofile777;
mgcp-version=MGCP-1-0; mgcp-variant=NCS-1-0;
|
If any of the mgw-profile token values need to be changed, use the change mgw-profile command.
|
Step 5
|
ADD MGW
Example:
add mgw id=CiscoGW50;
tsap-addr=192.168.26.104; call-agent-id=CA146;
mgw-profile-id=mgwprofile777; type=rgw;
aggr-id=cmts777;
|
Creates the MGW ID for a single eMTA, and specifies values for the other required parameters.
Note Be sure to set TYPE=RGW for an eMTA.
Note You must enter the value for AGGR-ID to identify the appropriate CMTS for this eMTA.
|
Step 6
|
ADD TERMINATION
Example:
add termination prefix=aaln/; port-start=1;
port-end=2; type=LINE; mgw-id=CiscoGW50;
|
Creates the line termination for the eMTA, and specifies values for the required parameters.
Note For eMTA terminations, always enter TYPE=LINE.
|
Step 7
|
CONTROL MGW
STATUS MGW
Example:
CONTROL MGW ID=CiscoGW50; TARGET-STATE=INS;
MODE=FORCED;
STATUS MGW ID=CiscoGW50;
Verify that the system responds that the administrative state is in service (INS).
|
Brings the eMTA in service (INS state), and verifies it is INS.
|
Step 8
|
EQUIP SUBSCRIBER-TERMINATION
CONTROL SUBSCRIBER-TERMINATION
STATUS SUBSCRIBER-TERMINATION
Example:
EQUIP SUBSCRIBER-TERMINATION ID=sub3456;
CONTROL SUBSCRIBER TERMINATION ID=sub3456;
TARGET-STATE=INS; MODE=FORCED;
STATUS SUBSCRIBER TERMINATION ID=sub3456;
Verify that the system responds that the administrative state is in service (INS).
|
Equips the termination, places it in service (INS state), and verifies it is INS.
|
Provisioning DQoS Parameters for Codec Negotiation Service
The Quality of Service (qos) table is used in providing the codec negotiation service. Codec negotiation is the process the Cisco BTS 10200 Softswitch uses to find a common codec for the compression or decompression of a signal between two gateways. The Subscriber Profile (subscriber-profile) and Subscriber (subscriber) tables point to the qos table.
The following commands allow you to specify the required characteristics for these tables.
SUMMARY STEPS
1. Provision QOS parameters—add qos.
2. Assign a specific QOS to each subscriber-profile or subscriber—
add subscriber-profile; add subscriber.
Note The token values shown in this section are examples.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
ADD QOS
Example:
add qos id=Gold1; codec-type=PCMU;
|
Adds a qos with the preferred codec type and other parameters.
|
Step 2
|
ADD SUBSCRIBER-PROFILE
ADD SUBSCRIBER
Example:
add subscriber-profile id=NorthDallas;
dial-plan-id=dp1; POP=BLDG222; qos-id=Gold1;
add subscriber id=Person29; dn1=800-555-0029;
sub-profile-id=richardson;
add subscriber id=Person123; dn1=800-555-0123;
sub-profile-id=richardson; qos-id=Gold1;
|
Assigns a qos ID to each subscriber-profile and/or subscriber.
|
Provisioning TGCP Interfaces to TGW
This section describes how to provision the TGCP interfaces to the TGWs.
Note The mgw-profile table provides templates for defining each type of TGW by hardware vendor. It identifies the specifications and settings necessary for communications between the Cisco BTS 10200 Softswitch (which functions as the MGC) and each type of TGW. Several tokens in this table have values that can be overwritten after the Cisco BTS 10200 Softswitch (MGC) queries the TGW for supported capabilities. If the TGW returns a value different from the value originally provisioned in the Cisco BTS 10200 Softswitch, the returned value automatically replaces the originally provisioned value.
SUMMARY STEPS
1. Enable TGCP support for each type of TGW—add mgw-profile.
2. Link each TGW to a mgw-profile—add mgw.
3. Add the trunk termination for a TGW—add termination.
4. Provision QOS parameters—add qos.
5. Assign a QOS-ID to the TGW—add trunk-grp.
Note The token values shown in this section are examples.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
ADD MGW-PROFILE
Example:
add mgw-profile id=tgwprf222; vendor=cisco;
mgw-type=MGX8850; mgcp-version=MGCP-1-0;
mgcp-variant=TGCP-1-0; mgcp-default-pkg=TRUNK;
pc-mptime-supp=y;
|
Creates a mgw-profile for this type of TGW, and specifies values for required parameters.
Note For most TGWs, set PC-MPTIME-SUPP to Y. However, for a Cisco MGX8850 VISM gateway, the MP function is not available. Therefore, set the PC-MPTIME-SUPP token to N for a Cisco MGX8850 VISM gateway.
Note Be sure to set the following values for a TGW:
MGCP-VERSION=MGCP-1-0
MGCP-VARIANT=TGCP-1-0
MGCP-DEFAULT-PKG=TRUNK
|
Step 2
|
ADD MGW
Example:
add mgw id=tgw50; tsap-addr=TGW1515.cisco.com;
call-agent-id=CA146; mgw-profile-id=tgwprf222;
type=tgw;
|
Links a specific TGW to the applicable mgw-profile.
Note Be sure to set TYPE=TGW.
|
Step 3
|
ADD TERMINATION
Example:
add termination prefix=S0/ds1-2/;
mgw-id=tgw50; port-start=1; port-end=24;
type=TRUNK;
|
Creates trunk terminations for the TGW.
Note Be sure to set TYPE=TRUNK.
|
Step 4
|
ADD QOS
Example:
add qos id=gold-service; lptime=20; hptime=20;
codec-type=PCMU;
|
Adds a qos with the preferred codec type and other parameters.
|
Step 5
|
ADD TRUNK-GRP
Example:
add trunk-grp id=101; call-agent-id=CA146;
tg-type=ss7; qos-id=gold-service;
mgcp-pkg-type=IT;
|
Assigns a qos ID to each TRUNK-GRP.
Note For trunk groups on TGCP-based TGWs (MGCP-VARIANT=TGCP-1-0 in the mgw-profile table), set the MGCP-PKG-TYPE value to IT (ISUP trunk package).
|
Provisioning the Keepalive AUEP and ICMP Ping Options (Release 4.4.x and Later)
This section explains how to provision the keepalive AUEP and ICMP ping options. There are two tokens to provision:
•AUEP and ICMP pings can be globally disabled on the system using the mgw-monitoring-enabled token in the Call Agent (call-agent) table.
•If globally enabled in the call-agent table, these pings can be selectively enabled or disabled for each mgw-profile using the keepalive-method token in the mgw-profile table. Each MGW (eMTA) is linked to a mgw-profile using the mgw table.
SUMMARY STEPS
1. Show the setting for mgw-monitoring-enabled—show call-agent.
2. If necessary, change the value of mgw-monitoring-enabled—change call-agent.
3. Show the setting for keepalive-method—show mgw-profile.
4. If necessary, change the value of keepalive-method—change mgw-profile.
5. Link individual MGWs (eMTAs) to MGW profiles—add mgw.
Note If mgw-monitoring-enabled=Y (the default value) in the call-agent table, the system checks the provisioning of the keepalive-method token in the mgw-profile table for each MGW.
However, if mgw-monitoring-enabled=N, both AUEP and ICMP ping are globally disabled, and the keepalive-method token is not checked.
Note The token values shown in this section are examples. In addition, these tables have many additional optional tokens not shown in these examples. For a complete list of all the tokens for each table, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
SHOW CALL-AGENT
Example:
SHOW CALL-AGENT ID=CA146;
The system responds with the current settings for the call-agent table. The default value of MGW-MONITORING-ENABLED is Y.
|
Show the setting for mgw-monitoring-enabled in the call-agent table.
|
Step 2
|
CHANGE CALL-AGENT
Example:
change call-agent id=CA146;
tsap-addr=sim-CA146.cisco.com;
mgw-monitoring-enabled=Y;
|
If the current value of mgw-monitoring-enabled is N, use this command to change it to Y. (Otherwise, skip to Step 3.
|
Step 3
|
SHOW MGW-PROFILE
Example:
show mgw-profile id=mgwprofile001;
The system responds with the current settings for the mgw-profile table.
|
Show the setting for keepalive-method in the mgw-profile table.
|
Step 4
|
CHANGE MGW-PROFILE
Example:
change mgw-profile id=mgwprofile001;
keepalive-method=<value (see options)>;
change mgw-profile id=mgwprofile001;
keepalive-method=auep-icmp;
|
If necessary, change the value of keepalive-method in the mgw-profile table.
The options for keepalive-method are:
•none—Disable both AUEP and ICMP ping.
•auep—Enable AUEP ping but not ICMP ping (this is the default value).
•auep-icmp—Enable sending of an AUEP ping followed (if AUEP is unsuccessful) with an ICMP ping.
|
Step 5
|
ADD MGW
Example:
add mgw id=mgw_abc;
mgw-profile-id=mgwprofile001;
|
Links an individual MGW (eMTA) to a mgw-profile.
|
Provisioning Security Interfaces
This section describes the PacketCable-based security interface feature and how to provision security options. The subsections are as follows:
•Provisioning Parameters for Secured Media
•Provisioning Security Interfaces to the MTA
•Provisioning Security Interfaces to the CMTS
•Provisioning Security Interfaces to the TGW
•Provisioning Security Interfaces to the RKS
•Provisioning IPsec Security Associations and Ciphersuite Algorithms
Note A global security parameter, IPSEC_ENABLED, must already be set in the initial configuration file (opticall.cfg) during the Cisco BTS 10200 Softswitch software installation process. This parameter enables or disables the IPsec feature on the Cisco BTS 10200 Softswitch. See the detailed requirement in the "Installing" section.
Provisioning Parameters for Secured Media
This section describes how to provision the SECURED-MEDIA-ONLY flag, which affects transmission of security parameters from the qos and ciphersuite tables when connecting a call. This parameter affects the setup of calls to unsecured MGWs.
SUMMARY STEPS
1. Show the current setting of the SECURED-MEDIA-ONLY flag—show ca-config.
2. If necessary, change the value of the secured media flag—change ca-config.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
SHOW CA-CONFIG
Example:
SHOW CA-CONFIG TYPE=SECURED-MEDIA-ONLY;
|
Displays the current setting of the secured-media-only flag:
•If set to Y, the Cisco BTS 10200 Softswitch forces the security parameters from the qos and ciphersuite tables to the endpoint while making the connection. This may result in call failure if either side cannot handle these parameters.
•If set to N, the Cisco BTS 10200 Softswitch forces the security parameters from the qos and ciphersuite tables while making the connection to the endpoint only if both sides can handle the security parameters.
|
Step 2
|
CHANGE CA-CONFIG
Example:
CHANGE CA-CONFIG TYPE=SECURED-MEDIA-ONLY;
DATATYPE=BOOLEAN; VALUE=Y;
|
If necessary, change the setting of the secured-media-only flag.
Caution Do not change this value unless specified by your network administrator. This command can affect the setup of calls to unsecured MTAs.
|
Provisioning Security Interfaces to the MTA
The MTA is the only device class that uses Kerberos key management. This section explains how to provision the MTA IP security (IPsec) interface, including:
•Provisioning Kerberos
•Provisioning IPsec policy
•Enabling IPsec
Note The token values shown in this section are examples. For detailed token descriptions, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.
SUMMARY STEPS
1. Provision Kerberos parameters—add ipsec-kerberos.
2. Display the rolling list of old Kerberos service keys—show ipsec-kerberos-keys (optional).
3. Add an IPsec policy for all incoming and outgoing traffic on the MTA—add ipsec-policy.
4. Enter values for additional security parameters—change mgw-profile (optional).
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
ADD IPSEC-KERBEROS
Example:
add ipsec-kerberos
krb-fqdn=cms-ca1.ciscolab.com;
krb-realm=cisco-realm.com;
krb-srv-key=546869732069732061206b6579206f6620
3234206368612e; srv-key-version=12345;
|
Provisions Kerberos parameters.
Note The KRB-FQDN must be the FQDN used on the KDC for this node.
KRB-REALM is used to create the CMS principal name.
•If the krb-serv-key is changed, the srv-key-version must also be changed, and if the srv-key-version is changed, the krb-srv-key must also be changed.
For krb-srv-key and srv-key-version, each cannot already exist in the ipsec-kerberos-keys table. The system updates the ipsec-kerberos table before it updates the ipsec-kerberos-keys table.
|
Step 2
|
SHOW IPSEC-KERBEROS-KEYS;
|
Displays the rolling list of old Kerberos service keys.
Note This step is optional. Use this command when you need to display the list.
|
Step 3
|
ADD IPSEC-POLICY;
Example:
See substeps a. and b. below.
|
Adds an IPsec policy for all incoming and outgoing traffic on the MTA. Perform one or more of the following steps, as applicable:
•Full-duplex security policy
–Using FQDN
–Using IP addresses
•Half-duplex security policy
|
a.
|
Provisioning example using FQDNs:
Use these two commands (examples shown):
add ipsec-policy id=mta01-out;
src-fqdn=cms-ca1.ciscolab.com;
dest-fqdn=mta1.ciscolab.com; action=apply;
add ipsec-policy id=mta01-in;
src-fqdn=mta1.ciscolab.com;
dest-fqdn=cms-ca1.ciscolab.com; action=permit;
or use this one command (example shown):
add ipsec-policy id=mta01;
src-fqdn=cms-ca1.ciscolab.com;
dest-fqdn=mta1.ciscolab.com; action=ipsec
Provisioning example using IP addresses:
Use these two commands (examples shown):
add ipsec-policy id=mta02-out;
src_ipaddr=192.168.45.211;
src_ipmask=255.255.255.0;
dest_ipaddr=192.168.17.222; action=apply;
add ipsec-policy id=mta02-in;
src_ipaddr=192.168.45.211;
src_ipmask=255.255.255.0;
dest_ipaddr=192.168.17.222; action=permit;
or use this one command (example shown):
add ipsec-policy id=mta02;
src_ipaddr=192.168.45.211;
src_ipmask=255.255.255.0;
dest_ipaddr=192.168.17.222; action=ipsec
|
Full-duplex security policy—When the MTA vendor applies security policy on all ports, use action=apply for outbound traffic and action=permit for inbound traffic. Alternatively, you can use a single command with action=ipsec for all outbound and inbound traffic.
Caution You must specify at least one of the following: src-fqdn, or src-ipaddr, or src-port. You must also specify at least one of the following: dest-fqdn, or dest-ipaddr, or dest-port.
The value of the action token defines whether security is applied to outbound or inbound traffic, both, or neither. This is a mandatory token. The allowed values are:
•PERMIT—Security on inbound traffic.
•APPLY—Security on outbound traffic.
•IPSEC—Security on both inbound and outbound traffic.
•BYPASS—No security
|
b.
|
Use these two commands (examples shown):
add ipsec-policy id=mta01-out;
src-fqdn=cms-ca1.ciscolab.com;
dest-fqdn=mta1.ciscolab.com; action=apply;
add ipsec-policy id=mta01-in;
src-fqdn=mta1.ciscolab.com;
dest-fqdn=cms-ca1.ciscolab.com; action=permit;
dest-port=2727;
|
