Downloads |
 Feedback
|
Table Of Contents
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
Optional Component (Hardware and Software)
Definition of Major, Point, and Maintenance Releases
Network Time Protocol Software
Upgrades and SIP Session Timers
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
CMTS Discovery Using the Static Subnet Table Enhancements
PacketCable CMS Subscriber Provisioning with SOAP/XML
CALEA Support for SIP Triggers
Ring Tone Mapping with SIP Triggers
Call Disposition—Delineate Blocked Calls from Incomplete Calls
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
SIP Triggers for SIP Endpoints
Disable Platform Shared Memory Replication
CMTS Discovery Using the Static Subnet Table
Subscriber ID Parameter and DQoS Measurement Counters Support
Own Calling Number Announcement Enhancement
Account Code Collection Enhancement
Terminal Make Busy and Group Make Busy
Database Table Size Enhancement
Switchover Data Mismatch Deferror Prevention
Retry After Period Enhancement
Own Calling Number Announcement
On-Net Routing and LNP for Inter-CMS Routing
CNAM Capability on a Trunk Group
Reception/Processing of DCS-LAES SIP Header
OSPS Services over SIP Between BTS Nodes
911 Ringback over SIP Between BTS Nodes
BLV and EI over SIP Between BTS Nodes
IP Transfer Point Non-Stop Operation Mode
SIP-Based Endpoints Behind Cable Modem
Separation of CMS and MGC Architecture—Inter-CMS Routing
CALEA Interaction with SIP Endpoints
CALEA Interaction with SIP Triggers
SIP REFER and SIP INVITE with Replaces
PacketCable CALEA/ES I04 Compliance
Multi-Lingual Support for IVR and Announcement Services
Non-IVR Activation and Deactivation of SCF, SCR, SCA, and DRCW
ISDN Backhaul Using IUA and SCTP
Extended Voice Quality Metrics Reporting for MGCP
Internal Secondary Authoritative DNS
Emergency 911 Trunk Connection Loss Alarm
DTMF Relay Call Agent Controlled Mode
PacketCable Multimedia QoS Enhancements
Fax, Modem, and TDD Handling Enhancements
Ability To Perform Full System Backup With Reduced Duration In Simplex Mode
Broadband Telephony Services Status
Security Advisory Due to Default User Names and Passwords
Transaction Throttling Capability
Tabular Display of CPI/CPM Data
Configurable Default Values in Subscriber Provisioning
Service Interaction Manager Measurements
Traffic Measurements Monitor Counters
Modified H323-TG-PROFILE Table
Pre-Manual Switchover Integrity Diagnostic Utility
Alarm Subsystem Enhancements and Redesign
North American Numbering Plan Administration (NANPA) Enhancements
LNP Event and Measurement Enhancements
Call Processing Events and Alarms
Changes from Previous Releases
Additional QoS Parameters in the Billing Records
Billing Timer Resolution in Milliseconds
New and Updated Documentation for Release 5.0
Obtaining Documentation and Submitting a Service Request
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
Revised: December 12, 2008, OL-10355-05Introduction
The Cisco BTS 10200 Softswitch is a class-independent software switch (softswitch) that provides next-generation integrated voice and data switching solutions for packet networks.
This document describes new features and enhancements provided in the initial Release 5.0, as well as Maintenance Release 1 (MR1) and Maintenance Release 2 (MR2). The new features and enhancements are for PacketCable telephony and operational tools and functionality.
For an overview of the components, functions and signaling protocols supported by the Cisco BTS 10200 Softswitch, see the Cisco BTS 10200 Softswitch System Description.
For descriptions of Release 5.0 network features, subscriber features, class of service (COS) functions, outgoing call barring (OCB), feature interactions, and interactive voice response (IVR) features, see the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions.
Contents
These release notes for the Cisco BTS 10200 Softswitch describe the enhancements and new features provided in Release 5.0 FCS (900-05.01.V00), MR1 (900-05.02.V00), MR1.1 (900-05.00.02.V05), and MR2 (900-05.00.03.V00).
Each Cisco BTS 10200 Softswitch release can include a series of maintenance Vxx releases following the initial release. The release notes for the Vxx releases are updated only if they contain new information about the release.
This document includes the following sections:
•
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
•
•
These release notes are updated periodically on an as needed basis and contain important operational information.
Before You Begin
Warning
Sun Explorer is CPU intensive and could case issues with the real-time processes running on active and standby BTS 10200 platforms. Sun Explorer should be run only when the BTS 10200 platform is OOS (for example, after a platform stop all is executed).
Caution
Note
System Requirements
This section describes the Cisco BTS 10200 Softswitch supported hardware platforms, their supported options and configurations, and the supported software releases.
Multiple hardware options are available. Service providers should consult with their Cisco account team and choose the option that best suits their network applications and traffic levels. For more information about the hardware options, refer to Table 1.
The physical plant requirements for installation of the Cisco BTS 10200 Softswitch are documented in the Cisco BTS 10200 Softswitch Site Preparation and Network Communications Requirements.
The Cisco BTS 10200 Softswitch requires the following equipment:
•
•
•
Note
Note
Sun Microsystems hardware can be ordered directly from the vendor or a Sun value added reseller; however, Cisco TAC does not support hardware or operating systems purchased directly from Sun or from any other vendor. Hardware support contracts should be purchased from Sun or the Sun value added reseller.
Hardware Requirements
The Cisco BTS 10200 Softswitch is available only in duplex (continuous-service) configurations. Determine if you need an AC or DC system, and if you want the hardware in a cabinet or ready to mount in a customer rack.
Table 1 lists the hardware requirements for the Cisco BTS 10200 Softswitch Call Agent (CA), Element Management System (EMS), and Feature Server (FS) platforms.
Caution
The minimum required memory for Release 5.0.x is 8 GB.
For best results, Cisco recommends using the hardware and memory options listed in Table 1.
Interface Options
The Cisco BTS 10200 Softswitch interface configurations are documented in the Cisco BTS 10200 Softswitch Cabling, VLAN, and IRDP Procedures.
In Release 5.0.x, the Call Agent (CA) requires four physical interfaces, and the Element Management System (EMS) requires two physical interfaces. If ordering your own hardware, make sure to purchase an adequate number of interfaces.
Note
Optional Component (Hardware and Software)
The HTTP feature server (HTTP-FS) is an optional component of the Cisco BTS 10200 Softswitch that enables users to configure user-parameters for certain applicable Cisco BTS 10200 features. The feature server performs ASCII text-based (rather than tones) queries to a CMXML-aware (v3.0 and above) SIP client.
For example, with a CMXML-aware Cisco 7960 IP phone, users can configure the Call Forwarding Unconditional (CFU) forwarding number using a text-based menu displayed on the phone's LCD panel.
Note
The HTTP-FS comprises two subcomponents: the GUI feature server (GUI-FS) and the Mini-Browser Adapter (MBA). To use the HTTP-FS, you must install the GUI-FS software package, which is part of the Feature Server for POTS/Tandem/Centrex (FSPTC). Install the FSPTC if not already installed.
Requirements for HTTP-FS
The Sun Fire V240 hardware and Solaris 8 are required to use the HTTP-FS. Load Solaris 8, and then install the MBA software package.
Note
Ancillary Hardware
If you are using reference sale hardware, the following pieces of ancillary hardware are required for use with the Cisco BTS 10200 Softswitch.
For AC Systems
You need two AC system switch routers configured as listed in Table 2.
Table 2 AC Systems
WS-C2950M-XL-EN
Cisco Catalyst 2950m xl AC 10/100 Autosensing Fast Ethernet Switch
For DC Systems
You need two DC system switch routers configured as listed in Table 3.
For All Systems
You need your own terminal server that allows for console login.
Cisco ITP Signaling Gateways
The Cisco IP Transfer Point (ITP) is required for SS7 interconnectivity. ITP is a comprehensive product for transporting Signaling System 7 (SS7) traffic over traditional time-division multiplexing (TDM) networks or advanced SS7-over-IP (SS7oIP) networks. You need Cisco ITP Signaling Gateways to provide SS7 interconnectivity for the Cisco BTS 10200 Softswitch in Release 5.0.x.
Note
The Cisco IP Transfer Point is implemented on the Cisco 2600XM Series Router (2651XM), the Cisco 7301 Router, and the Cisco 7500 Series Router (7507, 7513). All hardware models function similarly by performing MTP3 routing over SS7 TDM links or over an IP (or dual IP) network.
The Cisco ITP 2651, 7301, and 7507 Signaling Gateways are carrier class routers with a transparent SS7oIP convergence solution. The 2651XM offers 2 or 4 SS7 links, the 73xx supports up to 80 SS7 links, and the 7507 provides from 32 to 256+ SS7 links.
Note
Because the Cisco BTS 10200 and ITP both handle SS7 traffic using Sigtran protocols, they must be fully compatible in the version of the SCTP used.
Software Requirements
You need the Cisco BTS 10200 Softswitch Release 5.0 (900-05.00.00.Vxx) software in order to run the Cisco BTS 10200 Softswitch on the hardware platforms.
Definition of Major, Point, and Maintenance Releases
The following section describes the differences between major, point and maintenance releases.
Major Release
A major software release has significant new features, enhancements, architectural changes, and/or defect fixes. The major release number increments with each new version, and numbers cannot be skipped. This release is based on a previous main release and receives defect fixes synced from previous Main releases throughout the life of this release.
Point Release
A point software release has only a few new features of limited scope, enhancements and/or defect fixes. The point release number increments as content is added, and numbers can be non-sequential (skipped). This release is based on a previous major or minor release and receives defect fixes synced from previous major or minor releases throughout the life of this release.
Maintenance Release
A maintenance software release has defect fixes that address specific problems. The maintenance release number increments as content is added, and numbers can be non-sequential (skipped).
Release Naming Conventions
The Cisco BTS 10200 product release version numbering is defined as either:
•
•
where:
•
•
•
•
–
–
–
–
–
•
Some naming convention examples are:
•
•
•
•
Network Time Protocol Software
Note
NTP software is installed with Sun Solaris. Be sure to configure your Cisco BTS 10200 Softswitch to use NTP or the equivalent time synchronization software.
Caution
Optional Software
The following optional software can also be used with Cisco BTS 10200 Softswitch Release 5.0.
Cisco Extensible Provisioning Object Manager
You can use the Cisco Extensible Provisioning Object Manager (EPOM) Release 5.0 software as a provisioning tool for Cisco BTS 10200 Softswitch Release 5.0.x. For information on new EPOM features, refer to the Cisco BTS 10200 Softswitch EPOM Release Notes.
Note
EPOM requires its own host server. For more information, refer to the Cisco EPOM Getting Started Guide.
CORBA and OpenORB
The CORBA Adapter (CAD) interface is an object-oriented provisioning tool for the BTS 10200 that parallels the BTS 10200 CLI adapter in capability.
The CAD uses the OpenORB 1.4 interface to develop and deploy distributed object-based applications, as defined in the CORBA specification 2.4.2. OpenORB is a third party software package that leverages the Internet Inter-ORB Protocol (IIOP) using either the Transmission Control Protocol or the User Datagram Protocol (UDP) for connections.
For detailed information on CORBA and OpenORB, refer to the Cisco BTS 10200 Softswitch CORBA Adapter Interface Specification Programmer Guide.
SOAP and XML
The SOAP adapter provides a machine-to-machine interface (MMI) over Simple Object Access Protocol (SOAP).
The goal of the SOAP interface is to provide a provisioning method for the Cisco BTS 10200 Softswitch product that parallels the Command Line Interface (CLI) adapter in capabilities. SOAP provides an abstraction of the Cisco BTS 10200 Softswitch in a consistent, object-oriented model.
The SOAP adapter uses the Tomcat AXIS version 1.4 package to develop and deploy the SOAP application. AXIS 1.4 is a third-party freeware provided as part of the BTS 10200 Tomcat package.
The XML interface is abstracted by SOAP itself. The Tomcat package uses either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) for connections. Narrowing on the NameService will also produce the BTS10200 objects. Narrowing is covered in great detail in the coding examples in the Cisco BTS 10200 Softswitch SDK package. This is bundled with the Cisco BTS 10200 Softswitch application.
For detailed information on SOAP and XML, refer to the Cisco BTS 10200 Softswitch SOAP Adapter Interface Specification Programmer Guide.
Component Interoperability
Table 4 lists the peripheral platforms, functions, and software loads that have been used in system testing for interoperability with the BTS 10200 Release 5.0.x software. Earlier or later releases of platform software might be interoperable, and it might be possible to use other functions on these platforms. This list certifies only that the required interoperation of these platforms, the functions listed, and the protocols listed has been successfully tested with the BTS 10200.
Table 4 Component Interoperability Matrix
ThinkEngine Networks 500X and 4000X
Announcement Server
MGCP 1.0
3.0
IP Unity Harmony 6000
Announcement Server
MGCP 1.0
3.1.19
IP Unity Harmony 6000
Privacy Director
SIP RFC3261
3.1
IP Unity Harmony 6000
Voicemail Server
SIP RFC3261
3.1
Cisco IAD 242x
Residential/Business Gateway
MGCP 1.0
12.3(21)
Cisco IAD 243x
Residential/Business Gateway
MGCP 1.0
12.4(4)T5
Cisco Cat 3550
Ethernet Switch
121-22.EA6
Cisco Cat 2950
Ethernet Switch
121-22.EA6
Cisco MGX 8850 VISM
Trunking Gateway
MGCP 1.0, TGCP
3.53.30.203
Cisco MGX VXSM
Trunking Gateway
MGCP 1.0, TGCP
5.3.10.201-P2
Cisco AS5300
Trunking Gateway1
MGCP 1.0, TGCP
12.4.12
Cisco AS5350
Trunking Gateway1
MGCP 1.0, TGCP
12.4.12
Cisco AS5400
Trunking Gateway
MGCP 1.0, TGCP
12.4.12
Cisco PXM45/AXSM
Trunking Gateway
MGCP 1.0, TGCP
5.52(10.255)D
Cisco PXM1-4-155
Trunking Gateway
MGCP 1.0, TGCP
5.3.1
Cisco VISM-PR
Trunking Gateway
MGCP 1.0, TGCP
5.2.00
Cisco RPM
Trunking Gateway
MGCP 1.0, TGCP
12.4(6) T6
Cisco 2651
SS7 Signaling Gateway
SIGTRAN M3UA/SUA
12.2(25)SW7, 12.4(11)SW
Cisco 2811 ITP
SS7 Signaling Gateway
SIGTRAN M3UA/SUA
12.4(11)SW
Cisco 73xx ITP
SS7 Signaling Gateway
SIGTRAN M3UA/SUA
12.2(25)SW7, 12.2(18)ixc
Cisco 750x ITP
SS7 Signaling Gateway
SIGTRAN M3UA/SUA
12.2(25)SW7, 12.4(11)SW
Cisco uBR7246VXR Router
CMTS
PacketCable EM 08
12.3(13a)BC1, 12.3(13a)BC3
Cisco uBR 10K
CMTS
CALEA SII
12.3(13a)BC1, 12.3(13a)BC3
Cisco MSFC1
IP Core-Cat 6500
6.4-20
Cisco MSFC1
IP Core-Cat 6500
121-26.E4
Arris TM402P
eMTA
NCS 1.0, IPSEC
TS0440559_022406_MODEL_4_5_TELNET_ON
Motorola SBV5220
eMTA
NCS 1.0, IPSEC
2.16.1.1
Motorola SBV5120
eMTA
NCS 1.0, IPSEC
2.16.1.1
Motorola SBV4200
eMTA
NCS 1.0, IPSEC
2.16.1.1
Scientific Atlanta Dpx2203
eMTA
NCS 1.0, IPSEC
v1.1.2r1151-050224b-5
Linksys PAP2
SIP endpoint
SIP
3.1.5(Lsd)
Cisco 7940
SIP phone
SIP
6.2
Cisco 7960
SIP phone
SIP
6.2
Camiant Multimedia Service Controller
Policy server
2.3
CableMatrix On-Demand Service Platform (ODSP)
Policy server
1.0.0b6
Netnumber Titan
ENUM application
5.2.11
1 The Cisco AS5350 and AS5400 have also been tested as Announcement Servers
Table Sizes
To check the size of all tables specific to your BTS 10200 configuration, perform the command show db-usage.
Operator Access
Operator access to the Cisco BTS 10200 Softswitch is available only by secure shell (SSH) session to the EMS over Ethernet. The BTS 10200 does not support nonsecure FTP; in order for you to FTP to any other system, your BTS 10200 system must have secure FTP (SFTP) capabilities.
For security purposes, SSH access is limited to using defined management interfaces.
Installation Notes
Before running an installation, plan accordingly, by using the Install and Upgrade Guides. These guides provide detailed installation procedures. Installing the BTS 10200 Softswitch consists of:
1.
2.
3.
After installing and cabling the hardware, use the jumpstart procedure to have the system jumpstarted with the proper OS version and kernel patch level. Once the system is configured properly, you can begin the application installation.
Caution
Note
Upgrade Procedures
Note
A procedure is available for customers upgrading between Cisco BTS 10200 releases.
The Upgrade Guides are available on the Install and Upgrade Guides documentation web site.
Upgrades and SIP Session Timers
SIP Session Timer values configured prior to Release 5.0 are reset to the default values after an upgrade to Release 5.0. Additionally, you cannot configure the SIP session timers, such as minSE and session_expires_delta_secs, on the CA-CONFIG table.
To configure the SIP timers, you must use the new SIP-TIMER-PROFILE table and reference the SIP timers in the CA-CONFIG table.
Caveats
The Bug Toolkit online application allows you to query defects and caveats.
Bug Toolkit
To access Bug Toolkit, you must have an Internet connection, a Web browser, and a Cisco.com username and password. To query defects and caveats, follow this procedure:
Step 1
Step 2
Step 3
To view all caveats for Cisco BTS 10200, go to the "Search for bugs in other Cisco software and hardware products" section, and start typing BTS in the Product Name field.
Note
Step 4
Step 5
Note
Step 6
•
•
•
•
•
•
Bug Toolkit returns the list of caveats based on your query.
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
New documentation for these Release 5.0, MR2 features can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/products_feature_guides_list.html
The following features were added or enhanced for Release 5.0, MR2:
•
•
•
•
•
Multiline Variety Package
The BTS 10200 Multiline Variety Package (MVP) feature allows service providers to create logical groupings of subscribers and provide centrex features such as call-hold, call-park/retrieve and extension dialing to the subscribers within the group without requiring them to use access codes.
Although the MVP feature does not require access codes, you can configure the BTS 10200 to use prefixed extensions to reach subscribers within the group. For example, you can configure a group of eight subscribers with 1-digit extensions ranging from *2 to *9 or a group of up to 30 subscribers with 2-digit extensions ranging from *20 to *49. You can assign *0 for operator or attendant access.
For more detailed information on the MVP feature, refer to the Multiline Variety Package Feature Module.
IDX Soft Limits Enforcement
The IDX Soft Limits Enforcement feature sets soft limits on table sizes so that the IDX index cannot increment past the bounds. This feature synchronizes the memory size between a BTS 10200 Softswitch side A network element (NE) and a side B NE when the maximum memory size configuration increments in soak mode during a software upgrade to a new release. This addresses the backward replication issue that may cause data corruption due to the IDX being out of bounds.
When table sizes grow in soak mode while upgrading, call activity during soak mode may cause the following potential problems:
•
•
•
Note that this feature addresses issues caused when table sizes increase. Currently, full system fallback is not supported if the new release has a larger table size.
Implementation of the IDX Soft Limits Enforcement feature involves the following:
•
•
•
A new major alarm, DATABASE(27)—Failure setting IDX table soft limit, is implemented with this feature.
CMTS Discovery Using the Static Subnet Table Enhancements
This feature was introduced in Release 5.0 MR1. See the CMTS Discovery Using the Static Subnet Table feature description.
In Release 5.0 MR2, this feature was enhanced to provide the following new CLI commands:
•
•
•
For more detailed information on this feature and the new CLI commands, refer to the CMTS Discovery Using the Static Subnet Table Feature Module.
Multiple EMS Spindles
The Multiple EMS Spindles feature is an optional configuration that offers improved provisioning performance on the BTS 10200. The addition of EMS spindles (hard disks) significantly improves provisioning throughput, thereby increasing the capacity of the BTS 10200.
Multiple EMS spindles are installed on the BTS 10200 through a single, executable script which is run during a fresh OS install. The installation script migrates the existing Oracle database to a new disk pool, and the new file system is maintained after any reboots or application upgrades. There are no changes to any existing BTS 10200 application software.
For more information on multiple EMS spindles, refer to the Multiple EMS Spindles Feature Module.
PacketCable CMS Subscriber Provisioning with SOAP/XML
CMS subscriber provisioning over SOAP/XML interface was introduced in Release 5.0. This initial release supported only the Pkt-p1 interface to the Provisioning Server (PS)/Call Management Server (CMS) and the PcspService Object, without extensions.
In Release 5.0 MR2, CMS subscriber provisioning with SOAP/XML is fully compliant with the PKT-SP-CMSPROV1.5-I01-050128 PacketCable specification, allowing full support of PacketCable 1.5 subscriber provisioning.
In addition, the BTS 10200 now supports Cisco-specific extensions and customer-specific extensions to allow full provisioning and turn up of an in-service subscriber. The SOAP/XML interface enables you to peform the following provisioning operations:
•
•
•
•
•
Requests and responses between the Call Management Server (CMS) and Provisioning Server (PS) must be encapsulated in SOAP version 1.1. Secure transport protocol is achieved through the use of IPSec.
For more information on CMS subscriber provisioning with SOAP/XML, refer to the PacketCable CMS Subscriber Provisioning with SOAP/XML Feature Module (Beta Version).
CALEA Support for MLHG
BTS10200 provides CALEA support for the multiline hunt group (MLHG) where by a group or an individual member (i.e. Terminal) of a group can be placed under surveillance. If the whole MLHG group is under surveillance (i.e. Pilot DN is tapped), the BTS10200 will send call-identiying information for all the incoming calls to the group and outgoing calls from the group. If an individual member of group is under surveillance (i.e. associate DN is tapped), the BTS10200 will send call-identifying information for all the calls originating from the tapped terminal or terminated to the tapped terminal.
Note
CALEA Support for SIP Triggers
In Release 5.0 MR2, CALEA is supported for SIP triggers. The BTS 10200 CMS sends a CALEA Service Instance Message (SIM) with a service name of Call Block. The message is sent when SIP trigger calls are blocked by the Announcement Server (AS). Cause code 21 appears in the reason header of the message.
Ring Tone Mapping with SIP Triggers
Prior to Release 5.0 MR2, a BTS 10200 deployed with SIP triggers did not accept the Alert-info header sent from the Application Server (AS). As a result, certain features on the AS could not have distinctive ring tones and call waiting tones assigned to them.
In Release 5.0 MR2, the BTS 10200 is enhanced to accept the Alert-info header from the AS. The following values are allowed in the Alert-info header:
•
•
If the called NCS subscriber has call waiting, then the BTS 10200 applies the call waiting tone (CWT). If the call waiting tone is CWT1, then the BTS 10200 overwrites the tone based on the information in the Alert-info header received from the AS as follows:
•
•
•
Call Disposition—Delineate Blocked Calls from Incomplete Calls
To delineate blocked calls from incomplete calls requires the BTS 10200 to translate the reason code sent to the BTS 10200 from the SIP application server in BYE (only) into a new service type in the CDR. The new service type will indicate that Call-Blocked-because of Privacy Plus to the billing servers.
To make this requirement extendable to new features to be provided by application servers in future, the following is implemented:
•
•
•
•
During the invocation of the SIP trigger feature, if BYE is received from the application server with a reason-header having a code (can be any 2 digit or 3 digit code), the BTS 10200 will add a value of 200 to the code and capture it as the service type in billing. The code capture can be used by the billing server to determine the feature provided by the application server. For example if BYE is received with reason-code 21 from the application server, the BTS will capture code in CDR as 221.
The following is an example of the CDR that will be seen when a user executes a show command on the BTS 10200.
Note
Example:
SERVICETYPE 1 = AS_SERVICE_221FEATUREDATAONE1= NULL.USAGESENSITIVE1=FalseSERVICERESULTCODE1=SuccessThe numeric value that is captured in the CDR file for this service type is 221.
In the future, instead of adding the 200 to the reason code sent by the application server, the application server will send the Right Reason code (200 onwards). This removes the need for adding 200 at the BTS 10200 and at the CDR and the reason code value will be consistent.
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
New documentation for these Release 5.0, MR1 features can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/products_feature_guides_list.html.
Note
The following features were added or enhanced for Release 5.0, MR1:
•
•
•
•
•
•
•
•
•
SIP Triggers for SIP Endpoints
The SIP triggers feature was first supported in Release 5.0 for MGCP and NCS subscribers. For Release 5.0, MR1 and later, the BTS 10200 Softswitch supports SIP triggers for SIP endpoints (SIP subscribers) when the incoming call is based on a Directory Number (DN):
•
•
The SIP triggers feature is supported with the following limitations:
•
•
•
–
–
For more detailed information on SIP triggers for SIP endpoints, refer to the Cisco BTS 10200 Softswitch SIP Triggers for SIP Endpoints Feature Module.
SIP Server Groups
The SIP Server Groups feature provides an alternative to the DNS-SRV (RFC-3263) method for destination selection on the BTS 10200 SIP interface, while providing capabilities that extend beyond what DNS-SRV provides. These additional capabilities are:
•
•
•
•
This feature eliminates the need for the BTS 10200 SIP interface to perform DNS lookups for call processing. The elimination of DNS lookups helps avoid performance impacts on SIP call processing on the BTS 10200 as a result of DNS server latency, which can occur due to network congestion.
For more information on the SIP server groups feature, refer to the Cisco BTS 10200 Softswitch SIP Server Groups Feature Module.
CORBA Session Manageability
The CORBA session manageability enhancements affect the manageability of CORBA user sessions and impact the following areas:
•
•
•
•
•
For more information on the CORBA manageability enhancements, refer to the Cisco BTS 10200 Softswitch CORBA Manageability Featurette.
Seasonal Suspend
The Seasonal Suspend feature allows subscribers to suspend, rather than disconnect, their telephone service when going away for the off-season. This feature affects both inbound and outbound calls on the subscriber line.
This feature disables all domestic and international inbound and outbound calling, operator services, directory assistance, caller ID blocking, vertical service codes (VSCs), midcall and hookflash-based features, and all calling features other than the following:
•
•
•
The Seasonal Suspend feature is not available to Centrex or MLHG subscribers.
The BTS 10200 does not place any restrictions on the start and stop dates for seasonal suspend.
If no referral number is provisioned for a subscriber in the subscriber-feature-data table, then the system plays the generic seasonal suspend message.
For more information on the Season Suspend feature, refer to the Cisco BTS 10200 Softswitch Seasonal Suspend Feature Module.
SIP Name Dialing
The SIP Name Dialing feature enables the BTS 10200 to support the SIP soft clients.
For Release 5.0, MR1, only the voice portion of the SIP name dialing feature is implemented.
SIP soft clients can be provisioned in multiple BTS 10200 Softswitches within a network.
For more information on the SIP Name Dialing feature, refer to the Cisco BTS 10200 Softswitch SIP Name Dialing Feature Module.
Disable Platform Shared Memory Replication
Beginning with Release 5.0, MR1, the BTS 10200 supports replication disabling. This capability is used when performing upgrade procedures.
Aggregation ID Subnet
The Aggregation ID (aggr-id) Subnet feature allows a service provider to use the Subnet table to configure all subnets handled by every cable modem termination system (CMTS). The BTS 10200 Softswitch uses the IP address of the embedded multimedia terminal adapter (eMTA) and Subnet table to determine the CMTS handling of a particular eMTA. A CMTS is an aggregation device for multiple eMTAs.
For more information on the Aggregation ID Subnet feature, refer to the Cisco BTS 10200 Softswitch Aggregation ID Subnet Feature Module.
CMTS Discovery Using the Static Subnet Table
The CMTS Discovery Using the Static Subnet Table feature uses the statically provisioned Subnet table in the BTS 10200 system. The service providers must configure all subnets handled by every CMTS using the Subnet table. The BTS 10200 uses the IP address of the MTA and the Subnet table information to determine the CMTS (AGGR) handling the MTA.
The BTS 10200 uses the following data precedence to decide MTA Effective-AGGR-ID:
•
•
For more detailed information on this feature, refer to the CMTS Discovery Using the Static Subnet Table Feature Module.
Bulk Data Export
The Bulk Data Export feature introduces a new database tool to export the BTS 10200 EMS provisioning data from the Oracle database to raw ASCII data files. The new tool provides a transport for the customer to migrate the BTS 10200 data to other reporting systems. This feature also serves as a supplemental backup mechanism.
This new data export tool reduces the total data export time from several hours to minutes. It also provides customers with better granularity and flexibility to specify the export contents.
The user must logon to the BTS 10200 EMS system as one of the following users to execute the tool:
•
•
•
The operating system btsoper group and btsoper user is created at the BTS 10200 installation.
A few dbexp operations can only be executed by the privileged Oracle user.
For more information on the Bulk Data Export feature, refer to the Cisco BTS 10200 Softswitch Bulk Data Export Feature Module.
Subscriber ID Parameter and DQoS Measurement Counters Support
This feature (PacketCable ECN, DQoS 1.5-N-06.0339-4) adds a Subscriber ID in all Gate Control messages and enhances error codes returned from the Cable Modem Termination System (CMTS).
In the current DQoS (Dynamic Quality-of-Service) specification, the Gate ID is unique only to individual CMTS. With the CMTS proxying all Call Management Server (CMS) Gate control messaging through a central device, the CMS only has a single Common Open Policy Service (COPS) association to the proxy device. Since Gate IDs can be duplicated when using multiple CMTSs, this feature adds a Subscriber ID to each Gate Control message to disambiguate the Gate IDs between the CMS and proxy device.
The ECN DQoS 1.5-N-06.0339-4 augments the following COPS messages, where the Subscriber ID parameter is added:
•
•
•
•
The Subscriber ID is already available on the CMS and is currently used in the Gate-Alloc and Gate-Set messages.
This feature also enhances the error codes returned from CMTS or its proxy to allow more precise reasons as to why a particular gate operation failed.
For more information on the Subscriber ID Parameter and DQoS Measurement Counters Support feature, refer to the Cisco BTS 10200 Softswitch Subscriber ID Parameter and DQoS Measurement Counters Support Feature Module.
ENUM Application
The ENUM Application feature allows translation of E.164 address and SIP URL for call routing. The BTS 10200 interfaces with an external ENUM server for call routing.
This feature enables the BTS 10200 to perform ENUM query of calls and determine if a call is on-net. After the ENUM query, the BTS 10200 routes calls on-net or towards PTSN.
The new CDR field, ENUM-ROUTE-USED, is implemented for this feature.
For more information on the ENUM Application feature, refer to the Cisco BTS 10200 Softswitch ENUM Capability Feature Module.
Own Calling Number Announcement Enhancement
The Own Calling Number Announcement (OCNA) feature was enhanced in Release 5.0, MR1 to allow you to provision and activate the feature through a vertical service code (VSC).
For more information on the OCNA feature, refer to the Cisco BTS 10200 Softswitch Own Calling Number Announcement Feature Module.
Account Code Collection Enhancement
The following provisionable FEATURE-CONFIG parameters are added to the Feature Configuration Base table for account code collection:
•
•
•
•
Also, the CA-CONFIG parameter ACCT-CODE-PROMPT-DELAY accepts a maximum value of 10000.
For more information on the these new parameters for account code collection, refer to Cisco BTS 10200 Softswitch Call Processing Command Line Interface Reference - Call Processing Commands, Appendix B, Table B-4.
Terminal Make Busy and Group Make Busy
The Terminal Make Busy (TMB) and Group Make Busy (GMB) features enable the BTS 10200 to notify incoming callers that specific terminals within an MLHG or all members of the MLHG are busy. When TMB or GMB is activated, the BTS 10200 provides incoming callers with one of the following:
•
•
The following four new feature names are added to the Feature Name table for TMB and GMB activation and deactivation:
•
•
•
•
The subscriber activates TMB and GMB features by entering a vertical service code (VSC). The BTS 10200 supports TMB and GMB for MLHG, MLHG-Individual, MLHG-Pref-Individual, and CTXG-MLHG subscribers.
For more information on the TMB and GMB features, refer to the Terminal Make Busy and Group Make Busy Services Feature Module.
Database Table Size Enhancement
The new mem_commercial.cfg file provides database size requirements for commercial cable customers. These database tables are increased:
•
•
•
The mem_commercial.cfg file is added to all three CA platform installations.
Switchover Data Mismatch Deferror Prevention
The switchover data mismatch deferror prevention enhancements prevent Oracle data mismatch errors upon switchover. Prior to Release 5.0 MR1, at EMS switchover, the standby EMS platform was transitioned to active without waiting for the Oracle replication queue to completely drain from the active EMS. To alleviate this, the Session Manager (SMG) now waits 120 seconds when a switchover is initiated to allow the replication queue to drain. Two new commands, Query Oracle Replication Queue on the Active Element Management System (EMS) and Control Element Manager to Switchover have also been added.
For more information on these enhancements, refer to the Switchover Data Mismatch Deferror Prevention Feature Module.
Retry After Period Enhancement
Prior to Release 5.0 MR1, the Retry After period for 500 Internal Server Error Responses was hardcoded to a value of 10 seconds. This enhancement defaults the Retry After period to one second. In future BTS 10200 releases, the Retry After period will be made configurable in milliseconds.
New Features for Release 5.0
Documentation for Release 5.0
New feature documentation for Release 5.0 can be accessed through the following link: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/products_feature_guides_list.html.
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Telephony Features
The following telephony features were added to Cisco BTS 10200 Release 5.0.
SIP Triggers
The SIP Triggers feature uses the SIP protocol, with some extensions, to enable the Cisco BTS 10200 Softswitch to interoperate with third-party application servers so that Multi-Service Operators (MSOs) can provide customers with enhanced features and services.
Note
The Cisco BTS 10200 Softswitch enables appropriate trigger and routing mechanisms to provide enhanced features and services to residential subscribers. This BTS 10200 Softswitch functionality enables MSOs to integrate third-party application servers to provide originating services (such as voicedial) when a subscriber places a call, and enhanced terminating services (such as TV Caller ID, Custom Ringback) when a subscriber receives a call. The following triggers enable this integration:
•
Depending on the service invoked (for example, dial by name), the application server determines the desired called party and sends the call back to the BTS 10200 Softswitch to continue originating processing.
•
Own Calling Number Announcement
The Own Calling Number Announcement feature enables the BTS 10200 to play an announcement with the calling number when a calling party dials a specific pilot number. The announcement is played if the calling party is a subscriber. Calls originating outside the system are released with cause code CA_CCITT_NE_CAUSE_UNALLOCATED_NUM.
For subscribers with categories INDIVIDUAL, MLHG_INDIVIDUAL, and CTXG_INDIVIDUAL, the number from the DN1 field of the Subscriber table is played as part of the announcement. For subscribers with all other categories, the calling number is played, if available. Otherwise, the number from the DN1 field of the Subscriber table is played.
Multiple Directory Numbers
The multiple directory numbers (MDN) feature provides multiple secondary directory numbers, in addition to a primary directory number. Referred to as the "teen feature," MDN allows a subscriber to assign distinctive ring and call waiting tones for incoming calls. The subscriber can identify an incoming caller by the distinctive ring or call waiting tone without having to actually answer the call. The enhanced MDN feature allows a subscriber to assign ring and call waiting tones to a primary DN and five or more secondary DNs.
911 Overflow to Announcement
The 911 Overflow to Announcement feature enables the Cisco BTS 10200 Softswitch to play a specific announcement when all circuits to the emergency center are busy and the emergency call cannot be completed to the emergency center.
The internal cause code, CA_CP_EMG_TG_OVERFLOW, is a special cause code for this announcement. It is applied when the announcement resource is available and applicable.
On-Net Routing and LNP for Inter-CMS Routing
The On-Net Routing and LNP for Inter-CMS Routing feature provides the following capabilities:
•
•
•
•
•
CNAM Capability on a Trunk Group
Prior to Release 5.0, a CNAM query was performed when a call was terminated to a subscriber with the CNAM feature. Beginning with Release 5.0, there is a separation of the call management server (CMS) and the media gateway controller (MGC), requiring the CNAM query to be performed at the MGC before the call is routed to the CMS. To fulfill this requirement, the Cisco BTS 10200 Softswitch allows the CNAM feature to be assigned to a trunk group.
The trunk group types that allow the CNAM capability are:
•
•
•
•
Reception/Processing of DCS-LAES SIP Header
The BTS 10200 supports the reception and processing of the DCS-LAES SIP header as specified in PKT-SP-CMSS-I04-040730. Incoming calls with this header indicate that the call is under surveillance, and the receiving BTS 10200 taps the call content. This is applicable for both CMS-CMS and CMS-MGC call scenarios where the terminating CMS/MGC taps the call. It also includes the call redirection scenario where the redirecting CMS is no longer in the RTP path, and the other CMS/MGC must tap the call.
The BTS 10200 can send the DCS-LAES to indicate the call should be under surveillance to the next softswitch that handles the redirecting call out of the BTS 10200. The redirected-to softswitch is not a BTS 10200 and could be a Session Border Controller/ MGC. In Release 5.0, the redirected-to softswitch can be another BTS 10200, and this is where the enhancement is required.
SIP Response Code 302
In Release 5.0, the BTS 10200 handles the Session Initiation Protocol (SIP) response code 302 as a call forwarding feature in a CMSS environment. The BTS 10200 supports SIP headers on a 302 class response, including call redirection and surveillance information.
For the BTS to properly route the call the 302 must have the following:
•
•
The BTS performs SIP 302 redirection on its POTS Feature Server (FS) as several call forwarding features. When the BTS is the originating switch and it receives a 302 it either:
•
•
BTS implements SIP 302 as the Call Forward Redirection (CFR) feature. CFR does the following:
•
•
SIP 302 interacts with the following call forwarding features on the BTS:
•
•
•
•
Limitations
Support for the SIP 302 feature is subject to these limitations:
•
•
•
•
•
•
•
•
•
•
OSPS Services over SIP Between BTS Nodes
Support for Operator Service Position System (OSPS) services was added in Release 2.0 of the Cisco BTS 10200 Softswitch. These services include Busy Line Verification (BLV), Emergency Interrupt (EI) (which is sometimes called Operator Interrupt), and 911 ringback. In the Release 2.0 implementation, the services were limited to MGCP subscribers that were connected to the same Cisco BTS 10200 Softswitch to which the special Operator BLV CAS trunk was connected.
In Release 5.0 of the Cisco BTS 10200 Softswitch, these services are extended so that the BLV trunk can be connected to one Cisco BTS 10200 Softswitch and the features can be implemented on subscribers connected to a second Cisco BTS 10200 Softswitch. The two Cisco BTS 10200 Softswitches are bridged with a SIP trunk.
The Cisco BTS 10200 Softswitch support of OSPS Services over SIP between BTS Nodes feature addresses the requirements applicable to the Cisco BTS 10200 Softswitch OSPS over SIP feature. The main requirement is to comply with PacketCable specifications:
•
•
•
•
911 Ringback over SIP Between BTS Nodes
911 ring-back describes a scenario wherein a Public Safety Answering Point (PSAP) operator is communicating with someone that has dialed 911 and the caller hangs up before the PSAP operator has all of the information that the operator needs. The operator commands the terminating switch to "ring back" the caller. There are two different types of 911 service: Basic 911 (B911) and Enhanced 911 (E911). In B911 it is absolutely necessary that the call and connection be retained when a caller hangs up. In E911 the caller is allowed to disconnect the call and connection because the caller's critical information (name and location) is passed to the PSAP operator by a signaling and a database retrieval mechanism. Also in E911, there is no operator ring back service defined.
With Basic 911, it is the responsibility of the PSAP operator to gather information from the caller, such as the phone number and address, so that the operator can pass this information on to the authorities that will respond to the emergency situation. B911 is the original 911 service which is still used within parts of the United States. It generally uses a CAS trunk to connect from the local switch to the OSPS.
E911 is generally implemented over a CAS connection from an Endpoint office to an E911 Tandem which then connects to the PSAP. Additionally, E911 calls can be routed over SS7 trunks. With E911 service, Automatic Number Identification (ANI) is used to pass the caller DN from the End Office (Cisco BTS 10200 Softswitch/MGC) to the E911 tandem. The E911 tandem then prefixes a numbering plan digit (NPD) to the ANI DN and sends it to the PSAP. The PSAP uses the NPD + ANI to search through a 911 database for the caller's Automatic Location Information (ALI), which provides the location of the caller.
Because B911 relies on the PSAP operator gathering information from the caller to get the caller's location, it is prohibited for the local switch (Cisco BTS 10200 Softswitch) to disconnect the call when the calling party hangs up. Instead, the local switch must ring back the calling party so that all necessary information is retrieved by the PSAP operator.
BLV and EI over SIP Between BTS Nodes
Busy Line Verification (BLV) and Emergency Interrupt (EI) are two phases of a call in which an operator can break into an ongoing call between a CMS subscriber and a third party. The first phase of the call is the BLV phase. It occurs when an operator calls a CMS subscriber and listens in to see if the subscriber is already in a call. The second phase of the call is the EI. In the EI phase, the operator makes a verbal request to the CMS subscriber to hang up and accept a call from another party.
The following is a typical sequence of events that occur for the BLV/EI over the SIP trunk. The sequence deals with most the common case where a busy party is involved.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
IP Transfer Point Non-Stop Operation Mode
The NSO feature supports two Signaling Gateway Platforms (SGPs) per Signaling Gateway (SG) in a Signaling Gateway Group (SG-grp) for mated Signal Transfer Points (STPs) and also supports the Sigtran MTP3 User Adaptation (M3UA) and SCCP-User Adaptation Layer (SUA) Application Server Process (ASP) load-share traffic modes.
This feature also enhances the IP layer implementation on the Versatile Interface Processor (VIP) cards for handling complex routing to remote destinations using either static routes or a routing protocol. With this additional capability, the ITP provides VIP redundancy in addition to platform and RSP redundancy.
SIP-Based Endpoints Behind Cable Modem
The BTS 10200 supports SIP based MTA as regular SIP endpoints behind the cable modem with PCMM. The following functionality is supported in Release 5.0:
•
•
•
•
Separation of CMS and MGC Architecture—Inter-CMS Routing
The BTS 10200 can function as a standalone CMS or as a standalone MGC. Also, this feature supports call routing between the BTS 10200 acting as a CMS and another BTS 10200 acting as a MGC/CMS. The inter-routing between CMS and MGC/CMS is based on the PacketCable CMSS principle, PKT-SP-CMSS1.5.
The following features across the SIP trunking between BTS 10200-CMS and Cisco BTS 10200-MGC are provided:
•
•
•
•
•
•
CALEA Interaction with SIP Endpoints
In Release 5.0, the BTS 10200 supports CALEA Interaction with SIP Endpoints. The BTS 10200 follows the guidelines specified in PKT-SP-EM1.5- I01-050128 Appendix A for sending call-identifying information to the delivery function for SIP endpoints. While attempting to deliver call-content information, the BTS 10200 notifies the DF server about the unavailability of call-content IAP on either the originating side or terminating side of the call. These packet-cable compliant call-content IAPs typically are not available when the caller and called are SIP endpoints. In order to capture call-content information for these cases, the Delivery Function Server must use the Service Independent Intercept (SII) architecture and initiate a request for duplication of RTP streams.
Note the following additional clarifications about satisfying CALEA requirements for SIP endpoints:
•
•
CALEA Interaction with SIP Triggers
In Release 5.0, the BTS 10200 supports CALEA interaction with SIP Triggers. To use the SIP triggers feature functionality (not defined by packet-cable 1.5 specifications) on the BTS 10200, a call can be routed to an external application server for feature processing. The BTS 10200 supports two types of triggers: Originating Trigger and Terminating Trigger. For both types, when a trigger is detected, the BTS 10200 routes the call to the application server through a SIP interface. Typically, the application server executes the feature logic and performs one of the following two operations to enable the BTS 10200 to route the call to the final destination.
•
•
The rest of this section summarizes how the BTS 10200 operates and interacts with the application server to perform surveillance on calls for which the Originating or Terminating Trigger feature is invoked.
When the BTS 10200 detects any origination or termination attempt, it checks for active surveillance associated with the originating or terminating party before routing the call to the application server. If the subscriber is under surveillance, the BTS 10200 sends a Signaling Start message to the Delivery Function server and performs the call-content surveillance function on an available call-content Intercept access point. In addition, when the call is being routed to the application server, the BTS 10200:
•
•
If the application server redirects the call-back to the BTS 10200, the BTS 10200 forwards the surveillance to the terminating side of the call. However, if the application server initiates a new call (by sending new INVITE message) to the BTS 10200, the BTS 10200 expects the same (unchanged) P-DCS-LAES header (sent earlier on the original call) in the new INVITE message. The BTS 10200 performs the following operations when it receives an INVITE message from the application server:
•
•
In addition, if the surveillance function cannot be performed on the terminating side of the call, the BTS 10200 includes a new P-DCS-LAES header in an 18X or 200 response sent back to the application server. It is assumed that the application server can include the P-DCS-LAES header in a SIP Response message sent back to the BTS 10200 on the original call.
The BTS 10200 is fully compliant with RFC 3261 and RFC 3264 in both basic and feature call processing.
SIP REFER and SIP INVITE with Replaces
The SIP REFER and SIP INVITE with Replaces features for the Cisco BTS 10200 Release 5.0 provide call-transfer functions for transferring targets that have non-BTS serving-domain names in the "Refer-To" header. Cisco's implementation of this feature complies with the following standards:
•
•
•
•
•
Prior to the availability of the SIP REFER and SIP INVITE with Replaces features for BTS 5.0, the BTS implementation of the REFER feature operated as if the transfer target specified in the Refer-To header of the REFER message was a number served by BTS. The domain of the URL in the Refer-To header was treated as if it were the URL of a BTS serving domain. Also, the implementation of SIP REFER was based on draft-ietf-sip-refer04 and was not fully compliant with the current version of RFC 3515.
The SIP REFER and SIP INVITE with Replaces features address cases in which the transfer targets specified in the Refer-To header of the REFER message are domains that are not BTS serving domains. The user part of the SIP URL in the Refer-To header can be a non-numeric value. To manage non-BTS serving domains, for attended transfers, an INVITE message with the Replaces Header might need to be sent. The BTS can receive SIP INVITE messages with Replaces header. The BTS processes SIP INVITE messages with the Replaces Header according to RFC-3891.
The Referred-By header includes information you can use to identify the Transferrer by the transfer target. This information might need to be passed to the transfer target. Therefore, the SIP REFER and SIP INVITE with Replaces features also must process the Referred-By header according to RFC 3892.
PacketCable CALEA/ES I04 Compliance
To satisfy new FBI CALEA requirements, the BTS 10200 complies with the PacketCable PKT-SP-EM-I11-040723. This is needed to support PKT-SP-ESP-I04-040723, which is an updated specification to comply with the FBI punch list items. The majority of the enhancements center around the reporting of subject and network signals. These new EM messages are used to convey all activities of the subscriber under surveillance during call. This includes the reporting of Dialed Digit Extraction from the DF server (Note that DDE is a requirement to report the final call identifying information when the subscriber dials the 800 service and it will be provided by the DF server).
Multi-Lingual Support for IVR and Announcement Services
This feature adds Multi-Lingual Support (MLS) for Interactive Voice Response (IVR) and announcement services. Using a Vertical Service Code (VSC) subscribers pick which language (English, French, Spanish) to hear.
To provide IVR and announcement services MLS works with the following Media Servers (MS):
•
•
•
An MS has 4 audio files for each IVR audio segment or announcement. For example, each welcome.wav has:
•
•
•
Using Basic Audio Utility Package (BAU) encoding MLS provides IVR service via a remote MS. If a provisioned language is different from the default, the BTS specifies BAU in the encoding field. BTS adds the language picked by the subscriber in variable audio segments.
Using a Media Gateway Control Protocol (MGCP) announcement (ANN) package MLS provides announcement service via a remote MS. Cognitronics supports MGCP ANN, IPUnity does not.
Casual Dial Enhancement
This feature enhances casual calling by enabling the BTS 10200 to out-pulse 10 dialed digits in their entire dialed digit form (101xxxx+1+10D) on the outgoing trunk. This enhancement enables the BTS-CMS to easily offload routing decisions to a Class 5 switch, which in turn routes the calls to the appropriate carrier. This enhancement is configurable on a trunk by trunk basis.
For this feature, a new token, OUTPULSE_AS_DIALED, is added to the Trunk Group table. The following new flags are encoded in the OUTPULSE_AS_DIALED token:
•
•
•
•
•
Dial Around Indicator in SIP
The BTS 10200 supports the CMSS extension of Dial Around Indicator (di).
Four values specified in ANSI SS7 are supported over the SIP interface. These values are:
•
•
•
•
MWI Manipulation through CLI
This feature enables you to display and update a subscriber's message waiting indicator (MWI) from the BTS user interface through the use of new CLI commands. With this new feature, a BTS operator can query the status of the MWI and can set or reset the MWI through the CLI interface.
Non-IVR Activation and Deactivation of SCF, SCR, SCA, and DRCW
Currently, the Selective Call Forwarding (SCF), Selective Call Rejection (SCR), Selective Call Acceptance (SCA), and Distinctive Ringing Call Waiting (DRCW) features are offered to Cisco BTS 10200 Softswitch subscribers. A subscriber can provision them through interactive voice response (IVR). This feature provides the ability to use vertical service codes (VSCs) to activate or deactivate the features when the feature operating data is already configured.
For example, after a user dials *236, SCR is deactivated and the caller hears "Selective Call Reject is deactivated. You may hang up now."
Eight VSCs are provided to allow activating and deactivating each of the four existing features. Once the user has configured SCA, SCR, SCF, and DRCW, VSCs can quickly deactivate and reactivate the features. If a subscriber changes a feature from active to inactive, or from inactive to active, a billing record is generated that is identical to the one sent when the IVR method was used to activate or deactivate the feature.
ISDN Backhaul Using IUA and SCTP
This feature allows support of Integrated Services Digital Network (ISDN) backhaul using ISDN Q.921-User Adaptation (IUA) and Stream Control Transmission Protocol (SCTP). This feature supports user and network interface in the ISDN PRI configuration for facility associated signaling (FAS) and NFAS, as defined in RFC 3057. This feature supplements the currently supported ISDN backhaul using Reliable User Datagram Protocol (RUDP) to Cisco media gateways (MGWs).
The current use of RUDP for PRI backhauling is not affected. An ISDN trunking gateway can be configured to use either RUDP or IUA, but not both at the same time.
IUA and SCTP are two protocols defined for the transportation of telephony signaling over a packet network. SCTP is a reliable transport protocol like RUDP. IUA is the adaptation layer that makes SCTP services available to Q.921 services users, such as Q.931 and NI2. There are several benefits to using IUA/SCTP in place of Session Manager (SM)/RUDP, including the following:
•
•
•
•
•
In a typical network topology, one SCTP association is established between the gateway and each Call Agent. Multiple SCTP streams are carried out within each association. One stream is always dedicated for management purposes, and separate SCTP streams are used for each D-channel. Two IP addresses for each side are designated for the same SCTP association for multi-homing
A new component, the IUA manager (IUM), is added to the Cisco BTS 10200 Softswitch to support this feature. The IUM provides an interface to the IUA and SCTP stacks and communicates with gateways. The Cisco SCTP and IUA stacks are used for this feature.
In addition to IUA/SCTP support, this feature also includes the following enhancements:
•
•
•
•
•
This feature has been tested with Cisco 2420 and Cisco AS5850 using Cisco IOS Release 12.2(15)T.
MGCP Asynchronous DNS Lookup
The BTS 10200 supports the MGCP Asynchronous DNS Lookup feature. If the DNS server(s) fail or exhibit poor response times, synchronous DNS function calls could seriously impact call processing by throttling new calls and failing existing calls. Very slow DNS responses from improperly provisioned media gateway (MGW) fully qualified domain names (FQDN) or slower responses from any MGW FQDN(s) that are not provisioned in the DNS server seriously impacts existing call processing. Even call processing for all MGW who have very fast DNS responses is impacted. The BTS 10200 MGCP Asynchronous DNS lookup feature will make the BTS 10200 robust in the face of DNS failures. The scope of this feature is initially limited to name lookup only, not other query types, and the use of the feature is limited to the MGCP interface only. Protocols used include all gateway control protocols (xGCP) including PacketCable NCS and TGCP protocols.
The BTS 10200 MGCP Asynchronous DNS Lookup feature will launch asynchronous DNS lookups to resolve FQDN of the media gateways while attempting to send MGCP messages. It also makes the resolved IP addresses for FQDN available to standby side of a BTS 10200 for instant use without launching new DNS queries. When MGW reboots, the BTS 10200 re-confirms its IP address from DNS server and updates it in the BTS 10200 internal MGW DNS cache if the IP address is different. When the BTS 10200 is started or restarted, it starts using the IP address in the BTS 10200 internal MGW DNS cache if available and also triggers reconfirmation of that IP address from the DNS server. The BTS 10200 provides the configuration option to accept/reject and confirm/ignore the IP address of any FQDN and update the IP address if it is different.
This feature makes the BTS 10200 robust in the face of DNS failures.
Additionally, other subsystems of the BTS 10200 can make use of this asynchronous DNS lookup functionality in order to improve reliability of the BTS 10200.
The flow of the DNS lookup is as follows:
Step 1
Step 2
Step 3
a.
b.
c.
d.
e.
Step 4
Step 5
Extended Voice Quality Metrics Reporting for MGCP
The Extended Voice Quality Metrics Reporting for Media Gateway Control Protocol (MGCP) Endpoints feature provides these voice quality-related metrics from MGCP-based endpoints:
•
•
•
•
•
•
First voice quality metrics parameters are collected from media gateway endpoints. Then these parameters appear in Call Detail Records (CDRs).
Internal Secondary Authoritative DNS
The Cisco BTS 10200 Softswitch Internal Secondary Authoritative DNS feature provides the BTS 10200 customers with an internal DNS database identical to the DNS database in the network. In the event of a long DNS outage in the network, any prolonged network outage, or if the external DNS servers fail, the internal DNS server can still provide responses to any DNS queries, and the BTS 10200 can still perform the usual functions without interruption.
The purpose of internal secondary authoritative DNS server (ISADS) is to shadow the primary DNS server. In case the primary DNS server has a long outage, the ISADS will have a local database in the BTS 10200 system that can provide authoritative response to any DNS queries by BTS 10200 applications.
Call Tracer
The Cisco BTS 10200 Softswitch Call Tracer (CTRAC) feature provides a mechanism that uniquely marks each BTS 10200 system call to provide a system call trace troubleshooting capability.
In the BTS 10200 releases prior to Release 5.0, TRACE logs captured the detailed operations of the call processing system, but there was no easy means to filter out TRACE logs pertaining to a single basic or feature call. Troubleshooters had to manually correlate log lines and manually filter out those that pertained to specific calls. This was tedious and time consuming.
The CTRAC feature provides an easy means to filter out TRACE log lines that correspond to a given specific basic or feature call. The filtering enabled by a unique CTRAC-ID set unconditionally for every call attempt (at the earliest point-in-time in call-processing) and provides a copy of it to all call-processing modules in Cisco BTS 10200 Softswitch (across platforms). The copy is used for logging into per-call related TRACE lines corresponding to the call.
Because every per-call related TRACE log line has a CTRAC-ID, a user can easily use UNIX grep or a similar command to filter out the lines of interest.
Cluster Routing
A cluster is defined as two or more CMSs along with MGCs (or combined CMS/MGCs) deployed within a network. The cluster looks to the PSTN like a single, logical CMS/MGC. The Cluster Routing feature has the following limitations:
•
•
•
•
•
A cluster LRN (location routing number) is defined as a shared LRN across multiple CMS / MGCs within a cluster.
When a call with a cluster LRN is received by one of the CMSs (or MGCs) within a cluster, the call is routed to the terminating CMS either by a SIP route proxy with ENUM querying capability or by use of the npa-nxx of the called number.
For Automatic Recall (AR) and Automatic Callback (AC) feature support, the ITP performs 6 digits GTT (npa-nxx) to route AR/AC requests to the appropriate CMS.
The CLRN is treated as an admin-DN for the purpose of NRUF reporting.
Emergency 911 Trunk Connection Loss Alarm
Before Release 5.0, the BTS 10200 treated all trunk alarms the same and assigned the same severity level, regardless of the type of trunk. This is not adequate for monitoring emergency trunks.
With Release 5.0, the BTS 10200 can distinguish an emergency (911) trunk from non-emergency trunks and can provide a higher severity level when emergency (911) connectivity is lost in the alarm notification.
This feature enables the BTS 10200 to generate a critical alarm when an emergency trunk resource becomes remotely or locally blocked. This alarm is raised when one of the following events occurs:
•
•
•
A critical alarm will be raised when an emergency trunk is locally blocked or remotely blocked. An emergency alarm (Signal 152 or Signal 153) is raised because the trunk is used for emergency purposes. The emergency trunk can be of type CAS, SS7, or ISDN.
Temporary Disconnect
Telephone subscribers must sometimes be temporarily disconnected from the phone service. Temporary Disconnect (TEMP_DISCONNECTED) is a system feature which can be used for that purpose.
The Cisco BTS 10200 Softswitch support of OSPS Services over SIP between BTS Nodes feature allows the service provider to assign a status of temporarily disconnected (TEMP_DISCONNECTED) to specific subscribers, and restrict incoming and outgoing calls for those subscribers. Using this feature, the service provider can block subscribers with delinquent accounts from making any outbound calls to numbers other than (for example) emergency, repair services, or the billing department. Incoming calls disconnected due to TEMP_DISCONNECTED receive an appropriate generic announcement.
The Cisco BTS 10200 Softswitch support of OSPS Services over SIP between BTS Nodes feature is applicable to POTS and Centrex subscribers. The feature is also applicable to MLHG and CTX with MLHG subscribers. For Centrex applications, the service provider can provision the TEMP_DISCONNECTED feature at the individual subscriber level and at the main subscriber level.
Note
The temporary disconnect behavior provides capabilities for the Service Provider to easily restrict line call capabilities in the following way:
•
•
•
The BTS Softswitch Temporary Disconnect feature allows certain numbers (611, 911, and some 800 numbers). This is configurable at the POP level for the suspended profile/definition.
When a temporary disconnected subscriber calls a restricted number, the BTS redirects the call to an announcement. Additionally, all calls to a restricted number can be routed to a customer service number/agent or some other Service Provider-configured number instead of to an announcement system. Also, calls can be routed to announcements that can give a configurable DN.
DTMF Relay Call Agent Controlled Mode
This feature enables the Call Agent (CA) controlled mode for dual tone multifrequency (DTMF) relay based on RFC 2833. During call setup, the CA (the Cisco BTS 10200 Softswitch) can authorize an embedded multimedia terminal adapter (eMTA) or media gateway (MGW) to invoke RFC 2833 DTMF relay procedures.
This feature affects MGCP, NCS, TGCP, SIP, and H.323 gateways and endpoints connected to the Cisco BTS 10200 Softswitch.
Note
This feature can be invoked on the following types of calls:
•
•
•
•
•
•
•
•
•
•
The Cisco BTS 10200 Softswitch sends the RFC 2833 DTMF relay parameters to the MGW or endpoint when setting up the initial call and also when setting up features involved in the call, for example, call forwarding.
This feature complies with the following requirements from industry standards:
•
•
PacketCable Multimedia QoS Enhancements
In PacketCable networks, the Cisco BTS 10200 Softswitch supports QoS for analog phones connected to an embedded multimedia terminal adapter (eMTA) as follows:
•
•
In Release 5.0, the PCMM-based feature extends QoS for legacy devices (Type 1 clients) that do not support DQoS, such as endpoints using SIP, MGCP, or H.323 as the call-signaling protocol. This means that in controlling non-NCS endpoints (such as IAD, MGCP endpoints, and so forth), the BTS 10200 provides PCMM-based QoS services. The system sends MM-COPS to a Policy Server, which in turn exchanges QoS control messages with the CMTS or aggregation router.
This feature includes the following new parameters and functionalities:
•
•
•
•
•
Fax, Modem, and TDD Handling Enhancements
Release 5.0 enhances the fax, modem, and TDD handling feature, using call agent-controlled strict mode and Codec up-speed for modem, fax and TDD calls.
QoS Gate Audit
In Release 5.0, the QoS Gate Audit feature provides the BTS 10200 two new functionalities:
•
•
The Gate Memory Audit and the Gate Status Audit functions are both provisionable through the BTS 10200 CLI.
Operational Features
XML Over SOAP
In Release 5.0, the Cisco BTS 10200 Softswitch supports Extensible Markup Language (XML) over Simple Object Access Protocol (SOAP). The XML over SOAP feature provides a SOAP communication layer for the acceptance and translation of specific BTS 10200 XML requests. These XML requests provide access to command templates and command executions for BTS 10200 provisioning, status/control, report generation, etc. The goal of XML over SOAP interface is to provide a provisioning method that parallels the CLI and CORBA in capability.
Using the SOAP transport layer with the XML schema, users populate fields in standard templates to generate command execution. The command templates are generated by the BTS 10200 CPI/CPM CommandTable and CommandParameter Table.
Ability To Perform Full System Backup With Reduced Duration In Simplex Mode
Cisco BTS 10200 FSB does not require any single Cisco BTS 10200 network element (EMS, CA, FS, BDMS) to be in simplex mode for more than 20 minutes.
CDB File Naming Convention
The Cisco BTS 10200 system stores raw call detail blocks (CDBs) in a flat file, ASCII-based format, on the persistent store associated with the Bulk Data Management System (BDMS) for retention purposes. The BTS 10200 stores a minimum of 10 megabytes of billing records in a circular file implementation. This data is subsequently sent to the specified remote accounting office, billing server or mediation device via the File Transfer Protocol (FTP) or optional Secure File Transfer Protocol (SFTP).
The BTS 10200 provides a configurable option for how CDB file names are constructed. The file-name format is either the current native format or a new format based on the alternate CDB file naming feature. This is based on the PacketCable EM file naming convention which includes ECN #EM-N-04.0186-3.
The Native format (Default) CDB File-Naming format is outlined as follows.
By default, the Cisco BTS 10200 names CDB files according to this format:
<prefix>-<CA ID>-(0/1){+/-}HHMMSS-yyyymmdd-hhmmss-<sequence-number>-<state>
Where:
•
•
•
•
•
•
•
–
–
–
The BTS 10200 can optionally use the ALT CDB File-Naming format, which is based on the Alternate CDB FILE Naming feature. That is based on the PacketCable EM file naming convention, which includes ECN #EM-N-04.0186-3.
The BTS 10200 uses the following format [R-0431] if -CdbFileName PacketCable is specified in platform.cfg:
<prefix>_yyyymmddhhmmss_3_<record type>_<CMS ID>_<sequence num>.ascii[.tmp] tb06_20050112121948_3_0_55555_000002.ascii.tmp•
•
•
•
•
•
•
•
SUN 1280 (12 CPUs)
The BTS 10200 supports the SUN 1280 (12 CPUs) as the processor engine for the BTS's EMS and Call Agent.
Enhanced Software Upgrade
Release 5.0 provides an enhanced upgrade procedure that is more automatic, reducing the number of steps significantly. However, the benefits take place starting with Release 5.0 going forward, for patches to that release. These benefits include a reduction in manual steps to perform, and significantly less time to upgrade, audit, and fall back.
Note
The goals for the enhanced software upgrade are to:
•
•
•
•
•
Some of the key enhancements to the software upgrade include:
•
–
–
–
–
–
–
•
–
–
–
•
–
–
•
–
–
•
–
–
•
–
–
–
–
•
–
–
–
Broadband Telephony Services Status
The Broadband Telephony Services Status (BTSSTAT) software utility provides status information for the entire Cisco BTS 10200 Softswitch system. It can run on any Cisco BTS 10200 Softswitch host and report the status of all the network elements in the Cisco BTS 10200 Softswitch system, including those not on the same host. BTSSTAT is designed to be fast and secure.
The operator can execute the btsstat command from the UNIX shell on any host of a Cisco BTS 10200 Softswitch system. The operator can be any valid UNIX user.
The output of BTSSTAT includes the network element ID, side, host name, version, replication status, and redundancy status of every Cisco BTS 10200 Softswitch network elements. All of the results appear in one screen.
By default, BTSSTAT relies on /etc/opticall.cfg to find the host name for each Cisco BTS 10200 Softswitch network element, and uses the default TCP port numbers of the Platform Application Services (PAS) server on each side of the network element to establish an SSL connection to it. You can run BTSSTAT from a non-Cisco BTS 10200 Softswitch host, provided that the host can establish an SSL connection to the target Cisco BTS 10200 Softswitch host.
Security Advisory Due to Default User Names and Passwords
Installation scripts prior to this release populated default system accounts with default user names and passwords. If the installer did not change these, the BTS 10200 was left vulnerable with well-known default passwords. Later releases prompt username and password changes at installation via the install scripts. Please see Cisco bug ID: CSCsb00127 for fix information.
200K Subscriber DB Soft Limit
The SUN 1280 (8) and 1280 (12) CPUs can support a 200K database.
Transaction Throttling Capability
Cisco BTS 10200 Softswitch supports transaction throttling, which is an optional feature that can be disabled or enabled. This feature provides:
•
•
•
•
The measurement-throttle-summary measurement report contains threshold, throughput, total response time, and average response times for CLI, MNT, FTP, CORBA, SNMP, and SOAP session types. The measurement report contains four values for each provisioning adapter and period: the number of commands executed (throughput), the configured threshold, the total response time and the average response time. The response time is measured in milliseconds, and is the average for all commands executed during the collection period. The database stores records for the last 48 hours.
Use the "sum" parameter to add multiple records together for multiple periods in one record. The "sum" parameter then returns totals for the previous 24 hours. The number of returns is dependent on the parameters specified. Both sum and tail=96 must be included to receive the last 24 hours if the reporting period is the default of 15 minutes. If the sum is specified without tail, start-time, or end-time, the command returns an error.
For the measurement-throttle-summary command alone, the response time averages are weighted across all periods in the report. This is true whether the sum parameter is used or not.
SNMP Access to Current Alarms
The BTS 10200 SNMP Access to Current Alarms feature allows you to query current active alarms via SNMP. This feature allows your OSS to retrieve the most recent active alarms that are outstanding in a BTS 10200 system, so that abnormal or potentially abnormal conditions can be addressed or monitored. Access through standards-based SNMP allows OSS and similar tools to be used and customers are not tied to a BTS 10200 Softswitch-specific CLI syntax. The external interface to access the SNMP branch for current alarm information is contained in the OID branch.
User administration is not required to activate this feature. Customer NMS/OSS systems accesses the SNMP branch via standard SNMP protocol. There are no changes to the operator interface. Since there are changes to the SNMP mib, the NMS/OSS is required to reload the latest opticall.mib to get the definitions of the alarms.
Core File Monitor
The Cisco BTS 10200 Softswitch Core File Monitor feature provides BTS 10200 customers with an alarm notification whenever a core file is generated on a BTS 10200 platform system. The feature also removes core files automatically when disk space is critically low or when the core file has aged beyond a maximum allowable time.
Core files are generated and stored in the bin directory for the binary executable which generated the core. Normally, the operator moves the core files as they are created to another storage area. The monitoring of core files with alarm notification will remind the system operator to perform this process.
Tabular Display of CPI/CPM Data
The Tabular Display of CPI/CPM Data enables the Cisco BTS 10200 Softswitch to display current alarms, alarm history and event history in tabular form. The underlying CPI layer modification allows the display of commands in tabular form. The output of the show alarm and show alarm-log command provides one alarm per row. Each of the reported fields gives columns in the tabular output. This makes the outputs much easier to capture and print. CPI layer changes facilitate the tabular display of alarms. The CPI layer changes also allow the tabular display of other data through derived Request Managers.
The following are new commands for the tabular display feature:
•
•
•
An example of the output of executing of one the three commands follows:
CLI>show tab-alarm
Configurable Default Values in Subscriber Provisioning
The Configurable Default Values in Subscriber Provisioning feature adds reliability, robustness, and consistency to the Cisco BTS 10200 Softswitch provisioning mechanism.
Previously, you could configure a default value for a token only if the token was mandatory. In addition, there was no data validation of the user-configured default value. This feature provides the following new capabilities:
•
•
•
•
Overload Control
The Overload Control feature supports the BTS Call Agent (CA) and Feature Server (FS). Overload Control detects, controls, and manages overload from all types of networks (SIP, SS7, ISDN, MGCP, H.323).
Overload is a switch condition that exists when system resources cannot handle system tasks. Increases in call traffic or messages indirectly related to call traffic usually cause overload.
Detecting Overload
In the detection phase of Overload Control any one of three factors can have the highest MCL. This value dictates the MCL for the entire system. The three factors are:
•
•
•
Computing MCL
The BTS 10200 computes factor levels by calculating averages for each factor. The rate of sampling (number of slots) can be configured per factor (3 - 10 slots). The MCL is set according to a factor level.
Reducing Overload
When MCL exceeds MCL0, Overload Control reduces MCL as follows:
•
•
–
–
–
•
–
–
Slowing Overload Reduction
Sudden abatement reduction may cause MCL to rapidly increase again. To counteract MCL "bouncing", MCL reduces one MCL level at a time, regardless of how low computed MCL becomes. This permits the system MCL to reduce gracefully over a number of intervals.
Damping also slows the system MCL. Damping values are in milliseconds and define the shortest amount of time an MCL level can exist. You can configure the damping time for each MCL level in olm.cfg using:
•
•
•
•
Call Processing Measurements
Table 5 lists the new call processing measurements provided to support Overload Control.
Service Interaction Manager Measurements
Table 6 lists the new Service Interaction Manager measurements provided to support Overload Control.
Traffic Measurements Monitor Counters
Table 7 lists the new Traffic Measurements Monitor (TMM) measurements provided to support Overload Control.
Miscellaneous Measurements
Table 8 lists additional measurements added to support Overload Control.
Modified H323-GW Table
The following tokens are added to the H323-GW Table to support Overload Control.
Syntax Description
Modified H323-TG-PROFILE Table
A new token, PEER-GW-OVERLOAD-TIMER, is added to the H323-TG-PROFILE Table to indicate that a trunk group is congested. When this timer is started, traffic will not be routed to the trunk group. When the timer expires, traffic will resume to the trunk group.
Syntax Description
Pre-Manual Switchover Integrity Diagnostic Utility
The Pre-manual Switchover Diagnostic Utility feature provides the system health information of the switchover target so that Cisco BTS 10200 Softswitch customers can decide if they want to perform manual switchover.
Customer service providers often perform periodic switchovers during maintenance windows (after midnight and early in the morning). They ensure that the standby system is functional and clean up any system abnormalities.
In order to facilitate the switchover operational practice, this feature provides a diagnostic tool/utility to allow the operator to verify the operational status of the standby system/platform and see whether it is in a ready state to switchover, prior to executing the switchover command.
MGCP Asynchronous DNS Lookup
If the DNS server(s) fail or exhibit poor response times, synchronous DNS function calls could seriously impact call processing by throttling new calls and failing existing calls. Very slow DNS responses from improperly provisioned media gateway (MGW) fully qualified domain names (FQDN), or slower responses from any MGW FQDN(s) that are not provisioned in the DNS server, seriously impact existing call processing. Even call processing for all MGWs that have very fast DNS responses is impacted. The BTS 10200 MGCP Asynchronous DNS lookup feature makes the BTS 10200 robust in the face of DNS failures. The scope of this feature is initially limited to name lookup only, not other query types, and the use of the feature is limited to the MGCP interface only. Protocols used include all gateway control protocols (xGCP) including PacketCable NCS and TGCP protocols.
The BTS 10200 MGCP Asynchronous DNS Lookup feature launches asynchronous DNS lookups to resolve FQDN of the media gateways while attempting to send MGCP messages. It also makes the resolved IP addresses for FQDN available to standby side of the BTS 10200 for instant use without launching new DNS queries. When MGW reboots, the BTS 10200 re-confirms its IP address from DNS server and updates it in the BTS 10200 internal MGW DNS cache if the IP address is different. When the BTS 10200 is started or restarted, it starts using the IP address in the BTS 10200 internal MGW DNS cache if available and also triggers reconfirmation of that IP address from the DNS server. The BTS 10200 provides the configuration option to accept/reject and confirm/ignore the IP address of any FQDN and update the IP address if it is different.
Additionally, other subsystems of the BTS 10200 can make use of this asynchronous DNS lookup functionality in order to improve reliability of the BTS 10200.
Automatic Restart
The Cisco BTS 10200 Softswitch Automatic Restart feature is beneficial to customers because the BTS 10200 attempts to automatically restart a platform (EMS/FS/CA) to STANDBY that has become OOS-FAULTY and shut down. Currently, the BTS 10200 does not restart a platform in this situation, leaving the active platform running in a vulnerable simplex mode until the standby platform is restored manually.
Benefits of this feature:
•
•
•
Note
LERG Support in OAMP
The Cisco BTS 10200 Softswitch supports the Local Exchange Routing Guide (LERG) specification in the BTS 10200 operation, administration, maintenance, and provisioning (OAMP) application.
This feature enables you to utilize the routing data from the LERG files, and it allows you to view, add, delete, and change the data stored in the LERG tables. Also, it provides the means to schedule future LERG updates. A new set of commands and a script have been added to provision the LERG data.
The BTS 10200 operations and maintenance (OAM) application allows users to configure the LERG data from the LERG6INS.DAT and LERG6.DAT files. The following two mechanisms are provided on the BTS 10200 OAM application:
•
•
Other Enhancements
This section describes the changes made to existing features for Release 5.0. These are not new features, but rather enhancements or changes made to existing features.
The descriptions in this section are brief; for more information, refer to the Cisco BTS 10200 documentation. You can view the Document Change History table in the Preface of each book to see what changes have been made to the book for this release.
MGCP-Based Enhancements
In Release 5.0, the Cisco BTS 10200 Softswitch MGCP capabilities are enhanced as follows:
•
•
The following MGCP-based features of the Cisco BTS 10200 Softswitch have been added or enhanced:
•
•
•
The system uses the AuditConnection command to audit the status of connections to any MGCP-based endpoint. This allows the system to discover call identifiers corresponding to stray connections, that is, connections which exist on an MGCP endpoint but are not accounted for on the Cisco BTS 10200 Softswitch. An example of a stray connection is a ringing endpoint for which no call is being set up. These stray connections can occur, for example, on endpoints that were engaged in a three-way call (TWC) during a CA failover. The system can send an AuditConnection command to recover the connection state from the MGCP device after a CA failover. A provisionable parameter in the Cisco BTS 10200 Softswitch database allows the service provider to enable or disable the AuditConnection functionality for each MGW profile. The system uses the MGCP-compliant DeleteConnection command to clear stray connections.
CALEA Enhancements
The Enhanced CALEA feature in Cisco BTS 10200 Release 5.0 implements new messages and attributes defined in newer versions of the PacketCable specifications. In addition, the BTS 10200 has enhanced the internal algorithms to select the call-content IAPs according to the requirements associated with support of the P-DCS-LAES header for performing the surveillance function across multiple CMSs. These enhancements required additional development in the Delivery Function server so that it could continue performing surveillance functions for call-scenarios that include a single CMS or multiple CMSs. For a case in which the event Enhanced Delivery function server is not available, the BTS 10200 provides configuration options (EM-PROTOCOL-VERSION-MAJOR and EM-PROTOCOL-VERSION-MINOR flags in the ESS table) which enable the BTS to interoperate with existing software versions of the Delivery Function server.
Note
Note
When an origination or termination attempt is detected for a call under surveillance, the BTS 10200 issues call-data event messages to the Delivery Function device to provide call-identifying information. The BTS 10200 follows the procedural and encoding guidelines specified in PKT-SP-EM1.5- I01-050128 Appendix A for sending these event messages. For a detailed list of all the call-data event messages supported by the BTS 10200, refer to the Cisco BTS 10200 Softswitch Enhanced CALEA Feature Module.
When a call under surveillance spans multiple call management systems (CMSs), one CMS might not have access to all call identifying information or call-content intercept-access points to perform surveillance. RFC-3603 and PKT-SP-CMSS1.5- I01-050128 specify the procedure for a CMS to request other adjacent CMSs to perform surveillance on its behalf. According to these procedures, a CMS can request a CMST (CMS at the terminating side of the call) or a CMST (CMS at the originating side of the call) to perform surveillance functions. The CMS uses the SIP P-DCS-LAES header to make the request.
The Cisco BTS 10200 supports the sending and receiving of the P-DCS-LAES header in various SIP messages using guidelines specified in PacketCable specification PKT-SP-CMSS1.5- I01-050128. The detailed compliance with the procedures specified in the PKT-SP-CMSS1.5- I01-050128 specification is provided in Table 3. The following statements describe how the Cisco BTS 10200 uses the SIP P-DCS-LAES header to implement CALEA.
•
–
–
–
–
–
•
•
•
–
–
Table 9 describes the requirements included in the PacketCable specification PKT-SP-EM1.5-I01-050128, Appendix A and indicates the level of compliance provided by the CALEA feature in Cisco BTS 10200, Release 5.0.
Table 10 lists the requirements presented in the PacketCable specification PKTCBL 1.5 CMSS Section 7.7.2, Appendix D and indicates the level of compliance provided by the Enhanced CALEA feature for Cisco BTS 10200 Release 5.0.
Note
Table 10 Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D
Section 7.6.1, Procedures at Originating Exchange (REFER Method)
REQ5025
The CMS originating a REFER must include additional header parameters for P-DCS-Billing-Info, and should include the additional header parameters for P-DCS-LAES, and P-DCS-Redirect, as specified in Section 7.7.
Not applicable
BTS does not originate REFER message on CMSS trunk.
Section 7.7.2, P-DCS-LAES
REQ7454
REQ7455
REQ7456
The LAES-BCID field must always be present. The LAES-CCCID field must be present when the LAES-Content field is present. The LAES-Key field must not be included.
Compliant
REQ7457
When CMSO receives a 3XX Redirect response containing a P-DCS-LAES header in response to an INVITE, or receives a REFER request containing a P-DCS-LAES header in the Refer-To header for an active dialog, it must copy the received P-DCS-LAES header into the subsequent INVITE that is generated as a result of the REFER or Redirect.
Compliant
Section 7.7.2.2.1.1, Redirected Call Ends Early
REQ7458
If CMSO receives a REFER request or 3XX Redirect response message as described above, but the call ends before the subsequent INVITE is sent (if, for example, the call is abandoned), then CMSO must send a Surveillance Stop message to its local DF containing the following information:
•
•
•
•
•
Compliant
Section 7.7.2.2.1.2, P-DCS-LAES Header Cannot Be Included in Subsequent INVITE
Section 7.7.2.2.1.2.1, CMSO Chooses to Perform Requested Surveillance
REQ7459
If CMSO chooses to perform the requested call-data surveillance function, it must send a Signaling-Start message to its local DF containing the following information:
•
•
•
Compliant
REQ7460
If CMSO is already monitoring the call (for example, due to an outstanding lawfully authorized surveillance order on the originating subscriber) when it receives a P-DCS-LAES header, it must send a second Signaling-Start message to its local DF, containing the appropriate parameters as specified in the preceding item (REQ7459).
Compliant
REQ7461
If the P-DCS-LAES header received in the 3XX Redirect response or REFER request also indicates that call content surveillance is to be performed (in addition to call data surveillance), then CMSO must allocate a local CCCID for the call and request the CMTS of the originating line (or MG of the originating trunk if the originator is off-net) to provide a copy of the call content to the local DF.
Compliant
REQ7462
In addition to the call-data information specified in REQ7459, CMSO must include the following data in the Signaling-Start message to the local DF:
•
•
•
•
Compliant
Section 7.7.2.2.1.2.2, CMSO Chooses to Perform Call-Data but Not Call-Content
REQ7463
If the P-DCS-LAES header received in the 3XX Redirect response or REFER request indicates that both call-data and call-content surveillance are to be performed, but CMSO chooses to support only call-data (and not call-content), CMSO must send a Signaling-Start message to its local DF containing the call-data information specified in Section 7.7.2.2.1.2.1.
Compliant
REQ7464
CMSO must send a Surveillance-Stop message containing the following information:
•
•
•
Compliant
7.7.2.2.1.2.3 CMSO Chooses Not to Perform the Requested Surveillance
REQ7465
If CMSO chooses not to perform any of the requested surveillance functions, it must send a Surveillance-Stop message to its local DF containing the following information:
•
•
•
•
Not applicable
No scenario is identified where CMSO (if BTS) chooses not to perform the requested surveillance.
REQ7466
An indicator specifying that both call-data and call-content surveillance are to be stopped.
Not applicable
No scenario is identified where CMSO (if BTS) chooses not to perform the requested surveillance.
Section 7.7.2.3.1, Terminating Line is Able to Accept the Call:
REQ7467
If the terminating line is able to accept the call and a local outstanding lawfully authorized electronic surveillance order exists for the line or if a P-DCS-LAES header was received in the INVITE, CMST must send a Signaling-Start message to the local DF containing the identity of the terminating line and the local BCID assigned to the call. (The local BCID is a mandatory field.)
Compliant
(Identity of terminating line is assumed to be defined as the phone number associated with the terminating line. Signaling start is sent for the terminating party as identified by the information in the INVITE message.)
If the call is forwarded by the initial terminating party to another subscriber, the identify of the final terminating party should be derived from the last Redirection message associated with the call.
REQ7468
If a P-DCS-LAES header was received, CMST must include the following additional information in the Signaling-Start message:
•
•
Compliant
REQ7469
If either the local electronic surveillance order or the received P-DCS-LAES header indicates that call-content surveillance is to be performed, the CMST must allocate a local CCCID for the call and request the CMTS of the terminating line (or MG of the terminating trunk if the terminator is off-net) in order to provide a copy of the call content to the local DF.
Compliant
REQ7470
In addition to the call-data parameters, the CMST must include the local CCCID in the Signaling-Start message it sends to the local DF.
Compliant
REQ7471
If a P-DCS-LAES header was received that indicates that call-content surveillance is to be performed, CMST must include the following additional information in the Signaling-Start message:
•
•
Compliant
REQ7472
When the call ends, CMST must send a Surveillance-Stop message to its local DF containing the local BCID and indicating that both local and remote call-data and call-content surveillance are to be stopped.
Compliant
Section 7.7.2.3.2, Terminating Line Is Unable to Accept the Call
REQ7473
If CMST receives an INVITE request containing a P-DCS-LAES header, and the terminating endpoint is not able to accept the call for some reason (for example, line is busy, line is unknown), and CMST does not need to otherwise initiate a surveillance session, CMST must send a Surveillance-Stop message containing the following information:
•
Note
•
•
•
Compliant
Section 7.7.2.3.3, Terminating CMS Is Unable to Perform Call-Content Surveillance
REQ7474
If CMST receives an INVITE containing a P-DCS-LAES header requesting call-data and call-content surveillance, and CMST is unable to perform the call-content surveillance for some reason (for example, call routed to voice mail server), CMST must continue to perform the call-data surveillance as specified in Section 7.7.2.3.1.
Compliant
REQ7475
Once this procedure has established the local-to-remote call-data surveillance information in the local DF, CMST must send a Surveillance-Stop message containing the following information:
•
•
Compliant
Section 7.7.2.3.4, Terminating CMS Redirects or Transfers the Call
REQ7476
If CMST is required to perform surveillance on a call (either as a result of terminating to a subscriber with a lawfully authorized surveillance order, or as specified in the P-DCS-LAES header of the INVITE message from the CMSO), but the call is redirected or transferred to a new terminating line, CMST must send a Signaling-Start message to the local DF containing the identity of the terminating line and the local BCID assigned to the call.
Compliant
REQ7477
If a P-DCS-LAES header was received, CMST must include the following additional information in the Signaling-Start message:
•
•
Compliant
REQ7478
If either the local electronic surveillance order or the received P-DCS-LAES header indicates that call-content surveillance is to be performed, CMST must allocate a local CCCID for the call.
Compliant
REQ7479
In addition to the call-data parameters, CMST must include the local CCCID in the Signaling Start message to the local DF.
Compliant
REQ7480
If a P-DCS-LAES header was received indicating that call-content surveillance is to be performed, then CMST must include the following additional information in the Signaling-Start message:
•
•
Compliant
Section 7.7.2.3.4.1, CMST Sends REFER Request or Redirect Response1
REQ7481
If CMST transfers or forwards the call by sending a REFER request or Redirect response to the originating CMS, then it must include a P-DCS-LAES header in the Redirect response or in the Refer-To header of the REFER request.
Compliant
REQ7482
The P-DCS-LAES header must contain the following information:
•
•
Compliant
REQ7483
If CMST is required to perform call-content surveillance for the call, it must include the following additional data in the P-DCS-LAES header:
•
•
Compliant
REQ5178
If the P-DCS-LAES header is present in the 183-Session-Progress response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), CMSO must include this information in the Authorization for Quality of Service, or must signal this information to the device performing the intercept (for example, a media gateway).
Compliant
REQ5221
REQ5349
If a P-DCS-LAES header is present in the 3xx response, CMSO should include that header unchanged in the reissued INVITE.
Compliant
1 The Cisco BTS 10200 does not support sending a REFER message.
Event Management Enhancements
Release 5.0 enhances BTS 10200 event management in several areas.
Alarm Subsystem Enhancements and Redesign
The Alarm Subsystem Enhancements and Redesign feature provides an alarm filtering and correlation capability. The first step is to convert the alarm generation from the old API to a new API. The new API provides necessary information to construct unique component IDs, which are pivotal to alarm filtering and correlation.
Report Alarm Feature
The Report Alarm feature provides the alarm report capability for the end user. The alarm report capability allows the user to output the alarm information to a file in either CSV format or XML format. The end user can also filter the output, as is done with the show alarm command.
The signaling events and alarms listed in Table 11 are migrated to the new API to enable the Cisco BTS 10200 Softswitch Event Management Enhancements feature.
The maintenance events and alarms listed in Table 12 are migrated to the new API to enable the Cisco BTS 10200 Softswitch Event Management Enhancements feature.
The new report alarm CLI command enables the user to generate alarm reports in either CSV format or XML format. It has the same set of options as show alarm command except that it has no auto_refresh and start_row options, but has output and output_type added.
Examples
CLI> report alarm output=test1;CLI> report alarm output=test2; output_type=CSV;CLI> report alarm output=test3; output_type=XML;After report alarm command successfully replies, the output file can be viewed at the following URL:
https://<BTS_EMS_host_name_ or_IP_address>/report/Alarm_<output>.<output_type>
Note
Syntax Description
Event Message Enhancements
Release 5.0 provides new and enhanced event message (EM) fields.
Note
EM Generation Details
Table 13 lists the EMs generated by specific call configurations.
Table 14 lists the specific EMs that can be generated by the CMS and MGC.
Table 15 lists the EMs for a call and the triggers that generate them (single zone scenario only) in the appropriate logical entities running in the Cisco BTS 10200 Softswitch (CMS/MGC).
Table 16 lists the PacketCable 1.0 features, the EMs generated for them, and the event that triggers the message. Some of the triggering events include the logical entities—Originating CMS (O-CMS) and Terminating CMS (T-CMS)—running in the Cisco BTS 10200 Softswitch.
Table 16 PacketCable 1.0 Features and Associated EMs
911 service—Similar to on-net to off-net call on a unique trunk group ID.
None
—
—
Other N11 services—Similar to above
None
—
—
Database query
a.
on special trunkNone
—
—
b.
db_query
O-CMS on receipt of response to database dip
Query types:
1 = Toll Free Number Lookup
2 = LNP Number Lookup
3 = Calling Name Delivery Lookup
If the query is successful—that is, if the query returns the calling party's name—the query type (1, 2, or 3) is included in the EM:
•
•
If the query fails, no EM is sent.
Operator service
a.
None
Called party number 0 is replaced by Operator Service Provider number.
Only call routing.
b.
Only call routing.
Call block service (with new call to announcement server)
Service instance
O-CMS and T-CMS decide to block call.
If announcement server is connected, event messages are generated for call with same BCID.
Call waiting
a.
Service instance
O-CMS and T-CMS when call waiting is initiated. Second call BCID for service instance
Only two calls, one active and one on hold, are required. Each half-call generates an EM. A half-call for an on-net announcement server for call waiting tone need not generate an EM. Here is an example of a call scenario:
A calls B, C calls A:
(A -> B, C -> A)
BCID1 for A(O), other leg BCID2
BCID2 for B(T), other leg BCID1
BCID3 for C(O), other leg BCID4
BCID4 for A(T), other leg BCID3BCID4 for CW service instance, related BCID = BCID1
b.
not supported
—
—
Call forwarding
Service instance
CMS (O/T) when forwarded call leg is initiated.
A calls B, B forwards to C:
(A -> B -> C)
BCID1 for A(O), other leg BCID2
BCID2 for B(T), other leg BCID1
BCID3 for B(O), other leg BCID4
BCID4 for C(T), other leg BCID3
BCID3 for CFW service instance, related BCID=BCID2Return call
(with caller ID privacy restriction)CMS-CMS signaling is not supported in this release.
a.
Service instance
O-CMS on feature initiation.
—
b.
Not supported
—
—
Repeat call (*66)
CMS-CMS signaling is not supported in this release.
a.
Service instance
Repeat call is initiated.
Separate BCID for service instance.
b.
Not supported
—
—
Voice mail (voice mail server on off-net)
None
—
—
Deposit and retrieval: similar to on-net to off-net call
None
—
—
Message waiting indicator
None
—
No event messages for message waiting.
Privacy indicator
Signaling start
—
Indicates whether the system populates field #12 of the EM with the calling party service (privacy setting) for the calling party.
This attribute uses the previously undefined field #12 in PKT-SP-EM1.5-I02-050812.
1 "O" = Name is out of area, unknown, or not available. "P" = Name presentation is restricted.
North American Numbering Plan Administration (NANPA) Enhancements
These enhancements allow the Cisco BTS 10200 Softswitch to generate a NANPA report for audit purposes. The NANPA report provides data based on the DN2SUBSCRIBER table for the Numbering Resource Utilization/Forecast (NRUF) report.
The NANPA audit report provides information on data that is provisioned in the switch concerning Code Holder, Block Holder, Native, and Non Native. The report input can be 10 digits or NPANXX, which requires the import capability of LERG updates as well as LCADS for FCC-required NANPA audit compliance.
This feature allows the Cisco BTS 10200 Softswitch to have a Number Block table that has no dependencies for routing or call classification. The Number Block Table is a single table that is the sole reference for NANPA audits. This table can be customized. Updates to Number Block tables can come from data imported from other tables, changes from office-code updates, or manual updates.
The Number Block Table fields consist of the following:
Number Block: NPA to NPA-NXX-XXXX
Code Holder = Y/N
Block Holder = Y/N
Native = Y/N
Non-Native = Y/N
For FCC-required NANPA audit compliance, the report input is NPANXX. In markets outside of NANPA, the input can be based on either the combination of the national destination code (NDC) and the exchange code (EC), or just the EC.
The data for NRUF reporting is generated based on either the NDC or the EC. The service provider can use the report dn-summary command to generate the following reports:
•
•
The Cisco BTS10200 Softswitch, Release 5.0 introduces support for the Local Exchange Routing Guide (LERG), which enables the generation of NRUF reports based on:
•
•
LNP Event and Measurement Enhancements
Release 5.0 provides new and enhanced Local Number Portability (LNP) events and measurements.
Table 17 describes measurements and events added to the Cisco BTS 10200 Softswitch for Release 5.0:
Note
Call Processing Measurements
Note
AIN Service Measurements
The following Advanced Intelligent Network (AIN) services measurements are for this feature. For a complete description of these measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Call Processing Events and Alarms
Note
CALLP(42)
CALLP_LNP_OWN_LRN_MISROUTED
Modified DN2SUBSCRIBER Table
The description of the NP_RESERVED token in the DN2SUBSCRIBER table is modified as follows:.
Syntax Description
Other Features
Changes from Previous Releases
In Release 5.0, users can no longer change ntp_server from the CLI, but still can view it. The command has been marked as obsolete in the Release 5.0 CLI Guide.
Billing Features
Additional QoS Parameters in the Billing Records
The BTS 10200 captures QoS related data/call in the usage record (CDR). If data is not available, it is recorded as not available in the CDR. The data of both local and remote QoS statistics as reported by the eMTA/MGW is recorded in the CDR for each endpoint/MGW involved in the call.
In Release 5.0, the following additional QoS parameters are captured:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Billing Timer Resolution in Milliseconds
This feature adds milliseconds to the BTS date format:
yyyy-MM-dd HH:mm:ss:mmm
(where mmm is milliseconds)
The extended format allows users to refine CDR information.
New Documentation
New and Updated Documentation for Release 5.0
Release 5.0 introduces a new set of user documents specifically written for the Cisco BTS 10200 Softswitch Release 5.0 software and hardware. New documentation for Release 5.0 can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/products_feature_guides_list.html.
When used in conjunction with the manuals, these Release Notes provide a comprehensive guide to the Release 5.0 features and operations.
All Cisco BTS 10200 Softswitch user documentation, including prior releases, can be accessed at the following location: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/tsd_products_support_series_home.html.
Cisco Field Notices
In addition to reading the release notes and querying Bug Toolkit for release caveats and fixes, you also should visit the Cisco Field Notice Web site on a regular basis. The site provides information about updates or other issues that may impact your network.
The Cisco Field Notice Web site is located at:
http://www.cisco.com/en/US/customer/products/hw/vcallcon/ps531/prod_field_notices_list.html
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.
