Cisco BroadWorks accounting call detail record (CDR) fields can be controlled individually. For each field, it is possible to enable or disable its generation in all output formats (file, RADIUS, Diameter). When the Diameter format is used (Rf and Ro interfaces), many Diameter-standard and 3rd Generation Partnership Project (3GPP) vendor-specific attribute-value pairs (AVPs) are added. While most of these AVPs can be enabled or disabled globally, prior to this feature it was not possible to select which AVPs should be included individually.

This enhancement allows individual control of Diameter-standard and 3GPP vendor-specific AVPs.

Cisco BroadWorks accounting call detail record (CDR) fields can be controlled individually. For each field, it is possible to enable or disable its generation in all output formats (file, RADIUS, Diameter). When the Diameter format is used (Rf and Ro interfaces), many Diameter-standard and 3rd Generation Partnership Project (3GPP) vendor-specific attribute-value pairs (AVPs) are added. While most of these AVPs can be enabled or disabled globally, prior to this feature it was not possible to select which AVPs should be included individually.

This enhancement allows individual control of Diameter-standard and 3GPP vendor-specific AVPs.

Charging: This activity removes the obsolete Accounting Event interface and all implementation referring to it. The interface was introduced in Release 3.0 and has not been used since Release 8.0.

The accounting interface currently in use is the Call Detail Record (CDR) Accounting interface.

NOTE: This activity has no impact on the CDR Accounting Interface.

Call detail records are enhanced to identify which feature a user invoked as a result of dialing a feature access code. Since feature access codes are configurable per group, this enhancement simplifies the billing of usage-sensitive services.

Access-side correlation ID added to the CDR for the originating portion of the call to allow it to be correlated with the CDR for the terminating portion of the call in the IMS Third-Generation Partnership Project (3GPP) architecture.

Charging: Enhances the call detail record (CDR) by adding a new field AS Call Type to all originating and terminating CDRs.

The possible values for the reported call type in the CDR are:

• Group – When translations of the dialed address on the Application Server can identify the target user and this user is in the same group as the originator.

• Enterprise – When translations of the dialed address on the Application Server can identify the target user and this user is in the same enterprise but not the same group as the originator.

• Emergency – When translations of the dialed address on the Application Server find a match with the digit patterns defined as an emergency call type.

• Repair – When translations of the dialed address on the Application Server find a match with the digit patterns defined as a repair call type.

• Internal – When translations of the dialed address on the Application Server find a match with an FAC and:

• The feature access code is a programming FAC

• Per-call FAC without destination digit allows a user to activate the feature for a given call.

• Network – When translations of the dialed address on the Application Server do not yield a specific result, the address is sent to the Network Server for further translations. In such a case and when the address is made of digits, the Application Server call type is set to “Network”.

NOTE: The result of Network Server translations is reported in a distinct CDR field named networkCallType.

• Network URL – When translations of the dialed address on the Application Server do not yield a specific result, the address is sent to the Network Server for further translations. In such a case and when the address is made of a SIP-URI, the Application Server call type is set to “Network URL”.

NOTE: The result of Network Server translations is reported in a distinct CDR field named networkCallType.

This feature enhances the Application Server so that Cisco BroadWorks call detail record (CDR) captures the fact that a Carrier Identification Code (CIC) has been added as a Carrier Access Code (CAC).

The Network Server is also enhanced by allowing each hosting network element (NE) to decide whether to send the CIC as a CAC in the returned contacts.

The following list is a high-level overview of the capabilities provided by this feature:

• The Enhanced Call Logs Repository stores only the relevant call log information instead of the complete call detail record (CDR) information.

• Pertinent call log information such as call redirection by the Cisco BroadWorks user is captured in the call log entries on the Enhanced Call Logs Repository.

• Provides various query and filtering options for call log retrieval allowing call log clients and applications to retrieve specific call logs using Open Client Interface-Provisioning (OCI-P) or Xsi-Actions.

• All Database Server deployment models are supported to provide a redundant solution. Furthermore, if the connection between the Cisco BroadWorks Application Server (AS) and the Enhanced Call Logs Repository is lost, call log information is persisted to the local file system on the Application Server. The call logs from the local file system are delivered to the Enhanced Call Logs Repository once the connection between the Application Server and the Enhanced Call Logs Repository is re-established.

• Provides a call log retention mechanism. Call logs are maintained on the Enhanced Call Logs Repository for a specific period of time (called the retention period). All call logs older than the retention period are deleted from the Enhanced Call Logs Repository and can no longer be retrieved.

The ability for a customer to migrate call log data from a Call Detail Server (CDS) to the Enhanced Call Logs Repository is provided. The call logs migrated from the Call Detail Server can then be retrieved from the Enhanced Call Logs Repository by call log applications.

System Management (FCAPS): The call detail record (CDR) time stamps are currently captured when the applicable event is processed. This may be subject to errors due to queue and/or other processing delays.

With the implementation of this feature, the Application Server records the time stamps as soon as the packets are received on the socket. As a result, there is virtually no delay (under one microsecond processing time to receive the packet from the socket and record the time stamp) in the recorded time stamp for the packet.

Decode and call processing queue delays have no impact on the recorded time stamps. Therefore, the Application Server time stamps used to determine the call duration are well within the 500-microsecond accuracy limit required by the regulations of some countries.

Note that the definition of “call duration” is the computed difference between the release time and the answer time.

This feature is a combination of the following enhancements to the Charge Number service:

• Supports configurable Uniform Resource Identifier (URI) scheme for the P-Charge-Info header.

• Adds the capability to send the charge number in the Diversion header of an outgoing INVITE request to the network. Using the Diversion header to carry the charge number is a special regulatory requirement for carriers in some countries.

This feature introduces the system-level configuration parameter to modify the method of population of accounting CDR fields derived from a received

P-Charging-Vector when the Application Server is configured to run in stand-alone mode without the hybrid AS mode enabled.

Charging: Introduces support for prepaid subscribers on the Cisco BroadWorks platform. This entails requesting credits from an Online Charging System (OCS) before allowing a call to proceed, reporting used credits to the OCS, and terminating a call should credits eventually run out during the call.

Communication between the Application Server and the OCS is done using the Diameter interface. In IP Multimedia System (IMS) terminology, this Diameter interface between the Application Server and the OCS is known as the Ro reference point. However, this feature can equally be used in stand-alone mode and in IMS mode.

This feature implements the core Ro interface, which includes charging by time and disconnecting when credit is exhausted (as well as failover support).

Session Charging with Unit Reservation (SCUR) is the implemented mechanism, where units (of time) are reserved and debited once used.

A new user feature is introduced. Users must be assigned the Prepaid feature to enable online billing. No per-user configuration is necessary apart from assigning and enabling the Prepaid feature itself.

This feature provides enhanced interoperability between legacy networks and 3G mobile carriers without requiring an upgrade to an IP Multimedia Subsystem (IMS) solution by recording the PCV header content when the header is present in the 200 response to an INVITE. This feature does not proxy the PCV header.

The system captures the contents of the PCV header in the call detail record (CDR) for the call. This feature also adds a new CDR field for non-standard parameters called otherInfoInPCV. The contents of this field contain the additional parameters and their unparsed values, which do not match the standard parameters defined for the PCV header.

The originating CDR is populated with the otherInfoInPCV field when the call does not involve redirection. In the case of call redirection, the redirecting party’s originating CDR is populated when the call involves redirection.

This feature enhances the Application Server to capture the value of the

P-Access-Network-Info (PANI) received in a SIP REGISTER in the CDRs.

Configuration and Provisioning: The Application Server upload feature of the Network Server allows for importing the provisioning data of a Cisco BroadWorks Application Server into the Network Server database. This is particularly useful for resynchronizing a Network Server with all managed Application Servers upon reinstallation or database re-initialization.

This feature enhances the Application Server upload process by improving the performance of the command with respect to speed and consumed resources.

This feature provides web applications with the capability of generating single-use authenticated tokens that can be used to gain secure access to other web applications. These other web applications are hosted either on the same server or on a different server.

The use of these tokens allows seamless integration between different web applications either by allowing one web application to access another directly (server-side integration) or by allowing clients of one web application to use another secure web application (client-side redirect) without the need to re-authenticate the user. No security configuration or management is required on the part of the operator to allow secure web application cooperation.

The Single Sign-On services are provided by the BwCommunicationUtility and are available to web applications hosted on the Xtended Services Platform.

This feature converts three container options into system parameters and user controls.

• bw.scap.pnHonorAlertAllGroupPaging

• bw.ocip.includeDefaultDomain

• bw.ps.nsSynchConnectionTimeout

Calling Line Identity Enhancements significantly enhances the current configurable calling line identity (CLID) policy by:

• Separating the emergency and non-emergency CLID policy configuration

• Consolidating the current CLID configuration at the system level and placing it under system call processing policies

• Adding the new CLID policy configuration at the service provider level

• Consolidating the existing CLID configuration at the group level under the new CLID policy

• Adding a new CLID policy at the user level

• Adding a new call processing policy at all administrative levels to enable the sending of an alternate number as the redirecting identity in the redirection information

This feature is significant with regards to emergency call originations in that it allows the carrier to purchase fewer numbers in the Automatic Location Identification (ALI) database, which significantly lowers their cost of offering services. This enhancement has been requested by, and will be welcomed by many customers.

Provides a command line interface (CLI) that provides access to system provisioning and monitoring. The following functionality is accessible through the CLI:

• Alarms – access to generated alarms and events (SNMP traps). The display is real-time

• Audit Trails – provides access to all changes made by the service provider, including, adds, changes and deletions. Provides the ability to view and reset data

• Configuration – provides a command line interface for configuration performed by the system provider

• Service Performance Measurements – provides access to service-level performance measurements

• System Performance Measurements – access to service-level performance measurements

This feature enhances the Cisco BroadWorks Command Line Interface (CLI) for all servers in the following ways:

• Extends the tree command to support a dump of the entire CLI structure, including help and type information, into an XML format

• Enforces help for all parameters at each level for all CLIs on all servers

Through these enhancements, Cisco can provide an easy way for an operator to identify any CLI deltas between releases (major and/or service packs).

The various levels of the CommPilot web portals have been enhanced to improve navigation and usability. The enhancements were based on usability studies conducted by multiple large carriers. In most cases the body content has not been changed, only the appearances (for example, colors, font sizes, and so on), header content, and navigation content have been changed. Specifically, the following enhancements have been made to the CommPilot web portal:

• Left navigation modified to provide more intuitive navigation

• Error messages are more visible

• Web pages and menus have more text explaining use of services

• Read-only pages provided for assignable user services that have no configuration data (for example, Flash Call Transfer)

• Web pages designed to be easily modified (if necessary) to work with other browsers and content

• Support provided for browsers (other than Internet Explorer)

• Screens support 800 x 600 resolution

• All text has font size of at least 12 points

• Can use “Back” button on browser to navigate in the application

• Style sheet modified to make it easier for system or service providers to customize

The goal of this activity is to put in place the second phase of the Centralized Configuration. The two main objectives of this activity are to:

• Enable all Cisco BroadWorks servers for Centralized Configuration (Xtended Services Platform [Xsp] and Profile Server [PS] are already supported in Release 16.0), and

• Add a few additional key features to the Element Management System (EMS) Centralized Configuration framework.

This feature introduces Centralized Configuration on the Call Detail Server.

This feature adds new system parameters to support configuration options that were previously supported via container options:

A new SIP system parameter, useDomainForUnavailableIdentity,

is created to control how the Application Server builds unavailable identity.

• Two new system parameters, alwaysAllowRefreshForMS and msAuditIntervalSeconds, are created to control the custom session audit for the Application Server interface to the Media Server.

This feature converts the following four container options that were introduced in various patches:

• bw.scap.pnHonorAlertAllClickToDial

• bw.meetme.allowUnmuteInAutoLectureMode

• bw.conference.disableClampTones

• bw.cr.useContinueCallAfterFailureForOnDemandMode

This feature converts the following container options to formal command line interface (CLI) attributes:

• msfe enableSilenceSuppressionInConference

• msfe syncSsrcImmediately

• msfe dtmfTwistHi

• msfe dtmfTwistLo

• uvsfe enableSilenceSuppressionInConference

• uvsfe dtmfTwistHi

• uvsfe dtmfTwistLo

This feature also converts the formal CLI attribute, listeningIPAddresses from a list to individual IPv4 and IPv6 addresses aligning with supported usage.

This feature converts five container options into system parameters.

• bw.tpvm.sendDiversionUserId

• bw.diameter.roMultipleServicesIndicatorIsSupported

• bw.sip.honorSystemHoldSDPMethod

• bw.sip.disallowPAIHeaderFromNetworkSide18x

• bw.sip.trunk.useMostRecentEntryOnDeflection

System: Currently, the Application Server uses the Application Server publicIPAddress in the HTTP URL when signaling the Media Server for playing media files and not the address defined for the media file. The solution is to introduce the media Internet Protocol (IP) address to the appserver.properties file.

By defining the media interface IP address, the Application Server uses the specified media IP address when asking the Media Server to play a media file. If the media IP address is not defined in the properties file, the Application Server uses the Application Server publicIPAddress. The appserver.properties file supports a new property namedbw.http.mediaif.

Note that adding or changing this property requires a restart of the Application Server.

Element Management: Introduces a new configuration-management framework that provides centralized control of Cisco BroadWorks network-element configuration from the Element Management System (EMS). The framework introduces new components that are part of the Cisco BroadWorks server platform and others that are hosted on the EMS. The framework is based on management of XML configuration data formalized using XML Schema.

The EMS hosts the graphical management application that allows the operator to view and edit the configuration of the Cisco BroadWorks network elements it manages. Configuration data is version-controlled on the EMS where updates are staged and validated before being downloaded onto the selected network elements. Configuration changes are done without the need for interactions with the network elements.

The EMS provides the means to manage configuration settings common to pools of same-type network elements, thereby simplifying the management of server farms.

When the EMS is not used to manage network elements, configuration through the local CLI is supported. Otherwise, the CLI can always be used to read the configuration settings.

In this release, the configuration framework is only integrated with the Xtended Services Platform servers and Profile Servers and does not affect any other server type.

Platform and System Enhancements: This feature provides the ability to configure the SIP interface address of both the local and redundant Application Servers (in a cluster of two Application Servers) to route distributed group calls (DGCs) in a non-IP Multimedia Subsystem (IMS) environment.

Currently, in a non-IMS environment, DGCs are routed to the Network Server to obtain the SIP signaling address of the other Application Server in redundancy mode. This has proven to be problematic for system configurations that do not have a Network Server as part of the system deployment. In such cases, the SIP INVITE cannot be routed properly to the other Application Server in the cluster.

It is important to note that this functionality is provided regardless of whether or not the deployment contains a routing component (Network Server). If the configuration properties are empty, the current behavior of the system is not affected.

This feature introduces the following two system parameters to control the two different FTP timer values:

ftpConnectionTimeoutSeconds – This parameter controls the time

(in seconds) that the system waits for a successful connection.

• ftpMaxTransferDurationSeconds – This parameter controls the maximum time (in seconds) that a connection should remain open for a file transfer.

This feature converts a container option to a system parameter.

When the incoming digits are prefixed with OAC and the Execution Server detects the exact match with the configured Outside Access Code (OAC) digit, the Execution Server skips the internal translation if the parameter is “false”. If the parameter is “true”, then the Execution Server performs the internal translation. If the internal translation does not find a subscriber, then the Execution Server sends the request to the Network Server.

Currently, the Element Management System’s (EMS) enterprise/service provider migration tool allows operators to move a single enterprise or service provider from one Application Server (AS) cluster to another within a system. The amount of time that it takes to execute and validate the migration of a single enterprise only allows operators to migrate one or perhaps two enterprises in a single night’s work. For this reason, the tool is not practical for operators who want to migrate many enterprises from one Application Server cluster to another. It simply requires too many maintenance windows to migrate all the enterprises that they would like.

This enhancement allows operators to select a list of enterprises or service providers to migrate at one time. While there is no change to how the database data/files are migrated, this should improve the overall operation time by reducing the number of execution and validation steps needed when migrating one enterprise at a time.

Prior to this feature, the Network Function Manager only supported two user roles: Admin and User. This activity allows better user control access by offering a richer set of roles and a more tunable approach. The operator can define groups, associate roles to the groups, and assign users to a group.

This activity also adds security audit logs to track security-related operations performed by users.

Network Server Allows

Non-numerical Characters

Configuration and Provisioning: This feature adapts the Open Client Server (OCS) to run on the Xtended Services Platform (Xsp).

On the Xtended Services Platform, the OCS runs on top of the Java Container Application Framework as a Cisco BroadWorks application.

From an external perspective, this feature affects the configuration (command line interface, configuration agent), but preserves the same behavior and interaction for the clients and servers in the Cisco BroadWorks solution. Third-party applications communicating through the OCS will not require modifications.

On the Element Management System (EMS) and Application Server, the OCS continues to operate without change. In other words, it runs as a stand-alone process on those servers without affecting configuration.

For the EMS, Application Server, Network Server, and for an external web authentication server, the interaction with the OCS remains unchanged as well.

This feature removes the dependency between the Location-Based Calling Restriction and Roaming services.

Currently, roaming status is set only when the user has the Location-Based Call Restriction (LCR) service assigned. This activity removes this dependency so that roaming status can be determined for all users and not just users with Location-Based Call Restriction service assigned. Consequently, this feature, when enabled, performs roaming status checking for all users regardless of whether Location-Based Call Restriction service is assigned.

If a match is found in the Home Network table or Roaming table, a user is considered to be in an authorized network and the correct roaming status is set. When a user is unauthorized (roaming in a network with no roaming agreement and consequently not found in the Home Network or Roaming tables), terminating calls to the user are marked as Temporary Unavailable and can be redirected to voice mail or a forwarding number by corresponding services.

Note that the behavior for originating calls, (made in an unauthorized network), have not changed, that is, these calls are still blocked. When a user is unauthorized, no Office Zone status checking is done. When a user is authorized, Office Zone checking is continued. Office Zone status checking is still coupled with the Location-Based Call Restriction service assignment as previously implemented in Cisco BroadWorks.

Open Client Server/ Interface Enhancements

The Open Client Interface (OCI) is enhanced to support the following:

• Media File Upload – third-party applications can support the uploading of media files to the system. The features that allow the use of a custom sound file are: Auto Attendant, Call Center, Intercept Group, Intercept User, Music On Hold, Voice Messaging, and User’s Personalized Name

• Message Waiting Indicator – MWI information can be sent over the OCI. Thus, third-party clients can indicate whether message(s) are waiting on Cisco BroadWorks or third-party voice messaging system

• Call Details – redirection number, country code, name, and reason are added to the callUpdate message

The Open Client Server and interface have been enhanced as follows:

• Subscriber Location – OCS queries the Network Server location register to support multiple Application Servers simultaneously

• SOAP Interface – OCS supports a HTTP/SOAP interface

• Additional Information – OCI enhanced with additional information for third-party clients, including users’ mobile number and department

Configuration and Provisioning: Enhances the current Call Center password rules to:

• Store a history of the ten most recently used passwords

• Validate the selected new password against the password history

The system administrator can configure the option and the depth of the password history at the following levels:

• System

• Enterprise

• Service provider

• Group

This is configured along with all other password rule options.

Profiles provide a means to automatically tune the server configuration according to predetermined rules. Prior to this feature, it was not always clear to the operator the steps that were necessary to select a profile and when the changes became effective. Some profile tuning changes also modified configuration settings that were not exposed to the operator. Because of the black box behavior of the profile tuning, it was confusing and difficult to use correctly.

This feature enhances the profile tuning command line interface to better present information to the operator.

Configuration and Provisioning: This activity removes the deprecated Release 13.0 Open Client Interface (OCI) commands in Release 16.0.

The Cisco BroadWorks Application Server supports the deprecated OCI commands in the current release and the previous two releases of (N-2 support policy). With the Release Complete milestone of Release 16.0, the deprecated Release 13.0 OCI commands are no longer supported in 16.0 and forward. As such, the commands are being removed.

This feature enhances the time schedule and holiday schedule capabilities on Cisco BroadWorks by adding recurrence patterns, such as the fifteenth of every month, or every two weeks, or every first Monday of September. This enhancement allows daily, weekly, monthly, and yearly recurrences.

A new schedule is introduced and the existing holiday and time schedules are modified to use the new schedule. The new schedule provides the flexibility to configure recurrence patterns based on the day of the month, the day of the week, the day of the week in the month, or the month.

The new schedule is based on events. Events are equivalent to a holiday in the existing holiday schedule and a time interval (time range) in the existing time schedule. Events support daily, weekly, monthly, and yearly recurrences.

This feature provides provisioning administrators with the ability to search for service provider, enterprise, and group devices using the web portal and Open Client Interface-Provisioning (OCI-P) commands. Note that the provisioning administrator does not have access to system-level devices.

It also provides the system, provisioning, service provider, and group administrators with the ability to perform a search on endpoints.

The following enhancements have been made:

• Voice Portal Passcode Rules – allow service providers to configure rules to harden the passcode selected by users and administrators (for example, trivial patterns, repeated passcodes, and so on)

• Login Password Wizard – forces users to change their password upon initial login; also forces users to change expired passwords

This feature allows a service instance to be excluded from group and enterprise directory listings or from being reachable through Auto Attendant extension or name dialing. The following service instances have been enhanced to allow Privacy service to be assigned:

• Auto Attendant

• BroadWorks Anywhere

• Call Center

• Conference Bridges

• Hunt Groups

• Instant Group Call

• Meet-Me Conferencing

• Route Points

There are three privacy attributes available for service instances: Directory Privacy, Auto Attendant Extension Dialing, and Auto Attendant Name Dialing.

• If the Directory Privacy attribute is set to “Active”, the service instance’s name and information are filtered out of the group and enterprise directory displays on the web pages. A setting of “Inactive” includes the service instance in directory displays. Directory Privacy also prevents the subscriber from being included in custom contact directories.

• If the Auto Attendant Extension Dialing Privacy is set to “Active”, this service instance is not reachable via the Auto Attendant’s extension dialing. A setting of “Inactive” makes the service instance reachable.

If the Auto Attendant Name Dialing Privacy is set to “Active”, this service instance is not reachable via the Auto Attendant’s name dialing. A setting of “Inactive” makes the service instance reachable.

This feature includes:

• Support for multiple E.164 number registrations according to RFC 6140 (Generate Implicit Numbers [GIN] registration).

• Configuration option to allow Privacy:none from a trusted device to override a user’s Calling Line ID (CLID) Blocking service in stand-alone mode. (This functionality was previously available only in IMS mode.)

Operations, Administration, Maintenance: Allows for mapping called NPA-NXXs to a special identifier known as a Destination Trunk Group (DTG) for selected call types.

The DTG is passed to other network elements so they can use it to route calls without having to perform translations themselves, which greatly simplifies network provisioning.

Session Initiation Protocol (SIP) is also enhanced to support this functionality.

System: Many Cisco BroadWorks customers are using feature access codes (FACs) that are different from the default codes provided by Cisco BroadWorks on the system. This causes them to have to reset the default codes each time a new service provider or enterprise is created. For those customers who are required to create a number of enterprises, this becomes an operational burden.

This feature creates configurable default FAC codes at the system level. These codes are used as the defaults when a service provider or enterprise is created. Prior to this feature, the default FAC codes were hard-coded, and as a result, they were not configurable.

The feature also creates a configurable default Speed Dial 100 prefix at the system level, which is used as a default for authorization of Speed Dial 100 service to groups.

Cisco BroadWorks allows users to configure their Redirection services with phone numbers that can be disallowed by the user’s Calling Plan.

In such cases, when a call triggers the Redirection service, the call is blocked and provided with a treatment. Since there is no mechanism to notify the user of these calls being blocked, it may take a while before users realize the problem and fix it. This activity enhances the Cisco BroadWorks configuration framework to perform the validation of destination digits against the user’s calling plan immediately upon configuration.

The following OAM enhancements have been made to the Web Conferencing service:

• Conference Management – additional call control capabilities for bridge administrators and participants

• Accounting – incorporation of conferencing-specific information in the call detail records

• Administration – bridge administrators “own” the conferences they create and only view and modify their own conferences. Administrators can designate another bridge administrator as a delegate to view and modify their individual conferences

Block Service Unauthorization for Active Virtual Subscriber Feature Description

This feature introduces a new flag to control the unauthorization/unassigning of services having user-created virtual subscriber instances, thus protecting the customer from losing the virtual subscriber configurations.

This feature adds OCI-P requests to manage the Network Translation Indexes.

This feature facilitates the provisioning of enterprises by making it possible to keep all groups of an enterprise on the same hosting network element (NE) node by default.

This feature enhances the user’s and group’s ability to add, maintain, and associate announcements used by services in Cisco BroadWorks. Currently, these files are maintained individually meaning that if the same announcement file is to be used in multiple services, it must be uploaded multiple times. This feature provides the following key enhancements to make these announcements easier to manage:

• A common repository for user or group announcements may be viewed and maintained.

• The ability to share a single announcement in multiple services.

• The ability to modify an announcement with another file when being used by services (this is key for services like Call Center where a single announcement could be used numerous times).

• The ability to keep an announcement on the system without it being used by a service.

• The ability to record from the voice portal to create an announcement that can be used by any service.

In preparation for Control Hub using Calling Provisioning API (CPAPI) to add customers (enterprises) and locations (groups), consolidated Add commands are being created, which allow a customer or location to be closer to “up and running” using fewer Open Client Interface-Provisioning (OCI-P) commands or REST API calls. Additionally, the Common Identity organizational external ID is added to the enterprise for use in referencing customers by their external ID instead of using the customer ID in Cisco BroadWorks. An external ID is also added for groups; however, it does not tie back to anything in Common Identity.

This feature adds the capability to store the external ID of a service provider/enterprise on the Network Server.

The system provides a number of Find-me/Follow-me services that include phone numbers that are not managed on the system. The phone number is required to be unique between all the BroadWorks Anywhere phone numbers in the system. Otherwise, an error message is given. However, there is no method to identity the usage of BroadWorks Anywhere phone numbers in the system. In other cases, carriers are just trying to identify how a certain number is being activated, and again, there is no easy way to query the system.

This feature provides the ability to query a number and provide the result if the BroadWorks Anywhere service is configured with the number.

For BroadWorks Mobility, this feature provides the search capability for mobile subscriber directory numbers at the system level.

Prior to this feature, services such as the Outgoing Calling Plan,

Pre-alerting Announcement, Communication Barring User-Control

(CB-UC), Charge Number, and Calling Line ID Delivery Blocking were available to regular subscribers and certain types of virtual subscribers mentioned above. This feature makes these services available to other types of virtual subscribers.

The Element Management System (EMS) is an optional server that provides a single point of entry into the system for the system provider’s OAM systems. The EMS provides visibility to all Cisco BroadWorks servers for provisioning, network management, and maintenance. The following functionality is provided:

• Auto discovery

• Administrator and password management

• Web cut-through to network elements

• Performance management reporting

• Alarm consolidation and reporting

• Command line interface (CLI) cut-through to network elements

The EMS is enhanced to support alarms auto-clearing/correlation, which reduces the manual intervention required for an administrator to clear alarms. This enhancement also improves the meaning of alarm flow received from the Cisco BroadWorks servers.

The various tools and utilities available from the EMS have also been aligned with the tools and utilities of the other Cisco BroadWorks servers.

The EMS has been enhanced as follows:

• Centralized Software Management – images centralized on EMS; auto download to servers; remote server upgrade; and status reporting

• Centralized Management of Administrator Accounts – allows operator to manage the following from the EMS: “bwadmin” account password, administrator password, and SNMP access control lists

• Open Client Server (OCS) Support – OCS functionality ported to the EMS

This feature introduces a Cisco BroadWorks application named Network Monitoring. This application aims at providing the Fault (F), Accounting/Administration (A) and Performance (P) functional areas commonly called FCAPS.

The Network Monitoring application provides the following functionality:

• Integration of Network Function Manager applications with OpenNMS

• Synchronization of the node inventory and the list of users between Network Function Manager and OpenNMS

• Mapping of Cisco BroadWorks traps to OpenNMS events and alarms

• Cisco BroadWorks data collection, graphs, and maps

• Cisco BroadWorks reports (Jasper-based)

• Single Sign-On

• Secure Sockets Layer (SSL) support

• Network monitoring proxy

• Customization and rebranding of OpenNMS for Cisco BroadWorks

• Integration of OpenNMS northbound interface

• High availability

This feature enhances the Network Monitoring application to provide more flexibility in customizing data collection, graphs, and reports. It allows administrators to refine the application per their specific requirements in the following ways:

• Setting the performance measurements (PMs) to be automatically collected.

• Adapting the visual presentation associated with data collected from any PMs.

• Generating reports using data collected from any PMs.

Enables system administrators to diagnose system and network problems, using the following troubleshooting tools:

• Protocol monitor tool

• Query user tool

• Accounting record viewing tool

• CallP diagnostics

• Connectivity test for access and network devices

The feature adds new tools and diagnostics to the Cisco BroadWorks Application Server to help support staff when they investigate DNS-related problems as follows:

• SNMP Counters for DNS Timeouts from Call Processing Thread

• Log Messages in XSOutput

• SNMP Notification for DNS Time-Out from Call Processing Thread

• Option to Reset DNS Query Time Statistics

Element Management: Enhances the existing Element Management System (EMS) functionality in the performance management area, refining the following items:

• Eases maintenance of platform-dependent thresholds.

• Allows better encapsulation of health status monitoring from threshold data definitions.

• Allows the delegating of the evolution of threshold data definitions (including platform-dependent conditions) to the BroadSoft system engineering group.

• Provides EMS administrators with better control for managing health status changes and threshold definitions.

• Supports group health status definitions for clusters of more than two Network Servers.

It is important to note that this feature applies to all Cisco BroadWorks server types managed as network elements by the Element Management System (EMS). It does not apply to the Conferencing Server.

The Enhanced Call Logs (ECL) service provides call logs for carriers. This feature provides the following call log enhancements to carriers:

• A redundant data store for call logs

• Ability to support Enhanced Call Logs with additional data such as transfer information

• Ability to support searching and filtering to provide the carrier with the ability to create reports

This feature introduces the following call log enhancements to carriers:

• A redundant data store for call logs

• Supports enhanced call logs with additional data, such as, transfer information

• Supports searching and filtering to provide the carrier with the ability to create reports

• Supports the enhanced call logs functionality for the Execution Server (XS) mode architecture

The following terminology is used to describe the new solution:

• Enhanced Call Logs – The service/functionality provided

• Enhanced Call Logs repository – The data store for enhanced call logs in the Cisco BroadWorks Database Server (DBS)

System Management (FCAPS): This feature implements a new trap that triggers whenever a user or administrator reaches the maximum number of failed login attempts and the account is locked out. The notification identifying the user or administrator is sent to the SNMP server so any alarm subscribers are notified about the locked account.

The system triggers a Simple Network Management Protocol (SNMP) notification whenever there is a failed Open Client Interface-Provisioning (OCI-P) login attempt and the number of failed login attempts has reached the maximum allowed number of failed login attempts.

OCI-P commands that can generate this SNMP notification are the following:

• SessionStartRequest (Internal to Cisco BroadWorks)

• AuthenticationVerifyRequest

• AuthenticationVerifyRequest14sp8

• LoginRequest14sp4

• LoginRequest13mp10

Note that there is already a system trap bwMaximumFailedLoginAttempts sent when the total number of login failures for all users in the system exceeds a configurable threshold. This feature adds a different trap to report login failures on a per-user basis and does not remove or replace the bwMaximumFailedLoginAttempts trap.

This new notification is not sent if the password/passcode rules are configured to never disable the user login.

The userPhoneErrorCorrection system parameter allows the administrator to configure the type of user=phone error correction that is performed for originations in IMS mode. Prior to this feature, three different values were defined for this system parameter: “full”, “identityDomain”, and “none”.

This feature introduces a new value to the userPhoneErrorCorrection system parameter. When the parameter is set to this new value, the full error correction is performed just as it was when the parameter was set to “full”, with the following enhancement.

For a user origination to a SIP URI without user=phone present, user=phone is added prior to translations if the user portion of the URI is all digits. The host portion of the URI may or may not match the originating SIP URI Public User Identity’s (PUI’s) domain.

This feature introduces a solution to proactively monitor the Java heap to avoid server failure.

The general goal of this activity is to improve the manageability of all servers that use applications involving a JVM process. To monitor the Java heap, the JVM statistics collector is implemented for heap, non-heap, and garbage collection resources. Alarms have been implemented to warn administrators if an out-of-memory error or other uncaught exception error occurs. This way, customers are alerted when the heap is approaching the maximum threshold.

This feature introduces counters and gauges on all Cisco BroadWorks servers. It provides a uniform solution to set alarm thresholds on them for all server types.

This feature allows all servers to monitor threshold alarms the same way. Prior to this, only the Application Server (AS), Network Server (NS), and Media Server (MS) were able to do it. The Application Server and Network Server used their database to stock the thresholds and the Media Server used a threshold configuration file. With this feature, every server uses the configuration to get and set its alarm thresholds.

System Management (FCAPS): This feature offers additional tools to debug overload and other performance-type issues. It is often necessary to characterize incoming and outgoing traffic patterns, so a script is provided to parse the debug log files for the following metrics:

• Number of incoming and outgoing messages broken down by SIP method

• IP address and port

• User directory number (DN)

• Session identification number

High runner items are listed when the script is executed.

The following performance measurements have been added to help diagnose system performance:

• Average and maximum call setup delay

• Average and maximum internal cross-office delay

• Report system configuration (CPU, memory, swap space, drives)

• Memory usage

This feature standardizes and improves the user interface in terms of its relation to schedules. There are currently three BroadWorks features/services that require the user to provision schedules: Schedule Profile, Meet-Me Conferencing, and Call Center Reporting.

In addition, this activity adjusts the start and end date to the first occurrence of the recurrent schedule.

The following enhancements have been made to Cisco BroadWorks:

• Faults Source Address Enhancements – allows traps and faults to be sent out of the Cisco BroadWorks administrative interface, instead of the signaling interface, to better interwork with external network management systems

• Enhanced Alarm Typing – introduces a new type of field in the Cisco BroadWorks faults and alarms to facilitate screening and filtering by an external network management system

System performance can be managed and monitored via SNMP MIBs. All system components within the Cisco BroadWorks system can be monitored and managed using get commands. Thresholds on external systems can be set so that the system is polled and alarms are generated based on targeted operational devices and variables for capacity status and other critical performance measurements.

Service providers are also able to use the CLI to query and display reports on performance measurements. Both real time and historical (for example, last day, month, and year) reporting is available, and information can be viewed from the screen or a file. Data polling and archiving intervals can also be configured via the CLI.

This activity introduces a stronger implementation of stateful alarms, in which a notification can first be sent to arm an alarm, and the same notification can be sent to disarm that same alarm. The overall solution is characterized by:

• Stateful notification with correlation ID

• Parameterization of the notification variable attributes

• Ongoing support of legacy notification’s model for existing notifications

• Support of a mode in which applicable existing notifications are transformed into stateful alarms

• Alarm activity table visible both locally on a server and externally though Simple Network Management Protocol (SNMP)

This feature provides metrics on performance and use through in all Xtended Services Interface (Xsi) web applications using SNMP. In addition, a new MIB provides monitoring and debugging information on the Xtended Services Platform web container.

At a high level, the BwCommunicationUtility library is enhanced to expose an interface to register performance metrics. The Management Information Base (MIB) files and the MIB map files are packaged with the Web ARchive (WAR).

This feature affects the servers running web containers through the Apache configuration.

Emergency Callback Numbers at Group and User Level Feature Description

Prior to this feature, a common configurable CLID exist for both external and emergency calls. However, the configurable CLID may not be an ideal emergency callback number for emergency responders. Therefore, in this feature, AS is modified to allow configurable emergency callback numbers (ECBN) at the user and group levels. This allows users to have separate CLID for emergency and external calls.

Enhanced Handling of SIP Headers for Emergency Services on a Trunk Group

This feature enhances the Application Server (AS) to propagate the emergency call header values within the SIP dialog for the inbound calls terminating to the trunk groups.

Regulatory/Lawful Intercept – CALEA: Currently Lawful Intercept using the T1.678 Call Data Channel (CDC) sends the calling party name to the law enforcement agency (LEA) in the TerminationAttempt message on terminating calls when a user is configured as the intercept subject.

The Lawful Intercept (LI) specifications provide guidance indicating that this information should be provided in the NetworkSignal message within the TerminalDisplayInfo parameter. The same applies to intercept subjects originating calls when the called party name is provided.

This feature provides the capability to provide the calling party name or the called party name of intercept subjects in the NetworkSignal message within the TerminalDisplayInfo parameter.

Regulatory – CALEA: Enhances Calling Line Identity (CLID) and Connected Line Identity Presentation (COLP) capabilities by adding further proprietary information in the SIP messages sent on the SIP network interface.

CLID Enhancements – This feature enhances this functionality so that identity information from the redirect destination is passed back to the remote party even when the Connected Line Identification Privacy on Redirected Calls policy is in effect. This allows the redirect destination’s identity information to be available for Call Processing services in both internal (including Distributed Group Calls) and DNC scenarios when the Connected Line Identification Privacy on Redirected Calls policy is in use.

COLP Enhancements – This feature enhances this functionality so that COLP/Connected Line Identification Restriction (COLR) information is now sent to and received from the Network in SIP Re-INVITE/UPDATE requests and their 200 OK responses for both DGC and DNC connections. With this enhancement, the Cisco BroadWorks Application Server can now report and process remote party changes for any DGC or DNC connection.

Regulatory/Lawful Intercept – CALEA: Currently, for users who have configurable CLID and calling line ID policy set to “use Configurable CLID”, network calls made by the users do not have the user’s phone number in the INVITE message. Rather, the INVITE message has the configurable CLID in the FROM and P-ASSERTED-IDENTITY. Also, Cisco BroadWorks Application Server currently generates CDR records with the user’s phone number only and no configurable CLID.

This creates an issue where the CDR generated in the Cisco BroadWorks Application Server uses the user’s phone number as the originator ID and the public switched telephone network (PSTN) has to use the configurable CLID as the originator ID. As such, a correlation cannot be made using an originating calling number between the two CDR records.

This enhancement takes two approaches to solve this issue:

• Introduction of the P-CHARGE-INFO header in the SIP INVITE message to deliver a charge number. Currently the only option is to use the BroadSoft proprietary CHARGE header, which is not understood by all SIP devices. The charge number can be configured to be the user’s phone number. As such, Cisco BroadWorks delivers the originating phone number to the PSTN side.

• The CDR is updated to have the configurable CLID when one is configured.

The introduction of these two approaches enables the service provider to match CDR records based on the user’s phone number and/or the configurable CLID.

For regulatory reasons in Italy, the carrier selection code sent to the Network Server for calls categorized as local must be returned to the Application Server for use in routing the call to the selected carrier.

This feature affects three policies on the Network Server: Equal Access, Service Center Routing, and Rate Center Based Routing. These policies can change the way local calls are treated with regard to the carrier identification code (CIC) selection.

Government Emergency Telecommunications Service (GETS) is a set of requirements aimed at significantly increasing the likelihood of successful voice communication completion in times of crisis (natural or man-made disasters), when communication networks are expected to be overloaded.

This is achieved by identifying GETS calls early in their processing, reserving resources when necessary (or possible), bypassing congestion controls, and generally giving them higher priority, both for their signaling and media components.

The system implements the Telephony Application Server (TAS) functional element (FE) (with the Execution Server and Network Server) covered by this feature and the Media Resource Function Controller (MRFC)/Multimedia Resource Function Processor (MRFP) FE (with the Media Server) covered in another feature.

An important distinction to be made is that the Cisco BroadWorks Telephony Application Server does not implement the GETS-FC AS, GETS-NT AS, or GETS-AN AS FE behavior. As such, it does not communicate with the GETS PIN or translation databases; however, it executes originating, mid-call, and terminating services while honoring the GETS priority. The third-party GETS-AS may use the BroadSoft Media Server for its Interactive Voice Response (IVR) interactions.

In general, this activity also implements the 3rd Generation Partnership Project (3GPP) Multimedia Priority Service, as defined in 3GPP TS 22.153 v11.1.0 and 3GPP TS 23.854 v11.0.0.

This feature adds the following enhancements to the existing Cisco BroadWorks AS third-party emergency logic:

• Support for the secret key configuration option at SP/enterprise levels.

• Support for customer ID and secret key configuration options at group levels.

Voice phishing is a major problem in South Korea. Calls originating from an international softswitch with an invalid calling line ID (CLID) can be used for fraudulent purposes when terminating to a Korean subscriber. To protect the subscriber from voice phishing, the Korean government has issued a new regulation for calling line identification delivery.

When the domestic softswitch receives a call from an international softswitch, it must insert a prefix of “00X”, where X = 1 through 9, to the calling number. When the system receives a termination request with a CLID that contains the provisioned prefix, it must deliver the prefixed CLID to the subscriber whether or not any CLID number presentation service is enabled.

This feature fulfills this requirement and it applies to the Public Switched Telephone Network (PSTN) calls only.

Enables the following necessary functions for lawful intercept (for example, CALEA event monitoring):

• Administration – enables a system provider or law agency to assign and configure surveillances against particular users. Up to five surveillances can be assigned to one user

• Event Monitoring – generates call events for users under surveillance and delivers to the law agencies requesting the surveillance

• Media Monitoring – mixes the media of all parties of a call under surveillance and delivers to the corresponding law agencies based on the delivery IP address

The system can be customized to provide a compliant solution in countries that adhere to the European Telecommunications Standards Institute (ETSI) standard. Although the system itself is not Lawful Intercept ETSI-compliant, it can be deployed in conjunction with a mediation platform to provide an ETSI-compliant solution.

The following capabilities have been added to the Lawful Intercept interface:

• Subject-Initiated Dialing and Signaling – enhances service to report signals initiated by the user. For example, a message is sent to the law enforcement agency when a user flashes to toggle between two calls

• Dialed Digit Extraction – enhances service to report digits dialed by user after call is connected

Lawful Intercept interface has been enhanced with the following:

• Party Hold/Drop/Join – support of party hold/join/drop punch-list item enhanced to notify the law enforcement agency (LEA) of the parties involved in a subject-initiated conference call

• In-Band and Out-of-Band Signaling – support of in-band and out-of-band signaling punch-list item; informs LEA when a network message with call-identifying information (for example, busy, reorder, ringing, alerting, call waiting) is sent to a subject using the facilities under surveillance

• Address Registration/Deregistration Events – Serving System message introduced to report changes or attempted changes in the intercept subject’s addressing information for personal mobility (for example, registration or deregistration)

• T1.678 Standard Compliance – documented compliance with the T1.678 lawful intercept standard

Phase one of Russian Lawful Interception, delivered in Release 14.sp5 added additional fields in the call data channel (CDC) making Lawful Intercept (LI) compatible with Russian Lawful Intercept, also known as SORM.

Lawful Interception for Network Numbers augments the existing feature by adding the ability to monitor calls to and from public switched telephone network (PSTN) numbers (that is, external users), monitor calls to and from a range of PSTN numbers, and monitor calls to and from network gateway addresses.

This activity adds the following enhancements to the Lawful Intercept service:

• A method to pass correlation information using the Access Transport Parameter (ATP) of a Generic Transparency Descriptor (GTD) for the Callout - European Telecommunications Standards Institute-Contents of Communication (ETSI-CC) link type.

• An alternate method for generating the Communication-Identity-Number (CIN) that complies with the ETSI standard.

• Configuration of the system ID used for Lawful Intercept (LI) in LINUX installs.

Mixed Media for CALEA

Phase One – J-STD-0125A

(using VXML)

North American Lawful Interface specifications define two options for call content (audio) delivery. One option is to provide separate transmit and receive call content channels (CCC) when delivering intercepted content to a law enforcement agency. It is this option that is currently supported by the system. This works for law enforcement agencies that support dual CCCs; however, some law enforcement agencies only support the combined method of delivery.

This feature enhances Communication Assistance for the Law Enforcement Act (CALEA) feature to support the second defined option of delivery. It combines the transmit and receive content (audio) on a single CCC.

This feature is implemented in two phases:

• Phase one, to be delivered as part of Release 14.sp7, uses voice eXtensible markup language (VMXL)-based technology to combine the transmit and receive audio streams into a single CCC.

• Phase two is scheduled to be delivered in Release 14.sp9, which is targeted to be available in early January 2009. The Release 14.sp9 implementation will update the core CALEA function, taking the place of the VXML solution delivered as part of Release 14.sp7.

The system will continue to support the delivery of transmit and receive audio on separate CCCs.

Lawful Intercept interface specifications in North America define two options for call content (audio) delivery:

• The first option provides separate transmit and receive call content channels (CCC) when delivering intercepted audio content to the appointed law enforcement agency.

• The second option combines the transmitted and received audio content on a single CCC.

While the system currently provides the first option, delivering audio content on separate CCCs is problematic for law enforcement agencies that only support combined CCC delivery.

This feature augments Lawful Intercept capability allowing the delivery of audio content on a single CCC.

It is important to note that the system still supports content delivery on separate transmit and receive CCCs.

This feature provides support for the emulation of the following circuit-switched emergency calling services:

• Network or Bureau Hold – Enables the operator to maintain control of the call, and notifies the operator upon calling party disconnect.

• Operator Ringback – Allows the operator to re-establish communication with the calling party for cases when the calling party has gone on-hook, or remains off-hook, but has become unresponsive.

• Forced Disconnect – Allows the operator to disconnect the call.

This feature enhances the following policies on the Cisco BroadWorks Network Server (NS):

• Equal Access

• Service Center Routing

• Rate Center Routing

The enhancements permit a Carrier Identification Code (CIC), provided by the Cisco BroadWorks Application Server (AS) to be used as a Carrier Access Code (CAC) as if it had been dialed by the originating party.

Regulatory/Lawful Intercept – CALEA: LI events and messages appear on the Execution Server, Media Server, and Network Server logs, which are used for internal purposes. This exposes the number of the intercepted person.

This feature removes the events and messages for LI occurrences only.

Russian Lawful Intercept (LI) enhancements include the following:

• Call Hold Detection – Prior to this enhancement Call Hold reporting is handled through a pair of CCChange messages by examining the SDP for the start and end of the hold. When the Music-On-Hold (MOH) service is enabled the Lawful Intercept mediation device is unable to detect the hold state.

• This feature uses the ConnectionBreak and Connection messages for Call Hold detection in addition to the CCChange messages.

• Call Hold in Three-Way or N-Way Network Conference – Before this feature, when an intercepted user starts a three-way or N-way conference and the conference is provided by the Conference service, only one of the calls established by the conference controller is selected to report CDC messages to the Legal Enforcement Agency (LEA).

• This feature uses the SendHoldConnectionFor BroadWorksCDC lawful intercept system parameter to enhance the Connection or ConnectionBreak message reporting when the conference controller is under surveillance.

• Network Number Enhancement – Prior to this feature, a network surveillance call received by the system generated a termination message to the mediation server. A call to a network surveillance number generates an origination message. Additionally network surveillance calls subjected to call forwarding and call pickup generate multiple mediation server events.

• This feature aligns the CDC message with the direction of network surveillance.

Regulatory/Lawful Intercept – CALEA: This enhancement to the current implementation of Russian Lawful Intercept provides additional information to the LEA for distributed multi-party calls invoking certain supplementary services. The additional information includes:

• Identity enhancements

• Redirection enhancements

• Conference enhancements

• These identity enhancements apply to all LI interfaces (Cisco BroadWorks, J-STD-025-A, and T1.678).

• The supplementary services affected by this enhancement include:

• Call Forwarding

• Chain Call Forwarding (multiple forward actions)

• Call Waiting

• Three-party Conference

• Call Transfer with Consultation

• Call Hold (including Call Switching using the *22 FAC)

• Call Transfer

• Call Pickup

Regulatory/Lawful Intercept – CALEA: This feature adds the ability to configure caller information that can be passed to outside networks. The system currently supports the Calling Party Category service; however, the category values are predefined and cannot be edited by the system administrator. This feature allows the system administrator:

• To configure the calling party category values relevant to the networks to which they are connecting.

• To meet regulatory requirements for passing this information to outside networks.

In some countries this is a regulatory requirement used to identify the carrier of choice for the end user (similar to equal access in the United States). The category assigned to the user maps to an inter-city or international carrier that is then selected for routing outside the system.

Regulatory/Lawful Intercept – CALEA: Lawful intercept (LI) interface specifications define two options for providing media streams toward the Law Enforcement Agency (LEA):

• The first option provides separate transmit and receive call content channels (CCC) when delivering intercepted audio content to the appointed law enforcement agency. However, some LEA equipment does not support separate CCCs.

• The second option combines the transmitted and received media content on a single CCC from all participants. This approach is known as the “Combined CCC”.

This feature augments Lawful Intercept capability to support Combined CCC for the CalloutETSI function.

It is important to note that the system still supports content delivery on separate transmit and receive CCCs.

This feature provides enhancements to the Session Initiation Protocol (SIP) and Media Gateway Control Protocol (MGCP) interfaces to support the delivery of network cause or restriction information received from a trusted device on the boundary of the SIP network.

The enhancement addresses requirements for the Japanese market, which requires the delivery of the network asserted identity according to TTC-Standard JJ-90.22.