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, page 2
•
System Requirements, page 2
– Hardware Requirements, page 3
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Before You Begin
– Software Requirements, page 6
•
Component Interoperability, page 8
•
Installation Notes, page 10
•
Upgrade Procedures, page 11
•
Bug Toolkit, page 11
•
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3), page 12
•
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2), page 16
•
New Features for Release 5.0, page 22
•
Cisco Field Notices, page 79
•
Obtaining Documentation and Submitting a Service Request, page 79
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
Note
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.
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 on page 3.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
2
OL-10355-05
System Requirements
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
3
System Requirements
Table 1
Host Hardware Requirements
Hardware Platforms
Processors
Required Memory
Disk Size
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
4
OL-10355-05
System Requirements
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
5
System Requirements
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
6
OL-10355-05
System Requirements
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
7
Component Interoperability
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 BTS 10200 Softswitch Release Notes for Release 5.0.x
8
OL-10355-05
Component Interoperability
Table 4
Component Interoperability Matrix (continued)
Platform(s) Tested
Function(s) Tested
Protocol(s) Tested
Load(s) Tested
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
Cisco MGX VXSM
Trunking Gateway
MGCP 1.0, TGCP
3.53.30.203
MGCP 1.0, TGCP
5.3.10.201-P2
Trunking Gateway
1
MGCP 1.0, TGCP
12.4.12
Cisco AS5350
Trunking Gateway
1
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
Cisco AS5300
Embedded MTAs
Arris TM402P
eMTA
NCS 1.0, IPSEC
TS0440559_022406_MODEL_4_5_TE
LNET_ON
Motorola SBV5220
eMTA
NCS 1.0, IPSEC
2.16.1.1
Motorola SBV5120
eMTA
NCS 1.0, IPSEC
2.16.1.1
Motorola SBV4200
eMTA
NCS 1.0, IPSEC
2.16.1.1
Scientific Atlanta
Dpx2203
eMTA
NCS 1.0, IPSEC
v1.1.2r1151-050224b-5
Linksys PAP2
SIP endpoint
SIP
3.1.5(Lsd)
Cisco 7940
SIP phone
SIP
6.2
Cisco 7960
SIP phone
SIP
6.2
SIP Endpoints
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
9
Installation Notes
Table 4
Component Interoperability Matrix (continued)
Platform(s) Tested
Function(s) Tested
Protocol(s) Tested
Load(s) Tested
Policy Servers
Camiant Multimedia
Service Controller
Policy server
2.3
CableMatrix
On-Demand Service
Platform (ODSP)
Policy server
1.0.0b6
ENUM application
5.2.11
ENUM (Release 5.0 MR1)
Netnumber Titan
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
Note
Do not modify any operating system parameters that the Cisco BTS 10200 Softswitch Jumpstart installs.
The application installation procedure is for duplex systems, the only installation type supported for
Release 5.0.x.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
10
OL-10355-05
Upgrade Procedures
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
11
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
Step 6
Next to version (see Definition of Major, Point, and Maintenance Releases, page 6):
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
12
OL-10355-05
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
13
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
14
OL-10355-05
New Features and Enhancements for Release 5.0, Maintenance Release 2 (5.0.3)
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
15
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
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):
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
16
OL-10355-05
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
17
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
18
OL-10355-05
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
19
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
20
OL-10355-05
New Features and Enhancements for Release 5.0, Maintenance Release 1 (5.0.2)
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
21
New Features for Release 5.0
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
22
OL-10355-05
New Features for Release 5.0
– 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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
23
Telephony Features
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
24
OL-10355-05
Telephony Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
25
Telephony Features
•
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:
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
26
OL-10355-05
Telephony Features
•
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
27
Telephony Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
28
OL-10355-05
Telephony Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
29
Telephony Features
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
30
OL-10355-05
Telephony Features
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
31
Telephony Features
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
32
OL-10355-05
Telephony Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
33
Telephony Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
34
OL-10355-05
Telephony Features
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
35
Telephony Features
•
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).
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
36
OL-10355-05
Telephony Features
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
37
Telephony Features
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)
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
38
OL-10355-05
Telephony Features
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:
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
39
Operational Features
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
40
OL-10355-05
Operational Features
•
<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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
41
Operational Features
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
42
OL-10355-05
Operational Features
– 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:
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
43
Operational Features
•
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
44
OL-10355-05
Operational Features
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
12331874656
12331874657
12331874658
12331874659
TYPE
SIGNALING
MAINTENANCE
OSS
OSS
NUMBER
68
3
9
9
SEVERITY
MAJOR
MAJOR
MINOR
MINOR
TIMESTAMP
2005-11-20
2005-11-20
2005-11-20
2005-11-20
11:00:00
11:01:00
11:02:45
11:02:45
COMPONENT-ID
testing@mgw_id
testing
unixserver
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
45
Operational Features
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
46
OL-10355-05
Operational Features
•
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_EMERG Emergency calls rejected at MCL4
ENCY
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_DUM Number of ISUP messages dumped at MCL4 by layer 3/4 interface (MIM) due to system
PED
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
47
Operational Features
Table 6
Service Interaction Manager Measurements Used by Overload Control
Measurement
Description
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
48
OL-10355-05
Operational Features
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-OVERLOA
D-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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
49
Operational Features
MGCP Asynchronous DNS Lookup
If the DNS server(s) fail or exhibit poor response times, synchronous DNS function calls could seriously
impact call processing by throttling new calls and failing existing calls. Very slow DNS responses from
improperly provisioned media gateway (MGW) fully qualified domain names (FQDN), or slower
responses from any MGW FQDN(s) that are not provisioned in the DNS server, seriously impact existing
call processing. Even call processing for all MGWs that have very fast DNS responses is impacted. The
BTS 10200 MGCP Asynchronous DNS lookup feature makes the BTS 10200 robust in the face of DNS
failures. The scope of this feature is initially limited to name lookup only, not other query types, and the
use of the feature is limited to the MGCP interface only. Protocols used include all gateway control
protocols (xGCP) including PacketCable NCS and TGCP protocols.
The BTS 10200 MGCP Asynchronous DNS Lookup feature launches asynchronous DNS lookups to
resolve FQDN of the media gateways while attempting to send MGCP messages. It also makes the
resolved IP addresses for FQDN available to standby side of the BTS 10200 for instant use without
launching new DNS queries. When MGW reboots, the BTS 10200 re-confirms its IP address from DNS
server and updates it in the BTS 10200 internal MGW DNS cache if the IP address is different. When
the BTS 10200 is started or restarted, it starts using the IP address in the BTS 10200 internal MGW DNS
cache if available and also triggers reconfirmation of that IP address from the DNS server. The BTS
10200 provides the configuration option to accept/reject and confirm/ignore the IP address of any FQDN
and update the IP address if it is different.
Additionally, other subsystems of the BTS 10200 can make use of this asynchronous DNS lookup
functionality in order to improve reliability of the BTS 10200.
Automatic Restart
The Cisco BTS 10200 Softswitch Automatic Restart feature is beneficial to customers because the BTS
10200 attempts to automatically restart a platform (EMS/FS/CA) to STANDBY that has become
OOS-FAULTY and shut down. Currently, the BTS 10200 does not restart a platform in this situation,
leaving the active platform running in a vulnerable simplex mode until the standby platform is restored
manually.
Benefits of this feature:
Note
•
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.
An Automatic Restart will not be attempted in some fault scenarios where the restart of the system will
likely fail.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
50
OL-10355-05
Other Enhancements
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
51
Other Enhancements
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.5I01-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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
52
OL-10355-05
Other Enhancements
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
REQ2529
The PCES event message sent to the delivery function (DF) must not affect the
Compliant
monotonically increasing sequence-number that appears in the Event Message header sent
to the RKS.
REQ6108
All PCES event messages must have the Event Object field in the EM Header attribute set Compliant
to 1.
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
Compliance
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
53
Other Enhancements
Table 9
Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A (continued)
Requirement
Description
REQ6111
If an IAP does not receive an Accounting-Response message within the configured retry Compliant
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.
REQ6112
REQ6113
Compliance
When a DF receives a PCES event message in a Radius Accounting-Request message from Not applicable
an IAP, it must send an Accounting-Response message to the IAP.
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 Compliant
the dialed digits on an MF-trunk.
REQ2537
Compliant
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.
REQ2538
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).
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 Compliant
for terminating calls that have been redirected by a surveillance subject.
Section A.3, Signaling Stop
REQ6120
If the service (call) is under surveillance, this event message must be generated with all Compliant
the standard required parameters and with the additional required electronic surveillance
parameters.
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
54
OL-10355-05
Other Enhancements
Table 9
Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A (continued)
Requirement
Description
REQ6122
A Signaling_Stop message must be generated if a Signaling_Start message with the same Compliant
BCID has been generated for the call (In exception cases, this may be the result of a
proprietary timeout or cleanup process.)
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.
REQ6124
Originating CMS: In the intradomain or interdomain scenario, the originating CMS must Compliant
timestamp this message upon transmission of the last signaling event in the following list:
Compliance
•
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 Compliant
EM message immediately upon transmission of the NCS-signaling DLCX message.
REQ6124
Terminating CMS: In the intradomain or interdomain scenario, the originating CMS must Compliant
timestamp this message upon transmission of the last signaling event in the following list:
REQ6124
REQ6128
•
Transmission of the NCS-signaling DLCX message
•
Transmission of the CMSS-signaling BYE message or CANCEL message
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
Compliant
Terminating MGC (on-net to off-net).
The terminating MGC must timestamp this EM message immediately upon transmission
of the TGCP-signaling DLCX message.
Section A.4, Call Answer
REQ2552
If the service (call) is under surveillance, this event message must be generated with all Compliant
the standard required parameters and with the additional required electronic surveillance
parameters.
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 Compliant
the standard required parameters and with the additional required electronic surveillance
parameters.
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
55
Other Enhancements
Table 9
Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A (continued)
Requirement
Description
Compliance
REQ5992
The CMS and MGC must send this message:
Compliant
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
REQ5993
REQ5993—The CMS or MGC must timestamp this message on receipt of response from Compliant
an endpoint that triggered the sending of the message (for example, a response from a
modify or delete connection).
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.
Compliant
REQ6001.2—The CCC_ID attribute must not be present for call data surveillance.
REQ6002
REQ6002.1—The SDP_Upstream attribute must be included if SDP is received from the Compliant
surveillance subject's associate.
REQ6003
REQ6003.1—The SDP_Downstream attribute must be included if SDP is received from
the surveillance subject.
REQ6072
Compliant
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.
REQ6073
REQ6073.1—The Flow_Direction attribute must be included and it must indicate the
direction of flow, either upstream or downstream.
Compliant
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
REQ5997
If the service is under surveillance, the Signal Instance message must be generated and
Compliant
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.
When the generation of the Signal Instance message is due to Condition 1 in the preceding Compliant
requirement (REQ5994), the Signal_Type attribute in Table 68 of’ the PacketCable must
be set to a value of “1” (Network Signal).
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
56
OL-10355-05
Other Enhancements
Table 9
Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A (continued)
Requirement
Description
Compliance
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, Compliant
the Signal Type attribute in Table 68 of the PacketCable specification must be set to a value
of “2” (Subject Signal).
REQ6000
The Switch Hook Flash, Digits Dialed, and Misc Signaling Information attributes must be Compliant
present in the Signal Instance message that is generated if the subject under surveillance
receives any of these signaling instances.
REQ6074
The required attributes must be present in the Signal Instance message as defined in the
Comment section of Table 68 in the PacketCable specification.
REQ6075
Compliant
REQ6646
REQ6647
REQ6007
REQ6008
REQ6009
REQ6010
REQ6011
REQ6012
Section A.12, Conference Party Change
REQ6648
The CMS must generate this event message for a conference call that was initiated by the Compliant
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.
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 Compliant
the conference is established by the intercept subject's service.
REQ6652
This attribute must be included when known, to identify a communicating party when one Compliant
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.
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)
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
57
Other Enhancements
Table 9
Cisco BTS 10200 Release 5.0 Compliance with PKT-SP-EM 1.5-101-050128, Appendix A (continued)
Requirement
Description
Compliance
Section A.13, Surveillance Stop
Not available
The CMS must timestamp this EM immediately at:
Compliant
13—At the End of a call
14—When CMS determines that surveillance cannot be started, or can no longer be
performed
Not available
Not available
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.
Surveillance Stop type:
•
1—End of surveillance (CDC and, if present, CCC)
•
2—End of CCC only (CDC to continue)
Electronic Surveillance Indication
Compliant
Compliant
Compliant
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).
Section A.14, Redirection
Not available
Not available
The Redirection message must be sent to the DF if a call involving a surveillance subject Compliant
is redirected and:
•
The CMS is aware of the redirection.
•
No Service Instance is generated for the redirection.
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
58
OL-10355-05
Other Enhancements
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
The LAES-BCID field must always be present. The LAES-CCCID field must be present Compliant
when the LAES-Content field is present. The LAES-Key field must not be included.
REQ7456
REQ7457
Compliant
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.
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
Compliant
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
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 Compliant
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
59
Other Enhancements
Table 10
Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D (continued)
Requirement
Description
Compliance
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 Compliant
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.
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
Compliant
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.
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
60
OL-10355-05
Other Enhancements
Table 10
Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D (continued)
Requirement
Description
REQ7465
If CMSO chooses not to perform any of the requested surveillance functions, it must send Not applicable
a Surveillance-Stop message to its local DF containing the following information:
No scenario is
• REQ7465.1—The local BCID assigned by CMSO to the call. (Even though the local identified
BCID is a required parameter, it does not convey any useful information in this case, where CMSO
(if BTS)
because the local BCID was not bound to the remote surveillance session by a
chooses not to
previous Signaling-Start message.)
perform the
• REQ7465.2—The remote BCID assigned by CMST and received in the
requested
P-DCS-LAES header.
surveillance.
• REQ7465.3—The call-data IP address and port of the remote DF of CMST received
in the P-DCS-LAES header.
•
REQ7466
Compliance
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.)
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:
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
61
Other Enhancements
Table 10
Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D (continued)
Requirement
Description
Compliance
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
Compliant
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.
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
62
OL-10355-05
Other Enhancements
Table 10
Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D (continued)
Requirement
Description
Compliance
REQ7471
If a P-DCS-LAES header was received that indicates that call-content surveillance is to
be performed, CMST must include the following additional information in the
Signaling-Start message:
Compliant
REQ7472
•
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
When the call ends, CMST must send a Surveillance-Stop message to its local DF
containing the local BCID and indicating that both local and remote call-data and
call-content surveillance are to be stopped.
Compliant
Section 7.7.2.3.2, Terminating Line Is Unable to Accept the Call
REQ7473
If CMST receives an INVITE request containing a P-DCS-LAES header, and the
terminating endpoint is not able to accept the call for some reason (for example, line is
busy, line is unknown), and CMST does not need to otherwise initiate a surveillance
session, CMST must send a Surveillance-Stop message containing the following
information:
•
Note
Compliant
REQ7473.1—The local BCID assigned by CMST to this call
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
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 Compliant
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.
REQ7475
Once this procedure has established the local-to-remote call-data surveillance
Compliant
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
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 Compliant
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
63
Other Enhancements
Table 10
Cisco BTS 10200 Release 5.0 Compliance with PKTCBL 1.5 CMSS Section 7.7.2, Appendix D (continued)
Requirement
Description
Compliance
REQ7477
If a P-DCS-LAES header was received, CMST must include the following additional
information in the Signaling-Start message:
Compliant
•
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
REQ7478
If either the local electronic surveillance order or the received P-DCS-LAES header
indicates that call-content surveillance is to be performed, CMST must allocate a local
CCCID for the call.
Compliant
REQ7479
In addition to the call-data parameters, CMST must include the local CCCID in the
Signaling Start message to the local DF.
Compliant
REQ7480
If a P-DCS-LAES header was received indicating that call-content surveillance is to be
performed, then CMST must include the following additional information in the
Signaling-Start message:
Compliant
•
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
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 Compliant
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.
REQ7482
The P-DCS-LAES header must contain the following information:
REQ7483
•
REQ7482.1—The local BCID assigned to the call
•
REQ7482.2—The call-data IP address and port of the local DF
Compliant
If CMST is required to perform call-content surveillance for the call, it must include the Compliant
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
REQ5178
If the P-DCS-LAES header is present in the 183-Session-Progress response (indicating Compliant
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).
REQ5221
If a P-DCS-LAES header is present in the 3xx response, CMSO should include that
header unchanged in the reissued INVITE.
REQ5349
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
64
OL-10355-05
Other Enhancements
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
65
Other Enhancements
Table 11
Migrated Signaling Events and Alarms (continued)
Type and Number
Description
Severity
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
66
OL-10355-05
Other Enhancements
Table 12
Migrated Maintenance Events and Alarms (continued)
TYPE & NUMBER
DESCRIPTION
SEVERITY
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
67
Other Enhancements
Table 12
Migrated Maintenance Events and Alarms (continued)
TYPE & NUMBER
DESCRIPTION
SEVERITY
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
Syntax Description
The URL starts with “https” instead of “http”. Any existing target file is overwritten.
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
68
OL-10355-05
Other Enhancements
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
Originating CMS
X
X
Terminating CMS
X
X
Originating MGC
Terminating MGC
Off-net to On-net
X
X
Table 14 lists the specific EMs that can be generated by the CMS and MGC.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
69
Other Enhancements
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
Signaling_Start
Timestamp: Receipt of Prop trigger
NCS NTFY
Send: after translation
Signaling_Stop
If T-CMS releases first: If O-CMS releases
first: receipt of
receipt of 250RSP to
250RSP to DLCX
DLCX
Originating MGC
Terminating MGC
Receipt of IAM
or
Receipt of TGCP
NTFY
Receipt of Invite (prop)
Receipt of 250OK to
If T-MGC releases
DLCX
first: upon last of
following events:
1. Receipt/transmit
If T-CMS releases first:
If O-CMS releases
RLC from/to SG
before deallocating call
first: before
2. Receipt/transmit of
deallocating call block block
Ack for TGCP DLCX
3. Receipt/transmit last
msg from/to T-CMS
(prop)
If O-MGC releases
first: before
deallocating call block
Interconnect_Start
Transmit/receipt of
ACM
Transmit/receipt of
ACM
Interconnect_Stop
Release of PSTN
bandwidth
Release of PSTN
bandwidth
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
70
OL-10355-05
Other Enhancements
Table 15
EM Triggers by Logical Entity (continued)
Event Message
Originating CMS
Terminating CMS
Call_Answer
Receipt of 200OK to
Receipt of NCS NTFY Receipt of ANM or
Invite with call answer for off-hook of T-MTA Answer ind on
op.service
Call_Disconnect
Transmit DLCX or
delete connection on
errors
Transmit DLCX
Receipt of REL or
Receipt of REL or
Transmit BYE for REL 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
Periodic, based on
Periodic, based on
Periodic, based on
provisioned parameters provisioned parameters provisioned parameters provisioned parameters
Time_Change
When time is adjusted
When time is adjusted
Originating MGC
When time is adjusted
Terminating MGC
Receipt of ANM or
Answer ind on
op.service
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
PacketCable 1.0 Feature
Event Message
Trigger
Comments
911 service—Similar to on-net to off-net None
call on a unique trunk group ID.
—
—
Other N11 services—Similar to above
None
—
—
None
—
—
Database query
a.
Send all database queries to PSTN
on special trunk
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
71
Other Enhancements
Table 16
PacketCable 1.0 Features and Associated EMs (continued)
EMs Sent in Addition to Basic Call EMs
PacketCable 1.0 Feature
b.
Query database and route
accordingly
Event Message
Trigger
Comments
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.
b.
0– service (no digit after 0)
None
Called party number 0 Only call routing.
is replaced by Operator
Service Provider
number.
0+ service (digits after 0, not needed
in PacketCable 1.0)
Call block service (with new call to
announcement server)
Only call routing.
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
72
OL-10355-05
Other Enhancements
Table 16
PacketCable 1.0 Features and Associated EMs (continued)
EMs Sent in Addition to Basic Call EMs
PacketCable 1.0 Feature
Event Message
Trigger
Comments
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:
Call waiting
a.
Announcement server on net
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
Call forwarding
not supported
—
—
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)
a.
b.
CMS-CMS signaling is not
supported in this release.
Announcement server on net
Service instance
O-CMS on feature
initiation.
—
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 None
off-net call
—
—
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
73
Other Enhancements
Table 16
PacketCable 1.0 Features and Associated EMs (continued)
EMs Sent in Addition to Basic Call EMs
PacketCable 1.0 Feature
Event Message
Trigger
Comments
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)
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
74
OL-10355-05
Other Enhancements
•
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
Table 17
For the following measurements, an unusually rapid count may indicate a problem.
Call Processing Measurements
Measurement
Description
CALLP_LNP_RCV_MISROUTED_ The LNP Data Inconsistencies with release message (REL): the number of misrouted
PORTED
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_ The number of misrouted calls to a ported number detected by the reporting call agent
PORTED
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.”
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
75
Other Enhancements
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
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
76
OL-10355-05
Other Features
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.
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. The LNP database service control point (SCP) has an incorrect LRN for the given DN.
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
77
New Documentation
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
78
OL-10355-05
Cisco Field Notices
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.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
OL-10355-05
79
Obtaining Documentation and Submitting a Service Request
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and
Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access
Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the
Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink,
Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime
Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet,
Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks
of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0809R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco BTS 10200 Softswitch Release Notes for Release 5.0.x
80
OL-10355-05