Cisco BroadWorks XSI Event Package for Personal Assistant Status Synchronization Feature Description

This feature introduces a new PersonalAssistantSync event package to allow XSI clients to synchronize with Cisco BroadWorks Personal Assistant schedule based presence.

Cisco BroadWorks CORS Support on ADP Feature Description

This feature adds the support of Cross-Origin Resource Sharing (CORS) on the Xsi-Actions application on the ADP.

Logging Profile for Troubleshooting Feature Description

This feature enhances the existing log profile capabilities within the Cisco BroadWorks configuration, aiming to assist customers in efficiently diagnosing and resolving issues.

STIR-SHAKEN Signing And Verification Of Diverted Calls Feature Description

This feature enhances the signing and verification functions of the existing STIR-SHAKEN framework to support calls redirected by Cisco BroadWorks users.

STIR-SHAKEN Proxy Access Side Identity and Tagged Headers

This feature enhances the existing STIR-SHAKEN framework to support proxying of access side identity and tagged headers. In addition, it adds configuration to control whether verstat is send to network side calls.

STIR-SHAKEN From/P-Asserted-Identity Precedence and History-Info/Diversion Support of Verstat Feature Description

This feature enhances the existing STIR-SHAKEN framework to support differences in European standards.

This feature replaces the AdventNet library by the Net-SNMP Agent and the SNMP 4J library in the BroadWorks SNMP Agent to provide increased security.

The capabilities offered by the BroadWorks SNMP Agent do not change and the transition between the two architectures is transparent to the customer.

This feature aims at separating the services offered by the BroadWorks Platform from the applications using them. This is done through the evolution of the Xtended Services Platform (Xsp) Server into a platform on which applications are deployed.

The BroadWorks Container is a new feature offered by the BroadWorks Platform to initialize, launch, and manage applications. Applications running inside the BroadWorks Container can have their own threading model, garbage collection algorithm, and memory configuration. It provides flexibility for the applications, scalability for the servers, and ease to manage the development and deployment of current and future applications.

The Element Management System (EMS) Lightweight Directory Access Protocol (LDAP) server is used to centrally manage the UNIX accounts that allow users to log in to multiple computers using a single password. Currently, the EMS LDAP server has two modes of operation:

• EMS primary mode: The EMS LDAP server is used for user management and authentication.

• EMS proxy mode: The EMS proxies LDAP user management and authentication requests to an external LDAP server.

This feature enhances the EMS LDAP server to support EMS Pass-Through Authentication mode. In this mode, the EMS LDAP server is used for user management; however, authentication is performed by an external LDAP server. The EMS does not write and is not required to write Cisco BroadWorks data to the external LDAP server.

The security aspect of LDAP also requires enhancements related to the Password policy rules. This feature enhances the EMS LDAP server to support configurable Password policy rules for a better management of LDAP user passwords.

The Cisco BroadWorks Execution Server is enhanced to enable the use of some service elements from the MMTEL-Services document stored in the Home Subscriber Server (HSS). This information is used to configure the following Cisco BroadWorks user services.

• External Calling Line ID Delivery

• Calling Line ID Delivery Blocking

• Connected Line Identification Presentation

• Connected Line Identification Restriction

• Call Waiting

• Automatic Callback

• Call Forwarding Always

• Call Forwarding Busy

• Call Forwarding Not Reachable

• Call Forwarding No Answer

This feature changes the behavior so that Cisco BroadWorks relies on the HSS to have the service configuration for these services and it does not write or update that data. When this service data storage model is in use, the associated Cisco BroadWorks services are not assigned to the provisioned user in Cisco BroadWorks.

This feature enhances Cisco BroadWorks’ integration with External Authentication platforms by adding external authentication capacity when logging into the CLI and CommPilot portal. This allows customers to unify their credentials management across multiple systems.

The External Authentication configuration is available when logged in as an administrator, which removes any unwanted configuration changes by an unauthorized user. When the External Authentication is configured and enabled, and login is attempted in the AS, PS, and NS CLI and the CommPilot portal, an external authentication connection is performed.

This feature adds Lightweight Directory Access Protocol (LDAP) for centrally managing the UNIX accounts. This allows users to log in on multiple computers using a single password. This implementation includes LDAP server data backup and restore, server replication, security, and user management. This implementation of LDAP integrates Cisco BroadWorks user authentication and authorization against an external single sign-on system via LDAP. In this implementation, the Element Management System can:

• Configure an interface to an external LDAP authentication database.

• Be configured as the central authentication database for all Cisco BroadWorks users.

• Authenticate administrators via an external LDAP database.

This activity introduces built-in support for a distinct database log file disk. It also introduces the following TimesTen optimizations:

• Reduce the checkpointing default log file size trigger from 64 MB to 16 MB

• Control the TimesTen replication logging disk usage

For each hosting network element (NE), a failover data center can be configured so that route advancing is limited to Execution Servers from the local data center (from the Network Server point of view) and the failover data center. It is possible to not configure such a failover data center (value “Local”) or keep the previous behavior by configuring value “All”, in which case no data center restrictions are enforced.

The number of Execution Servers attempted from a given data center is limited to a configurable maximum.

Prior to this feature, the deployment model had the Authentication Service web application instances using specific Cisco CI clusters through a single configured URL. As a result, the same cluster was used to generate and validate CI access tokens.

The federated deployment model relies on the multiple independent CI clusters for authentication. Hence, the main objective of this activity is to allow interactions between the Authentication Service web application and all clusters within the CI Federation.

This feature upgrades major third-party software components in Cisco BroadWorks Release 15.0. The following components are upgraded: Apache, Tomcat , TimesTen, Java, FreeRADIUS, Linux 5.1.

For Linux 5.1, it is not a third-party upgrade but an operating system (OS) upgrade. The eXtensible Markup Language (XML) bean library (jar) is also upgraded as part of this activity. The Client Management Profile Server (CMPS) and Client Management Access Server (CMAS) are not supported by this feature.

This feature adds support for 3GPP2 Voice Call Continuity (VCC) Application Server (AS). Most of the functionality required to support 3GPP2 is already provided by Cisco BroadWorks; however, the following enhancements are required:

• Support of IP Multimedia Routing Number (IMRN) termination

• Support of domain availability notifications that indicate that the user equipment (UE) is moving to a circuit-switched (network)-only area, and use of these notifications to select the terminating access network domain (T-ADS)

• Support of a slightly different call flow for continuity, where the Session Transfer Number for Single Radio (STN-SR) is fetched via the Service Control Function Server

This enhancement to the Cisco BroadWorks Application Server provides a translation, routing, and service usage analysis tool that can be used without having to use a device to originate or to terminate a test call on behalf of or to a user. The Cisco BroadWorks Application Server is enhanced to provide the ability to trigger test calls using command line interface (CLI) commands in a similar way to the Network Server “vtr” and “vtri” commands.

The purpose of the new CLI commands provided by the AS-VTR is to:

• Identify which specific rule allowed the detection of the originating user

• See if the translation results are for the Application Server only or whether they involve Network Server translations. This includes any kind of service triggered or network routing translations

• Identify which originating services have executed.

• Identify which terminating services have executed

• Determine why a call attempt was blocked, and then by which service or which policy

• Identify what treatment was used, if applicable

• Determine if a redirection occurred and determine the destination

It is important to note that all acceptable combinations of Cisco BroadWorks call originations and terminations, as well as public-switched telephone network (PSTN) originations and terminations are supported.

The Application Server Verify Translation and Routing (VTR) tool is intended to be used for debugging purposes in the field or in a lab; however, it can also be used by those provisioning to test configurations when new services are deployed.

The Per-user Primary Inter/IntraLATA Carriers feature allowed Preferred Inter-exchange Carriers (PICs) to be assigned to users, groups, and enterprises. When the Preferred Carrier User service is assigned to a user and the user dials the casual dial prefix and carrier code, the Application Server does not send the casual dial prefix and carrier code in the SIP INVITE request to the Network Server.

This feature implements a system-wide policy on the Application Server to remove or send the casual dial prefix and carrier code, dialed by the user, in the SIP INVITE request to the Network Server.

This feature enhances the Cisco BroadWorks Media Server to support the Session Description Protocol (SDP) Alternate Connectivity (ALTC) attribute lines for dual IP version (IPv4, IPv6) media connectivity according to the Session Description Protocol (SDP) Alternative Connectivity (ALTC) Attribute, draft-boucadair-mmusic-altc-04.txt.

The Media Server, when configured to send offer SDPs using the ALTC mechanism, provides an IPv6 address followed by an IPv4 address in the media level “a=altc” attribute lines in addition to providing the IPv4 connection addresses in the connection (“c=”) lines. Legacy IPv4 devices that do not support the SDP ALTC mechanism ignore the “a=altc” attribute lines and continue to negotiate IPv4 connection addresses using the connection lines. Devices that support the SDP ALTC mechanism are able to negotiate IPv6 connection addresses using the addresses provided in the ALTC attribute lines.

Cisco BroadWorks currently supports IPv6 for SIP, DIAMETER, and DNS interfaces in XS mode. This activity enhances the Cisco BroadWorks Execution Server (XS) and Cisco BroadWorks Network Server (NS) to support IPv6 on additional interfaces. With this enhancement, it is possible to operate the Execution Server or the Network Server without assigning public IPv4 addresses.

On the Cisco BroadWorks Execution Server, the following interfaces support IPv6: SMTP, POP3, IMAP, FTP, SMPP, SOAP, RADIUS, XS-OCI, ASR, CAP, OCI-C, and Provisioning Validation.

It is important to note, however, that the server must have an IPv4 protocol stack as the Cisco BroadWorks inter-process communication on the Execution Server and use the IPv4 loopback address 127.0.0.1.

On the Cisco BroadWorks Network Server, the following interfaces support IPv6: Synchronization API, OCI, OSS, ASR, HTTP, and CAP.

Cisco BroadWorks currently supports IPv6 for SIP, DIAMETER, and DNS interfaces in XS mode. This activity enhances the Cisco BroadWorks Execution Server (XS) and Cisco BroadWorks Network Server (NS) to support IPv6 on additional interfaces. With this enhancement, it is possible to operate the Execution Server or the Network Server without assigning public IPv4 addresses.

On the Cisco BroadWorks Execution Server, the following interfaces support IPv6: SMTP, POP3, IMAP, FTP, SMPP, SOAP, RADIUS, XS-OCI, ASR, CAP, OCI-C, and Provisioning Validation.

It is important to note, however, that the server must have an IPv4 protocol stack as the Cisco BroadWorks inter-process communication on the Execution Server and use the IPv4 loopback address 127.0.0.1.

On the Cisco BroadWorks Network Server, the following interfaces support IPv6: Synchronization API, OCI, OSS, ASR, HTTP, and CAP.

This feature gives the system administrator additional control over the announcements and locales on a per-service provider/enterprise basis.

The new controls introduced by this feature allow the system administrator to create a set of service provider-specific overrides for announcements on a per-locale basis and to specify, which supported languages are valid for a service provider. The two portions of the feature are independent. That is, a service provider can limit the supported languages without customizing any announcements and vice versa.

This feature gives the system administrator additional control over the announcements and locales on a per-service provider/enterprise basis.

The new controls introduced by this feature allow the system administrator to create a set of service provider-specific overrides for announcements on a per-locale basis and to specify, which supported languages are valid for a service provider. The two portions of the feature are independent. That is, a service provider can limit the supported languages without customizing any announcements and vice versa.

This feature enhances the Network Server so that two different carrier prefixes can be used when a carrier access code (CAC) prefix is added in the returned contacts. One is for national calls and one is for international calls. It also adds the possibility to strip the national and international prefixes from the returned contacts.

Prior to this feature, only one carrier prefix could be configured and it was used for national and international calls. In addition, the national or international prefixes were always present in the returned contacts.

In some Cisco BroadWorks deployments, it is desirable that the prefix sent along with the “request to translate” be returned as part of the contact when using the Rate Center-based Routing policy.

This feature adds additional flexibility over the current format of the contacts returned by the Rate Center-based Routing policy on the Cisco BroadWorks Network Server (NS). A new flag called keepPrefix is added to the Rate Center-based Routing policy.

• When the value of this parameter is set to “false”, the previous behavior is maintained. Any prefix, as determined when there is call typing, is removed from the contacts returned by the policy, if applicable.

• When the value is set to “true”, the policy keeps any present prefix when building the contacts, if applicable.

Platform and System Enhancements: Prior to the implementation of this feature, if the P-Access-Network-Info (PANI) header were present in an initial INVITE for a Cisco BroadWorks user origination, then the Application Server would capture the contents of the PANI in the accessNetworkInfo field of the originating call detail record (CDR). The Application Server proxies the PANI header in an initial INVITE request and an 18x/200 OK response to a trusted device.

With the addition of this feature, the Application Server captures the contents of the PANI in the accessNetworkInfo field of the terminating CDR if the PANI header is present in the 18x/200 OK response for the initial INVITE.

The 3rd Generation Partnership Project (3GPP) has specifications for IMS centralized services and service continuity. This feature implements a subset of these specifications, for scenarios where the user device is enhanced for IMS centralized services (ICS), and using the Gm reference point.

End-user devices (intelligent phones) have evolved with the ability to use SIP and can now exploit this protocol for call control, using the LTE/4G network.

A problem arises when these devices move to an area that does not yet have LTE/4G coverage and have only 2G/3G access networks

Service centralization and continuity allows devices on the IMS network to connect to the system using SIP for call control, and circuit switched (CS) access for media, when located in (or moving to) a 2G/3G-only area.

Note that centralization specifically refers to scenarios in which the call starts with the user already in a 2G/3G area, whereas continuity refers to scenarios where the UE starts in an LTE/4G area, with the call control and media both on the IP

packet-switched, (PS) network, but moves out of the LTE/4G coverage, into a 2G/3G area.

This activity adds support for several modes of deployment. The system is enhanced to support deployments where:

• An Access Transfer Control Function (ATCF) anchors the call.

• The mobile device attaches to a Mobile Switching Center (MSC) supporting ICS, without an ATCF.

• The mobile device attaches to an MSC not supporting ICS (but supporting Single Radio Voice Call Continuity [SRVCC]), without an ATCF.

This follows the recommendations from GSM Association’s (GSMA) IR.64.20 IMS Service Centralization and Continuity Guidelines.

This activity is an enhancement to the service centralization and continuity (SCC) functionality, which implements a subset of the 3rd Generation Partnership Project (3GPP) and 3rd Generation Partnership Project 2 (3GPP2) functionality.

Most of the functionality required to support 3GPP/3GPP2 is already provided by the system; however, the following enhancements are required:

• Retrieve and insert location information from IP Multimedia Routing Number (IMRN) allocation request or from Home Subscriber Server (HSS).

• Retrieve circuit-switched domain routing number (CSRN) from HSS.

• Support IMRN prefixing

Service codes are used as routable addresses in some markets. Service codes follow a free format that is similar to Cisco BroadWorks feature access codes. Usually, service codes should be sent to the Cisco BroadWorks Network Server for further translation and routing. However, when a service code is defined in such a way that it overlaps with a feature access code, Cisco BroadWorks translations handle it as a feature access code.

This activity addresses this problem by introducing a service code translation table that is applied before the standard feature access code translation. The service code translation table includes service codes and service code patterns. Cisco BroadWorks first compares the dialed digits with the service code translation table.

• If an exact match is found, standard translation is bypassed and the call is processed and routed based on the dialed address.

• If the collected digits do not result in an exact match, they are passed to standard translation for regular processing, which includes the feature access codes translations.

This feature modifies the Execution Server (XS) Telephony Application Server (TAS) to support additional features that were already supported on the Application Server (AS). These features are introduced on the Execution Server with functional parity with Release 18.0 of the Application Server. For information on the functionality, see the corresponding Application Server Feature Descriptions (FDs).

The following features are now available on the Execution Server:

• External Custom Ringback. For information, see the External Custom Ringback Feature Description.

• Treat Deflected Calls as Out-of-the Blue Requests. For information, see the Treat Deflected Calls as Out-of-the-Blue Requests Feature Description.

This feature introduces support for both types of Telephony Application Servers (TASs) (Execution Server and Application Server) to

co-exist within the same network, sharing as many components as possible.

Business Connectivity Enhancements: This feature implements support as defined in draft-york-sipping-p-charge-info-01. It allows the use of the P-CHARGE-INFO header in place of the CHARGE header.

• The P-CHARGE-INFO header passes the subscriber charge number in an outgoing INVITE to a routing network element (such as a softswitch).

• The P-CHARGE-INFO header is a system-wide option, which is set to “CHARGE” as the default so as to retain the current behavior for Charge Number service.

There is no change in the support for the CHARGE header.

This feature provides a system setting that can be modified to control the usage of the Telephone URI scheme in the SIP signaling going to the IMS core when calls are performed using a client interface (Open Client Interface-Call Control [OCI-C] and Xtended Services Interface [Xsi]).

This feature solves an issue with Serving – Call Session Control Function (S-CSCF) IMS implementations, which does not support the Telephone URI but does support the SIP URI.

With this feature, a system parameter is available when the Application Server is deployed or configured in IMS mode.

This feature enhances the capabilities provided with third-party voice mail support. This feature allows the system administrator to provision one or many directory numbers (DNs) to access a system-wide Third-Party Voice Mail (VM) system.

Calls received on Cisco BroadWorks for the provisioned DNs override the Outgoing Calling Plan (OCP), Communication Barring (CB), and Account Authorization Code (AAC) services, allowing the calls to proceed regardless of the settings for these services. Additionally, the Calling Line Identity policies for Cisco BroadWorks subscribers’ calls to the provisioned DNs are ignored for voice mail retrieval (VMR), allowing the Third-Party Voice Mail system to receive the subscriber’s DN to correlate to the associated mailbox on the Voice Mail system.

Enhanced Support for History-Info

This feature will extend support for proxying, generation and analysis of the hi-target-param values in the History-Info entry.

This feature implements a new Cisco BroadWorks platform providing support for SCCP devices. It includes the following capabilities:

• SCCP to SIP mediation for integration of SCCP device access to the system services, including Network Address Translation (NAT) and Call Processing.

• Trivial File Transfer Protocol (TFTP) to Hypertext Transfer Protocol (HTTP) mediation for SCCP device management integration to Cisco BroadWorks.

• Selected Cisco BroadWorks M6 feature capability specific to SCCP devices on the system.

• Core platform integration with system components such as the Application Server, Element Management System, Network Server, Profile Server, and Xtended Services Platform.

The Access Mediation Server (AMS) was added to Cisco BroadWorks as a migration path for service providers using the Cisco BroadWorks M6 system to migrate to Cisco BroadWorks. The platform enables support of Signaling Connection Control Part (SCCP) devices on Cisco. The initial platform capabilities included support for common devices and common features. Additional features for deployment of the platform were requested by customers. These include support for the:

• Cisco 7905, 7906, 7911, and 7912 phones

• Cisco 7914, 7915, and 7916 expansion modules (Busy Lamp Field feature is added for phones with expansion modules attached)

• Call Join feature

• Busy Lamp Field feature

Business Telephony: The time division multiplexing (TDM) overlay access device option was as part of the In-Call Service Activation (ICSA) feature. The ICSA implementation uses this option to determine whether it needs to initiate Media Server relay and interactive voice response (IVR) sessions to extract digits from the media stream provided by the user’s device.

There is no equivalent option defined for the network-signaling profile, that is, there is no equivalent SIP interface parameter. For calls extended to BroadWorks Anywhere locations, the TDM Overlay option is always enabled and there is no option to turn it off. This creates issues for deployments that do not require Cisco BroadWorks digit detection, that is, when the network gateway sends digits in INFO requests. As a result, Media Server relay and IVR sessions are not required.

To remedy this issue, this feature introduces the following changes:

• The access device option is renamed to “Requires BroadWorks Digit Collection”.

• The SIP interface system parameter requires BroadWorksDigitCollection is added.

The BroadWorks Anywhere service is modified to honor the new SIP interface system parameter.

This feature enhances the Cisco BroadWorks Office Communicator (OC) Tabs application to support non-English languages.

Cisco BroadWorks OC Tabs is bundled with support for the following languages: English, Spanish (CALA and European), French, German, Italian, and Simplified Chinese

The enhancement also allows changes to the language-specific resources, such as labels and messages.

This feature also:

• Replaces the current installation and configuration programs with a single program that serves as both an installation and configuration program

• Allows customization of branding through the command line interface (CLI)

Cisco BroadWorks OC Tabs is an Xtended web application that integrates Microsoft Office Communicator with the system.

Call Center: Enhances the interoperability between the system and the access device by synchronizing the following Call Center Automatic Call Distribution (ACD) states between the system and the device:

• Sign in

• Sign out

• Available

• Unavailable

• Wrap up

The user’s web portal also has an option for these ACD states with appropriate licensing.

New feature tags identifying the device roaming mode are used to optimize the domain selection performed by an IMS core / Service Centralization and Continuity-Application Server (SCC-AS) for international roaming.

This feature enables the configuration of a device with a Roaming Mode, for which the values can be “CDMA”, “GSM”, or “None”. Based on the device’s configured Roaming Mode, Cisco BroadWorks respectively adds the +volte-comma, +volte-gsm, or no feature tag to the Accept-Contact header.

With this feature, the Session Initiation Protocol (SIP) User Datagram Protocol (UDP) receive buffer size becomes configurable. The change applies to the Application Server, the Execution Server, and the Network Server.

• For the Application Server and the Execution Server, the size of the UDP receive buffer is determined by the value of the bw.sip.udp.receiveBufferSize start-up parameter, which is accessible from the command line interface (CLI) at the System/StartupParam level.

• For the Network Server, the size of the UDP receive buffer is determined by the value of the udpReceiveBufferSize system parameter, which is accessible from the CLI at the Interface/SIP level. The value of this system parameter applies locally to the Network Server where it is set, that is, its value is not replicated to other Network Servers in the cluster.

This feature improves Media Server capabilities used in services such as Meet-Me Conferencing. The improved capabilities of this feature are:

• Record audio and video streams for up to 12 hours

• Append audio and video to an existing recording

• Report the loudest participants in a conference to an Application Server

• Support Session Data Replication (SDR) redundancy on the Application Server

• Introduce labels cfw-conf, cfw-largeconf, and cfw-ivr to specify traffic type

Media Resources: The Cr reference point defined by 3GPP formalizes the protocol between an Application Server and a Media Server/Media Resource Function. The Cr reference point currently provides IVR and Conferencing services; however, it can be extended to provide other services, for example Fax service.

This feature implements the Cr reference point on the Cisco BroadWorks Media Server for IVR services. Two new protocols are supported with this activity:

• CFW, which is carried on top of Transmission Control Protocol (TCP). It provides the basic primitives required to exchange capabilities and commands between SIP entities. RFC 4145 negotiation is used to set up and establish the MediaCtrl control channel.

• msc-ivr/1.0, which provides the means to define and control IVR dialogs. Commands from msc-ivr/1.0 are carried over in a CFW control channel.

These two protocols form the control channel used to manage the experience of SIP media dialogs.

Before this enhancement, when User A calls User B and User B deflects the call via Call Forwarding to User C, Cisco BroadWorks did not treat the forwarded call as an out-of-the-blue (OOTB) request. As such, the P-Served-User/P-Served-User-Identity headers were not sent to the Serving-Call Session Control Function (S-CSCF). Therefore, the S-CSCF cannot rigger the originating services execution for User B.

With the addition of this enhancement, the call deflection services before answer are now initiating an OOTB request when the route mode is defined as asRoute or receivedRouteLocation and the new forceDeflectedCallBeforeAnswerAsOOTB system parameter is set to “true”. When the call deflection occurs, the system processes the redirecting services for the user deflecting the call, and then sends the INVITE to the deflected-to user as an OOTB request, with the P-Served-User/P-Served-User-Identity header defined as the deflected-by user. This enables the Call Session Control Function (CSCF) to process and route the call to the deflected-to user.

System: Enhances the Device Management functionality to support Cisco Skinny Client Control Protocol (SCCP) devices.

This feature:

Adds the support of the Trivial File Transfer Protocol (TFTP) on the Xtended Services Platform.

• Introduces dynamic tags required for the SCCP devices on the Cisco BroadWorks Application Server.

• Improves the device file Application Server location lookup on the Xtended Services Platform and Network Server.

The purpose of this activity is to build a Diameter stack, be used in the following products: BroadWorks Application Server (Sh, Rf, and Ro interfaces) and BroadWorks Rating Function Application (RFN) developed in the context of Advice of Charge.

The stack has a first layer with core functionalities of Diameter, common to all specific interfaces, such as the connection establishment and management along peer state machine in RFC 3588, including the Capability Exchange negotiation, the Device Watchdog process, and so on. The second layer provides interface-specific application programming interfaces (APIs). As Cisco BroadWorks uses only the Rf, Ro, and Sh interfaces, only those interface-specific APIs are required. For example, the Rf API provides the ability to create offline accounting sessions, create Accounting-Requests (ACRs), and send and receive Accounting-Answers (ACAs) and pass them to the Rf application for proper processing.

This feature allows specifying how the name retrieved by the Calling Name Retrieval service is used in the headers to establish the identity of a caller.

The display name can now be updated either in the P-Asserted-Identity header, the From header, or in both headers.

This feature enhances the Xsi-Actions-XS-TAS API so that the device profile command (/user/<userid>/profile/Device) returns the media access control (MAC) address for each device profile associated with a user if the MAC address is provisioned in Cisco BroadWorks.

In addition, this Xtended Services Interface (Xsi) command is enhanced to support a new parameter that specifies the MAC address of the device for which to return details.

This activity enhances External Authentication in two ways:

• Adds plain text authentication to the Open Client Interface/WAS to support systems that only support plain text authentication, such as Microsoft Active Directory.

• Adds WAS authentication support to the Xtended Services Platform (Xsp) for web applications such as Xtended Services Interface (Xsi), which require support.

This feature adds support for the G.722 wideband CODEC on the Cisco BroadWorks Application Server. Services on the Cisco BroadWorks Application Server, such as Auto Attendant, Voice Mail, and Music On Hold benefit from support for this new CODEC.

NOTE: The G.722.1 and G.722.2/AMR-WB CODECS are not supported by this feature.

This feature adds support for the G.722 wideband CODEC on the Cisco BroadWorks Media Server for conferences and Call Control eXtensible Markup Language (CCXML). Services on the Cisco BroadWorks Application Server such as Three-Way Calling, N-Way Conferencing, Instant Group Call, and Push To Talk benefit from this new codec.

Note the following important caveats:

• Interactive Voice Response (IVR) services such as Auto Attendant, Voice Mail, and Music On Hold do not support the G.722 wideband codec.

• G.722.1 and G.722.2/AMR-WB CODECS are not supported by this feature.

This feature enhances how the Application Server interacts with a Serving Call Session Control Function (S-CSCF) in an IP Multimedia Subsystem (IMS) deployment using the IMS Service Control (ISC) interface. This includes support for the P-Called-Party-ID and

P-Charging-Function-Addresses headers, support of the mode parameter for Route entries, and various other changes regarding how the Application Server populates and/or proxies headers such as the Request-URI, From, To, and P-Asserted-Identity.

Platform and System Enhancements: Enhances the Cisco BroadWorks Internet Protocol Multimedia Subsystem (IMS) Service Control (ISC) interface.

This feature provides a configuration option to determine whether an Out-of-the-Blue (OOTB) request is generated for account/authorization code calls or whether the received route is reused for account/authorization code calls.

Platform and System Enhancements: This feature enhances the Session Initiation Protocol (SIP) proxy behavior of the Application Server by:

• Transparently passing the Accept and Allow header when conveying the value “dtmf-relay”.

• Only applying the transparency behavior to the initial INVITE request and its responses (18x and 200).

The transparency behavior only applies to end-to-end call scenarios (for example, a SIP INVITE request is received from an access or network device and a corresponding SIP INVITE request is sent out directly to the terminating access or network device).

Media Resources: Enhances the Cisco BroadWorks Media Server to support Internet Protocol Version 6-based (IPv6) Session Initiation Protocol/Session Description Protocol (SIP/SDP) signaling for both User Datagram Protocol (UDP) and TCP transports between the Cisco BroadWorks Application Server and the Media Server.

The feature also supports the corresponding media over IPv6. In addition, the Media Server supports associated Hypertext Transfer Protocol (HTTP) media file transfer over IPv6 and associated sendmail over IPv6.

IPv6 support applies to the following types of SIP sessions:

• Announcement

• Voice XML/Call Control XML (CCXML)

• Media Server Control Markup Language (MSCML) IVR

• MSCML Fax

• Repeater

NOTE: The Media Server supports IPv6 SIP signaling for MSCML repeater sessions. However, all repeaters and associated listeners within a SIP repeater session must be of the same address type.

Enabling IPv6 support does not preclude calls conducted in IPv4. Calls conducted in IPv6 and calls conducted in IPv4 can coexist.

For more information regarding IPv6 support on the Media Server, see the Media Server IPv6 Support Feature Description (available from BroadSoft upon request).

This feature modifies how the Cisco BroadWorks Media Server handles the c = line in the Session Description Protocol (SDP). According to RFC 4566, the c = line may be present in the session description portion of the SDP or the media description portion of the message or both. However, to facilitate interoperability, the Media Server typically uses a single session description c = line when deployed in an IPv4-only network or IPv6-only network. The Media Server uses the media description level c = lines when deployed in a combined IPv4/IPv6 network.

This feature also incorporates other minor configuration changes as follows:

• Added nuance_v8 and nuance_v9 as Media Resource Control Protocol (MRCP) Text to Speech (TTS) vendor choices to the Media Server command line interface (CLI).

• Allowed Media Control Channel Framework (CFW) maximum recording size to be configurable by the Media Server CLI.

• Removed the mediaDialogServiceName and controlChannelDialogServiceName from the MS_CLI/Applications/MediaStreaming/ Interfaces/CFW level (as they are no longer used).

• Added a new alarm to indicate a failure to initialize the local Call Control XML (CCXML) HTTP server (if configured).

Platform and System Enhancements: This feature changes the behavior of dual-tone multi-frequency (DTMF) collection for D-Link 102 devices. For these devices, DTMF collection is out-of-band. The system requests notification of digit detection by the integrated access device (IAD) during normal call signaling. Once the system receives an NTFY for the detected digit, it proxies the information out-of-band to the remote endpoint.

Out-of-band DTMF detection and handling is active during normal call processing and second call origination. For second call origination, the Media Server still provides dial tone; however, it receives each detected digit out-of-band in a SIP INFO message. All SIP INFO commands resulting from DTMF detection are encapsulated in a SIP message with dumb-relay as the content type.

Any negative responses to an INFO request or any other errors resulting from proxying a DTMF NTFY message from a D-Link 102 endpoint are not reported to the endpoint.

Platform and System Enhancements: This feature changes the behavior of dual-tone multi-frequency (DTMF) collection for D-Link 102 devices. For these devices, DTMF collection is out-of-band. The system requests notification of digit detection by the integrated access device (IAD) during normal call signaling. Once the system receives an NTFY for the detected digit, it proxies the information out-of-band to the remote endpoint.

Out-of-band DTMF detection and handling is active during normal call processing and second call origination. For second call origination, the Media Server still provides dial tone; however, it receives each detected digit out-of-band in a SIP INFO message. All SIP INFO commands resulting from DTMF detection are encapsulated in a SIP message with dumb-relay as the content type.

Any negative responses to an INFO request or any other errors resulting from proxying a DTMF NTFY message from a D-Link 102 endpoint are not reported to the endpoint.

This feature enhances the MGCP protocol to support Embedded Media Terminal Adapters (eMTAs) deployed in the Japanese market. Specifically, this feature addresses two parameters used to support legacy eMTAs using the MGCP protocol:

Sending the “bz” parameter rather than the “osi” parameter in the DELETE CONNECTIONS request – In the current implementation of MGCP on Cisco BroadWorks, the DELETE CONNECTIONS request contains the “osi” parameter, which tells the endpoint device (eMTA) to play the network disconnect tone after the connection is deleted. In the Japanese market, the eMTA expects to receive the “bz” or “busy” parameter in the DELETE CONNECTIONS request.

Removing the “a=recvonly” parameter in the SDP received from the MGCP device (eMTA) upon call origination – Some legacy MGCP devices (eMTAs) deployed in the Japanese cable market send “a=recvonly” in the SDP in the call origination. The system does not manipulate the SDP and passes it on to the termination end point, thus setting up a call with one-way audio. This feature enables the removal of the “a-recvonly” parameter from the SDP received from the endpoints before sending to the endpoint.

The current implementation of the Sametime Connector Web Application (v1.2) supports a connection to a single IBM Sametime Community Server (single tenant). This prevents a service provider from hosting multiple enterprises that need to connect to different IBM Sametime Community servers on a single Xtended Services Platform (Xsp). To serve multiple IBM Sametime Community servers, the service provider is required to deploy the Sametime Connector on multiple Xtended Services Platforms.

This feature provides multi-tenant support to the Sametime Connector enabling it to connect to and serve multiple IBM Community Servers

Protocols: This feature allows the creation of custom media types in the CLI for Media Call Processing policies. The feature specifically introduces a custom media type, message, to control use of the Message Session Relay Protocol (MSRP) codec (for Multimedia Telephony Service/MMTel session-based instant messaging and presence). Currently there are three media types:

• Audio

• Video

• Image

This feature allows the addition of any number of unique media types with which any codec can be associated. The operator can create a custom media type or use a pre-provisioned custom type called message associated with the MSRP codec. The operator can then use the new media type to control media use through Call Processing policies as can currently be done with the other supported media types.

This activity enhances the Phone Xtension (PXT) solution. This version of the PXT solution contains enhancements to features in the following categories:

• Application initialization

• Line and soft key editing

• Retrieving Busy Lamp Field data

• Administrator access

Other PXT general enhancements included in this activity are:

• A new PXS-SDK interface allowing service providers to retrieve the actual values for Cisco BroadWorks tags contained in device template files. The data contained in the template files can be used to display actual device key configuration values instead of system tags.

• A new command line interface option has been added to the PXS permitting mapping from the PXS device type to the Cisco BroadWorks device type.

Support for “ToolTip” in the Phone Editor and Phone Xtension services. This allows PXS developers the ability to populate the ToolTip or Help area, providing instructions to the end user about data needed for the configuration of line or soft keys.

Protocols: Provides two new Media Gateway Control Protocol (MGCP)/Network Control Protocol (NCS) device profiles, the Motorola SBV5220 Payphone and Arris TM402/TM502 NCS Payphone. It provides support for polarity line inversion on the device for originating calls.

Upon answer, the customer premises equipment (CPE) is signaled to release coins into a pay phone coin box. Polarity inversion is controlled by requesting that the endpoint play the signal “rev” with parameter “+” to enable, or “-” to disable.

Once the system applies polarity inversion, it remains enabled until the call ends. Polarity inversion is not enabled on a call that is not answered. Note that the application of treatment or early media by the system does not constitute an answered call.

System: Introduces a new pre-upgrade validation tool to assist with system upgrades. This tool is:

• Operating system (OS) independent

• Downloadable from Xchange with the Cisco BroadWorks software release

There is one version of the pre-upgrade validation tool per major release of Cisco BroadWorks (for example, one for Release 14.0, one for Release 15.0, and so on). The tool’s file, bw-preUpgradeValidation.bin, is a self-extractable command that runs all of the validation rules of the system installer. The tool is self-extracted in the directory it is executed from and only performs validation.

It is important to note that it is recommended to always download and use the latest version of this tool.

Platform and System Enhancements: Prior to the implementation of this feature, the Application Server proxied the Proxy MSRN using P-Called-Party-ID (PCPI) header in an initial INVITE request only in Internet Protocol (IP) Multimedia Subsystem (IMS) deployments.

With the addition of this feature, the following behaviors apply:

• Cisco BroadWorks User Termination – The Application Server proxies the PCPI header in an initial INVITE in non-IMS deployments if the destination is the user’s primary location. It is important to note that it does not proxy the PCPI header to the user’s secondary or alternate locations.

• Cisco BroadWorks User Origination – The Application Server proxies the PCPI header in an initial INVITE in non-IMS deployments.

For correct operation of the Busy Lamp Field (BLF) service, it is recommended that the SIP subscription use Transmission Control Protocol (TCP). This recommendation is made as the BLF SIP NOTIFY requests are typically too large to avoid user datagram protocol (UDP) fragmentation.

This enhancement introduces a configuration option forcing the Cisco BroadWorks Application Server to disregard explicit, implicit, or Domain Name Server (DNS)-resolved selection of UDP for sending BLF NOTIFY requests. When this option is enabled, it forces the NOTIFY requests to be sent using TCP.

The SIP interface is enhanced to support new drafts, RFCs, and standards that enable new capabilities on access devices, network devices, and partner platforms. Enhancements include:

• RFC 3311 support

• Reject calls with un-decodable SDP

• Enhanced hold handling

• Registration time extension

• Reliable provisional response

• SDP management

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• Proxy after answer INFO messages

• Application Server to check diversion header

• Symmetrical signaling

• Invite without SDP

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• IMS ISC Enhancements – enhances the way the Application Server interacts with an S-CSCF in an IMS deployment using the ISC interface

• Media Server SIP Enhancements – enhances the Media Server SIP stack to comply with IMS specifications TS 23.002 and TS 24.229

• P-Charging Vector Enhancements – provides the ability to add new proprietary parameters to the P-Charging-Vector to assist BroadSoft IMS partners

• IMS Sh Interface – provides an interface between an IP Multimedia Subsystem (IMS) Application Server and a third-party IMS Home Subscriber Server (HSS)

• SIP Registration (Minimum Registration Time) – allows administrators to specify a minimum SIP registration period for the system. Registrations whose expiration is less than the configured minimum value are denied

• SIP TCP Enhancements – introduces a number of enhancements to improve SIP TCP socket management. SIP TCP connections are closed based upon expirations and reaching the maximum number of connections. Connections are also closed and prevented upon server state changes

• Support Offer Answer and Early Media (UPDATE Compliance) – modifies the system call model and SIP interface to improve media services, scenarios that involve early media changes, and media clipping issues

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• IMS ISC Enhancements – enhances the way the Application Server interacts with an S-CSCF in an IMS deployment using the ISC interface

• Media Server SIP Enhancements – enhances the Media Server SIP stack to comply with IMS specifications TS 23.002 and TS 24.229

• P-Charging Vector Enhancements – provides the ability to add new proprietary parameters to the P-Charging-Vector to assist BroadSoft IMS partners

• IMS Sh Interface – provides an interface between an IP Multimedia Subsystem (IMS) Application Server and a third-party IMS Home Subscriber Server (HSS)

• SIP Registration (Minimum Registration Time) – allows administrators to specify a minimum SIP registration period for the system. Registrations whose expiration is less than the configured minimum value are denied

• SIP TCP Enhancements – introduces a number of enhancements to improve SIP TCP socket management. SIP TCP connections are closed based upon expirations and reaching the maximum number of connections. Connections are also closed and prevented upon server state changes

• Support Offer Answer and Early Media (UPDATE Compliance) – modifies the system call model and SIP interface to improve media services, scenarios that involve early media changes, and media clipping issues

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• IMS ISC Enhancements – enhances the way the Application Server interacts with an S-CSCF in an IMS deployment using the ISC interface

• Media Server SIP Enhancements – enhances the Media Server SIP stack to comply with IMS specifications TS 23.002 and TS 24.229

• P-Charging Vector Enhancements – provides the ability to add new proprietary parameters to the P-Charging-Vector to assist BroadSoft IMS partners

• IMS Sh Interface – provides an interface between an IP Multimedia Subsystem (IMS) Application Server and a third-party IMS Home Subscriber Server (HSS)

• SIP Registration (Minimum Registration Time) – allows administrators to specify a minimum SIP registration period for the system. Registrations whose expiration is less than the configured minimum value are denied

• SIP TCP Enhancements – introduces a number of enhancements to improve SIP TCP socket management. SIP TCP connections are closed based upon expirations and reaching the maximum number of connections. Connections are also closed and prevented upon server state changes

• Support Offer Answer and Early Media (UPDATE Compliance) – modifies the system call model and SIP interface to improve media services, scenarios that involve early media changes, and media clipping issues

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• IMS ISC Enhancements – enhances the way the Application Server interacts with an S-CSCF in an IMS deployment using the ISC interface

• Media Server SIP Enhancements – enhances the Media Server SIP stack to comply with IMS specifications TS 23.002 and TS 24.229

• P-Charging Vector Enhancements – provides the ability to add new proprietary parameters to the P-Charging-Vector to assist BroadSoft IMS partners

• IMS Sh Interface – provides an interface between an IP Multimedia Subsystem (IMS) Application Server and a third-party IMS Home Subscriber Server (HSS)

• SIP Registration (Minimum Registration Time) – allows administrators to specify a minimum SIP registration period for the system. Registrations whose expiration is less than the configured minimum value are denied

• SIP TCP Enhancements – introduces a number of enhancements to improve SIP TCP socket management. SIP TCP connections are closed based upon expirations and reaching the maximum number of connections. Connections are also closed and prevented upon server state changes

• Support Offer Answer and Early Media (UPDATE Compliance) – modifies the system call model and SIP interface to improve media services, scenarios that involve early media changes, and media clipping issues

The SIP interface is enhanced to support new applications, to better interwork with network and access devices, and to comply with the most recent standards. Enhancements include:

• IMS ISC Enhancements – enhances the way the Application Server interacts with an S-CSCF in an IMS deployment using the ISC interface

• Media Server SIP Enhancements – enhances the Media Server SIP stack to comply with IMS specifications TS 23.002 and TS 24.229

• P-Charging Vector Enhancements – provides the ability to add new proprietary parameters to the P-Charging-Vector to assist BroadSoft IMS partners

• IMS Sh Interface – provides an interface between an IP Multimedia Subsystem (IMS) Application Server and a third-party IMS Home Subscriber Server (HSS)

• SIP Registration (Minimum Registration Time) – allows administrators to specify a minimum SIP registration period for the system. Registrations whose expiration is less than the configured minimum value are denied

• SIP TCP Enhancements – introduces a number of enhancements to improve SIP TCP socket management. SIP TCP connections are closed based upon expirations and reaching the maximum number of connections. Connections are also closed and prevented upon server state changes

• Support Offer Answer and Early Media (UPDATE Compliance) – modifies the system call model and SIP interface to improve media services, scenarios that involve early media changes, and media clipping issues

Protocols: Enhances the forking proxy support on the Cisco BroadWorks Application Server.

The enhancement allows multiple early dialogs for an INVITE to simultaneously exist according to RFC 3261. This allows the Cisco BroadWorks Application Server to support proxies (or proxy simulators) that perform forking services such as Simultaneous Ringing upon an INVITE sent by the Application Server.

It is important to note that this feature does not add support of receiving such requests (multiple INVITE, SUBSCRIBE, and so on) from forking proxies.

When the SIP forking proxy functionality was used with the “singleDialogWithUPDATE” option, the Cisco BroadWorks Application Server would send SIP messages using the UPDATE method even if the UPDATE method was not present in the Allow header of the related requests.

This activity addresses this issue by enhancing the SIP forking functionality with a new possible option that improves on the “singleDialogWithUPDATE” behavior by avoiding the use of the UPDATE method if the latter is not signaled in the Allow header.

This enhancement to Cisco BroadWorks provides the following:

• Allows the Cisco BroadWorks Application Server to send a SIP NOTIFY request according to RFC 3515 to suppress the implicit REFER subscription

• Continues to allow suppression of the implicit REFER subscription without sending NOTIFY

• Introduces a new configuration parameter suppressImplicitReferSubscription to control how the implicit REFER subscription is suppressed.

The purpose of this feature is to enhance Cisco BroadWorks Session Initiation Protocol (SIP) compliance and IP Multimedia Subsystem Service Control (ISC) interface compliance.

This feature enhances the RFC 3455-related functionality within the Application Server and Network Server to support RFC 7315 with respect to some non-backward compatible SIP modifications and some new parameters. Regarding the decoding of the SIP headers, this feature also enhances the Service Control Function Server, Access Mediation Server, WebRTC Server, and UC-Connect for Microsoft.

The purpose of this feature is to enhance Cisco BroadWorks Session Initiation Protocol (SIP) compliance and IP Multimedia Subsystem Service Control (ISC) interface compliance.

This feature enhances the RFC 3455-related functionality within the Application Server and Network Server to support RFC 7315 with respect to some non-backward compatible SIP modifications and some new parameters. Regarding the decoding of the SIP headers, this feature also enhances the Service Control Function Server, Access Mediation Server, WebRTC Server, and UC-Connect for Microsoft.

Provides the following capabilities for the SIP protocol stack:

• Network Route Reliability – used to ensure signaling paths between network devices. A keep-alive mechanism is provided for network device connections. Each connection has a state, reflecting the current connectivity status. This connectivity state is checked before routing a call to the associated network device. The route timeout process is tightened to ensure rapid rerouting in case of a network device outage or unavailability

• Privacy Drafts – used to properly pass calling line identity information over SIP

• Authentication – securely authenticate identities of end users

Protocols: Allows unknown or unprocessed headers to be proxied through based on system-level policies.

When the Cisco BroadWorks Application Server receives a SIP request or response that includes headers that have no semantic meaning for local services on the platform, Cisco BroadWorks applies a new system-level policy called SIP Header Transparency to determine whether the header should be proxied through to the remote party/parties or dropped. This allows operators to have greater control over which unknown headers are allowed to be proxied and how they are affected by service interactions.

Headers require and supported contain option tags. Option tags that have no semantic meaning for local services on the Cisco BroadWorks platform may also be proxied using a mechanism similar to unknown SIP headers.

This feature modifies trunk group configuration options to support the functionality that was previously supported via container options.

• Redirect Trunk Group Lookup Policy for Out-of-Dialog PBX Redirection

• Originator Lookup Policy for Out-of-Dialog PBX Redirection

• Include Trunk Identity in Network-Side INVITE for All Originations

• Trunk Group Originating User Lookup Policy

• ETRouteExhaustUnreachable Configurable Treatment service

Media Resources: This feature allows the Cisco BroadWorks Application Server to accept .3gp and .wma file formats for all features where media files may be customized. While these file formats are currently supported on the Cisco BroadWorks Media Server, some customers do not have a Media Server in their network and as a result, must support these file formats on the Application Server to play announcements, perform IVR, or serve most other feature activities where an audio response is required.

Windows Media Audio (.wma) files are based in advanced systems format (.asf) files and are the default audio format for Windows Vista.

The .3gp is a multimedia container format defined by 3GPP for use on 3G mobile phones, and is a mandatory format for IMS-based networks. It is a simplified version of MPEG-4 Part 14 (MP4).

IMS and Protocols: Enhances Cisco BroadWorks accounting interfaces by adding support for the 3GPP Rf interface. It is used to provide offline charging information to the billing servers. The system implements the Rf interface as defined in specifications 3GPP TS 32.260 V7.4.0 and 3GPP TS 32.299 V7.7.0.

The Rf interface is based on the Diameter protocol (RFC 3588). The system uses the Condor’s Diameter protocol stack introduced in Release 14.sp4. The accounting messages carried over Diameter contain standard Diameter attribute-value pairs (AVP), 3GPP AVP, and BroadSoft vendor-specific AVP.

This feature enhances the Cisco BroadWorks Application Server to encode the Calling Party Category (CPC) or Originating Line Information (OLI) in the P-Asserted-Identity header of outgoing INVITE messages. In addition to the encoding of the CPC/OLI values in the

P-Asserted-Identity header, the Application Server also follows the trusted domain rules according to the specifications. This enhancement is only applicable to the IP Multimedia Subsystem (IMS) mode of the Cisco BroadWorks Execution Server.

This feature enhances the Cisco BroadWorks Media Server to permit recording and playback of H.264 video files at up to 720p HD (1280 x 720) resolution, enhancing the end-user experience on HD (high definition) video phones.

The Application Server includes H.264 video prompts prerecorded in 720p HD resolution in its set of default video prompts. These prompts can be selected via the bwSwitchActiveVideo script. The Media Server transcodes 720p HD sized prompts to 768 x 448 when playing to a device that supports 768 x 448. The Media Server plays 720p HD sized prompts as 720p HD to a device that supports 720p HD.

This feature introduces the capability to play and record H.264 video files with up to 720p HD resolution over Real-Time Transport Protocol (RTP). Of particular interest are:

• 768 x 448 – for compatibility with Tandberg E20

• 720p HD (1280 x 720) – for compatibility with LifeSize Room

The Media Server supports the max-fs and max-mbps H.264 SDP payload format options. An endpoint includes these options to indicate that it can handle a greater resolution and frame rate than that supported by the H.264 level.

This feature introduces support for passing the Jurisdiction Information Parameter (JIP). The JIP is included in the routing number (rn) parameter as part of the P-Asserted-Identity header user part according to TIA 1112 v1.0.

This enhancement introduces a new SIP system parameter enabling the proxying of the P-Asserted-Identity routing number parameter (contained in TEL URI) from the incoming originating INVITE to the outgoing originating INVITE. For more information, see RFC 4694.

The proxyRoutingNumberFromPAssertedIdentity system parameter allows for the enabling and disabling of this new SIP configuration. It is configurable at the command line interface (CLI) under /Interface/SIP and its default value is “false”.

Advanced Services: Supports the Media Resource Control Protocol (MRCP) protocol on the Cisco BroadWorks Media Server.

This protocol extends VoiceXML support to make use of external Text-to-Speech and Automatic Speech Recognition engines.

Before this enhancement, when User A calls User B and User B deflects the call via Call Forwarding to User C, the system did not treat the forwarded call as an out-of-the-blue (OOTB) request. As such, the P-Served-User/P-Served-User-Identity headers were not sent to the Serving-Call Session Control Function (S-CSCF). Therefore, the S-CSCF cannot rigger the originating services execution for User B.

With the addition of this enhancement, the call deflection services before answer are now initiating an OOTB request when the route mode is defined as asRoute or receivedRouteLocation and the new forceDeflectedCallBeforeAnswerAsOOTB system parameter is set to “true”. When the call deflection occurs, the system processes the redirecting services for the user deflecting the call, and then sends the INVITE to the deflected-to user as an OOTB request, with the P-Served-User/P-Served-User-Identity header defined as the deflected-by user. This enables the Call Session Control Function (CSCF) to process and route the call to the deflected-to user.

This activity introduces a new system-level SIP parameter to configure the behavior that the Application Server should adopt when receiving an INVITE with “unknown” as the display name in the From header.

This feature also addresses an issue concerning the Call Park service. Some devices are not able to detect the reorder tone played by a Call Park failure, such as parking or retrieving, and may leave the parked party on hold indefinitely. For this reason, this feature adds Call Park to the list of services that can be customized with a configurable treatment (see the Configurable Treatment Handling Feature Description). Call Park can now be mapped to a configurable treatment; therefore, the reply from the Application Server can be fully customized.

Prior to this activity, the HTTP processing pipeline provided by the Web Container proved expensive in server resources for a number of applications, particularly those relying on HTTP streaming. This feature calls for streamlining the HTTP processing pipeline on the Xtended Services Platform (Xsp) to increase its capacity.

While the HTTP server performance is expected to remain similar for most non-streaming HTTP applications, the main purpose of this activity is to enhance significantly the throughput of streaming HTTP and specifically for the Xsi-Events application.

Advanced Core Services: This feature introduces functionality required to support the new Cisco BroadWorks Xtended Services Interface, or Xtended Services Interface.

Specifically, this release includes:

Cisco BroadWorks Xtended Services Platform – In Release 14.sp5, a new server is introduced, the Xtended Services Platform. The Xtended Services Platform server provides a turnkey solution to deploy new Cisco BroadWorks web-based applications.

Xtended Services Interface – The introduction of the RESTful interface for Cisco BroadWorks includes the following default capabilities:

• Session-less Transactions – Transactions are allowed without first creating a session using standard HTTP Authentication.

• External Authentication – Support for external authentication in addition to system Authentication.

Initially, the services provided are:

• Do Not Disturb

• Call Forwarding Always

• Simultaneous Ringing Personal

Advanced Services: Provides the ability to access enterprise and group directory entries over the Cisco BroadWorks Open Client Interface-Provisioning (OCI-P), in a “paged” manner.

Instead of listing the entire directory in a response, a paged response to the contact list request is now possible. Since this enhancement affects the OCI-P interface, this functionality is available to any external OCI-P client application.

This enhancement allows the Xtended Services Interface to present enterprise and group directory listings without adverse performance impacts to the system for large enterprise/group listings.

The Xtended Services Interface (Xsi) currently consists primarily of the Xsi-Actions web application. This web application supports the Service Management, Call Management, and Call Lists categories of commands (for example, querying for a user’s service setting, placing a call, or retrieving a contact directory).

This feature introduces a new web application called “Xsi-Events”. Xsi-Events are designed to support the delivery of notifications to clients when various events occur in the system. This new application allows a client to subscribe to various events that may occur against a subscriber.

The subscription triggers a notification back to the client when a corresponding event occurs. This implies, of course, that these applications have the capability to subscribe to events from the system using the Xtended Services Interface and are notified when such events occur.

Xsi-Events (like Xsi-Actions) supports camel case and lower case uniform resource locators (URLs) when commands are issued, producing the same response.

The following Xtended Services Interface commands are enhanced:

• User Profile: /user/profile command enhanced to include the time zone.

• Call Notify: /user/services/callnotify/criteria/<criterianame> command added to support POST, PUT, GET, and DELETE.

• User Schedule Management: /user/profile/schedule/time and /user/profile/schedule/holiday commands modified to support POST, PUT, and DELETE for schedules and events under schedules.

Xtended Services Platform (Xsp) load balancing allows easier management of dynamic Xtended Services Platform instantiation when Xtended Services Platforms are frequently added and removed from a farm. Previous techniques used DNS entries to allow clients to discover new nodes, which is too slow for rapidly evolving networks as it can take a long time to refresh DNS caches.

With the new load balancing capability, clients always connect to a load-balancing node before being routed to the actual backend Xtended Services Platform. The load-balancing node can be reconfigured on the fly to add or remove Xtended Services Platforms.

This feature enhances the Xsi-Actions web application. The primary purpose of this enhancement is to permit the VoiceXML capability already present on the system to use Xtended Services Interface-based applications.

VoiceXML scripts typically only have access (or can gain access) to a user’s phone number and voice portal passcode. Using these credentials and being able to issue Xtended Services Interface commands from within a VoiceXML script greatly enhances the capability of creating new voice applications.

Specifically, this enhancement allows user authentication via any phone number belonging to a user and their voice portal passcode, as well as the current authentication credentials of a user ID and password.

This feature enhances the Xsi-Actions web application. The primary purpose of this enhancement is to permit the VoiceXML capability already present on the system to use Xtended Services Interface-based applications.

VoiceXML scripts typically only have access (or can gain access) to a user’s phone number and voice portal passcode. Using these credentials and being able to issue Xtended Services Interface commands from within a VoiceXML script greatly enhances the capability of creating new voice applications.

Specifically, this enhancement allows user authentication via any phone number belonging to a user and their voice portal passcode, as well as the current authentication credentials of a user ID and password.

This feature provides the following capabilities required to perform Xtended Services Interface operation from within VoiceXML applications:

• HTTP GET

• HTTP PUT

• HTTP DELETE

• HTTP POST

The Xtended Services Interface (Xsi) functionality is provided by three Xtended Services Interface web applications: Xsi-Actions, Xsi-Events, Xsi-MMTel.

These webapps are currently packaged separately from Cisco BroadWorks. They can run in a container like the Xtended Services Platform (Xsp) or a third-party container. As such, they have their own version and are packaged separately from Cisco BroadWorks.

This feature delivers the Xtended Services Interface webapps as part of the Xtended Services Platform. The functionality of these webapps has not changed, however their installation, upgrade, and patching are now done by following the software management procedures used for the Xtended Services Platform server. These webapps no longer have a separate version as they are packaged as part of the core Cisco BroadWorks software.

As a result of this action, the Xtended Services Interface webapps can only be installed on an Xtended Services Platform server. They cannot be installed on other non-Cisco BroadWorks web containers.

This feature also enhances the Xtended Services Interface webapps logging functionality, providing more configuration options and flexibility. The logging function is now replaced by the standard system logging mechanism.

This feature adds enhancements to the Hierarchical Communication Barring (HCB) service by allowing the group administrator of an enterprise to control the HCB profile that should be applied to a specific user in the group.

This feature also enhances the communication barring digit patterns to allow the “$” wildcard character at the beginning of the digit string.

This feature introduces the Security Classification service that allows the system to classify calls in which a user is involved, with a security classification level. The purpose of the feature is for users to be conscious of the maximum level of classified information that can be safely exchanged in a conversation.

The Security Classification service allows the assigning of a security classification level to a user. Security classification levels are defined and prioritized at the system level.

This feature provides support the Calling-Party-Address strict compliancy with 3rd Generation Partnership Project (3GPP) specification TS 32.299.

The objective of this feature is to introduce a new call detail record (CDR) field named callingPartyAddress in the 3GPP module. This field contains the complete “addr-spec” value taken from the P-Asserted-Identity (PAI) header (RFC 3325) of the SIP INVITE for the call when present; otherwise, it contains the string value “unknown”. This new CDR field is defined as a list field that can accommodate the presence of multiple identities in the PAI.

This enhancement also adds a new Diameter accounting configuration, which enables a mode of operation strictly compliant with the statement described above.

This feature enhances the Cisco BroadWorks Call Logs to support Call Completed Elsewhere functionality.

An alerting call for a Cisco BroadWorks user location is considered as answered elsewhere when it is released because it has been answered by another location. With this feature, a Received call log is created instead of a Missed call log for such a call.

This feature provides additional checks to prevent users from entering their own numbers as the destinations when it would cause loops at run time.

Prior to this feature, users could enter their own BroadWorks Mobility number when setting up a redirection address for a service covered by provisioning validation. They could also enter their own directory number (DN) (their primary location), alternate DN, or their BroadWorks Mobility location as the destination for the Remote Office and BroadWorks Anywhere locations.

Cisco BroadWorks EVS codec Support Functional Description

This feature adds support for the EVS audio codec on the Cisco BroadWorks Media Server and Application Server.

This feature allows the EVRC-A codec, namely EVRC0, and EVRC-NW codecs, namely EVRCNW and EVRCNW0, to be chosen as the preferred audio codec for the Music On Hold service in XS mode. Additionally, these codecs can be added to the list of supported codecs on the Execution Server.

The feature has no impact on the preferred audio codec functionality on the Execution Server. The new codec is part of the Cisco Media Server (MS) range of supported codecs used to stream media.

This feature delivers transcoder free operation of VP9 and H.264 codecs through the Web Real Time Communication (WebRTC) Server to improve the WebRTC Server video throughput and quality.

This feature delivers RTP and RTCP relay enhancements to the WebRTC Server transcoder free operation and to the Media Server video call recording dual output capabilities. This feature also provides support for dynamic downgrade of video bit rate to the Media Server unique display mode video mixing capabilities. These enhancements provide end-to-end video interoperability and resilience to packet loss when video calls traverse the WebRTC Server, and/or being recorded by the Media Server.

H.264 parameter sets carry information such as picture size and other video characteristics, which apply for more than one frame. However, the information carried by H.264 parameter sets is not necessarily common among video files.

RFC 3984 specifies that H.264 parameter sets can be carried in both SIP/Session Description Protocol (SDP) offer/answer signaling and/or over the Real-Time Transport Protocol (RTP) stream.

If H.264 parameter sets were initially exchanged over SIP signaling, it is necessary to issue a SIP re-INVITE to update the current H.264 parameter sets with the remote end whenever a video file H.264 parameter set is different from the previous video file parameter sets. However, this step is not required when carrying H.264 parameter sets solely over RTP.

Furthermore, there is a wider range of video phones using the RTP method of carrying H.264 parameter sets. Video phones from Polycom and video soft clients such as Eyebeam carry H.264 parameter sets as part of the RTP stream instead of using SIP signaling. To provide interoperability with Polycom, Eyebeam, and other video phones, the Media Server must support the RTP method.

With this feature, the Media Server stops exchanging H.264 parameter sets over SIP signaling.

This feature provides the following enhancements to the Media Server Control Markup Language (MSCML) and VoiceXML capabilities of the Media Server:

• Records video to .3gp file and streams video from .3gp file

• Records audio to .wma file and streams audio from .wma file

• Accepts H.263/H.264 .mov files without hinted tracks

This feature adds several Media Server configuration enhancements.

The following Media Service capabilities are updated so that their SIP session audit interval (validity period) is controlled via one global configurable session audit interval. Prior to this feature, their validity periods were hard-coded.

• Media Server Control Markup Language (MSCML) Interactive Voice Response (IVR) – sip:ivr@mediaserver

• MSCML FAX – sip:fax@mediaserver

• RFC 4240 Announcements – sip:annc@mediaserver

• RFC 4240 Conferencing – sip:conf@mediaserver

• VoiceXML/Call Control eXtensible Markup Language (CCXML) – sip:dialog@mediaserver

• Cr interface SIP media dialogs:

• sip:cfw-ivr@mediaserver

• sip:cfw-media@mediaserver

• sip:cfw-conf@mediaserver

• sip:cfw-largeconf@mediaserver

The purpose of this feature is twofold:

• From a client perspective, it allows Cisco BroadWorks to authenticate using an X.509 certificate when accessing the audio database.

• From a server perspective, it allows the Media Files application to provide additional flexibility for authentication by supporting mTLS authentication in an optional way.

This feature modifies the Application Server so that it supports

re-INVITEs coming to and from the Media Server for Interactive Voice Response (IVR) and fax sessions. This support involves relaying the re-INVITE to the other party, and sending the response back to the Media Server.

This feature takes the useProxyForAllStartupScriptCalls and routeAdvanceOn5XXOnly container options that were introduced during the course of a recent patch on the Media Server and converts them into formal configuration attributes for the Media Server CLI.

Additionally, this feature exposes several Key Performance Indicators (KPIs) on the Media Server and Video Server to their SNMP Management Information Base (MIB) interfaces. Since the Media Server and Video Server are able to keep up with timing requirements at CPU occupancy levels higher than the thresholds used by Cuomo, using the number of frames skipped and the number of frames late by over 500 microseconds is more accurate than relying on CPU threshold alarms, when measuring their performance.

This feature provides the following enhancements to the Media Server playback and recording capabilities:

• Plays audio/moving picture experts group (MPEG) .mp3 file encoded at 8, 11.025, 12, 16, 22.05, 24, 32, 44.1 (cd quality), and 48 kHz

• Records audio/mpeg .mp3 files encoded at either 8 kHz or 16 kHz

The OPUS codec is a new, superior quality, royalty-free audio codec that is also used in the UC-One clients. It has been added to the Media Server and Video Server and can be used for all media services that are supported, such as announcements, interactive voice response (IVR), recording, and conferencing.

In addition, Opus can be chosen as the preferred codec for route points, call centers, and Music On Hold, as well as for media policies.

The Video Server (UVS) is a new server in the Cisco BroadWorks Collaborate server lineup that together with the Collaborate – Video service on the Cisco BroadWorks Application Server powers the

UC-One client’s video collaboration rooms.

The Video Server mixes the audio stream and video stream from multiple room participants and sends back a single stream of mixed audio and a single stream of mixed video to each participant. The video stream sent to each video participant consists of a tiled layout of up to six participants. The video stream sent to a particular participant does not include that participant’s own image. The Video Server supports the H.264 advanced video coding (AVC) constrained baseline profile up to level 3.1, which natively supports up to 720p HD resolution.

Audio-only participants are also supported. They send and receive audio; however, they do not send or receive any video. Therefore, they do not affect what is displayed in the tiled image. Their audio is mixed with the audio from the other conferencing participants.

A video collaboration room can handle up to 30 participants, 15 of which can be video participants. Once 15 video participants are connected to a video collaboration room, the Video Server refuses additional video participants, but allows audio-only participants to connect to the room.

Cisco BroadWorks Support for Secure POP3 and IMAP Feature Description

The Cisco BroadWorks Application Server and CommPilot applications are enhanced to configure secure POP3 and IMAP protocols for voice mail retrieval at the System, Group, and User levels.

This feature introduces the Security Audit Toolkit. This tool is used to help find or fix security issues. It is available on all Cisco BroadWorks servers.

The tool is located under /usr/local/broadworks/bw_base/sbin on the server. It must be executed as root.

This activity introduces a new security toolkit for the BroadWorks Application Server, which contains a set of tools that help operators detect and prevent fraudulent scenarios by either inspecting the Cisco BroadWorks call detail record (CDR) or

end-user database. The tool addresses security risks in the following areas:

• Weak password detection

• Identification of users with suspicious patterns in redirecting services

• Detection of suspicious calling patterns from Cisco BroadWorks CDRs

• Basic device authentication misconfiguration

• Audit of various system-level configurations

Both the Element Management System (EMS) and its MySQL database include security enhancements that restrict access to sensitive information and functionalities. Enhancements to the Cisco BroadWorks Simple Network Management Protocol (SNMP) Agent provide the ability to disable SNMP version 2 (SNMPv2) and offer the access control capabilities available in SNMP version 3 (SNMPv3). Several security enhancements are also implemented to the Cisco BroadWorks platform. Those changes further restrict root access through Cisco BroadWorks files.

Note that EMS is no longer supported and has been replaced by the Network Function Manager, which also uses MySQL.

This feature introduces the ability for the BroadworksFileRepos web application running on a Profile Server and the BroadWorksDms web application running on an Xtended Services Platform to store encrypted files.

The use of this enhancement is optional and it is enabled via the system configuration.

This feature implements a new design in the Notification Push Server (NPS) to resolve the security vulnerability of sharing push notification certificate private keys with service providers for the run-time branded Unified Communications (UC) clients in Unified Communications as a Service (UCaaS).

The feature enhances the capability of the Notification Push Server to push notifications to Android devices through the new Google Firebase Cloud Messaging (FCM) HTTPv1 API.

This feature allows Xsi requests to bypass the user authentication when the HTTP X-3GPP-Asserted-Identity header is specified. The authentication is skipped but the authorization to access the requested resource remains.

The 3GPP TS24.623 specification allows to use an authentication proxy (AP) to authenticate the client, rather than having authentication performed over the Ut interface. To deploy an AP, the Xtended Services Platform (Xsp) treats the AP as a trusted device and allows HTTP requests to be processed without performing user authentication. The list of trusted APs is configured via the CLI.

This feature addresses security issues related to the web applications.

• CommPilot - Session Cookie Set Without HttpOnly Flag

• Session Token Reflected in HTML

• Open Redirection

• Cacheable HTTP Responses

This feature introduces several enhancements to the use of SSL/TLS for internal Cisco BroadWorks communications on all servers:

• Simplify certificate management.

• Provide operator control over all certificates.

• Have clients validate the identity of the server using its certificate.

This feature introduces support for the Xtended Services Platform to validate the client’s certificate in a secure environment (TLS/SSL). This enhancement allows an administrator to enforce client authentication. Upon client authentication enforcement, the Xtended Services Platform automatically rejects a client request from a client without a valid client certificate, whereas client requests coming from a client with a valid client certificate normally proceed in the same manner as they did before.

By default, this functionality is disabled. An administrator can enable it on a per-interface basis (CTI, OCS, and HTTPS).

This feature introduces client authentication only. That is, this activity does not introduce any support for client authorization.

This feature introduces a new user-level configuration to select a device endpoint as the preferred answer endpoint for Auto-Answer and Forced Answer. This device endpoint is used in the following cases:

• For auto-answer, which makes use of the answer-after parameter in the Call-Info header of the SIP INVITE. This is typically invoked for Click to Dial scenarios from a call control client.

• When forcing answer using the Cisco BroadWorks remote control talk events package. This is typically used when call control clients attempt to force answer on an incoming call in the alerting state.

The primary purpose of this feature is to add native Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure Sockets (HTTPS) transport to the Cisco BroadWorks Device Management solution so that devices can download configuration, firmware, and other resource files directly from Cisco BroadWorks.

This feature also enhances the Cisco BroadWorks IP Device Configuration Management solution by adding a richer set of configuration tags and capabilities. This enhancement introduces the concept of “dynamic” versus “static” configuration tags.

• Dynamic tags are tags that are replaced with contextual values based on the line profiles associated with the device.

• Static tags are tags that are created and set to an explicit value by the administrator. Static tags make it easy to administer a set of configuration attributes that are common across two or more device types.

Also, the concept of a “configuration tag set” is introduced to make it easy to group static tags together and apply them to a device.

This feature finally adds a new user service to Cisco BroadWorks. The new service is called Polycom Phone Services.

The Device Management is updated by this feature as follows:

• Device families are introduced to allow associating one or more tag sets with one or more device tags.

• The Custom Tag Set Regional Override functionality provides the ability to override the value resolved for a tag based on a predefined region or country.

• The hotline number allows defining the contact to call when populating the Dial-On-Pickup configuration for a line of a given phone. The value set for this parameter is used to replace the new %BWHOTLINECONTACT-x% tag at resolution time.

The Device Management is updated by this feature as follows:

• Device families are introduced to allow associating one or more tag sets with one or more device tags.

• The Custom Tag Set Regional Override functionality provides the ability to override the value resolved for a tag based on a predefined region or country.

• The hotline number allows defining the contact to call when populating the Dial-On-Pickup configuration for a line of a given phone. The value set for this parameter is used to replace the new %BWHOTLINECONTACT-x% tag at resolution time.

This feature introduces the following enhancements to Device Management (DM):

• It is now possible to trigger a device configuration file rebuild force at the web portal. Depending on the administrator level, the appropriate rebuild capability should be offered.

• It is now possible to trigger a device profile rebuild (including force) at the CLI.

• A link to the device type is added to the device profile web pages to make it easier to browse to the related device type. Only system administrators can see this link.

This feature fixes a shortcoming in the way the authentication challenge is performed between the Device Management servlet and the Application Server/Provisioning Server by implementing a new mechanism to encapsulate the authentication errors within the Open Client Interface-Provisioning (OCI-P) response.

System: Device Management was introduced in Release 14.sp6. This feature enhancement corrects confusion associated with how the files are created. When new files are created, only one file of a given file type can be created within a given device type.

The text box input may confuse end users because there is no feedback on existing file types and no visual cues as to what value should be inserted.

These two issues are addressed by this enhancement.

This feature resolves two Device Management issues, one regarding configuring SIP access gateways, which requires the managing of static lines, and the other regarding the assignment of trunking users for Device Management tag resolution.

Device Management uses a dynamic line concept, by default, for provisioning IP devices. If the first line on an IP phone is unassigned, the remaining lines are migrated up a line position on the device. This concept does not work well on SIP gateways when the configuration files are rebuilt. This reconfiguration of the device causes calls to be sent to the wrong line. This feature enhances the existing Device Management line ordering by adding a Static Line/Port Ordering option. This allows the administrator to specify the line order at the provisioning time.

The second issue regards users in a trunk group. Currently, Device Management cannot distinguish between users in a Cisco BroadWorks trunk group assigned to a device and Cisco BroadWorks users assigned to a Foreign eXchange Subscriber (FXS) line on a device. These users appear in the Reorder Line/Ports on this Identity/Device Profile page, which incorrectly associates a trunk user with a port on the device even though they do not consume a physical port on the device. This feature enhances Device Management by not showing the trunk users’ lines in the Reorder Line/Ports regardless of the static line reordering option.

This feature enhances Device Management by introducing per-file access based on the file access protocol type (HTTP or HTTPS). The Device Type defines the default access protocol the device must use for downloading configuration files through the use of a “tag”. Then for each file listed, the download protocol can be defined and enforced by Device Management, which in turn only returns the file if the request from the target device uses the allowed download protocol(s) for the given file.

It is important to note that the system can be configured to deposit configuration files on an external configuration file repository or configured to use an integrated configuration file repository. Note that this feature applies only to the integrated configuration file repository. When configured to use an integrated configuration repository, the Cisco BroadWorks Profile Server (PS) and Cisco BroadWorks Xtended Services Platform (Xsp) must be deployed.

This feature permits monitoring and controlling Device Management event queues by allowing the administrator to perform the following actions:

• Monitor the status of a specific event

• Cancel an event

• Monitor the current number of events (system-wide)

• Cancel all events system-wide

This feature also changes how events are prioritized for processing. Events are prioritized such that small jobs are given priority over large jobs.

This is a Device Management feature that enhances Device Management and Configuration Management Proxy by:

• Providing Key Performance Indicators (KPIs) to help in reporting and investigating HTTP status codes returned back to the phones.

• Introducing a retry mechanism to handle Yealink SIP-T46GW phones.

• Introducing a mechanism to return empty configuration files to the phone if a media access control (MAC) address configuration is not provisioned in the system.

A template is a generic version of a file needed by a device. For a given template, multiple files can exist on a repository, each corresponding to a specific device. In Device Management, templates are defined on the Application Server. The process of turning a template into multiple device files is called a rebuild. The rebuild results are pushed to a repository for later retrieval by devices. This allows the operator to edit a single, generic device template and impact many specific device files.

Rebuilds are triggered either by a manual request from the operator or by an automatic event following provisioning changes. To improve performance, this feature prevents identical files from being sent to the repository. To improve responsiveness, manual rebuilds now have priority over automatic rebuilds.

This feature also adds the new “force” parameter to the current set of rebuild commands. This parameter gives the operator an option to force file uploads to the repository (for example, if a file has been manually deleted on the repository). This parameter is only available from the CLI and is not used and is not valid for automatic events.

This feature introduces the following enhancements to Device Management (DM):

• It is now possible to disable the automatic generation of Device Management rebuild events dynamically instead of relying on a configuration file read once at system start-up.

• Longer delays between resets sent to devices can be specified.

• The Device Management event queue size is now specified in terms of total file events that can be queued instead of using a complex formula.

• The system can be configured to always push files to the file repository, regardless whether the hash on the file’s content has changed.

• It is now possible to configure the number of retries attempted by the Application Server when an error occurs while reading, writing, deleting, or creating a folder on the file repository.

Additional performance counters are added to track errors occurring between the Application Server and the file repository. Metrics are also added to count the number of both dropped events and successful device resets.

This feature improves the Device Management experience, by providing the following enhancements:

• Display of Xtended Services Platform (Xsp) file access uniform resource locators (URLs) on the web portal.

• Finer granularity and ease of use for file rebuilds.

• Adding of template tags for network conferencing and business trunking.

• Capability for web applications on the Xtended Services Platform to modify the templates.

Currently devices using the credentials as the only key to get a configuration file that have the same user name/password get the same device configuration even if, on the repository, there are two different configuration files. To remedy this, the Application Server now ensures the Device Profile authentication user name is unique to the Device Type when adding or modifying a Device Profile.

When adding new or modifying existing Device Profiles, the Application Server checks to ensure the Device user name is unique. If not, an error message is displayed indicating the Device Profile user name already exists.

When upgrading, the Application Server checks to ensure all Device Profile user names are unique within the same Device Profile type. If not, the upgrade fails and provides a list of Device Profile user names that are not unique. The list is provided in a comma-separated values (.csv) file.

In Device Management deployments, the file repository is centralized. A single cluster of Profile Servers is fronted by multiple Xtended Services Platform (Xsp) servers. On each file download, the content is streamed from the Profile Server through the Xtended Services Platform server and on to the requesting device. Given a large number of devices requesting large files, (for example, firmware files), network contention can occur on the Profile Server.

This feature alleviates this contention by introducing a caching mechanism on the Xtended Services Platform server. When cached in the Device Management web application on the Xtended Services Platform server, frequently requested but seldom modified files are served from the local cache instead of being streamed from the file repository.

Device Management: This feature enhances Cisco BroadWorks IP device configuration management by adding a richer set of configuration tags and capabilities. This enhancement introduces the concept of “dynamic” versus “static” configuration tags.

Dynamic tags are tags that are replaced with contextual values based on the line profiles associated with the device.

Static tags are tags that are created and set to an explicit value by the administrator. Static tags make it easy to administer a set of configuration attributes that are common across two or more device types.

This feature also adds the concept of a “Configuration Tag Set”, making it easy to group static tags together and apply them to a device.

This Application Server/Provisioning Server feature enhances Device Management by introducing a new user-assignable service called Visual Device Management, which adds the support of the Leonid System’s Loki Visual Device Management (VDM) portal to the CommPilot web portal.

In this enhancement, the Cisco BroadWorks administrator (group and above) is provided with a link to access the visual provisioning of a device associated with a Cisco user through the Loki VDM portal.

Note that this feature is applicable to Leonid System’s Loki Visual Device Management (VDM) portal, version 9285-2.26 and above.

This feature enhances the accounting of several multi-leg services to provide additional information in call detail records (CDRs).

The services include Call Park, Call Park Retrieve, Call Pickup, and Directed Call Pickup.

This feature adds support for allowing handover from the circuit-switched network to the packet-switched network for devices supporting Dual Radio Voice Call Continuity (DRVCC).

To handle this capability, this feature enhances the Service Centralization and Continuity (SCC) by adding missing 3GPP and 3GPP2 specifications related to Voice Call Continuity (VCC).

This feature provides the ability to perform domain-based routing for configurable types of calls. Based on the provisioned domain and user prefixes, the calls originated by Cisco BroadWorks users can be routed differently by the network elements (for example,

S-CSCF) to allow, for example, least-cost routing via Private Branch Exchanges (PBXs).

Cisco BroadWorks in XS mode depends on database change notifications from the Database Server (DBS) for normal operation.

The current approach where the database notifications are generated by the Oracle database and distributed to the interested components by the Cisco BroadWorks persistency framework has a number of drawbacks.

This feature provides an alternative approach with notifications using a standard Structured Query Language (SQL) interface and it does not require proprietary database mechanisms.

This feature enhances Device Management (DM) on the Execution Server by adding support for the Polycom Services license.

In addition, this feature brings the Device Management on the Execution Server at par with the Application Server for functionality.

This feature includes the following enhancements to the Rf interface:

• Support for sending additional information to better align with 3rd Generation Partnership Project (3GPP) specifications

• Support for making ACR[Event] optional

• Support for the Private User Identity in the User-Name attribute-value pair (AVP)

• Support for the custom vendor-IDs

This feature also ports the Per-Device Charging functionality from the Application Server to the Execution Server.

This feature provides the following enhancements to the Ro interface:

• Support for Re-Auth-Request (RAR) and Re-Auth-Answer (RAA) message

• Support for Abort-Session-Request (ASR) and Abort-Session-Answer (ASA) message

• Support for emergency call notification

• Support for user location change notification

• Support for final unit redirection

• Sending additional information to better align with 3rd Generation Partnership Project (3GPP) specifications

This feature enhances the Shared Call Appearance (SCA) service to allow the user to have simultaneous calls using their primary device and one secondary location.

This feature also modifies the Execution Server to support the Call Decline Device Policy feature that is already supported on the Application Server.

In certain deployments, for Voice over WiFi (VoWiFi) calls, the P-Access-Network-Info (PANI) header in the incoming Session Initiation Protocol (SIP) INVITE message may contain two access types: one for LTE cell-id and another for WLAN node-id. This follows the allowed syntax of the P-Access-Network-Info header field described in RFC 7315. The original access type is identified by the orig-access-type parameter in the PANI.

Prior to this feature, all contents of the PANI header were written directly into the Access-Network-Information attribute-value pair (AVP). This feature introduces a new mechanism to remove the whole access type (for example, 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=311480660418ebc601) and the orig-access-type parameter name from the PANI header when copying it into the Access-Network-Information AVP to keep only the “original” PANI. This removal is only made if the orig-access-type parameter is present in the PANI header.

This feature enhances the BroadWorks Anywhere service by implementing an Xtended Services Interface call-through functionality, originally introduced on the Application Server by the Mobility Service Enhancements feature with the expansion of BroadWorks Mobility Xtended Services Interface capabilities.

This enhancement provides the capability for BroadWorks Anywhere locations to use the Xtended Services Interface to obtain an IP Multimedia Routing Number (IMRN). This IMRN can then be used by the Cisco BroadWorks Execution Server to anchor the call to provide originating services to the mobile user represented by the BroadWorks Anywhere location.