Guest

Release Notes for Release 5.0.x

  • Viewing Options

  • PDF (1.0 MB)
  • Feedback
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x

Table Of Contents

Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x

Introduction

Contents

Before You Begin

System Requirements

Hardware Requirements

Interface Options

Optional Component (Hardware and Software)

Ancillary Hardware

Cisco ITP Signaling Gateways

Software Requirements

Definition of Major, Point, and Maintenance Releases

Release Naming Conventions

Network Time Protocol Software

Optional Software

Component Interoperability

Table Sizes

Operator Access

Installation Notes

Upgrade Procedures

Upgrades and SIP Session Timers

Caveats

Bug Toolkit

New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)

Multiline Variety Package

IDX Soft Limits Enforcement

CMTS Discovery Using the Static Subnet Table Enhancements

Multiple EMS Spindles

PacketCable CMS Subscriber Provisioning with SOAP/XML

CALEA Support for MLHG

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

SIP Server Groups

CORBA Session Manageability

Seasonal Suspend

SIP Name Dialing

Disable Platform Shared Memory Replication

Aggregation ID Subnet

CMTS Discovery Using the Static Subnet Table

Bulk Data Export

Subscriber ID Parameter and DQoS Measurement Counters Support

ENUM Application

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

New Features for Release 5.0

Documentation for Release 5.0

Telephony Features

SIP Triggers

Own Calling Number Announcement

Multiple Directory Numbers

911 Overflow to Announcement

On-Net Routing and LNP for Inter-CMS Routing

CNAM Capability on a Trunk Group

Reception/Processing of DCS-LAES SIP Header

SIP Response Code 302

Limitations

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

Casual Dial Enhancement

Dial Around Indicator in SIP

MWI Manipulation through CLI

Non-IVR Activation and Deactivation of SCF, SCR, SCA, and DRCW

ISDN Backhaul Using IUA and SCTP

MGCP Asynchronous DNS Lookup

Extended Voice Quality Metrics Reporting for MGCP

Internal Secondary Authoritative DNS

Call Tracer

Cluster Routing

Emergency 911 Trunk Connection Loss Alarm

Temporary Disconnect

DTMF Relay Call Agent Controlled Mode

PacketCable Multimedia QoS Enhancements

Fax, Modem, and TDD Handling Enhancements

QoS Gate Audit

Operational Features

XML Over SOAP

Ability To Perform Full System Backup With Reduced Duration In Simplex Mode

CDB File Naming Convention

SUN 1280 (12 CPUs)

Enhanced Software Upgrade

Broadband Telephony Services Status

Security Advisory Due to Default User Names and Passwords

200K Subscriber DB Soft Limit

Transaction Throttling Capability

SNMP Access to Current Alarms

Core File Monitor

Tabular Display of CPI/CPM Data

Configurable Default Values in Subscriber Provisioning

Overload Control

Detecting Overload

Computing MCL

Reducing Overload

Slowing Overload Reduction

Call Processing Measurements

Service Interaction Manager Measurements

Traffic Measurements Monitor Counters

Miscellaneous Measurements

Modified H323-GW Table

Modified H323-TG-PROFILE Table

Pre-Manual Switchover Integrity Diagnostic Utility

MGCP Asynchronous DNS Lookup

Automatic Restart

LERG Support in OAMP

Other Enhancements

MGCP-Based Enhancements

CALEA Enhancements

Event Management Enhancements

Alarm Subsystem Enhancements and Redesign

Report Alarm Feature

Event Message Enhancements

EM Generation Details

North American Numbering Plan Administration (NANPA) Enhancements

LNP Event and Measurement Enhancements

Call Processing Measurements

AIN Service Measurements

Call Processing Events and Alarms

Modified DN2SUBSCRIBER Table

Other Features

Changes from Previous Releases

Billing Features

Additional QoS Parameters in the Billing Records

Billing Timer Resolution in Milliseconds

New Documentation

New and Updated Documentation for Release 5.0

Cisco Field Notices

Obtaining Documentation and Submitting a Service Request


Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x


Revised: December 12, 2008, OL-10355-05

Introduction

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:

Before You Begin

System Requirements

Hardware Requirements

Software Requirements

Component Interoperability

Installation Notes

Upgrade Procedures

Bug Toolkit

New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)

New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)

New Features for Release 5.0

Cisco Field Notices

Obtaining Documentation and Submitting a Service Request

These release notes are updated periodically on an as needed basis and contain important operational information.

Before You Begin


Warning Sun Explorer is installed as part of Release 5.0 builds as a requirement from Sun for resolving hardware issues, but is left disabled. Sun Explorer should not be enabled to run using cron as this is a untested and unsupported configuration.

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 All customers must be operating on the Sun Solaris 10 06/06 operating system (OS) prior to upgrading to Release 5.0, MR1 (5.0.2) or MR2 (5.0.3). Detailed information on installing and upgrading to Solaris 10 06/06 OS can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/prod_installation_guides_list.html.


Note Beginning with Release 5.0 MR1, SUP functionality is disabled by default. If you require SUP functionality be enabled by default, contact Cisco TAC (http://www.cisco.com/tac) to obtain the necessary method of procedure (MOP).


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:

Call Agent/Feature Server (CA/FS)—Two hardware platforms for redundant operation.

Element Management System/Bulk Data Management System (EMS/BDMS) server— Two hardware platforms for redundant operation. The EMS minimum requirements for the Release 5.0 medium configuration is 8 GB.

Two Ethernet switches.


Note Both AC and DC systems require two redundant feeds. We highly recommend that uninterruptable power supplies be provided for both AC and DC systems. For information on the voltage required, refer the Sun Microsystems Web site.



Note The Cisco Technical Assistance Center (TAC) only supports Cisco software running on Cisco-approved hardware configurations. The software is not supported on any other hardware.

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 Before choosing a hardware configuration, consult with your Cisco representative to determine the hardware that will give you the best results based on your network configuration, proposed traffic, and desired call processing power.

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.

Table 1 Host Hardware Requirements

Hardware Platforms
Processors
Required Memory
Disk Size

Sun Fire V240

2 x 1280

8 GB

2 x 73 GB

Sun Netra 240

2 x 1280

8 GB

2 x 73 GB

Sun Fire V245

2 x 1500

16 GB

4 x 73 GB

Sun Fire V440

4 x 1280

8 GB

4 x 73 GB

Sun Netra 440

4 x 1280

8 GB

4 x 73 GB

Sun Fire V445

4 x 1593

16 GB

2 x 73 GB

Sun Netra 1280

4 x 1200

8 GB

2 x 73 GB

Sun Netra 1280

8 x 1200

16 GB

2 x 73 GB

Sun Netra 1280

12 x 1200

24 GB

2 x 73 GB

Sun Fire V1280

4 x 1280

8 GB

4 x 73 GB

Sun Fire V1280

8 x 1200

16 GB

2 x 73 GB

Sun Fire V1280

12 x 1200

24 GB

4 x 73 GB

Sun Netra 1290

8 x 1500

32 GB

2 x 146 GB


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 In Release 5.0.x, the Cisco BTS 10200 system must use the 4/2 configuration.


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 Even though the LCD is capable of displaying graphical content, the HTTP-FS uses only text-based menus.


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 The software for both the GUI-FS and the MBA are included in the software supplied with your Cisco BTS 10200 Softswitch.


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

Part Number
Description

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.

Table 3 DC Systems 

Part Number
Description

WS-C2950M-XL-EN-DC

Cisco Catalyst 2950m xl DC 10/100 Autosensing Fast Ethernet Switch

WS-C2970G-24TS-E-DC

Cisco Catalyst 2970 x1 DC 10/100 Autosensing Fast Ethernet Switch


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 If using SS7 with Release 5.0, you must purchase ITP equipment as described here.


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 When running ITP with Cisco BTS 10200, you might encounter an "Unrecognized Parameter" error message. The message appears because the Cisco BTS 10200 supports an optical SCTP feature that is not supported on the ITP, but it does not affect calls or performance.

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:

Cisco BTS 10200 uu.ww.xx.yzz Pxx (for example, in the Release Notes)

900-uu.ww.xx.yzz Pxx (as a part number on a CD)

where:

uu is the (major) release ID (0-99)—for example, 900-03.ww.xx.yzz

ww is a point (minor) release (within a major) (0-99)—for example, 900-03.05.xx.yzz

xx is the maintenance package number (within a point) (0-99)—for example, 900-03.05.03.yzz

y is the Software State, such that—for example, 900-03.05.03V00

D = Development load

I = Integration load

Q = System test load

F = Field verification ready

V = Verified (specified for externally available)

When Pxx is at the end of the release numbering, a patch has been applied. P is the patch, and xx is the patch numbering.

Some naming convention examples are:

900-04.05.00.V01

900-04.05.01.V00

900-05.00.00.V00

900-05.00.02.V00

Network Time Protocol Software


Note Cisco BTS 10200 automatically installs and runs the Network Time Protocol (NTP) time synchronization software. However, you must specify which NTP servers to use with your installation, and you must use NTP servers that are rated STA 3 or better. For information on how to configure the NTP servers, refer to the Release 5.0 installation procedure.


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 Users should never attempt to modify the system date or time in their Cisco BTS 10200 Softswitch host machines while system components (CA, FS, EMS, and BDMS) are running. This can cause the system to have serious problems. Allow the Solaris OS to obtain the time automatically through NTP services.

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 5.0 is the only version intended to work with Cisco BTS 10200 Release 5.0.x


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 

Platform(s) Tested
Function(s) Tested
Protocol(s) Tested
Load(s) Tested

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

Embedded MTAs
     

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

SIP Endpoints
     

Linksys PAP2

SIP endpoint

SIP

3.1.5(Lsd)

Cisco 7940

SIP phone

SIP

6.2

Cisco 7960

SIP phone

SIP

6.2

Policy Servers
     

Camiant Multimedia Service Controller

Policy server

 

2.3

CableMatrix On-Demand Service Platform (ODSP)

Policy server

 

1.0.0b6

ENUM (Release 5.0 MR1)
     

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. Installing and cabling the hardware

2. Running the jumpstart procedure

3. Running the software (application) installation procedure

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 Do not modify any operating system parameters that the Cisco BTS 10200 Softswitch Jumpstart installs.


Note The application installation procedure is for duplex systems, the only installation type supported for Release 5.0.x.


Upgrade Procedures


Note All customers must be operating on the Sun Solaris 10 06/06 OS prior to upgrading to Release 5.0.x. Detailed information on installing and upgrading to Solaris 10 06/06 OS can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/prod_installation_guides_list.html.


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 Click here to log onto Bug Toolkit. You must have a Cisco.com user name and password.

Step 2 Click the Launch Bug Toolkit hyperlink.

Step 3 If you are looking for information about a specific caveat, enter the ID number in the "Enter known bug ID" field.

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 Cisco BTS 10200 Softswitch appears after you type the first two letters, B and T.


Step 4 Click Next. The Cisco BTS 10200 Softswitch search page appears.

Step 5 Select the filters to query for caveats. You can choose any or all of the available options.


Note To make queries less specific, use the All wildcard for the Major/Minor release, Features/Components, and keyword options.


Step 6 Next to version (see Definition of Major, Point, and Maintenance Releases):

Select Major for the major releases (that is 5.0, 4.5, 4.4, 4.2, 4.1, 3.5).

Select Minor Release for more specific information—for example, selecting major Version 5.0 and minor Version 1 queries for Release 5.0.2 caveats.

Select the Features or Components to query.

Use keywords to search for a caveat title and description.

Select the Advanced Options, including the Bug Severity level, Bug Status Group, and Release Note Enclosure options.

Click Next.

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

IDX Soft Limits Enforcement

CMTS Discovery Using the Static Subnet Table Enhancements

Multiple EMS Spindles

PacketCable CMS Subscriber Provisioning with SOAP/XML

CALEA Support for MLHG

CALEA Support for SIP Triggers

Ring Tone Mapping with SIP Triggers

Call Disposition—Delineate Blocked Calls from Incomplete Calls

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:

Handset provisioning tables may increment past the bounds.

Dynamic tables may increment past the bounds.

Limited subscriber provisioning may cause subscriber tables to increment past the bounds.

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:

IDX library provides an API to set the soft limit (the maximum allocatable index) for an IDX table.

RDM process automatically exchanges the table size information and sets the soft limit when the platform starts up.

The soft limit stays even when the other side goes down.

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:

Non-DQoS call display

Refreshing IP address cache

Termination connection test with the DQoS command

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:

Login/logout

Add a new subscriber

Delete an existing subscriber

Modify an existing subscriber

Get/Query an existing subscriber

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 Call Identifying Informaiton for Extention dialing i.e. calls within the MLHG groups are not sent towards the delivery function server.


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:

<file://Bellcore-drx>—Where x can be a digit from 1-7 and maps to ring type 1-7 as specified in the DN2Subscriber table. The corresponding ring type is the ringing tone for the user, unless another feature on the BTS 10200 overwrites it.

Alert-info header maps to the SAI_ALERTING_PATTERN (1-7) on the interface between BCM and SIA.

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:

DR2 = CWT2

DR3 = CWT3

DR4-7 = CWT4

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:

The BTS 10200 treats the reason-code received in BYE from the application server as an application server specific service type.

The BTS 10200 provides a base value of 200 for all the application server specific service types.

All of the service type values under 200 are used by the BTS 10200 for natively provided features.

The BTS 10200 will capture TAT/OHT Service Type in without any modifications.

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 SERVICETYPE 1 is used to identify TAT1/TAT2/OHT depending on the originating or terminating triggers.


Example:

SERVICETYPE 1 = AS_SERVICE_221 
FEATUREDATAONE1= NULL. 
USAGESENSITIVE1=False
SERVICERESULTCODE1=Success 

The 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 All customers must be operating on the Sun Solaris 10 06/06 OS prior to upgrading to Release 5.0, MR1 (5.0.2). Detailed information on installing and upgrading to Solaris 10 06/06 OS can be accessed at: http://www.cisco.com/en/US/products/hw/vcallcon/ps531/prod_installation_guides_list.html.


The following features were added or enhanced for Release 5.0, MR1:

SIP Triggers for SIP Endpoints

SIP Server Groups

CORBA Session Manageability

Seasonal Suspend

SIP Name Dialing

Disable Platform Shared Memory Replication

Aggregation ID Subnet

CMTS Discovery Using the Static Subnet Table

Bulk Data Export

Subscriber ID Parameter and DQoS Measurement Counters Support

ENUM Application

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

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):

Termination attempted trigger 1(TAT_1)

Termination attempted trigger 2 (TAT_2)

The SIP triggers feature is supported with the following limitations:

SIP triggers are not supported for Centrex subscribers.

The system does not support the off-hook trigger for SIP subscribers.

The BTS 10200 does not invoke any SIP triggers for SIP subscribers in the following cases:

For incoming calls based on address of record (AOR)

For features that are performed by the SIP endpoint, rather than the BTS 10200

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:

Tree model approach to SIP element selection

Blacklisting of SIP endpoints that are unreachable

SIP element advance on 5XX SIP responses

Server groups for established dialog requests

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:

New CLI commands to manage CLI and CORBA user sessions—Includes stop client-session to free up resources

Policy-driven Smart Session Management—Includes the smart removal of idle sessions allowing new sessions to login

New password aging notification and password reset API in CORBA Software Developer's Kit (SDK)

New functionality to disable password aging by setting user status to PERSIST

SDK Programmer's Guide containing details of session management features and commands

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:

Emergency (911)

Toll-free customer service numbers

Voicemail—Customers can retrieve messages and access voicemail functions.

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:

MTA's Effective-AGGR-ID is equivalent to its Manual-AGGR-ID (Aggr-Id provisioned in the MGW table) as long as the latter is provisioned (NOT NULL).

If MTA's Manual-AGGR-ID is not provisioned, then MTA's Effective AGGR-ID is equivalent to its Subnet's Manual AGGR-ID (Aggr-Id provisioned in the Subnet table).

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 btsoper user

Any user that belongs to the btsoper group

The Oracle user

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:

GATE-INFO

GATE-DELETE

GATE-OPEN

GATE-CLOSE

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:

ALLOW-NCS-ACCT-CODE-PROMPT—Allows you to delay NSC endpoints before prompting for an account code. The default behavior is for NSC endpoints to not delay.

LOCAL-NOD-ACCT-CODE-COLLECT—Calls with a Nature-Of-Dial (NOD) of LOCAL result in a prompt for an account code. The default behavior is LOCAL NOD calls do not prompt for an account code.

TOLLFREE-NOD-ACCT-CODE-COLLECT—Calls with a NOD of TOLLFREE result in a prompt for an account code. The default behavior is TOLLFREE NOD calls do not prompt for an account code.

NON-EMG-NOD-ACCT-CODE-COLLECT—Calls with a NOD of NON-EMG will result in a prompt for an account code. The default behavior is NON-EMG NOD calls prompt for an account code.

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:

A busy signal when the called DN is associated with an MLHG when GMB is activated.

The next available number in the hunt sequence if a specific terminal DN within an MLHG is called when TMB is activated.

The following four new feature names are added to the Feature Name table for TMB and GMB activation and deactivation:

Terminal Make Busy Activation (TMBA)

Terminal Make Busy Deactivation (TMBD)

Group Make Busy Activation (GMBA)

Group Make Busy Deactivation (GMBD)

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:

Policy-region table

CENTREX-GRP table

Policy-Nxx table

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

SIP Triggers

Own Calling Number Announcement

Multiple Directory Numbers

911 Overflow to Announcement

On-Net Routing and LNP for Inter-CMS Routing

CNAM Capability on a Trunk Group

Reception/Processing of DCS-LAES SIP Header

SIP Response Code 302

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

Casual Dial Enhancement

Dial Around Indicator in SIP

MWI Manipulation through CLI

Non-IVR Activation and Deactivation of SCF, SCR, SCA, and DRCW

ISDN Backhaul Using IUA and SCTP

MGCP Asynchronous DNS Lookup

Extended Voice Quality Metrics Reporting for MGCP

Internal Secondary Authoritative DNS

Call Tracer

Cluster Routing

Emergency 911 Trunk Connection Loss Alarm

Temporary Disconnect

DTMF Relay Call Agent Controlled Mode

PacketCable Multimedia QoS Enhancements

Fax, Modem, and TDD Handling Enhancements

QoS Gate Audit

Operational Features

XML Over SOAP

Ability To Perform Full System Backup With Reduced Duration In Simplex Mode

CDB File Naming Convention

SUN 1280 (12 CPUs)

Enhanced Software Upgrade

Broadband Telephony Services Status

Security Advisory Due to Default User Names and Passwords

200K Subscriber DB Soft Limit

Transaction Throttling Capability

SNMP Access to Current Alarms

Core File Monitor

Tabular Display of CPI/CPM Data

Configurable Default Values in Subscriber Provisioning

Overload Control

Pre-Manual Switchover Integrity Diagnostic Utility

MGCP Asynchronous DNS Lookup

Automatic Restart

LERG Support in OAMP

Other Enhancements

MGCP-Based Enhancements

CALEA Enhancements

Event Message Enhancements

North American Numbering Plan Administration (NANPA) Enhancements

LNP Event and Measurement Enhancements

Other Features

Changes from Previous Releases

Billing Features

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 In Release 5.0, the SIP triggers are added to MGCP and NCS subscribers only. The BTS 10200 supports multiple application servers. Application servers are provisioned per subscriber origination and subscriber termination.


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:

Off-Hook (Delayed or Immediate) Trigger—This trigger occurs either immediately after the user goes off-hook or after a delay set through a configurable timer. If off-hook delay is provisioned and the user goes off-hook, dial tone is provided to the subscriber for the configured number of seconds. When the delay timer expires, dial tone is stopped and the BTS 10200 Softswitch establishes a connection to the application server. If the user starts dialing before the delay timer expires, digit collection completes before the connection is established to the application server.

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.

Termination Attempt Trigger (TAT)—This trigger occurs when a call terminates on the BTS 10200 Softswitch with a subscriber that has the TAT trigger enabled. In this case, the BTS 10200 Softswitch sends the call to the application server before ringing the subscriber. The application server might provide services such as screening or custom ringback. If the application server determines that the call is to be offered to the subscriber, the application server sends the call back to the BTS 10200 Softswitch to continue termination 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:

ANSI LNP Query Support for Carrier Calls: Conditionally allows LNP queries on carrier calls, as determined by the Carrier LNP-QUERY flag.

LNP Query for On-net Routing, Inter CMS Routing: Provides control of LNP queries based on the dialed digit-string prefix and destination. The operator can allow or deny LNP queries for different calls and routing scenarios. For example, queries should be unconditionally blocked for some CMS originations, and for some MGC cases queries should be performed. When a Cisco BTS 10200 Softswitch is acting as both CMS and MGC, the query should be prevented on the subscriber origination towards a route proxy, but performed when a call terminates at the MGC on a SIP or PSTN trunk. For traditional Cisco BTS 10200 Softswitch on-net routing scenarios, a query might be desired on subscriber originations to DNs potentially on the same switch (SUB-ONLY), or on other on-net switches (ALL-CALLS).

On-net Route Bypass of Carrier Route: For Interlata or toll calls, allow an "on-net route," as defined in the Destination table, to override the carrier routing. "On-net" refers to facilities owned by an operator that include one or more Cisco BTS 10200 Softswitches (or other switches). SUB-ONLY allows carrier bypass to route the call to a local subscriber on the same Cisco BTS 10200 Softswitch. ALL-CALLS allows carrier bypass for all calls which have a valid on-net route. LNP query results are taken into account in the routing decision.

Remove LNP Query result data when Carrier LNP-QUERY= N: For an outgoing carrier call with Carrier LNP-QUERY = N, remove the LNP query result data, if present. The LRN, FCI, and GAP are destroyed as if a query were not performed.

Ignore Inbound LNP information: For an incoming trunk call with LNP data, that is, forward call indicators (FCI) bit-M indication "number translated" and Location Routing Number (LRN) and Generic Address Parameter (GAP), the LNP data is ignored, resulting in call delivery based on the called DN (from the GAP).

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:

SOFTSW

SS7

ISDN

H.323

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:

Contact header URL with the host name of the local BTS SIP interface

IP address/phone number different than the one initially entered by the calling party

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:

Re-routes the call using a network-based re-route mechanism

Uses one of its call forwarding mechanisms (BTS default)

BTS implements SIP 302 as the Call Forward Redirection (CFR) feature. CFR does the following:

Looks for the cause code and redirected number passed from the BTS CA

Instructs the BTS CA to forward the call

SIP 302 interacts with the following call forwarding features on the BTS:

Call Forwarding No-Answer (CFNA)

Call Forwarding Combined (CFC)

Call Forward Combination No-Answer (CFCNA)

Voice Mail No-Answer (VMNA)

Limitations

Support for the SIP 302 feature is subject to these limitations:

Sending 302 is only supported for CFNA.

302 is only supported for SIP trunks.

CFNA sends 302 if it is the first call forwarding feature invoked after the call is received.

Relaying SIP 302 is not supported.

302 tandems through the BTS (if the call is SIP to SIP) is not supported.

Receiving 302 to local SIP subscribers is not supported.

Sending 302 to local SIP subscribers is not supported.

Receiving multiple contact lists in 302; BTS uses the first and ignores the rest.

Forwarding only the original called number (OCN) and redirecting number (RDN) when the BTS forwards an INVITE out on a SIP trunk (in-between or middle-hop diversion headers are dropped).

Sending diversion headers (if enabled) in 302 only for OCN and RDN.

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:

PacketCable 1.5 specifications

CMS-to-SMC signaling

PKT-SP-CMSS1.5-I01-050128

PacketCable 1.5 PSTN Gateway Call Signaling Protocol Specification, PKT-SP-TGCP1.5-O01-050128

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. A person (the customer) is trying to call a Cisco BTS 10200 Softswitch subscriber (the busy party), but is unable to get through.

2. The customer asks the operator to verify whether or not the busy party is in a phone conversation with another party (the 3rd party).

3. The operator puts the customer on hold and calls the busy party over a BLV (no-test) trunk that is connected to BTS1.

4. BTS1 receives the incoming BLV call and determines that the called party number should be routed out a SIP trunk that is connected to BTS2. It sends a SIP INVITE with BLV indicator to BTS2.

5. BTS2 receives the incoming SIP INVITE with BLV indicator and determines the call should be routed to a cable subscriber (the busy party). When BTS2 determines that the cable subscriber is already connected to the 3rd party, it first creates a connection between the operator and the busy party. Next it conferences this connection with a preexisting connection between the busy part and third party to form a three-way connection between the operator, the busy party, and the 3rd party.

6. The operator now listens to the busy party and 3rd party conversation through special circuitry that garbles their voices to protect their privacy. At this point the operator's voice is muted by the OSPS.

7. The operator reports back to the customer that the busy party is in a conversation.

8. The customer requests that the operator break into the conversation and ask if the busy party is willing to hang up and take a call from the customer.

9. The operator puts the customer back on hold and presses an emergency interrupt button on the console which deactivates the garbling circuitry, un-mutes the microphone, and sends an emergency (operator) interrupt tone over the line, so that the busy party and the 3rd party know that the operator is interrupting their conversation.

10. The Trunking Gateway recognizes the operator interrupt tone and sends a NTFY event to BTS1. BTS1 translates the NTFY event into an outgoing SIP UPDATE (EI) message that is sent towards BTS2. BTS2 responds to the UPDATE with a 200OK, but won't actually act on it. Generating an UPDATE (EI) and receiving it are mandatory for compliance testing but serve no functional purpose in our design.

11. The operator explains to the busy party that another caller (the customer) would like to speak with the busy party and asks if the busy party is willing to hang up and accept the call. The operator then releases the connection to them and reports back to the customer who is on hold.

12. If the busy party agrees to hang up, the customer has the option of redialing the number or completing the call as an operator-assisted call.

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:

The BTS 10200 supports SIP based MTA call processing in two modes: internal registrar within the BTS 10200 or external registrar to the BTS 10200.

The PCMM extends to the SIP based eMTA call processing, which is another non-NCS/QoS enabled endpoint.

The SIP based MTA feature set is the same as the SIP feature set that the BTS 10200 has supported since R4.1 as documented in the user documentation set.

The BTS 10200 supports the interworking between SIP based MTA and NCS eMTA for both basic call and feature calls.

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:

Emergency Services (B911 and BLV/OI)

Multiple Rate Center support for routing between CMS and MGC to continue to support local, intra, and inter LATA call typing and interfacing to PSTN as when CMS and MGC functions are integrated (not separated) within a BTS 10200 system

Originating Line Information and Transit Network Selection (carrier and circuit code) handling between CMS and MGC

CNAM, 8xx, and LNP handling between CMS and MGC

Automatic Callback and Return (AC/AR) between CMS and MGC

CALEA call content tapping during call redirection between CMS and MGC

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:

If feature functionality is provided at the endpoint, the BTS 10200 does not receive any explicit indication about the feature provided by the endpoint. Therefore the BTS 10200 is not required to send Service Instance messages indicating invocation of a feature.

The requirements in PKT-SP-EM1.5- I01-050128 Appendix A that pertain to sending Signal Instance messages is explicitly designed for NCS/MGCP endpoints. If a tapped subscriber is using SIP endpoints, the BTS 10200 does not instruct the endpoint to play any signals/tones towards the user explicitly. However, the BTS 10200 may send information in SIP messages that trigger an endpoint to play tone or display information to the user. For detailed information on how the BTS10200 behaves with regard to sending Signal Instance messages when a tapped subscriber is using a SIP endpoint, refer to the Cisco BTS 10200 Softswitch Enhanced CALEA Feature Module.

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.

An application server might initiate a new call (by sending a new INVITE message) to the BTS 10200 and include a SIP header to enable the BTS 10200 to associate the new call with the original call for which feature logic was invoked.

An application server might send a 3XX redirect back to the BTS 10200 when feature logic processing is complete.

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:

Initiates a new Signaling Start message with Electronic Surveillance Indication attribute containing the billing-correlation-id set to the billing-correlation-id included in the previous Signaling Start message sent to the Delivery Function server.

Includes a P-DCS-LAES header with a billing-correlation-id associated with the terminating half of the call.

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:

Initiates a new Signaling Start message with Electronic Surveillance Indication attribute containing the billing-correlation-id set to the billing-correlation-id included in the previous Signaling Start message sent to the Delivery Function server

Transfers the surveillance towards the terminating side of the call

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:

RFC 3515—SIP Refer Method

RFC 3891—SIP "Replaces" Header

RFC 3892—SIP Referred-By Mechanism

RFC 3420—Internet Media Type message

RFC 3893—SIP Authenticated Identity Body (AIB) Format

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):

IPUnity—IVR and announcements

Cognitronics—IVR and announcements

IOS Gateway—announcements

An MS has 4 audio files for each IVR audio segment or announcement. For example, each welcome.wav has:

eng_welcome.wav

fra_welcome.wav

spa_welcome.wav

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:

OUTPULSE_CASUAL_AS_DIALED = Y/N

OUTPULSE_PREFIX1_AS_DIALED = Y/N

OUTPULSE_OPERATOR_AS_DIALED = Y/N

OUTPULSE_INTL_AS_DIALED = Y/N

OUTPULSE_INTL_OPR_AS_DIALED = Y/N

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:

"presub"—The CIC contains the caller's presubscribed carrier

"presub-da"—The CIC contains the caller's dialed carrier-id-code; the caller has a presubscribed carrier

"presub-daUnkwn"—The CIC may contain either a caller dialed carrier-id-code or the caller's presubscribed carrier

"da"—The CIC contains the caller's dialed carrier-id-code; the caller does not have a presubscribed carrier

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:

The Multi-Streaming feature of SCTP allows each D-channel to use a different stream to prevent head of line blocking.

The Multi-Homing feature of SCTP provides more efficient network redundancy compared to RUDP.

SCTP allows a configurable maximum outstanding receive window in number of bytes, which allows data through the network faster. RUDP supports a fixed value of 32 datagrams.

SCTP uses dynamic timers based on calculated round trip time. RUDP has fixed timers.

SCTP provides a cookie mechanism for better security.

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:

Support of ISDN D-channel status and control commands.

The status and control commands of the Trunk Group table are decoupled from the ISDN D-Channel table.

Equip and control individual trunk-termination in service (INS) after the corresponding trunk-group is brought INS. This enhancement makes ISDN consistent with SS7.

D-channel operational status tracking of the D-channel in the secondary side Call Agent.

Support of multiple trunk groups per D-channel.

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 The MGA internal cache is queried for the DNS.

Step 2 If the DNS is not present in the MGA internal cache, a sync lookup is launched.

Step 3 A get host by name is executed in the following order:

a. NSCD

b. A-DNS

c. Primary external DNS

d. Secondary external DNS

e. Additional external DNS servers

Step 4 The DNS name list is accepted as a FQDN in the Resolution DYN table.

Step 5 An update MGW DYN table DNS cache occurs. The MGA internal cache and the MGW DYN cache are then synced.


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:

MGCP lines

MGCP trunks

Network-based Call Signaling (NCS) lines

Trunking Gateway Control Protocol (TGCP) trunks

Announcement trunks

Interactive Voice Response (IVR) trunks

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:

Each CMS, MGC, or combined CMS/MGC has its own Point Code.

A trunk group cannot be split across multiple MGCs.

All CMSs within a cluster share a common LRN (referred as a Cluster LRN).

The npa-nxx of the ported-in numbers is not split across multiple CMSs (f there is no NRS in the network).

The subscriber DNs cannot be ported-out within a cluster.

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:

The gateway becomes unreachable.

The emergency trunk termination is administratively made OOS from the BTS 10200 CLI.

The emergency trunk termination is remotely or locally blocked.

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 system never attempts to perform COS screening on call types EMG (including 911), EXTENSION, and VSC. There is no provisioning option to allow COS screening to occur on these call types.


The temporary disconnect behavior provides capabilities for the Service Provider to easily restrict line call capabilities in the following way:

Configurable behavior option: At the POP level, restrict all services including, dial-tone and 911 to the line.

Configurable behavior option: At the POP level, allow dial-tone and limited call capabilities based on call-types and preconfigured DNs.

At the switch level disable any incoming calls except 911, unless under service denied condition.

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 Prior to Release 5.0, RFC 2833 DTMF relay was not controlled by the Call Agent (Cisco BTS 10200 Softswitch), therefore invocation of RFC 2833 DTMF relay was based on the configuration in the individual eMTA or MGW.


This feature can be invoked on the following types of calls:

MGCP (subscribers and trunks) <-> NCS (subscribers)

MGCP (subscribers and trunks) <-> H.323 (endpoints and trunks)

NCS (subscribers) <-> H.323 (endpoints and trunks)

MGCP (subscribers and trunks) <-> SIP (subscribers and trunks)

NCS (subscribers) <-> SIP (subscribers and trunks)

SIP (subscribers and trunks) <-> H.323 (endpoints and trunks)

MGCP (subscribers and trunks) <-> MGCP (subscribers and trunks)

H.323 (endpoints and trunks) <-> H.323 (endpoints and trunks)

SIP (subscribers and trunks) <-> SIP (subscribers and trunks)

NCS (subscribers) <-> NCS (subscribers)

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:

Section 7.1.1 of PKT-SP-NCS1.5-I01-050128

Section 7.1.1 of PKT-SP-TGCP1.5-I01-050128

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:

Network-based Call Signaling (NCS)—Used as the call signaling protocol between the eMTA and the call management server (CMS)

Dynamic QoS (DQoS)/Common Open Policy Service (COPS)—Used between the CMS and the cable modem termination system (CMTS).

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:

CLI Provisioning—Currently all CMTS network elements (EMs) interfacing with the CMS are provisioned in AGGR table. This feature introduces a new POLICY-SERVER table alias which uses existing AGGR table to store the Policy Server provisioning data. An additional field is added to the existing POP table to identify the Policy Server used for the set of subscribers or trunk groups. A new table, AGGR-PROFILE, is introduced by this feature, and some fields in the existing AGGR table are moved to AGGR-PROFILE table.

Status and control—This feature adds support for AGGR status and control.

COPS interface—Support is added for the COPS-MM protocol interface between CMS and the policy server. This includes a mechanism to initiate COPS-MM based QoS for Client Type-1 subscribers, and type-of-admission-control for the billing function.

Traffic measurements—Several traffic measurements are added for message exchange between the BTS 10200 and the CMTS and policy server.

Billing—New information is added in billing call detail block (CDB) to identify the type of admission control used at the originating or terminating side of the call.

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:

BTS Gate Memory Audit—Audits internal shared memory to detect and release memory consuming dangling gate records.

CMTS Gate Status Audit—Detects gates deleted in CMTS and alerts you if the deleted gates were due to an internal error.

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:

<prefix> is the billing file prefix from billing-acct-addr.

<CA ID> is the Call Agent ID where the records were generated, e.g. CA146.

(0/1) is daylight saving time (DST). Enter 1 to turn on DST. Enter 0 to turn off DST.

{+/-}HHMMSS is the UTC offset time.

yyyymmdd-hhmmss is the time the file was created.

<sequence-number> is a sequentially increasing six-digit number from 000001 to 999999 that will roll over to 000001 after the maximum value of 999999 is reached.

<state> is a letter indicating the state of the file.

P = primary (i.e., complete but untransferred)

S = secondary (i.e., complete and transferred)

O = open (i.e., currently collecting CDB records, incomplete, and untransferred).

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

<prefix> is the billing file prefix from CLI> billing-acct-addr.

yyyymmddhhmmss is the file creation date/time stamp.

3 is the priority of file. It does not change and is hardcoded to 3.

<record type> = 0 untransferred, 1 transferred.

<CMS ID> is the CMS ID provisioned from CLI>call-agent-profile.

<sequence num> is the 6-digit number from 000001 to 999999.

<.ascii> is the file format. It does not change, and is hard-coded to .ascii.

[.tmp] is the temporary extension used by the BTS 10200 to indicate that the file is the current/open file. The .tmp extension is stripped off before the file is sent to the BMS.

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 Customers upgrading from previous releases (such as Release 3.5.4, for example) will not benefit initially from the automated upgrade process. They must first upgrade to Release 5.0; after migrating to Release 5.0 and setting up a stable infrastructure, they will benefit from the automated upgrade process going forward.


The goals for the enhanced software upgrade are to:

Reduce time to perform upgrade during maintenance window.

Automate steps that were previously manual steps, reducing the possibility of mistakes.

Continue support for in-service upgrades with minimal loss of service.

Provide for patch installation, as well as for a full release upgrade.

Reduce time to perform upgrade to meet Service Level Agreements (SLAs).

Some of the key enhancements to the software upgrade include:

Incremental patch upgrade

Incremental build to support individual component upgrades.

Only changed components are built (recompiled).

Only packages with changed components are built.

Only changed packages are installed, resulting in reduced upgrade time.

Significant reduction in number of manual steps (approximately 75% reduction) through automation reduces the possibility of mistakes.

After the incremental patch upgrade is completed, a report is generated listing the newly installed components on the system.

Pre-install health check

Checks for proper health of the system prior to starting the upgrade procedure.

Users can specify the necessary upgrade inputs via a configuration file prior to upgrade.

Upgrade utility checks for package contents and reports to user all the components that are modified.

Checkpoints

Checkpoints are recorded during upgrade process.

In case of an upgrade step failure, the upgrade can resume from the last successful checkpoint.

Fallback

All components that changed during upgrade process are archived.

Archived files are used during fallback to return the system to the pre-upgrade state.

Centralized upgrade logging

All installation and upgrade activities are logged to in a dedicated log file.

Central application reports currently installed Cisco BTS 10200 package versions.

Migration paths

Pre-documented and well-published upgrade migration paths are supported.

V-load upgrades are supported on a given release from any Vxx load to any Vyy load (where yy > xx), and a V-load upgrade is installed as an incremental patch upgrade.

Major release upgrades are supported from the last maintenance release of the last two major releases, including database conversion.

Maintenance release upgrades are supported for all maintenance releases of the current major release, but no database conversions.

Documentation

All installation and upgrade documentation is complete in and of itself.

Installation and upgrade errors are mapped by unique error codes for clarity.

After the incremental patch upgrade is completed, a report is generated listing the newly installed components on the system.

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 capability to monitor command processing throughput of commands issued from external interfaces (session types) such as the CLI, CORBA, SOAP, and the batch (bulk) provisioning FTP adapter. The database stores records for the last 48 hours. The feature allows you to specify the parameter "sum" to add multiple records together for multiple periods up to 24 hours in one record. The response time fields are in milliseconds whether sum is specified or not. For measurement-throttle-summary, the averages are weighted across all periods in the report (SOAP).

The facility to set thresholds for external interfaces and raise event(s) when the threshold associated with a certain external interface is crossed.

The facility to prepare a report containing the number of commands processed in each or all external interface(s), the average response time on the EMS and total command processing time based on the collection interval. For requests such as "status/control/equip," the processing time reflects the cumulative time on both the EMS and the Call agent.

The capability to dynamically change the threshold monitoring interval.

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:

"show tab-alarm"—Shows current alarms in tabular format

"show tab-alarm-hist"—Shows alarms history in tabular format

"show tab-event-hist"—Shows events history in tabular format

An example of the output of executing of one the three commands follows:

CLI>show tab-alarm

ID
TYPE
NUMBER
SEVERITY
TIMESTAMP
COMPONENT-ID
12331874656
SIGNALING
68
MAJOR
2005-11-20 11:00:00
testing@mgw_id
12331874657
MAINTENANCE
3
MAJOR
2005-11-20 11:01:00
testing
12331874658
OSS
9
MINOR
2005-11-20 11:02:45
unixserver
12331874659
OSS
9
MINOR
2005-11-20 11:02:45
skittles

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:

Allows you to configure default values for optional tokens

Adds data validation of configured default values

Allows you to provision default values using a command alias

Allows you to show the Cisco BTS 10200 Softswitch factory default settings

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:

Critical processes CPU usage—The olm.cfg configuration file has UNIX "nice" values. BTS uses these values to calculate CPU utilization for critical processes over a small period of time (2 seconds minimum). Values for each process should be at or below the set value.

Critical process queue lengths—The olm.cfg configuration file has critical queue lengths for BTS processes like BCM, MGA, SGA, SIA, ISA and H3A. You can define multiple (32 factors total) critical queues for any BTS process. BTS monitors the usage proportion of each critical IPC queue.

IPC buffer pool usage—BTS monitors the proportion of available buffers in the IPC buffers pool. This reflects MCL: the higher the usage, the greater the congestion.

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:

Selectively reject new calls by the signaling adapters—A percentage of calls and messages are rejected at the current MCL level, based on olm.cfg. Emergency calls are not rejected at MCL 1 - 3, but all calls, including emergency calls, are rejected at MCL4.

Tell the network to stop sending traffic—This starts when BTS is mildly congested (at MCL1) and continues through all higher MCL levels until the overload condition abates to MC0. This action can only be applied to the following types of networks:

SS7 sends Automatic Control Level (ACL) parameter in ISUP release messages.

H.323 sends Resource Availability Indicator (RAI) message.

SIP sends 500 or 503 with a retry.

CA stops sending triggers to POTS FS—When the FS is congested the following occurs:

FS notifies CA once of its congested status.

CA sends only emergency triggers to FS, as it manages FS's congestion abatement

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:

level_1_damping_time

level_2_damping_time

level_3_damping_time

level_4_damping_time

Call Processing Measurements

Table 5 lists the new call processing measurements provided to support Overload Control.

Table 5 Call Processing Measurements Used by Overload Control

Measurement
Description

CALLP_OLM_OFFERED

The total number of calls offered to OLM

CALLP_OLM_ACCEPT

The total number of calls accepted by OLM

CALLP_OLM_REJECT

The total number of calls rejected by OLM

CALLP_OLM_ACCEPT_MCL0

Calls accepted by OLM at MCL0

CALLP_OLM_ACCEPT_MCL1

Calls accepted by OLM at MCL1

CALLP_OLM_ACCEPT_MCL2

Calls accepted by OLM at MCL2

CALLP_OLM_ACCEPT_MCL3

Calls accepted by OLM at MCL3

CALLP_OLM_REJECT_MCL1

Calls rejected by OLM at MCL1

CALLP_OLM_REJECT_MCL2

Calls rejected by OLM at MCL2

CALLP_OLM_REJECT_MCL3

Calls rejected by OLM at MCL3

CALLP_OLM_REJECT_MCL4

Calls rejected by OLM at MCL4

CALLP_OLM_REJECT_EMERGENCY

Emergency calls rejected at MCL4

CALLP_OLM_MCL1_COUNT

Total number of MCL1 occurrences

CALLP_OLM_MCL2_COUNT

Total number of MCL2 occurrences

CALLP_OLM_MCL3_COUNT

Total number of MCL3 occurrences

CALLP_OLM_MCL4_COUNT

Total number of MCL4 occurrences

CALLP_OLM_ISUP_MSG_DUMPED

Number of ISUP messages dumped at MCL4 by layer 3/4 interface (MIM) due to system overload.


Service Interaction Manager Measurements

Table 6 lists the new Service Interaction Manager measurements provided to support Overload Control.

Table 6 Service Interaction Manager Measurements Used by Overload Control

Measurement
Description

SIM_OC_TRIG_FILTERED

The number of triggers dropped when the FS is overloaded (a single counter is used by SIM, which tracks the trigger filtering for all the FS). SIM will update this counter every time it filters a trigger due to congestion on a FS.

SIM_OC_EMG_TRIG_FORCED

The number of emergency triggers (i.e. TRIGGER_911) forced when the FS is overloaded (a single counter is used by SIM which tracks number of emergency triggers forced for all the FS). SIM will update this counter every time when it forces an emergency trigger (TRIGGER_911) to FS.

SIM_OC_TRIG_FORCED

The number of triggers forced when the FS is overloaded (a single counter is used by SIM which tracks the number of forced triggers for all the FSs). SIM will update this counter every time when it forces a trigger.


Traffic Measurements Monitor Counters

Table 7 lists the new Traffic Measurements Monitor (TMM) measurements provided to support Overload Control.

Table 7 TMM Timers Used by Overload Control

Measurement
Description

SIA_OC_RX_INVITE_REJECT

The total number of incoming INVITE messages rejected by SIA due to overload.

SIA_OC_RX_REGISTER_REJECT

The total number of incoming REGISTER messages rejected by SIA due to overload

SIA_OC_RX_REFER_REJECT

The total number incoming REFER messages rejected by SIP due to overload.

SIA_OC_RX_SUBSCRIBE_REJECT

The total number of incoming SUBSCRIBE messages rejected.

SIA_OC_RX_UNSOL_NOTIFY_SUPP

The total number of unsolicited notification requests suppressed without sending to endpoints.

SIA_OC_RX_OPTIONS_REJECT

The total number of incoming OPTIONS messages rejected by SIA due to overload.


Miscellaneous Measurements

Table 8 lists additional measurements added to support Overload Control.

Table 8 Miscellaneous Measurements Used by Overload Control

Timer
Description

ISUP_CONG_CALL_REJECTED

The congestion-rejected calls on a per trunk group basis. This is implemented for SGA.

POTS_OC_DP_RECEIVED

The number of Detection Points (DPs) reported during periods of congestion. This is being pegged by the FS

H323_OC_SETUP_REJECTED

The total number of incoming H.225 Setup messages rejected by the BTS due to overload.

MEAS_ISA_OC_SETUP_REJECTED

The number of ISDN calls rejected due to system overload.

MEAS_MGA_OC_CALL_REJECTED

The number of MGCP calls rejected due to system overload.


Modified H323-GW Table

The following tokens are added to the H323-GW Table to support Overload Control.

Syntax Description

SEND-RAI

Indicates whether to send RAI message to the Gatekeeper when overload condition occurs.

VARCHAR(1): Y/N (Default=Y).

ALT-ENDPOINT1

When provisioned, the BTS reports an alternate endpoint in the Registration Request (RRQ) message to the Gatekeeper. Contains the TSAP address of the endpoint in the format 10.89.227.114:1720. (Default=NULL).

ALT-ENDPOINT2

TSAP address of the second alternate endpoint.

ALT-ENDPOINT3

TSAP address of the third alternate endpoint.

ALT-ENDPOINT4

TSAP address of the fourth alternate endpoint.

ALT-ENDPOINT5

TSAP address of the fifth alternate endpoint.


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

PEER-GW-OVERLOAD-TIMER

Shows how many seconds to mark a trunk group congested and reroute or drop calls to the trunk group. INTEGER: 0—300 (default = 60). A value of 0 disables this timer.

Note This behavior does not apply if RAS is enabled on the trunk group. In this case, it is the Gatekeeper's responsibility to throttle, reroute, or reject the call to the terminating endpoint.


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:

Reduced outage risk. Automatic restart brings the platform up to STANDBY in minutes instead of potentially much longer, as support personnel work to restore the platform. This reduces the risk of outages by reducing the amount of time the system is in simplex mode.

Automated forensic data collection. Planned aspects of this feature are to automatically save off data useful for offline debugging (trace logs, status files, cores, etc.). Currently this data is retrieved manually. Sometimes customers have even deleted useful debugging files. Automating the process of saving off useful information will make sure this information is preserved.

Faster switchovers. When a process exceeds the maximum number of restarts a system-initiated switchover is executed. By not transitioning to OOS-FAULTY, the standby side will avoid the taxing database copy process.


Note An Automatic Restart will not be attempted in some fault scenarios where the restart of the system will likely fail.


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:

A single command to generate BTS 10200 LERG commands from the input LERG6.DAT. This command parses the LERG6.DAT and creates a file containing the BTS 10200 command list. This command file is then loaded by means of the ftpAdapter and applied to a corresponding table in the BTS 10200 OAMP application. The command file is also sent to the Call Agent.

A single command to generate the BTS 10200 LERG commands from the input LERG6INS.DAT file. This command parses the LERG6INS.DAT file and creates a file containing the BTS 10200 command list with appropriate start times. This command file is then loaded by means of the ftpAdapter and applied to the corresponding table in the BTS 10200 OAMP application. The command file is also sent to the Call Agent at the specified start time.

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:

Enhanced functionality based on the requirements of CableLabs specification PKT-SP-EC-MGCP-I10-040402, PacketCable Network-Based Call Signaling Protocol Specification, April 2, 2004.

Enhanced AuditConnection functionality, including detection and deletion of stray connections to remote endpoints. (These stray connections can exist after a Call Agent (CA) failover.)

The following MGCP-based features of the Cisco BTS 10200 Softswitch have been added or enhanced:

The MGCP message timeout algorithm has been upgraded to comply with the message retransmission algorithm specifications in PKT-SP-EC-MGCP-I10-040402.

The QoS parameters for silence suppression and echo cancellation can be configured not to override the MGCP endpoint default settings.

The MGCP encoder and decoder have been updated to support the Augmented Backus-Naur Form (ABNF) syntax in PKT-SP-EC-MGCP-I10-040402.

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 By using the configuration options, the BTS 10200 provides backward compatibility by disabling the new messages and attributes implemented in BTS 10200 Release 5.0. However, BTS 10200 Release 5.0 does not provide backward compatibility to permit selecting the call-content IAP to generate the duplicate call-content based on the algorithm implemented in older releases of the BTS 10200 software.



Note The BTS 10200 enables use of the version flags that provide backward compatibility for certain requirements (or implementations) to avoid interoperation problems with the current version of the Delivery Function server. However, the BTS 10200 does not provide control for all of the different versions of the PacketCable specifications that describe the use of these flags.


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.

When the BTS 10200 requires assistance from another CMS to perform the call-data surveillance function or call-data and call-content surveillance function, it includes the SIP P-DCS-LAES header in a SIP message. Depending on the call scenario, the following SIP messages can carry the P-DCS-LAES header as an indication of a surveillance request sent to the CMST or CMS:

INVITE (or RE-INVITE) message

183 Progress

180 Alerting

200 OK

302 Redirection

When the BTS 10200 requires the assistance of an adjacent CMS in performing the call-data surveillance function, it includes BCID, CDC-IP-Address, and CDC-IP-Port information in the SIP P-DCS-LAES header.

When the BTS 10200 requires the assistance of an adjacent CMS to perform the call-data and call-content surveillance functions, it includes BCID, CDC-IP-Address, CDC-IP-Port, CCC-ID, CCC-IP-Address, and CCC-IP-Port information in the SIP P-DCS-LAES header.

When the BTS 10200 receives P-DCS-LAES header information in any of the following SIP messages, it takes on the surveillance responsibility based on the content of SIP P-DCS-LAES header.

The BTS 10200 assumes the responsibility of Call-Data surveillance if the P-DCS-LAES header is included in a SIP message with valid BCID, CDC-IP-Address, and CDC-IP-Port information.

The BTS 10200 assumes the responsibility of Call-Data and Call-Content if the P-DCS-LAES header is included in a SIP message with BCID, CDC-IP-Address, CDC-IP-Port, CCC-ID, CCC-IP-Address, and CCC-IP-Port information.

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 9 Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A 

Requirement
Description
Compliance

REQ2529

The PCES event message sent to the delivery function (DF) must not affect the monotonically increasing sequence-number that appears in the Event Message header sent to the RKS.

Compliant

REQ6108

All PCES event messages must have the Event Object field in the EM Header attribute set to 1.

Compliant

REQ6109

PCES event messages must not be sent to the RKS.

Compliant

REQ6110

Intercept Access Points (for example, CMS, CMTS, and MGC) and DF must support the Radius Protocol over UDP.

Compliant

REQ6111

REQ6112

If an IAP does not receive an Accounting-Response message within the configured retry interval, it must continue resending the same Accounting-Request until it receives an acknowledgment from the DF or the maximum number of retries is reached. The IAP can drop the request after the maximum retries is reached.

Compliant

REQ6113

When a DF receives a PCES event message in a Radius Accounting-Request message from an IAP, it must send an Accounting-Response message to the IAP.

Not applicable

Section A.1, Service Instance Message

REQ2530

If the service (call) is under surveillance, the Service Instance Event Message must be generated with all the standard required parameters and with the additional required electronic surveillance parameters.

Compliant

Section A.2, Signaling Start

REQ2534

If the service is under surveillance as defined in requirement 8, this event message must be generated with all the standard required parameters and with the additional required electronic surveillance parameters.

Compliant

REQ2535

The MGC must generate, timestamp, and send this event to the DF for a terminating call under surveillance to a PSTN gateway.

Compliant

REQ2536

The MGC must timestamp this message when it sends the SS7 IAM message or transmits the dialed digits on an MF-trunk.

Compliant

REQ2537

REQ2538

For an originating call from an MTA or from a PSTN Gateway, if the MGC receives signaling notification from the terminating CMS that the call is to be intercepted but the terminating device is unable to perform the interception, the MGC must timestamp and send an additional Signaling_Start event message to the Electronic Surveillance Delivery Function before it delivers a response to the originating MTA or PSTN gateway.

This Signaling_Start event message must contain the Electronic_Surveillance_Indication attribute, and the value of the Direction_Indicator attribute must be integer 2 (2=Terminating).

Compliant

REQ2539

The CMS must generate, timestamp, and send this event to the DF if the originating call from an MTA is under surveillance.

Compliant

REQ2540

The CMS must timestamp and send this event message to the DF after all translation of the dialed digits is complete, whether the translation is successful or not. This includes unroutable digits reported to the CMS (that is, partially dialed digits).

Compliant

REQ2541

The CMS must generate, timestamp, and send this event to the DF for a terminating call to an MTA under surveillance, or for a terminating call under surveillance to an MTA.

Compliant

REQ2542

The CMS must timestamp and send this event message to the Electronic Surveillance Delivery Function prior to invoking any termination features.

Compliant

REQ2534.13.1

The Electronic_Surveillance_Indication attribute must be present in events sent to the DF for terminating calls that have been redirected by a surveillance subject.

Compliant

Section A.3, Signaling Stop

REQ6120

If the service (call) is under surveillance, this event message must be generated with all the standard required parameters and with the additional required electronic surveillance parameters.

Compliant

REQ6121

A Signaling_Stop message must not be generated unless a Signaling_Start message with the same BCID has been generated for the call.

Compliant

REQ6122

A Signaling_Stop message must be generated if a Signaling_Start message with the same BCID has been generated for the call (In exception cases, this may be the result of a proprietary timeout or cleanup process.)

Compliant

REQ6123

Originating CMS: In the single-zone scenario, the originating CMS must timestamp this EM message immediately upon transmission of the NCS-signaling DLCX message.

Compliant

REQ6124

Originating CMS: In the intradomain or interdomain scenario, the originating CMS must timestamp this message upon transmission of the last signaling event in the following list:

Transmission of the NCS-signaling DLCX message

Transmission of the CMSS-signaling BYE message or CANCEL message

Compliant

REQ6125

Terminating CMS: In the single-zone scenario, the terminating CMS must timestamp this EM message immediately upon transmission of the NCS-signaling DLCX message.

Compliant

REQ6124

Terminating CMS: In the intradomain or interdomain scenario, the originating CMS must timestamp this message upon transmission of the last signaling event in the following list:

Transmission of the NCS-signaling DLCX message

Transmission of the CMSS-signaling BYE message or CANCEL message

Compliant

REQ6124

Originating MGC (off-net to on-net): The originating MGC must timestamp this EM message immediately upon the last signaling event in the following list:

REQ6127.1—Transmission/receipt of an RLC to/from the Signaling Gateway that communicates with the SS7 network

REQ6127.2—Transmission of the MGC-issued TGCP DLCX message

REQ6127.3—Receipt of an MG-issued TGCP DLCX message

REQ6127.4—Transmission of the CMSS-signaling BYE message or CANCEL message

Compliant

REQ6128

Terminating MGC (on-net to off-net).

The terminating MGC must timestamp this EM message immediately upon transmission of the TGCP-signaling DLCX message.

Compliant

Section A.4, Call Answer

REQ2552

If the service (call) is under surveillance, this event message must be generated with all the standard required parameters and with the additional required electronic surveillance parameters.

Compliant

REQ2553

The CMS or MGC must send this event message to the DF.

Compliant

Section A.5, Call Disconnect

REQ2556

If the service (call) is under surveillance, this event message must be generated with all the standard required parameters and with the additional required electronic surveillance parameters.

Compliant

REQ2557

The CMS or MGC must send this event message to the DF.

Compliant

 

Section A.6, QOS Reserve (Not applicable)

 
 

Section A.7, QOS Releases (Not applicable)

 
 

Section A.8, QOS Commit (Not applicable)

 

Section A.9, Media Report Message

REQ5992

The CMS and MGC must send this message:

REQ5992.1—When it opens a new media channel and receives a confirmation that include identification of the Session Description Protocol (SDP)

REQ5992.2—When it closes a media channel

REQ5992.3—When it receives a new SDP for an open media channel

Compliant

REQ5993

REQ5993—The CMS or MGC must timestamp this message on receipt of response from an endpoint that triggered the sending of the message (for example, a response from a modify or delete connection).

Compliant

REQ6071

REQ6071.1—The EM_Header attribute must be present as the first attribute of the EM.

Compliant

REQ6001

REQ6001.1—The CCC_ID attribute must be present for call content surveillance. CMS and MGC provide CCC_ID.

REQ6001.2—The CCC_ID attribute must not be present for call data surveillance.

Compliant

REQ6002

REQ6002.1—The SDP_Upstream attribute must be included if SDP is received from the surveillance subject's associate.

Compliant

REQ6003

REQ6003.1—The SDP_Downstream attribute must be included if SDP is received from the surveillance subject.

Compliant

REQ6072

REQ6072.1—The Channel_State attribute must be included and set to "Open" if a new channel has been opened, to "Change" if SDP is being provided for an opened channel, or to "Close" if the media channel has been closed.

Compliant

REQ6073

REQ6073.1—The Flow_Direction attribute must be included and it must indicate the direction of flow, either upstream or downstream.

Not Compliant (BTS includes both SDPs in one Media report message.)

 

Section A.10, Signal Instance Message

Section A.11, Terminal Display Information Attribute Structure

 

REQ5994

If the service is under surveillance, the Signal Instance message must be generated and time-stamped when any of the following events occurs, unless the information reported in the Signal Instance message would be redundant with the information reported by other event messages (for example, Signaling_Start):

REQ5994.1—The CMS receives a positive acknowledgment in response to a Notification Request command that asked for immediate generation of a signal contained in Table 66 the surveillance subject

REQ5994.2—The CMS receives a Notify command that indicates the surveillance subject's initiation of a signal contained in Table 67 of the PacketCable specification.

REQ5994.3—For DTMF tones, the CMS must not generate the Signal Instance message until it has received all of the digits provided by the surveillance subject.

Compliant

REQ5997

When the generation of the Signal Instance message is due to Condition 1 in the preceding requirement (REQ5994), the Signal_Type attribute in Table 68 of' the PacketCable must be set to a value of "1" (Network Signal).

Compliant

REQ5998

The Alerting Signal, Subject Audible Signal, Terminal Display Info, and Misc Signaling Information attributes must be present in the Signal Instance message generated in response to Condition 1 (Network Signal) if applied to the party under surveillance.

Compliant

REQ5999

When the generation of the Signal Instance message is due to Condition 2 in REQ5994, the Signal Type attribute in Table 68 of the PacketCable specification must be set to a value of "2" (Subject Signal).

Compliant

REQ6000

The Switch Hook Flash, Digits Dialed, and Misc Signaling Information attributes must be present in the Signal Instance message that is generated if the subject under surveillance receives any of these signaling instances.

Compliant

REQ6074

REQ6075

REQ6646

REQ6647

REQ6007

REQ6008

REQ6009

REQ6010

REQ6011

REQ6012

The required attributes must be present in the Signal Instance message as defined in the Comment section of Table 68 in the PacketCable specification.

Compliant

Section A.12, Conference Party Change

REQ6648

The CMS must generate this event message for a conference call that was initiated by the user under surveillance when:

REQ6648.1—The subject adds a one or more additional parties to an existing call to form a conference call.

REQ6648.2—A party in a subject-initiated conference call is placed on hold.

REQ6648.3—A party in a subject-initiated conference call is retrieved from hold.

Compliant

REQ6649

The EM Header attribute must be present as the first attribute of the EM.

Compliant

REQ6650

Within the EM Header, the BCID must be one of the BCIDs associated with a call leg participating in the conference call.

Compliant

REQ6651

This attribute must be included when known, to identify all communicating parties, when the conference is established by the intercept subject's service.

Compliant

REQ6652

This attribute must be included when known, to identify a communicating party when one is added to the conference established by the intercept subject's service. This attribute can appear multiple times, one for each added party. This attribute can appear independently or in combination with other attributes.

Compliant

REQ6653

This attribute must be included when known, to identify a previously communicating party, when that party is removed (for example, placed on hold) from the conference established by the intercept subject's service. This attribute can appear multiple times, one for each removed party. This attribute can appear independently or in combination with other attributes.

Partially compliant (hold cases not addressed)

Section A.13, Surveillance Stop

Not available

The CMS must timestamp this EM immediately at:

13—At the End of a call

14—When CMS determines that surveillance cannot be started, or can no longer be performed

Compliant

Not available

Surveillance Stop destination:

1—Surveillance Stop applies to local surveillance only.

2—Surveillance Stop applies to both local and remote surveillance.

3 = Surveillance Stop applies only to remote surveillance.

Compliant

Not available

Surveillance Stop type:

1—End of surveillance (CDC and, if present, CCC)

2—End of CCC only (CDC to continue)

Compliant

Not available

Electronic Surveillance Indication

This structure must be included when the local DF is not part of the DF chain (that is, the CMS has not established a DF chain by not including the ESI attribute in a Signaling Start EM). This structure must not be included when the local DF is part of the DF chain (that is, the CMS has established a DF chain by including the ESI attribute in a Signaling Start EM).

Compliant

Section A.14, Redirection

Not available

The Redirection message must be sent to the DF if a call involving a surveillance subject is redirected and:

The CMS is aware of the redirection.

No Service Instance is generated for the redirection.

Compliant

Not available

The EM Header, Redirected From Party Number, Redirected To Party Number, Carrier Identification Code, and Related BCID attribute must be sent according to the requirements in Table 73 of the PacketCable Specification.

Compliant


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 The BTS 10200 does not originate a REFER message to the other CMS to transfer the call but can process the REFER message received from another CMS.


Table 10 Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D 

Requirement
Description
Compliance

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:

REQ7458.1—The local BCID already assigned to the call (this is a required field in the event message header)

REQ7458.2—The remote BCID assigned by CMST and received in the P-DCS-LAES header

REQ7458.3—The call-data IP address and port of the remote DF of CMST received in the P-DCS-LAES header

REQ7458.4—An indicator specifying that both call-data and call-content surveillance are to be stopped

REQ7458.5—An indicator specifying that the local surveillance session (if active) and remote surveillance session are to be stopped

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:

REQ7459.1—The local BCID already assigned to the call (this is a required field in the event message header)

REQ7458.6—The remote BCID assigned by CMST and received in the P-DCS-LAES header

REQ7459.2—The call-data IP address and port of the remote DF of CMST received in the P-DCS-LAES header

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:

REQ7462.1—The local CCCID assigned to the call.

REQ7462.2—The remote CCCID assigned by CMST and received in the P-DCS-LAES header.

REQ7462.3—The call-content IP address and port of the remote DF of CMST received in the P-DCS-LAES header.

REQ7462.4—When the call ends, CMSO 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.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:

REQ7464.1—The local BCID assigned by CMSO to the call. (This BCID was bound to the remote surveillance session by the previous Signaling-Start message.)

REQ7464.2—An indicator specifying that only the remote surveillance session is to be stopped. (This allows a local surveillance session that may be in progress on the originating endpoint to continue.)

REQ7464.3—An indicator specifying that (only) call-content surveillance is to be stopped. (This allows the remote call-data surveillance to continue.)

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:

REQ7465.1—The local BCID assigned by CMSO to the call. (Even though the local BCID is a required parameter, it does not convey any useful information in this case, because the local BCID was not bound to the remote surveillance session by a previous Signaling-Start message.)

REQ7465.2—The remote BCID assigned by CMST and received in the P-DCS-LAES header.

REQ7465.3—The call-data IP address and port of the remote DF of CMST received in the P-DCS-LAES header.

REQ7465.4—An indicator specifying that only the remote surveillance session is to be stopped. (This allows a local surveillance session that may be in progress on the originating endpoint to continue.)

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:

REQ7468.1—The remote BCID assigned by the remote CMS and received in the P-DCS-LAES header

REQ7468.2—The call-data IP address and port of the remote DF received in the P-DCS-LAES header

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:

REQ7471.1—The remote CCCID assigned by the remote CMS and received in the P-DCS-LAES header

REQ7471.2—The call-content IP address and port of the remote DF received in the P-DCS-LAES header

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:

REQ7473.1—The local BCID assigned by CMST to this call

Note To avoid affecting other surveillance sessions, CMST must use the BCID for this call and not the BCID of any other in-progress call on the same line.

REQ7473.2—The remote BCID received in the P-DCS-LAES header

REQ7473.3—The call-data IP address and port of the remote DF received in the P-DCS-LAES header

REQ7473.4—An indicator specifying that both call-data and (if active) call-content surveillance are to be stopped

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:

REQ4857.1—The local BCID assigned to the terminating call

REQ4857.2—An indication that call-content surveillance is to be terminated

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:

REQ7477.1—The remote BCID assigned by the remote CMS and received in the P-DCS-LAES header

REQ7477.2—The call-data IP address and port of the remote DF received in the P-DCS-LAES header

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:

REQ7480.1—The remote CCCID assigned by the remote CMS and received in the P-DCS-LAES header

REQ7480.2—The call-content IP address and port of the remote DF received in the P-DCS-LAES header

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:

REQ7482.1—The local BCID assigned to the call

REQ7482.2—The call-data IP address and port of the local DF

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:

REQ7483.1—The local CCCID assigned to the call

REQ7483.2—The call-content IP address and port of the local DF

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.

Table 11 Migrated Signaling Events and Alarms 

Type and Number
Description
Severity

SIGNALING(12)

Feature Server is not Up or is not Responding to Call Agent

CRITICAL

SIGNALING(13)

SS7 Signaling Link Down

MAJOR

SIGNALING(14)

Link is Remotely Inhibited

MINOR

SIGNALING(15)

Link is Locally Inhibited

MINOR

SIGNALING(16)

Link is Congested

MINOR

SIGNALING(19)

Link Set Inaccessible

MAJOR

SIGNALING(20)

Link Set Congestion

MAJOR

SIGNALING(21)

Route Set Failure

MAJOR

SIGNALING(22)

Route Set Congested

MINOR

SIGNALING(23)

DPC Unavailable

MAJOR

SIGNALING(24)

DPC Congested

MINOR

SIGNALING(40)

Trunk Remotely Blocked

MAJOR

SIGNALING(59)

Auto State Change for ISDN Trunk Group by Media Gateway

MAJOR

SIGNALING(60)

ISDN STATUS Message Containing Error Indication Received

WARNING

SIGNALING(61)

Trunk Operational State Changed by Service Message

INFO

SIGNALING(62)

Received ISDN RESTART Message

INFO

SIGNALING(69)

CA and FS Communication Message Timeout

CRITICAL

SIGNALING(70)

ISDN Unable to Restore D-channel Due to Failed Communication

WARNING

SIGNALING(71)

ISDN Unable to Establish D-channel

WARNING

SIGNALING(73)

ISDN - Unable to Send RESTART Due to RESTART Timer Expired

WARNING

SIGNALING(74)

ISDN - Unable to Send the SERVICE Due to the SERVICE Timer Expired

WARNING

SIGNALING(77)

ISDN D-channel Switchover for NFAS

INFO

SIGNALING(78)

ISDN single D-channel Down for NFAS

MINOR

SIGNALING(86)

Remote H323 Gateway is not Reachable

MAJOR

SIGNALING(87)

H323 Message Parsing Error

MAJOR

SIGNALING(88)

H323 Message Encoding Error

MAJOR

SIGNALING(89)

Gatekeeper not Available/Reachable

MAJOR

SIGNALING(90)

Alternate Gatekeeper is not Responding

MAJOR

SIGNALING(102)

H323 Network Congested

MINOR

SIGNALING(103)

AGGR Connection Down

MAJOR

SIGNALING(106)

ESA BTS DF Connection Down

MINOR

SIGNALING(107)

Logical IP Addresses not Mapped Correctly

CRITICAL

SIGNALING(108)

Simplex Only Operational Mode

MAJOR

SIGNALING(110)

Signaling Gateway Group is Out-of-Service

CRITICAL

SIGNALING(113)

Signaling Gateway Failure

MAJOR

SIGNALING(114)

Signaling Gateway Process is Out-of-Service

MAJOR

SIGNALING(121)

M3UA Cannot Go Standby

MAJOR

SIGNALING(122)

M3UA Cannot Go Active

MAJOR

SIGNALING(124)

Remote Subsystem is Out of Service

MINOR

SIGNALING(125)

SCCP Routing Error

MAJOR

SIGNALING(126)

SCCP Binding Failure

MAJOR

SIGNALING(127)

TCAP Binding Failure

MAJOR

SIGNALING(132)

TCAP Reaches the Provisioned Resource Limit

WARNING

SIGNALING(142)

SIP Trunk Operationally Out of Service

CRITICAL

SIGNALING(143)

IP Interface Link to the SS7 Signaling Gateway is Down

MINOR

SIGNALING(144)

All IP Interface Links to SS7 Signaling Gateway are Down

CRITICAL

SIGNALING(145)

One IP Interface to SS7 Signaling Gateway is Down

MINOR

SIGNALING(150)

SCTP Association Congested

MINOR


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.

Table 12 Migrated Maintenance Events and Alarms 

TYPE & NUMBER
DESCRIPTION
SEVERITY

MAINTENANCE(3)

KAM: Local Side has Become Faulty

MAJOR

MAINTENANCE(4)

KAM: Mate Side has Become Faulty

MAJOR

MAINTENANCE(5)

KAM: Changeover Failure

MAJOR

MAINTENANCE(6)

KAM: Changeover Timeout

MAJOR

MAINTENANCE(7)

KAM: Mate Rejected Changeover

MAJOR

MAINTENANCE(8)

KAM: Mate Changeover Timeout

MAJOR

MAINTENANCE(9)

KAM: Local Initialization Failure

MAJOR

MAINTENANCE(10)

KAM: Local Initialization Timeout

MAJOR

MAINTENANCE(18)

PMG: Process has Died

MINOR

MAINTENANCE(19)

PMG: Process Exceeded Restart Rate

MAJOR

MAINTENANCE(20)

KAM: Lost KAM Connection to Mate

MAJOR

MAINTENANCE(21)

KAM: Network Interface Down

MAJOR

MAINTENANCE(23)

PMG: Process Failed to Complete Initialization

MAJOR

MAINTENANCE(24)

PMG: Restarting Process

MINOR

MAINTENANCE(26)

PMG: Going Faulty

MAJOR

MAINTENANCE(40)

PMG: Binary Does not Exist for Process

CRITICAL

MAINTENANCE(43)

PMG: Process Failed to Come Up in Active Mode

CRITICAL

MAINTENANCE(44)

PMG: Process Failed to Come Up in Standby Mode

CRITICAL

MAINTENANCE(45)

Application Instance State Change Failure

MAJOR

MAINTENANCE(47)

Thread Watchdog Counter Expired for a Thread

CRITICAL

MAINTENANCE(48)

IDX Table Usage Exceeded Minor Usage Threshold Level

MINOR

MAINTENANCE(49)

IDX Table Usage Exceeded Major Usage Threshold Level

MAJOR

MAINTENANCE(50)

IDX Table Usage Exceeded Critical Usage Threshold Level

CRITICAL

MAINTENANCE(51)

A Process Exceeds 70% of CPU Usage

MAJOR

MAINTENANCE(53)

The CPU Usage is Over 90% Busy

CRITICAL

MAINTENANCE(55)

The 5 Minute Load Average is Abnormally High

MAJOR

MAINTENANCE(57)

Memory and Swap are Consumed at Critical Levels

CRITICAL

MAINTENANCE(61)

No HB Messages Received Through the Interface

CRITICAL

MAINTENANCE(62)

Link Monitor: Interface Lost Communication

MAJOR

MAINTENANCE(63)

Outgoing HB Period Exceeded Limit

MAJOR

MAINTENANCE(64)

Average Outgoing HB Period Exceeds Major Alarm Limit

MAJOR

MAINTENANCE(65)

Disk Partition Critically Consumed

CRITICAL

MAINTENANCE(66)

Disk Partition Significantly Consumed

MAJOR

MAINTENANCE(67)

The Free IPC Pool Buffers Below Minor Threshold

MINOR

MAINTENANCE(68)

The Free IPC Pool Buffers Below Major Threshold

MAJOR

MAINTENANCE(69)

The Free IPC Pool Buffers Below Critical Threshold

CRITICAL

MAINTENANCE(70)

The Free IPC Pool Buffer Count Below Minimum Required

CRITICAL

MAINTENANCE(71)

Local DNS Server Response Too Slow

MAJOR

MAINTENANCE(72)

External DNS Server Response Too Slow

MAJOR

MAINTENANCE(73)

External DNS Server not Responsive

CRITICAL

MAINTENANCE(74)

Local DNS Service not Responsive

CRITICAL

MAINTENANCE(77)

Mate Time Differs Beyond Tolerance

MAJOR

MAINTENANCE(82)

Average Outgoing HB Period Exceeds Critical Limit

CRITICAL

MAINTENANCE(83)

Swap Space Below Minor Threshold

MINOR

MAINTENANCE(84)

Swap Space Below Major Threshold

MAJOR

MAINTENANCE(85)

Swap Space Below Critical Threshold

CRITICAL

MAINTENANCE(97)

IPC Input Queue Entered Throttle State

CRITICAL

MAINTENANCE(98)

IPC Input Queue Depth At 25% Of Its Hi-Watermark

MINOR

MAINTENANCE(99)

IPC Input Queue Depth At 50% Of Its Hi-Watermark

MAJOR

MAINTENANCE(100)

IPC Input Queue Depth At 75% Of Its Hi-Watermark

CRITICAL

MAINTENANCE(101)

Switchover in Progress

CRITICAL

MAINTENANCE(102)

Thread Watchdog Counter Close to Expiry for a Thread

CRITICAL

MAINTENANCE(103)

CPU Is Offline

CRITICAL

MAINTENANCE(107)

No HB Messages Received Through Interface From Router

CRITICAL

MAINTENANCE(109)

5 Successive Log Files cannot be Transferred

MAJOR

MAINTENANCE(110)

Access to LAF Configuration File Failed or File Corrupted

MAJOR

MAINTENANCE(111)

Cannot Login to External Archive Server

CRITICAL

MAINTENANCE(112)

Congestion Status

MAJOR


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 The URL starts with "https" instead of "http". Any existing target file is overwritten.


Syntax Description

component_id

The id of the component reporting the alarm(s) (1 to 32 ASCII characters).

display

The fields of the alarms that will be shown in the output file. Enter at least 0 characters, but not more than 51200 characters. If you want to clear the value, please enter NULL.

end_time

Timestamp indicating the time the monitoring of the specified alarm states should end in the format: yyyy-MM-dd HH:mm:ss.

id

The unique system-assigned serial number of an alarm.

limit

The limit on the number of alarms in the output file. Enter a number from 0 to 100000000.

number

The numerical identifier of the alarm of the specified type (1 to 500).

order

The field name that the output will be sorted by. Enter at least 0 characters, but not more than 51200 characters. If you want to clear the value, please enter NULL.

origin

The internal designation of the process generating the alarm(s) (1 to 32 ASCII characters).

output

Required field. The output file name. Any existing file with the same name is overwritten. (1 to 32 characters long).

output_type

The output file type: [CSV, XML]. Default to CSV if not specified. The output can contain characters: "a-z", "A-Z", "0-9", "_", and "-".

severity

The severity level of the alarm, which can be any one of the following values: [MINOR, MAJOR, CRITICAL].

start_time

Timestamp indicating the time the monitoring of the specified alarm states should start in the format: yyyy-MM-dd HH:mm:ss.

timestamp

Enter a date and time in the format: yyyy-MM-dd HH:mm:ss.

type

Type of alarm to show, which can be any one of the following values: BILLING, CALLP, CONFIG, DATABASE, MAINTENANCE, OSS, SECURITY, SIGNALING, STATISTICS, SYSTEM, AUDIT.


Event Message Enhancements

Release 5.0 provides new and enhanced event message (EM) fields.


Note For EM provisioning and file-handling procedures, see the Cisco BTS 10200 Softswitch PacketCable and Event Message Provisioning and Operations Guide.


EM Generation Details

Table 13 lists the EMs generated by specific call configurations.

Table 13 EMs Generated by Call Configuration 

Cisco BTS 10200 Softswitch Generates EMs for ...
Call Configuration
On-net to On-net
On-Net to Off-net
Off-net to On-net

Originating CMS

X

X

 

Terminating CMS

X

 

X

Originating MGC

 

 

X

Terminating MGC

 

X

 


Table 14 lists the specific EMs that can be generated by the CMS and MGC.

Table 14 EMs Generated by Logical Entity 

Event Message
CMS
MGC

Signaling_Start

X

X

Signaling_Stop

X

X

Interconnect_Start

 

X

Interconnect_Stop

 

X

Call_Answer

X

X

Call_Disconnect

X

X

Database_Query

X

 

Service_Instance

X

 

Service_Activation

X

 

Service_Deactivation

X

 

Media_Alive

X

X

Time_Change

X

X


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 15 EM Triggers by Logical Entity 

Event Message
Originating CMS
Terminating CMS
Originating MGC
Terminating MGC

Signaling_Start

Timestamp: Receipt of NCS NTFY
Send: after translation

Prop trigger

Receipt of IAM
or
Receipt of TGCP NTFY

Receipt of Invite (prop)

Signaling_Stop

If T-CMS releases first: receipt of 250RSP to DLCX

If O-CMS releases first: before deallocating call block

If O-CMS releases first: receipt of 250RSP to DLCX

If T-CMS releases first: before deallocating call block

If T-MGC releases first: upon last of following events: 1. Receipt/transmit RLC from/to SG 2. Receipt/transmit of Ack for TGCP DLCX 3. Receipt/transmit last msg from/to T-CMS (prop)

If O-MGC releases first: before deallocating call block

Receipt of 250OK to DLCX

Interconnect_Start

 

 

Transmit/receipt of ACM

Transmit/receipt of ACM

Interconnect_Stop

 

 

Release of PSTN bandwidth

Release of PSTN bandwidth

Call_Answer

Receipt of 200OK to Invite with call answer

Receipt of NCS NTFY for off-hook of T-MTA

Receipt of ANM or
Answer ind on op.service

Receipt of ANM or
Answer ind on op.service

Call_Disconnect

Transmit DLCX or
delete connection on errors

Transmit DLCX

Receipt of REL or Transmit BYE for REL

Receipt of REL or Disconnect ind on op. service trunk disconnect

Database_Query

Receipt of response from DB/Intelligent peripheral

Receipt of response from DB/Intelligent peripheral

 —

 —

Service_Instance

Operation of service

Operation of service

 —

 —

Service_Activation

Successful activation

Successful activation

 —

 —

Service_Deactivation

Successful deactivation

Successful deactivation

 —

 —

Media_Alive

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Time_Change

When time is adjusted

When time is adjusted

When time is adjusted

When time is adjusted


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 

 
EMs Sent in Addition to Basic Call EMs
Comments
PacketCable 1.0 Feature
Event Message
Trigger

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. Send all database queries to PSTN
on special trunk

None

 —

 —

b. Query database and route accordingly

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:

For types 1 and 2, the value in the EM Return_Number field contains the new called party digits.

For type 3, the value in the EM Return_Number field contains a valid string, such as "O" or "P". 1

If the query fails, no EM is sent.

Operator service

a. 0- service (no digit after 0)

None

Called party number 0 is replaced by Operator Service Provider number.

Only call routing.

b. 0+ service (digits after 0, not needed in PacketCable 1.0)

 

 

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. Announcement server on net

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 BCID3

BCID4 for CW service instance, related BCID = BCID1

b. Announcement server on PSTN

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=BCID2

Return call
(with caller ID privacy restriction)

CMS-CMS signaling is not supported in this release.

a. Announcement server on net

Service instance

O-CMS on feature initiation.

 —

b. Announcement server on PSTN

Not supported

 —

 —

Repeat call (*66)

CMS-CMS signaling is not supported in this release.

a. Announcement server on net

Service instance

Repeat call is initiated.

Separate BCID for service instance.

b. Announcement server on PSTN

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:

Report on all DNs belonging to a specific NDC and EC.

Report on a thousands group within a specific NDC and EC.

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:

Operating Company Number (OCN)

Common Language Location Identifier (CLLI) code.

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 See the "Measurements" section of the Cisco BTS 10200 Softswitch Operations and Maintenance Guide for all traffic measurements.


Call Processing Measurements


Note For the following measurements, an unusually rapid count may indicate a problem.


Table 17 Call Processing Measurements 

Measurement
Description

CALLP_LNP_RCV_MISROUTED_PORTED

The LNP Data Inconsistencies with release message (REL): the number of misrouted calls to a ported number (ANSI ISUP REL cause 26) reported by another exchange after an LNP query in the reporting call agent.

CALLP_LNP_SND_MISROUTED_PORTED

The number of misrouted calls to a ported number detected by the reporting call agent after an LNP query in the reporting call agent.

CALLP_LNP_UNALLOC_NUM_ NO_GAP

The LNP Unallocated Number Calls: The number of calls resulting in either:

an unallocated number

a misrouted ported number

This measurement shows when an LNP query (from the BTS or another switch) results in either of the above conditions from the donor switch's reporting call agent.

To find out when this query occurred use the Forward Call Indicator's (FCI) Ported Number Translation indicator parameter with no "Ported Number" generic address parameter (GAP).

CALLP_LNP_UNALLOC_NUM_ OWN_LRN

LNP Data Inconsistencies: The number of LNP calls getting an Unallocated indication. This occurs when a donor (or another switch) detects the reporting call agent's own local routing number (LRN) after an LNP query.

To find out when this query occurred use the Forward Call Indicator's (FCI) Ported Number Translation indicator parameter with a "Ported Number" generic address parameter (GAP).


Note This does not apply to DNs marked "LNP-Reserved."



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.

AINSVC_TOTAL_LNP_QUERY

AINSVC_EXT_LNP_QUERY

AINSVC_EXT_LNP_QUERY_SUCC

AINSVC_EXT_LNP_FAIL_APP

AINSVC_EXT_LNP_FAIL_NETW

AINSVC_EXT_LNP_QUERY_LRN

AINSVC_EXT_LNP_QUERY_FAIL

AINSVC_LOC_LNP_QUERY

AINSVC_LOC_LNP_FAIL_APP

AINSVC_LOC_LNP_QUERY_SUCC

AINSVC_LOC_LNP_QUERY_RN_FOUND

AINSVC_LOC_LNP_QUERY_NO_RN

TOOLS_LNP_QUERY_ATTMP

TOOLS_LNP_QUERY_SUCC

Call Processing Events and Alarms


Note See the "Events and Alarms" section of the Cisco BTS 10200 Softswitch Troubleshooting Guide for details about event causes and corrective actions.


CALLP(42)

CALLP_LNP_OWN_LRN_MISROUTED

DESCRIPTION

Failed after LNP Query with LRN of this switch and the dialed number (DN) is unallocated

SEVERITY

INFO

THRESHOLD

100

THROTTLE

0

DATAWORDS

Calling Number—STRING [20]

Called Number (GAP)—STRING [20]

Location Routing Number (LRN)—STRING [20]

Jurisdiction Information Parameter (JIP)—STRING [20]

PRIMARY
CAUSE

1. Provisioning of ported-in subscriber has not been completed.

2. The LNP database service control point (SCP) has an incorrect LRN for the given DN.

PRIMARY
ACTION

1. Ensure the process of porting the DN from donor to recipient switch (and all nodes in between) has time to complete; if misrouting still occurs when porting completes proceed to the next step.

2. On the reporting BTS, ensure that the DN is correctly provisioned.

3. Check the LNP database on the SCP or in another switch. If there is an error, notify the administrators.


Modified DN2SUBSCRIBER Table

The description of the NP_RESERVED token in the DN2SUBSCRIBER table is modified as follows:.

Syntax Description

NP_RESERVED

This token can only be set when the STATUS is VACANT.

If a call is received with the switch LRN and GAP parameter containing a DN for which the DN2SUBSCRIBER status is VACANT:

If NP_RESERVED=Y, send release cause 1 (vacant/unallocated number)

If NP_RESERVED=N, send release cause 26 (misrouted ported number)


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:

Packet Loss at Originating and Terminating End Point

Latency at Originating and Terminating End Point.

Deleted (was bit error rate)

Packet Loss Rate at Originating and Terminating End Point

Jitter at Originating and Terminating End Point.

Buffer Size of Originating and Terminating End-Point/MTA

Packet Size of Originating and Terminating End Point

Speech size of Originating and Terminating End Point

Allocated Bandwidth at Originating and Terminating End Point

Packets Sent from Originating and Terminating End Point

Packets Received at Originating and Terminating End Point

Octets Sent from Originating and Terminating End Point

Octets Received at Originating and Terminating End Point

Deleted (was Call Usage (Records/Events) Sent From Originating and Terminating End Point)

Deleted (was Out of Order Packets at Originating and Terminating End Point)

Codec Type used in the call.

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.