Docstoc

BW FunctionalSummary

Document Sample
BW FunctionalSummary Powered By Docstoc
					BROADWORKS FUNCTIONAL SUMMARY
RELEASE 11
Version 1

BroadWorks® Guide

Copyright Notice
Copyright © 2004 BroadSoft, Inc. All rights reserved. Any technical documentation that is made available by BroadSoft, Inc. is proprietary and confidential and is considered the copyrighted work of BroadSoft, Inc. This publication is for distribution under BroadSoft non-disclosure agreement only. No part of this publication may be duplicated without the express written permission of BroadSoft, Inc. 220 Perry Parkway, Gaithersburg, MD 20877. BroadSoft reserves the right to make changes without prior notice.

Trademarks
BroadSoft® and BroadWorks® are registered trademarks of BroadSoft, Inc. Microsoft, MSN, Windows, and the Windows logo are registered trademarks of Microsoft Corporation. Other product names mentioned in this publication may be trademarks or registered trademarks of their respective companies and are hereby acknowledged. This document is printed in the United States of America.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 2 OF 93

Table of Contents
1 2 Introduction ............................................................................................................6 User Services .........................................................................................................7 Auto Attendant Immediate Extension Dialing................................................. 7 2.1.1 Description ............................................................................................. 7 2.2 Auto Attendant Dial by First Name ................................................................. 7 2.2.1 Description ............................................................................................. 7 2.3 Holiday Schedule for Auto Attendant.............................................................. 8 2.3.1 Description ............................................................................................. 8 2.4 Enhanced Business Hour Support ............................................................... 10 2.4.1 Description ........................................................................................... 10 2.5 Caller ID Restriction Override ....................................................................... 12 2.5.1 Description ........................................................................................... 12 2.6 Directed Call Pickup with Barge-in ............................................................... 13 2.6.1 Description ........................................................................................... 13 2.7 Auto Callback................................................................................................. 15 2.7.1 Description ........................................................................................... 15 2.8 Phone Status Monitoring............................................................................... 16 2.8.1 Description ........................................................................................... 16 2.9 User Category Service .................................................................................. 17 2.9.1 Description ........................................................................................... 17 2.10 Call Waiting .................................................................................................. 18 2.10.1 Description ......................................................................................... 18 2.11 Calling Line ID Delivery ............................................................................... 18 2.11.1 Description ......................................................................................... 18 2.12 Configurable Calling Line ID for Emergency Calls..................................... 19 2.12.1 Description ......................................................................................... 19 2.13 Lawful Intercept Punch-List Items............................................................... 20 2.13.1 Description ......................................................................................... 20 3 Group Services ....................................................................................................21 3.1 Department Music On Hold........................................................................... 21 3.1.1 Description ........................................................................................... 21 3.2 Large Enterprise Support .............................................................................. 21 3.2.1 Description ........................................................................................... 22 3.3 Originating Fully Restricted ........................................................................... 29 3.3.1 Description ........................................................................................... 29 3.4 Terminating Fully Restricted ......................................................................... 31 3.4.1 Description ........................................................................................... 31 4 Messaging Services ............................................................................................33 4.1 Callback Returns to Voice Mail..................................................................... 33
2O-BD5013-00 PAGE 3 OF 93

2.1

BROADWORKS FUNCTIONAL SUMMARY

4.1.1 Description ........................................................................................... 33 4.2 Send to VM Feature Access Code ............................................................... 34 4.2.1 Description ........................................................................................... 34 4.3 Third-Party Voice Mail Support Enhancements........................................... 34 4.3.1 Description ........................................................................................... 34 4.4 Voice Portal Calling ....................................................................................... 35 4.4.1 Description ........................................................................................... 35 5 Operations, Administration, and Maintenance ...............................................40 5.1 5.2 Call Capture and Trace Utility ....................................................................... 40 5.1.1 Description ........................................................................................... 40 Conferencing OAM Integration ..................................................................... 41 5.2.1 Web Portal Integration......................................................................... 41 5.2.2 Accounting Integration......................................................................... 41 5.2.3 Description ........................................................................................... 41 5.2.4 Bridge Provisioning Enhancements.................................................... 42 5.2.5 Conference Scheduling....................................................................... 44 5.2.6 Presentation Setup .............................................................................. 44 5.2.7 Ad-Hoc Conferencing .......................................................................... 45 5.2.8 Conference Call Control and Recording............................................. 45 5.2.9 Presentation Viewing and Moderating................................................ 45 5.2.10 Audio Recording and Slide Show Playback..................................... 46 5.2.11 Accounting Integration....................................................................... 47 OSS Enhancements...................................................................................... 48 5.3.1 Description ........................................................................................... 48 Performance Enhancements for Troubleshooting....................................... 49 5.4.1 Description ........................................................................................... 49 5.4.2 Memory Monitoring.............................................................................. 50 Service Pack Migration Tools ....................................................................... 51 5.5.1 Description ........................................................................................... 51 Call Client Hold Integration............................................................................ 53 6.1.1 Description ........................................................................................... 53 Calling Line ID Delivery Enhancements....................................................... 55 6.2.1 Description ........................................................................................... 55 Configurable Ringing Timeout ...................................................................... 56 Element Management System ..................................................................... 56 6.4.1 Description ........................................................................................... 57 G.729 Codec Support.................................................................................... 61 6.5.1 Description ........................................................................................... 61 International Call Screening .......................................................................... 61 6.6.1 Description ........................................................................................... 61 Line/Port Domain Scoping ............................................................................ 63
2O-BD5013-00 PAGE 4 OF 93

5.3 5.4

5.5 6

System ..................................................................................................................53 6.1 6.2 6.3 6.4 6.5 6.6 6.7

BROADWORKS FUNCTIONAL SUMMARY

6.7.1 Description ........................................................................................... 64 6.8 Live Audio Support ........................................................................................ 66 6.8.1 Passive Music On Hold ....................................................................... 66 6.8.2 Active Music On Hold .......................................................................... 66 6.8.3 Description ........................................................................................... 66 6.8.4 Analog Audio Port................................................................................ 66 6.8.5 Supported Codecs............................................................................... 67 6.9 Media Server Access Control and Performance Management .................. 68 6.9.1 Description ........................................................................................... 68 6.10 Multiple Country Code Support................................................................... 69 6.10.1 Description ......................................................................................... 69 6.11 Multiple Language Support ......................................................................... 69 6.11.1 Description ......................................................................................... 69 6.12 No-Charge Treatments................................................................................ 74 6.12.1 Description ......................................................................................... 74 6.13 Configurable Tone Upon Disconnect.......................................................... 75 6.14 Open Client Interface Proxy ........................................................................ 75 6.14.1 Description ......................................................................................... 75 6.15 Outgoing/Incoming OTG ............................................................................. 78 6.15.1 Description ......................................................................................... 78 6.16 Per-Enterprise LCA...................................................................................... 80 6.16.1 Description ......................................................................................... 80 6.17 Pre-Typing Policy......................................................................................... 81 6.17.1 Description ......................................................................................... 81 6.18 Ring Period................................................................................................... 83 6.19 SIP Enhancements...................................................................................... 83 6.19.1 Description ......................................................................................... 83 6.20 SIP as Media Server Control Protocol........................................................ 84 6.20.1 Description ......................................................................................... 84 6.21 Solaris 9 Support.......................................................................................... 90 6.21.1 Description ......................................................................................... 90 6.22 Unregistered Endpoint Announcement ...................................................... 93 6.22.1 Description ......................................................................................... 93

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 5 OF 93

1

Introduction
This document describes new capabilities added for the Release 11 BroadWorks platform. The changes cover the following areas:
!

User services – These changes introduce new user services or enhance existing user services. Group services – These changes include new group services, enhancements to existing group services, and enhancements to the management capabilities of the group administrator. Messaging services – These changes include new functionality and changes to the existing messaging capabilities of BroadWorks. Operations, administration, and maintenance – These changes introduce new capabilities in the areas of faults, performance, security, provisioning, configuration, and accounting. System – These changes introduce new capabilities and enhance the existing functionality of the BroadWorks system in the areas of protocols, components, and internationalization.

!

!

!

!

BroadSoft can provide in-depth information on any of these items upon request.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 6 OF 93

2

User Services

2.1

Auto Attendant Immediate Extension Dialing
Feature ID(s): 13120 The group administrator can allow callers to dial an extension from the first-level menu. In the current Auto Attendant, the caller can only dial an extension from a second-level menu. 2.1.1 Description In Release 10, the Auto Attendant supported extension dialing. However, extension dialing is only possible as a submenu option. When extension dialing is enabled, a caller hears a message similar to this: “If you know your party’s extension, press 1”. If the caller presses 1, then the caller hears another announcement: “Please dial the extension for the party you are trying to reach”. In Release 11, a new option is added to speed up the Auto Attendant interface for extension dialing. The “First-Level Extension Dialing” option allows the administrator to enable or disable immediate extension dialing for a given Auto Attendant. When the feature is enabled, the caller to the Auto Attendant can dial the desired extension immediately from the first level of the Auto Attendant menu without having to first navigate to the second level.

2.2

Auto Attendant Dial by First Name
Feature ID(s): 13121 The group administrator can allow name dialing from a combined first name and last name list in addition to the current last name and first name list. 2.2.1 Description Currently, the BroadWorks Auto Attendant supports name dialing. The list of names is constructed by concatenating the last name and first name for each person in the directory. Therefore, a caller can dial “Doe, John”, but not “John Doe”. In this release, this capability is extended to support First-Name and Last-Name Dialing in addition to Last-Name and First-Name Dialing. This feature is optional and can be enabled and disabled by the administrator. When enabled, a caller can dial “Doe, John,” or “John Doe”.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 7 OF 93

2.3

Holiday Schedule for Auto Attendant
Feature ID(s): 13122 Currently Auto Attendant Business Hours are defined based on a generic week and company holidays must be manually set. This task allows a group administrator to define the company holidays and assign those holidays to Auto Attendants. Those Auto Attendants then perform the after-hour logic on holidays. 2.3.1 Description A group administrator can define a holiday schedule that can be associated with an Auto Attendant. More than one holiday schedule can be created. Each holiday schedule can be a maximum of 20 dates or date ranges. 2.3.1.1 Holiday Entry

A group administrator is able to create holiday schedules. There are no limits to the number of schedules that can be created (U.S. and Canadian holidays). Each schedule can have zero to 20 dates or date ranges defined as a holiday.

•

Figure 1 Holiday Schedule Page

2.3.1.2

Holiday Calendar Entry

A new calendar element is introduced for date entry. The element is composed of two controls, a text box for a date entry and a calendar pop-up used to select a date. The entry of the date supports two formats, American and European. The format shown to a user or administrator is automatically determined by their preferred language.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 8 OF 93

•

Figure 2 Calendar Pop-up

2.3.1.3

Auto Attendant

Once defined in the group profile, holiday schedules can be assigned to Auto Attendants from the Auto Attendant main configuration page. During the holiday schedule dates, the Auto Attendant automatically provides the after-hours menu to callers.

•

Figure 3 Auto Attendant Add Page

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 9 OF 93

2.4

Enhanced Business Hour Support
Feature ID(s): 13580 Currently Auto Attendant Business Hours are defined by a single time range and the selection of days. This does not allow many companies to define the business hours they use. This feature fixes these issues by supporting business hours that have multiple time ranges (for example, 9 A.M. to 12 P.M. and 1 P.M. to 5 P.M.) and support different hours on different days. The time entry is also extended to the criteria for user services such as Call Notify, Priority Alert, and Selective Acceptance/Rejection/Forward. 2.4.1 Description A group administrator can define time schedules for their group. Multiple time schedules can be created. Time schedules can consist of up to 20 date and time ranges per week. Time schedules can be business hours, call center hours, after business hours, and so on. Time schedules created by the group administrator are visible to groups and users. A user can also create time schedules that only the user can view and use.

•

Figure 4 Time Schedule Page

The Auto Attendant is enhanced to allow assigning a time schedule that determines the Auto Attendant’s business hours. As a result, the existing Auto Attendant scheduling is no longer necessary and is removed.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 10 OF 93

•

Figure 5 Auto Attendant Add Page

Screening services have also been enhanced to make use of time schedules defined for the group and user. As a result, the existing selective service scheduling is no longer necessary and is removed.

•

Figure 6 Call Forwarding Selective Add Page

The use of the time schedule still allows the Every Day, All the Time options, which override the selected time schedule.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 11 OF 93

2.5

Caller ID Restriction Override
Feature ID(s): 10560 Calling Line ID Blocking Override (CLIO) allows a user to override the calling line identity presentation restrictions and therefore always receive the calling line identity at their customer premises equipment (CPE), if available. In other words, the user who activates this option always receives the calling line identity if available, regardless of whether or not the calling line identity is blocked. The user never receives a calling line identity indicating “private”. This service is configured via the CommPilot web portal. 2.5.1 Description CLIO is offered as an override to Calling Line ID Delivery Blocking. When activated by the user, this service ignores the presentation indicator and delivers the calling line ID to the user if it is available (both name and number). The user activates and deactivates the service through the CommPilot Personal web interface. It should be noted that the caller information provided to the CLIO user is bound to what BroadWorks receives from the calling party and from other peripheral systems. For example, if the caller’s name is blocked in the CNAM database and cannot be obtained by BroadWorks, the CLIO user only receives the calling number. Similarly, if the Caller ID Enhancement service is activated and the incoming call is overseas, from a payphone or from an operator, the CLIO user only receives the corresponding indication instead of the caller ID. When this service is active, all Caller ID-based services behave as if the Caller ID was present, regardless of the presentation indicator, unless the call is Anonymous, as follows:
! ! !

Anonymous Caller Rejection lets private calls through Screening services apply regardless of the presentation indicator The Call Manager’s incoming call log shows all incoming Caller IDs

This service is only overridden by the CLID Delivery (both External and Internal) service. If the Caller ID Delivery service is not active for a user, then CLIO has no impact.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 12 OF 93

2.6

Directed Call Pickup with Barge-in
Feature ID(s): 10562, 13394 Directed Call Pickup with Barge-in (DPUBI) allows users to dial a feature access code (FAC) followed by an extension to pick up (answer) a call directed to another user in the same customer group, or barge-in on the call if the call was already answered. When a barge-in occurs, a three-way call is established between the parties with the DPUBI user as the controller. Note that the pickup portion of this feature is identical to the existing Directed Call Pickup (DPU) feature. DPUBI is a completely separate service from DPU, however, the barge-in capability is added, and it has its own unique FAC. Throughout this section, the following terms are used:
! ! !

DPUBI user – the user invoking the DPUBI service Picked-up user – the user whose extension has been selected by the DPUBI user Other party – the party that is connected with the picked-up user before the DPUBI attempt takes place

2.6.1 Description 2.6.1.1 Provisioning

The DPUBI service is a user service. Therefore, it can be authorized to service providers and groups, and can be assigned to users. The only configurable option for the DPUBI user service is the barge-in warning tone. This option controls whether a warning tone is given to the picked up user when a barge-in occurs. The warning tone option is only configurable by administrators. Users can view the current warning tone setting, but cannot change it. At the group level, the DPUBI FAC can be configured by administrators. It defaults to *33, but can be changed to any valid, available FAC. 2.6.1.2 Service Invocation

A user invokes the DPUBI service by dialing the DPUBI FAC. If the user does not supply an extension when dialing the DPUBI FAC, then they are given a stutter dial tone so that they can enter the extension to be picked up. If an invalid extension is entered (for example, an extension that does not exist in the group, too few digits, and so on), then the DPUBI user is given reorder tone. If a valid extension is entered, then a pickup or barge-in is attempted as described in the following sections. Note that if the picked-up user has no calls or more than one call, then the DPUBI user is given a reorder tone. A pickup or barge-in can occur only when the picked-up user has exactly one call.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 13 OF 93

2.6.1.3

Pickup

A pickup is triggered by the DPUBI service when the picked-up user is alerted for a single, terminating call. When a pickup occurs, the DPUBI user and the other party are connected to one another, and the picked-up user is released. The DPUBI service pickup functionality is identical to the DPU service. 2.6.1.4 Barge-in

A barge-in is triggered by the DPUBI service when the picked-up user has a single, answered call. The barge-in occurs regardless of whether the picked-up user’s call was originating or terminating, and regardless of its current state (for example, active, held, and so on). When a barge-in occurs and the user’s warning tone option is enabled, the picked-up user is given the barge-in warning tone (one second of 440 Hz followed by 50 ms of silence). The other party is put on hold while the picked-up user is receiving the warning tone. Note that the picked-up user is not given the warning tone if they have put the call on hold. Once the warning tone has finished (or immediately if the user’s warning tone option is disabled), a three-way call is established with the DPUBI user as the controller. The DPUBI user now has a call with the picked-up user and with the other party. The pickedup user and the other party now have a call with the DPUBI user instead of with each other. If the DPUBI user has the Flash Three-Way Call service assigned and flashes while the three-way call for the barge-in is present, then the other party is dropped from the threeway call. If the DPUBI user does not have the Flash Three-Way Call service and flashes, then the flash is ignored according to the existing flash service rules. If the DPUBI user has the Flash Transfer service assigned and hangs up (goes on-hook) while the three-way call for the barge-in is present, then the picked-up user and the other party are transferred together. If the DPUBI user does not have the Flash Transfer service assigned and hangs up, the picked-up user and the other party are released. 2.6.1.5 Barge-in Exempt

When a user has the Barge-in Exempt service enabled, the user’s calls cannot be barged in on by another user using the DPUBI service. If a user attempts to use DPUBI to bargein, then the barge-in is rejected and the user receives the reorder tone. If the Barge-in Exempt service is disabled, then DPUBI barge-in attempts are allowed as usual. If a user has the Barge-in Exempt service enabled but has a single incoming, alerting call then the call can be picked up by another user using the DPUBI service. Barge-in Exempt does not block pickup attempts.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 14 OF 93

2.7

Auto Callback
Feature ID(s): 10714 The Automatic Callback (ACB) service allows users to monitor a busy party and automatically establish a call when the busy party becomes idle. Upon reaching a valid ACB busy condition, the user hears an announcement asking if they would like to monitor the line and be called back when it is idle. To activate ACB the subscriber enters the digit when prompted then goes on hook. As soon as the called party becomes idle again, ACB attempts to re-establish the call between the subscriber and the previous busy party. The ACB service can only be activated against a destination within the same group. ACB is authorized and provisioned as a subscriber service, and can be enabled and disabled by the subscriber. 2.7.1 Description Automatic Callback is an outgoing call feature that allows a subscriber to place a call to another subscriber in the same group. If the called subscriber is busy, the call originator can activate Automatic Callback to be notified when the called subscriber is idle. When notified, a new call setup attempt to the idle subscriber is initiated automatically and the originating subscriber is not required to redial the phone number. The new call attempt is treated as an originating call attempt; it could receive busy treatment or be redirected. For the new call setup to be attempted both parties must be available. A terminating subscriber is considered busy, or unavailable if they cannot receive a call at their primary location. This means that if a terminating feature redirects the call and the new location is busy, ACB is not activated. ACB is also disabled if the call is handled by any of the following terminating services, Selective Call Rejection and Selective Call Acceptance, but is not limited to these service interactions. When a subscriber originates a call to another subscriber in the group, if the called party is unable to receive the call because of a valid ACB busy condition, a prompt is played giving the originator the opportunity to activate ACB (for example, callers hear the message: The line you are calling is busy. Press 1 if you would like to be notified when the line is available). After activating ACB, the subscriber goes on hook and is notified with special ringing when both parties are idle. If the user answers special ringing, call setup is automatically initiated toward the other party. A subscriber that has activated ACB can also deactivate all outstanding ACB requests. Entering the ACB deactivation Feature Access Code cancels all outstanding requests by that subscriber. ACB has several operating parameters that are configured at the system:
!

Monitor minutes: The amount of time to camp-out on the busy line, waiting for it to become idle. (The default is 30 minutes and the range is 5 to 120 minutes.) Retry originator minutes: The amount of time to wait before re-trying a busy Automatic Callback originator (the owner of the ACB session). (The default is 5 minutes and the range is 1 to 15 minutes.) Maximum sessions: The total number of outstanding ACB sessions for one subscriber. (The default is 5 and the range is from 1 to 30 sessions.)

!

!

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 15 OF 93

!

Maximum retry rings: The maximum number of rings when alerting the originator that the terminator is available. (The default is 6 and the range is from 3 to 8.) Maximum time to retry: The total amount of time to alert an originator that has been busy (unavailable). The amount of time ACB tries to alert a busy originator. (The default is 180 minutes and the range is from 180 to 360 minutes.)

!

2.8

Phone Status Monitoring
Feature ID(s): 11914 Currently, in order to monitor a user using the CAP interface, a user must have the Attendant Console feature assigned because this is how monitored users are configured. In this release, a new user feature called Phone Status Monitoring is added, which is used to configure the list of monitored users. It can be assigned to a user independently from the Attendant Console feature. Otherwise, the Attendant Console feature maintains its current functionality. This allows the monitoring function to be decoupled from the BroadWorks Attendant Console so that it is available to third-party clients. 2.8.1 Description This activity introduces a new Phone Monitoring feature that can be assigned to a user. When assigned, by default there are no users in the monitored user’s list. Once the list is populated, the same list can be used by the Attendant Console client, client license applications, or any other third-party attendant console application that communicates with the Application Server via the OCI interface. All other users in the same group can be added to or removed from the list of monitored users. The available users can be filtered based on the users’ department. All other configurations that are part of the Attendant Console feature remain with the Attendant Console including the following:
! ! ! !

Flag to indicate if the Attendant Console is launched on login Flag to allow user to configure call details Flag to allow user to view call details Ability to configure display columns

For third-party applications using the Attendant Console functionality via OCI, the user must have both the Client Call Control and the Phone Status Monitoring features assigned. For client license applications using the Attendant Console functionality via OCI, the user must have the corresponding Client License feature and the Phone Status Monitoring feature assigned. For the user who is using the BroadSoft Attendant Console client, the user must have both the Attendant Console and the Phone Status Monitoring features assigned. For users with the Attendant Console feature currently assigned, the new Phone Status Monitoring feature is automatically assigned to the user through the upgrade process.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 16 OF 93

2.9

User Category Service
Feature ID(s): 10767 The Calling Party Category service allows a category to be associated with a subscriber. The category is included in the signaling for all outgoing calls. It is used by as softswitch or switching system for call routing, and is also used by operator services system to determine the allowed policies for a subscriber. 2.9.1 Description The Calling Party Category (CPC) service allows a category to be associated with a subscriber. The category is included in the signaling for all outgoing calls. It is used by a softswitch or switching system for call routing and is also used by an operator services system to determine the allowed policies for a subscriber. The system administrator, service provider administrator, and group administrator can assign this feature to users and configure the category of users. The user can only view current configuration of the feature. Depending on the trunking device BroadWorks is interacting with for a given call, BroadWorks automatically populates the user category in the appropriate format so it can be passed to that trunking device (either the CPC or ISUP-OLI). BroadWorks supports the following two Calling Party Category formats:
Calling Party Category Ordinary Payphone Prison Hotel Hospital Special Description User has no special characteristics User represents a smart payphone User is from a prison User is from a hotel or motel User is from a hospital User should always be routed to an operator service system

The category is only included when the call is routed to a PSTN terminating party. During a call forward or call transfer to another subscriber by the terminating party in a different group, and when the terminating party is assigned a category, the category of the terminating party is substituted in the SIP INVITE to the terminating party.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 17 OF 93

2.10 Call Waiting
Feature ID(s): 12679 Currently, call waiting is implicitly offered to any user:
! ! ! !

Assigned the Call Manager Assigned the Client Call Control service With an endpoint on an intelligent device or a trunking device Assigned the Flash Call Waiting service

The purpose of this feature is to create a Call Waiting service that provides users with the same call waiting functionality but which must be explicitly assigned to make the functionality available. 2.10.1 Description This activity consolidates call waiting functionality under a new user service called Call Waiting, which must be explicitly assigned to users to provide call waiting functionality. This enhancement allows service providers to license and authorize call waiting functionality explicitly, thus allowing them to sell the service instead of having the functionality automatically provided to users based on their endpoint and other factors. After upgrading to this release, users who had call waiting functionality via other mechanisms are automatically provided with the new Call Waiting service so their service set remains unchanged. Only their CommPilot Personal portal is modified to expose the new Call Waiting service.

2.11 Calling Line ID Delivery
Feature ID(s): 12680 Currently, caller ID is delivered by default to BroadWorks users when available. This service makes Calling Line ID Delivery a service that can be authorized and assigned so that an operator can sell the service. 2.11.1 Description The Calling Line ID Delivery service is divided into two features: External Calling Line ID Delivery and Internal Calling Line ID Delivery. 2.11.1.1 External Calling Line ID Delivery This feature allows BroadWorks subscribers to view the caller ID information of another user in a different group. This feature also applies to intra-group calls using the Network Server. Once this service is assigned, the user can disable or enable the service. 2.11.1.2 Internal Calling Line Delivery This feature allows BroadWorks subscribers to view the caller ID information of another user within the same group. Once the service is assigned, the user has the option to disable or enable the service.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 18 OF 93

2.12 Configurable Calling Line ID for Emergency Calls
Feature ID(s): 13613 This activity changes the Release 10 Configurable Calling Line ID functionality. Currently Configurable Calling Line ID is not used for emergency calls. This feature allows use of the configurable user calling line ID (CLID) for emergency calls. The requirements to enable the CLI feature have changed. The system parameter that is used to enable or disable the feature must accommodate the following conditions:
! ! ! !

Enable the use of configurable CLID for all calls Enable the use of configurable CLID for all calls except emergency calls Enable the use of configurable CLID for emergency calls only Disable the use of configurable CLID for all calls

2.12.1 Description For the Configurable Calling Line ID feature, the following Calling Line ID delivery rules apply:
!

For non-emergency calls, the precedence for calling line ID delivery is as follows: − − The group CLID (if configured and enabled) always has precedence over configurable user CLID as well as the user’s phone number The configurable user CLID always has precedence over the user’s phone number when the configurable CLID is enabled for “All calls” or for “All except emergency calls” The configurable user CLID is not used when the configurable CLID is enabled for “Emergency only calls” The group CLID (if configured and enabled) has precedence over configurable user CLID only when the configurable CLID is disabled or enabled for “All except emergency calls” The configurable user CLID has precedence over the group CLID when the configurable CLID is enabled for “All calls” or for “Emergency only calls”

−
!

For emergency calls, the precedence for calling line ID delivery is as follows: −

−

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 19 OF 93

2.13 Lawful Intercept Punch-List Items
Feature ID(s): 12975, 12976 This feature addresses the following Communication Assistance for the Law Enforcement Act (CALEA) items:
!

Subject-initiated signaling — the SubjectSignal message is introduced and sent to the lawful enforcement agency (LEA) or mediation device’s (MD) collection function. Dialed-digit extraction — the DialedDigitExtraction message is introduced and sent to the LEA or MD’s collection function if digits are dialed by the subject under surveillance once a call is connected.

!

2.13.1 Description This feature enhances the Lawful Intercept administrative function and implements the SubjectSignal and DialedDigitExtraction CDC messages required to address some of the CALEA punch list items. 2.13.1.1 Lawful Intercept Administration The administrative function of Lawful Intercept is modified to allow a toggle for the new functionality on a per surveillance basis. 2.13.1.2 SubjectSignal The SubjectSignal CDC message captures any signal that is initiated by the intercept subject. In the context of BroadWorks, the following signal is detected and reported: Flash – The user flashes 1) to put a call on hold and originate a second call, 2) to answer a second incoming call and toggle between two calls, 3) to transfer a consultation call or 4) to conference two calls together. When a surveillance subject flashes, the appropriate SubjectSignal is sent to the LEA. 2.13.1.3 DialedDigitExtraction The DialedDigitExtraction CDC message captures the digits dialed by the subject under surveillance once the call is connected. Extracted digits are reported individually in separate DialedDigitExtraction messages. For a typical call under surveillance where media monitoring is enabled, a pair of repeaters is set up on the Media Server and the media stream between the subject under surveillance and the other party is hair-pinned back to the Media Server repeaters. Each repeater works in a particular direction and repeats the received media to the other party. The Media Server also repeats the intercepted media streams to the LEA. If Dialed Digit Extraction is enabled for that surveillance, the media stream in the transmit direction is also repeated to a Media Server IVR that reports all the dialed digits to the Application Server. Note that although the Dialed Digit Extraction capability relies on the setup of repeaters in the media path between the subject and the other party, media monitoring does not need to be enabled for dialed digit extraction to be active on a call. If media monitoring is disabled and Dialed Digit Extraction is enabled, then the media stream between the subject under surveillance and the other party is hair-pinned back to the Media Server repeaters, but the intercepted media is not transmitted to the LEA.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 20 OF 93

3

Group Services

3.1

Department Music On Hold
Feature ID(s): 13732 This feature allows a Music-On-Hold (MOH) audio source to be configured on a department basis. When assigned to a department, the audio source applies to all calls held or parked by users of that department. If no audio source is specified for the department, the group-defined audio source is used by default. This new functionality is for large or distributed enterprises with many departments or many remote departments for which a local audio source is required. 3.1.1 Description This activity enhances the existing group MOH service providing a separate music-on-hold audio source to be configured on a per-department basis. The per-department audio source is optional, and departments without their own audio source make use of the group-defined audio source by default, as usual. Once a group administrator allows a department to use its own audio source, this audio source can be configured by the department administrator. If the department MOH is defined, but Park or Hold is not enabled, the caller does not hear MOH. In this case, the default, group-defined MOH is not used.

3.2

Large Enterprise Support
Feature ID(s): 13772, 13429, 13768, 13769, 13770 This activity adds an Enterprise layer to the BroadWorks provisioning model, as shown in Figure 7 Enterprise Layer. This layer allows BroadSoft customers to better administer and manage large multi-site enterprises. Prior to this release, carriers using BroadWorks have used the BroadWorks service provider to represent a large enterprise and a BroadWorks group to represent a site. As of this release, instead of using a service provider to represent an enterprise, the new Enterprise layer can be used. This layer resides in parallel with service providers; therefore a system administrator can create service providers and/or enterprises. Each is administered separately.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 21 OF 93

S ys te m

S e r v ic e P r o v id e r (s )

E n te r p r is e (s )

G r o u p (s )

G r o u p (s )

U s e r (s )

U s e r (s )

•

Figure 7 Enterprise Layer

3.2.1 Description 3.2.1.1 Introducing the Enterprise

The concept of Enterprises is added to the Application Server. An enterprise should be used when a company has multiple sites or heavily geographically distributed users. The Application Server models an Enterprise as a specific type of service provider. All the capabilities of the service providers are available to the Enterprise. A system provider now sees a list of service providers and a list of enterprises. The existing service provider layer remains unchanged. The web interface is enhanced to exhibit the enterprise at the enterprise, sites, and user levels. 3.2.1.2 Enterprise Creation Wizard

A new wizard is provided to assist the administrator in creating a new enterprise on the Application Server. The first step is the creation of the enterprise itself along with the basic enterprise profile:

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 22 OF 93

•

Figure 8 Enterprise Setup Step 1 of 4 Page

The second step is to add administrator(s) to the enterprise. These administrators carry out the daily management tasks related to the enterprise. One or more administrators can be created in this step.

•

Figure 9 Enterprise Setup Step 2 of 4 Page

The next step is to authorize the services that can be further assigned to sites making up the enterprise.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 23 OF 93

•

Figure 10 Enterprise Setup Step 3 of 4 Page

The last step is to authorize phone numbers and blocks of phone numbers to the enterprise. These phone numbers can be further assigned to the sites and then to the users.

•

Figure 11 Enterprise Setup Step 4 of 4 Page

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 24 OF 93

3.2.1.3

Enterprise Private Dialing

This capability is used to create a private dialing plan shared between multiple sites making up an enterprise on the Application Server. The enterprise dialing plan allows users of the enterprise to call one another using location codes and extensions instead of full phone numbers.

•

Figure 12 Voice VPN Page

From the main Enterprise Voice VPN page, the administrator can create new voice VPN entries (policies) that apply to the enterprise.

•

Figure 13 Voice VPN Add Page

When creating the sites (group), the administrator can assign location codes to each group that is used by enterprise users to make calls between sites using a private dialing plan and the previously configured VPN policies.
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 25 OF 93

All the enterprise private dialing changes and policies carried out by the administrator on the Application Server are automatically synchronized on the Network Server without administrator intervention. It should be noted however that the Network Server can be accessed directly by an enterprise administrator to provision the enterprise routing policies or to configure advanced routing policies, which are not exposed via the enterprise administrator portal on the Application Server.

•

Figure 14 Profile Page

3.2.1.4

Policies for Service Provider and Enterprise Administrators

Policies are added for the service provider and enterprise administrators similar to the policies that currently exist for group administrators. Enterprise profile access options are as follows:
!

Full access to modify the enterprise’s profile. This is the default, which is the same as it is today. Read-only access to the enterprise’s profile. The Enterprise Profile page is read-only. No access to the enterprise’s profile. The Enterprise Profile page is not shown.

! !

Group access options are as follows:
! !

Full access to groups. This is the default, which is the same as it is today. Restricted from adding or removing groups as follows: − − The Add and Add Wizard buttons are not shown on the Enterprise: Profile → Groups page. The Delete button is not shown on the Group: Profile → Profile page.
2O-BD5013-00 PAGE 26 OF 93

BROADWORKS FUNCTIONAL SUMMARY

!

No access to groups. The Enterprise: Profile → Groups option is not available on the Profile menu.

Administrator access options are as follows:
!

Full access and able to add, modify, and delete enterprise administrators. This is the default, the same as it is today. Read-only access to enterprise administrators. The Enterprise: Profile → Administrators list is read only. No access to enterprise administrators. The Enterprise: Profile → Administrators is not available from the Profile menu.

!

!

Device access options are as follows:
! !

Full access to devices. This is the default, the same as it is today. Read-only access to devices as follows: − − − The Enterprise: Resources → Devices page is a read-only list. The Group: Resources → Devices page is a read-only list. All device assignments are read only (user profile, shared call appearance, music on hold, and so on).

Domain options are as follows:
!

Assignable only. Domains can be assigned to groups and users, but new domains cannot be added and existing ones cannot be deleted Read and write access, which is the default. Domains can be viewed, added, deleted, and modified.

!

Phone number access is as follows:
! !

Full access to phone numbers. This is the default, the same as it is today. Read-only access to phone numbers − − The Group: Resources → Assign Numbers option is not shown on the Resources menu. All number assignments are read-only. Administrators cannot assign phone numbers to users or group services.

Service access options are as follows:
!

Full access to assign resources to the group or users. This is the default, the same as it is today. Read-only access to service assignments as follows: − − − Group: Resources → Services page is read-only similar to a group administrator’s view. Group assignment web pages are not shown, for example, Assign Group Services, New User Services Template, and Existing User Services. User assignment web page, Assign User Services, is not shown.

!

Service pack definition access options are as follows:

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 27 OF 93

!

Full access to add, modify, and delete service packs. This is the default, the same as it is today. No access to service pack definitions, as follows: − − Enterprise: Resources → Service Pack page is not shown. Enterprise: Utilities → Service Pack Migration page is not shown.

!

Web branding access options are as follows:
! !

Full access to web branding. This is the default, the same as it is today. No access to web branding as follows: − Enterprise: Utilities → Web Branding page is hidden. Priority Alert:

3.2.1.5

The BroadWorks Priority Alerting page currently has in the Calls From section, a radio button that is used to select “Any external phone number”. When this option is selected, then all calls received from outside the group use distinctive ringing, even if the caller is in the same enterprise. This behavior is modified by this enhancement.
!

If “Any external phone number” is selected, then the user should not receive distinctive ringing for any call originated within its enterprise (even if it is in a different group). If city-wide centrex (CWC) is active, and Priority Alerting is set to “Any external phone number”, then when a call is received from a PSTN number (and the caller is in the same CWC group), then the call does not receive distinctive ringing.

!

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 28 OF 93

3.3

Originating Fully Restricted
Feature ID(s): 12677 The Outgoing Calling Plan (OCP) service is enhanced to prevent users from reaching a location outside of their group. Currently, there is functionality that prevents a user from making direct calls to external parties. The new screening rules prevent users’ calls from being forwarded or transferred to external parties. When an outgoing call is denied based on these new rules, the user receives the applicable OCP treatment. This is similar to the Enhanced Outgoing Calling Plan (EOCP) service which applies only to direct calls and not to forwarded or transferred calls, however this enhancement does not imply EOCP processing for authorization code verification or transfer to a pre-defined number. The purpose of this enhancement is to set a user as being “OCP-Fully Restricted”, or “Originating-Fully Restricted” (OFR). An OCP-fully restricted user is one that:
!

is restricted from making outside calls (all call types are not allowed except for “group”) under the existing OCP/EOCP functionality. This functionality is already offered by BroadWorks. is restricted from transferring calls outside of his/her group. Again, this functionality is already offered by BroadWorks. is restricted by the Outgoing Calling Plan service from being forwarded or transferred to a party outside of his/her group. This is new functionality.

!

!

3.3.1 Description 3.3.1.1 Applicability of Enhancement

The configuration of the Outgoing Calling Plan is enhanced as follows:
Group – Originating Group – Fwd/Transfer is renamed to Group – Forwarding/Transferring Group – Being Forwarded/Transferred (new) User – Originating User – Fwd/Transfer is renamed to User – Forwarding/Transferring User – Being Forwarded/Transferred (new)

As opposed to the former categories, the sections “Being Forwarded/Transferred” (Group, User) do not make the distinction between different call types. Only the distinction between intra-group and extra-group is made, this is to implement the Originating Fully Restricted functionality. So, each of the newest sections contains two Boolean values:
!

Group — whether or not a user can be forwarded or transferred to an intra-group party. Outside group — whether or not a user can be forwarded or transferred to a party outside of the group. Any user in the same BroadWorks group as the reference user is obviously considered as an “inside group” party. This includes calls made between users of a same group that are hosted on different Application Servers, which can happen temporarily after a server failover. When the group of the reference user is assigned the City-Wide Centrex service, any user whose group is also assigned the City-Wide Centrex service is considered as an
2O-BD5013-00 PAGE 29 OF 93

!

Definition of “inside group” and “outside group” parties are as follows”
!

!

BROADWORKS FUNCTIONAL SUMMARY

“inside group” party. This possibly includes users hosted on different Application Servers, but assumes that the Applications Servers are interconnected through a network that passes along the GTD containing the CWCINFIE (CityWide Centrex Information IE).
!

All other cases are considered as being “outside group” parties. Scope of Applicability of the OCP-Restriction

3.3.1.2

An OCP fully restricted user cannot be forwarded or transferred outside of his/her group. This implies that any step of the chain of call forwards/transfers (as opposed to the effective terminating location only) is restricted to be inside the user’s group, or within the same City-Wide Centrex domain. 3.3.1.3 Behavior of Call Forwarding

When a caller attempts to place a call that implies an OCP-restricted location, the user hears the standard OCP-denial treatment: You are not able to make this call. Please contact your system administrator for assistance. Thank you. 3.3.1.4 Support for City-Wide Centrex

City-Wide Centrex is supported. In order to support this scenario, BroadWorks sets the “originating fully restricted” parameter in the CWCINFIE of the GTD that is passed along with the SIP messaging from the originator’s server to the terminator’s server. When the parameter is set to 1 (restrict), then the terminator is prevented from transferring or forwarding the originator outside of the City-Wide Centrex group. This restriction also applies after any transfer made inside of the City-Wide Centrex group. In order to implement this, BroadWorks sets the “Originating Full Restriction” flag. However, if the restricted user receives a call from a City-Wide Centrex location, then the user’s remote party can to transfer the user outside of the City-Wide Centrex group regardless of the OCP restriction of “being forwarded/transferred”. This limitation applies only to transfers, as forwarding is not applicable on a terminator. 3.3.1.5 Transfer

Any transfer of a BroadWorks user by a BroadWorks user of the same group is subject to the OCP validation. On a transfer failure:
!

the user who attempted the transfer is recalled (automatic recall because the user hung up while leaving another user on hold) the target of the transfer: − − stops ringing if the user did not answered is disconnected if the user answered is reconnected with the transferring user if the user answers is dropped otherwise Conferences

!

!

the transferred user: − −

3.3.1.6

Originating fully restricted users can end up being connected with a caller from outside through a conference initiated by a member of their group. However, if the conferencing party hangs up, each of the parties who remain on the call are subject to OCP validation. Users for whom the validation fails are dropped from the call.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 30 OF 93

3.4

Terminating Fully Restricted
Feature ID(s): 12678 The “calls from outside group” screening rules of the Incoming Calling Plan (ICP) service are enhanced to handle the distinction between: A. Allow calls from outside of the group. B. Partial — allow calls from outside of the group only if transferred by a group user. C. Block calls from outside of the group. The following table shows the mapping between the Release10 meaning of the “calls from outside group” option, and the meaning of the enhanced Release11 mapping.
Setting A B C Release 10 Option checked Option unchecked Not applicable Release 11 Option set to Y (yes) Option set to P (partial) Option set to N (no)

For a user, setting the “call from outside group” option to N does not allow incoming calls from callers outside of the group, no matter how the call got to the user. When an incoming call is denied by this new attribute, the caller receives the standard ICP denial announcement. The enhancement also provides support for ICP over City-Wide Centrex locations. This means that, for the purpose of ICP, any City-Wide Centrex call between different hosting Application Servers is considered to be an intra-group call. 3.4.1 Description The “calls from outside group” option of the ICP service is enhanced. From a two-value option (allow, block), it is changed to a three-value option (allowed, allowed if intra-group transferred, blocked). In the context of the present document, “ICP Fully Restricted” refers to a user for which the “calls from outside group” is set to “N” (no, or blocked) Any pre-answer transfer (deflection) made to an ICP-restricted user is subject to the new screening condition. Upon failure, the original caller hears a treatment, and the ICPrestricted user is not called. Any post-answer transfer made to an ICP-restricted user is screened. In this case, the call is never connected. 3.4.1.1 Conferences

An ICP-restricted user can be connected with a caller from outside through a conference initiated by a member of the same group (who is able to establish such a conference). However, if the conferencing party hangs up, the ICP-restricted user is also disconnected. 3.4.1.2 Interaction with Call Pickup

A fully restricted ICP user cannot pick up a call originated outside of the user’s group. This behavior also applies to various flavors of the Call Pickup service (Directed Call Pickup and Call Pickup with Barge-in).

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 31 OF 93

3.4.1.3

Call Park

A fully restricted ICP user cannot retrieve a call originated outside of the user’s group, regardless of whether or not the user who parked the call was the originator or the terminator of the call.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 32 OF 93

4

Messaging Services

4.1

Callback Returns to Voice Mail
Feature ID(s): 13537 This activity enhances the voice message callback functionality that allows a user to listen to a voice message and then press a key to call the sender back. Currently, if the user elects to call back the sender, then upon ending that call, the user is disconnected and has to re-dial into the voice portal to continue listening to or handling voice messages. 4.1.1 Description The “Initiate Call to Sender” option of the Play Messages menu is enhanced to allow the user to continue a Voice Portal session upon terminating the call to the sender. This enhancement is available regardless of whether the Voice Portal Calling service is assigned to the user and is enabled. The following diagram shows how this feature modifies the “Initiate call to sender” option of the Play Messages menu.

Play Messages
# - Save message 7 - Delete message 2 - Play or repeat message; skip envelope 4 - Return to previous message 5 - Play message envelope 6 - Move to next message 8 - Initiate call to sender 9 - Hear additional options * - Return to Voice Messaging main menu

Functions while Call Initiated to Sender
## - To cancel/terminate outgoing call and return to Play Messages menu

•

Figure 15 Callback Returns to Voice Mail

The user plays back messages and, for a given message, has the capability to initiate a call to the sender of that message. Upon selecting the “Initiate Call To Sender” option, a call is originated to the sender of the message. Once the call is terminated, the user is returned to the Play Messages menu and can resume listening to messages. For more details, refer to section 4.4 Voice Portal Calling.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 33 OF 93

4.2

Send to VM Feature Access Code
Feature ID(s): 11655 This new functionality introduces the capability for a user to transfer his/her remote party or parties to the voice mailbox of any user of his/her group, at anytime during a call, and without using the CommPilot Cal Manager. The target mailbox can be the user’s own mailbox. The transfer is done by entering a configurable FAC (feature access code) while the remote parties are on hold. 4.2.1 Description A new feature access code (FAC) is introduced. It is used only in consultative mode, with all connected calls put on hold. Then, from a new consultative call, the user dials the “Direct Voice Mail Transfer” FAC in order to initiate the transfer. A first-time user is guided by announcements that explain how to transfer the held party to the user’s mailbox, or to another’s mailbox. Power users can dial through, and perform the transfer without waiting for the prompts. With the new Direct Voice Mail Transfer functionality, a user can essentially achieve the same transfers to a voice mailbox as possible with the CommPilot Call Manager. The only exception to this is that a user can only do post-answer transfers to voice mail.

4.3

Third-Party Voice Mail Support Enhancements
Feature ID(s): 13819 This activity standardizes BroadWorks services to transparently support third-party voice mail. Currently, the voice portal requires the Voice Messaging Group feature to be assigned, which causes some undesirable options to show up on the web portal: the Voice Messaging Group Configuration page is present, and CommPilot Express has options that are only applicable to BroadWorks voice mail. This feature thus:
! !

Shows how to rename the Voice Messaging Group feature name if desired. Hides the BroadWorks voice mail-specific CommPilot Express parameters, as well as the Voice Messaging Group Configuration page.

4.3.1 Description 4.3.1.1 Simple Voice Portal Decoupling

There are two separate changes. First, the Voice Messaging Group service name, visible in the Service Provider and Group Authorization pages, as well as the Group Assign page, can be modified by the system provider (to Voice Portal Group for example). There is no development required for this, but this document explains how it can be achieved by modifying the appropriate localization file. Second, the Voice Messaging Group Configuration page is made visible but only if:
! !

The Voice Messaging Group feature is assigned to the group. The Voice Messaging User feature is authorized to the group or a service pack containing the Voice Messaging User feature is authorized to the group.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 34 OF 93

4.3.1.2

CommPilot Express Support for External Voicemail

These simple modifications to the CommPilot Express user configuration page involve:
!

Making the voice message e-mail notification visible in the “Busy” profile only if the Voice Messaging User feature is assigned to the user. Making the greeting selection (no-answer/unavailable) visible in the “Unavailable” profile only if the Voice Messaging User feature is assigned to the user, since a thirdparty voice mail system is not assured to properly support this distinction.

!

4.4

Voice Portal Calling
Feature ID(s): 10886 This feature enhances the CommPilot voice portal by allowing an authenticated user to originate calls. This feature is particularly useful for traveling users who already access the voice portal to retrieve voice messages and configure services. Traveling users typically access the voice portal using a toll-free number and this feature allows them to originate calls that eventually are charged against their account. For similar reasons, this feature can be useful for an employee working at home who needs to make long distance or international calls on behalf of the company. Dialing in to the voice portal first allows the subsequent long distance call to be charged to the company instead of the user’s home line. Once the voice portal authenticates the user, the user can make calls as if the calls originated from their usual location. This means that services such as Outgoing Calling Plan, Account/Authorization Code, and Voice VPN services apply on outgoing calls made from the voice portal. This also means that accounting records are generated against the user’s account. The user can make as many calls as desired. The user can either wait for the remote party to hang up, or enter an escape sequence to originate a new call from the voice portal. 4.4.1 Description The Voice Portal Calling (option number 6, called “Make Call”) is added as an option to the top-level menu of the voice portal. This option allows VP users to make a call as if calling from their desk phone. This option is available only if the Voice Portal Calling service is assigned to the user and it is enabled. The user accesses a web page to enable and disable the service. The following diagram shows the new menu option available from the Voice Portal main menu.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 35 OF 93

Voice Portal Main Menu
1 - Access Voice Messaging¹ 2 - Change CommPilot Express Profile¹ 3 - Record Personalized Name 4 - Change Call Forwarding Options¹ 6 - Make Call¹ 8 - Change Passcode 9 - Exit # - Repeat Main Menu

Functions while Call Originated
## - To cancel/terminate outgoing call and make another call

¹ Options for accessing these services are only given if assigned and enabled

•

Figure 16 Voice Portal Calling

After selecting the Make Call option, the user is presented with a prompt inviting to make a call as follows: Please enter the destination digits or press # to return to the Voice Portal Main Menu. While this prompt is playing, the user can:
1) 2)

Wait for the prompt to timeout, or enter the # without entering any digits. The user is returned to the Voice Portal main menu. Dial the destination phone number.

The destination phone number is validated against a digit collection map. If the digits entered are invalid and do not match any pattern specified in the digit map, then the digits are processed through translation and eventually receive an appropriate treatment. If the destination digits are valid, then a call is originated on behalf of the user. Once the call is terminated, the user is returned to the Digit Collection prompt and can originate another call. 4.4.1.1 Digit Collection

Digit collection for this feature is similar to digit collection for Flash Consultation or per-call Calling ID Blocking. While the user is presented with the Digit Collection prompt, the Media Server performs digit collection. The digit collection map configured for that user is sent to the Media Server. The digit collection map can be configured on a system-wide basis or a group-basis. Depending on the user’s group configuration, the appropriate digit collection map is retrieved and provided to the Media Server. The administrator should note that the system digit collection map allows extension dialing between users of the same group, but does not allow Voice VPN dialing between users of the same enterprise. If the Voice VPN service is assigned to the enterprise, this digit collection map should be modified to allow voice VPN dialing from the Voice Portal.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 36 OF 93

4.4.1.2

Call Origination

BroadWorks attempts to make the call to the specified destination. The call attempt typically results in one of the following conditions:
1)

Call reaches destination normally. Ringback is provided either locally by BroadWorks, or remotely by the far-end device. Upon answer, the VP user is connected with the called party. The calling ID for this call is transmitted as if the call had been originated from the user’s usual location.

2)

Call reaches a treatment. The treatment is provided either locally by BroadWorks (for example, translations fail, OCP service blocks call), or in-band from the PSTN.

The call is originated as if the call had been originated from the user’s normal location. This means that the user’s originating service profile is enabled for these types of calls. For example, OCP, Account/Authorization code applies for calls originated from the Voice Portal. Once the call is connected to a treatment or ringback, the following conditions allow the call to be terminated:
!

The called party hangs up and the far-end disconnect is propagated through the network back to BroadWorks. The treatment times out. For an in-band treatment, the far-end disconnect is propagated through the network back to BroadWorks. The user invokes the “Terminate-Call” function. For more details about the “Terminate-Call” function, refer to section 4.4.1.3Terminate-Call Function. The user simply hangs up.

!

!

!

Calls originated by the Voice Portal on behalf of the user generate an accounting record in the same way as if the call had been originated from the user’s primary location. A service invocation flag allows the billing system to distinguish calls originated by the Voice Portal from calls originated at the user’s usual location(s)1. Calls originated by the Voice Portal on behalf of the user are treated independently from calls originated from the user’s usual location(s) or using the CommPilot Call Manager.
!

Whether a user is busy on a call originated from the Voice Portal or not, incoming calls to that user are delivered to the user’s usual location(s). Whether a user is busy on a call originated from the Voice Portal or not, calls can still be originated from the user’s usual location(s). The CommPilot Call Manager is not updated with calls originated from the Voice Portal. Users cannot use the CommPilot Call Manager to control calls originated from the Voice Portal Terminate-Call Function

!

!

4.4.1.3

The Terminate-Call function allows a user to dial an escape sequence at any time during the call and terminate a call to return to the current operation. That is, for the “Make Call” option, the user is prompted to make another call. For the “Initiate Call To Sender” option, the user returns to the Play Messages menu. Prior to the actual call origination, an instruction prompt is played to the VP user if the terminate-call function is available. The instruction prompt is played only once per context during a VP session. This means that if a VP user originates successive calls using the
The user’s usual location(s) is meant to describe the user’s primary or alternate locations. When other services are active on the user’s account, this can also mean the forwarded-to location or the remote location. BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 37 OF 93
1

“Make Call” option, then the instruction prompt is played only prior to the first call origination. If, during the same session, the VP user invokes the “Initiate Call To Sender” option multiple times, then the instruction prompt is played prior to the first call origination. The instruction prompt is not played prior to the subsequent call originations in that context. The instruction prompt is: At any time during the call, press ## to return to the Voice Portal. The Terminate-Call function depends on the repeater service of the Media Server. Upon initiating a call from the Voice Portal, a pair of repeaters is set up on the Media Server and the media stream between the VP user and the called party is hair-pinned back to the Media Server repeaters. Each repeater works in a particular direction and repeats the received media to the other party. In the transmit direction, the media stream is also repeated to an IVR session that allows the collection of the escape sequence. The following diagram shows how the media stream between the VP user and the called party transits via the Media Server.
Application Server

Voice Portal SIP/MGCP

MSCML Repeater commands

MSCML IVR commands

VP User

Called Party

Repeater Function

IVR Digit Collection Function

Media Server

•

Figure 17 Terminate-Call Function

During the set up of the call, the Application Server queries the Network Server to obtain a list of Media Servers that provide the repeater service. The Application Server attempts to allocate the repeater pair on one of the listed Media Servers. The eventually selected Media Server can be the same as the Media Server used for the Voice Portal IVR session. If the repeater service is not available, then the Terminate-Call function is not available and the media path is established directly from the VP user’s device to the called party’s device. In these cases, the instruction prompt is not played to the VP user prior to establishing the call. Notice that each call originated from the Voice Portal requires three Media Server ports for the duration of the call, that is, two repeater ports and one IVR port.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 38 OF 93

4.4.1.4

Detection of Escape Sequence and Codec Negotiation

The escape sequence to terminate a call is two consecutive pounds, that is, “##”. To terminate the call, the user must dial # keys no more than one second apart. When a call is established between the VP user and the called party, the VP user provides the offer SDP and the called party responds with an answer SDP. When the Media Server does not support the selected codec, the IVR session is set up such that the BroadWorks Media Server still receives the RFC 2833 DTMF tones and is able to report them back to the Application Server. Typically, in-band DTMF tones can only be transported in-band for high bit-rate encoding such as G.711 or G.726. The BroadWorks Media Server supports these two codecs.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 39 OF 93

5

Operations, Administration, and Maintenance

5.1

Call Capture and Trace Utility
Feature ID(s): 10178 The Call Trace Utility is a tool that allows a user to trace specific calls in the debug logs based on a BroadWorks user ID, a directory number, and a specified time frame. This allows customers to provide BroadWorks support using only the necessary sections of the Execution Server logs that pertain to a particular call scenario, which enables BroadWorks support to more easily diagnose problems. 5.1.1 Description Providing the proper logs for support is always a difficult task for customers. The Call Trace Utility addresses this problem by providing a method for customers to specify a time range and a call scenario and extract the precise sections of the Execution Server debug logs. The Call Trace Utility is used via the command line interface. The user is required to specify the following:
!

Starting time, which should be in the format “YYYY.MM.DD HH:MM”. Hours should be specified using the 24-hour clock. Ending time, which should be in the format “YYYY.MM.DD HH:MM”. Hours should be specified using the 24-hour clock One or more directory numbers (DNs) or user IDs to identify either the terminating or originating side of the call. DNs should be in E.164 format. Inter-group calls should be specified with both originating and terminating user IDs or DNs. Tracing scenarios that cannot identify the user (for example, a 404 response to a REGISTER) should be searched with “Unknown” as the user. PSTN call legs must be specified with a DN A BroadWorks user can be specified with either DN or user ID. Users without a provisioned DN must be searched by user ID.

!

!

!

!

! !

The user can also specify a file name to store the output or dump the output to the screen. Output displayed on screen can be paged so it can be easily viewed. Both sides of the call are included in the call trace output. In addition to the parsed call trace data, configuration information is included in the output, describing the device and configuration for the user.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 40 OF 93

5.2

Conferencing OAM Integration
Feature ID(s): 13585, 13584, 13587 5.2.1 Web Portal Integration The purpose of this activity is to make Conferencing Server functionality available in the BroadWorks web application. Specifically, this activity makes available the following call control commands that were not previously fully supported on the Conferencing Server, as follows:
!

Ad-hoc conferencing (bridge administrator initiates a conference on-the-fly by specifying their own phone number and a participant’s phone number – the bridge dials out to both numbers and establishes the conference). Bridge administrator or participant can initiate an outgoing call from the conference bridge to a specified number, automatically adding a participant to a specified conference (known as "join a conference" functionality). Bridge administrator or participant can initiate an outgoing call from the conference bridge to a specified number, automatically starting playback of a conference recording.

!

!

5.2.2 Accounting Integration In Release 11, the Application Server integrates more seamlessly with the Conference Server. As part of a larger integration effort, this particular feature integrates accounting information from the server into the BroadWorks call detail records. BroadWorks service providers should find it easier to bill their customers for use of the Conference Server. This feature affects two Application Server interfaces: the Application Server or Conference Server SIP interface, and BroadWorks call detail records. The Application Server or Conference Server SIP interface adds support for SIP NOTIFY messages from the Conference Server to the Application Server. These NOTIFY messages convey relevant accounting information from the Conference Server to the Application Server. The BroadWorks call detail records add new information necessary for more accurate billing for Conference Server usage. 5.2.3 Description 5.2.3.1 Web Portal Integration

There are several concepts introduced on the Application Server by this activity, as follows:
! ! ! ! ! ! !

Bridge provisioning enhancements (available both in the web and OSS) Conference scheduling (available both in the web and OSS) Presentation set up (web only) Ad-hoc conferencing (web only) Conference call control and recording (web only) Presentation viewing and moderating (web only) Audio recording and slide show playback (web only)
2O-BD5013-00 PAGE 41 OF 93

BROADWORKS FUNCTIONAL SUMMARY

The last two items involve delivering files (graphical files and audio files) from the Conferencing Server to the browser. If the Conferencing Server is on the private network, it cannot “serve” these files to users accessing the BroadWorks system from the public network, for example, through the External Web Server. Therefore, the Conferencing Server must also be reachable from the public network. For other access to the Conferencing Server, an access control list restricts the use of the Conferencing Server web user interface.
Public Private NS Cluster http End-User EWS Pair http Media CS Cluster http Application CS Pair Administrator ajp AS Cluster

http

http

•

Figure 18 Accounting Integration

5.2.4

Bridge Provisioning Enhancements Prior to Release 11, a conference bridge administrator was able to view and manage all conferences on a given bridge, regardless of who created the conference. This was because multiple administrators shared one account on the Conferencing Server with the same viewing and modification permissions as illustrated in the following figure.

Bridge Admin A

Conference 1

Bridge Admin B

Conference 2

Bridge Admin C

Conference 3

Created by View/ Modify

•

Figure 19 Release 9.1 and 10 Relationship Model

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 42 OF 93

In the current release conferences are “owned” by their creator, which means that administrators can view and modify only those conferences they created. At the same time, deleting a bridge administrator deletes conferences owned by that administrator, which was not the case in previous releases. For added flexibility, a bridge administrator can designate another bridge administrator as a delegate, on a per-bridge basis. Delegates are then able to view and modify conferences created by the delegator, in addition to their own as illustrated in the following figure.

Bridge Admin X

Conference I

Bridge Admin Y (Delegate of X)

Conference II

Bridge Admin Z

Conference III

Created by View/ Modify

•

Figure 20 Release 11 Relationship Model

Note that delegates can also create conferences in the name of any of their delegators. 5.2.4.1 Upgrade Considerations

Even if it were possible to change the owner of an existing conference on the Conferencing Server, it would be impossible to map existing conferences to a particular owner after an upgrade from Release 9.1 or 10 to Release 11, if there are multiple administrators per bridge. Taking into account these two limitations, the following process is automatically applied upon an upgrade:
1)

Existing conferences are marked as “owned” by the “Bridge Default Administrator” for a given conference bridge on the Application Server. The default administrator does not appear in the list of bridge administrators. Existing bridge administrators are designated as delegates of the default administrator. This cannot be undone.

2)

The main purpose of the default administrator is to take ownership of existing conferences. Being designated as delegates of “default”, existing bridge administrators continue to view and modify existing conferences. However, no new conferences can be created in the name of the default administrator. New bridge administrators automatically become delegates of “default”, in order to view pre-upgrade conferences. (However, this only happens if the default administrator exists on the Conferencing Server.) Eventually, all pre-upgrade conferences are deleted and the default administrator eventually recedes from view.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 43 OF 93

5.2.5

Conference Scheduling Conference scheduling functionality previously offered through the Conferencing Server web interface is now offered through the Application Server web and OSS interfaces. Supported conference types are as follows:
! ! !

One-time Recurring Reservationless

Note that ad-hoc conferences are essentially one-time conferences, the difference being in how they are created, that is the data that is provided at creation time is different. Both ad-hoc and scheduled conferences are subsequently modified in the same way. The following functionality is available:
!

Get current conferences per administrator, including delegators. These are conferences that are scheduled at the current time and/or have not yet finished (web only). Get future conferences per administrator, including delegators (web only). Get expired conferences per administrator, including delegators (web only). Get all conferences per administrator, including delegators (OSS only). Add conference (administrators can add conferences in their own name and in the name of a delegator). Modify a conference. Delete a conference. Get conference access codes. There is a different code for leaders and participants. Compose invitation e-mail, which opens an e-mail editor window pre-populated with conference data. The data is different for leaders and participants (web only). Compose meeting request, which opens a Microsoft Outlook meeting request window pre-populated with conference data. The data is different for leaders and participants (web only). Obtain the URLs for the Join a Conference page. There are different URLs for leaders and participants (web only).

! ! ! !

! ! ! !

!

!

5.2.6

Presentation Setup Presentation setup commands, available in the web interface only, are as follows:
! ! ! ! !

Upload a Microsoft Word, Excel, or PowerPoint document. Specify the password used to decrypt the uploaded document. Obtain the status of the uploaded document (queued, ready, or error). Delete a document. Obtain URLs for the presentation web application (different URLs for leaders and participants). Specify the password used to protect access to the presentation web application. Obtain the above-mentioned password.

! !

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 44 OF 93

5.2.7

Ad-Hoc Conferencing From the Conferences page, a bridge administrator clicks a button to go to the Conference Quick Add page. The bridge administrators can easily create a conference, by invoking dial out from the bridge to their own phone and another participant’s phone. As soon as this is performed, the conference appears in the list of current conferences (as a one-time conference). This can also be performed through the OSS interface.

5.2.8

Conference Call Control and Recording Conference call control functionality is available to the bridge administrator from the main Application Server web application. A pop-up window opens from the Conferences Modify page and the bridge administrator can:
!

Obtain a list of participants currently on the call (the leader is specifically marked). A manual refresh of the web page is required to obtain the current status. Mute a participant or all participants except for the leader (lecture mode). Put a participant on hold or put all on hold. Drop a participant or drop all participants. Lock a conference (no new are participants allowed). Call a participant (invoke dial-out from the bridge to a specified phone number). Start or stop recording the conference. If there is a presentation, it is automatically recorded in HTML+TIME format at the same time. Join the conference as the leader (initiate dial-out based on the phone number provisioned for the administrator).

! ! ! ! ! !

!

Note that muted participants can toggle their mute status by dialing ##1 (hand-raising feature). Note that leaders on a call can invoke dial-out from the bridge using a DTMF code. By dialing ##2, a voice prompt provides instructions how to add a new participant. In addition, the conference call control and recording functionality includes a way for the leader and participants to invoke a dial-out from the bridge to their phone number. This is done through a new “join a conference” stand-alone web application on the Application Server, to which the leader and participants gain access through the URLs shown in the Conferences Modify page. 5.2.9 Presentation Viewing and Moderating Presentation leaders (there can be more than one leader for a presentation) and participants access different stand-alone web applications on the Application Server. Leaders are able to perform the following operations:
! ! ! ! ! !

Select the current document. Select the current page (if the document is a PowerPoint document). Move one page forward or backward (if the document is a PowerPoint document). Jump to first or last page (if the document is a PowerPoint document). Terminate the presentation. Click on a link to open the Join a Conference web page (as a leader).
2O-BD5013-00 PAGE 45 OF 93

BROADWORKS FUNCTIONAL SUMMARY

These operations are performed using user interface elements in the top part of the page, while the remainder of the page shows the document content (or current page if it is a PowerPoint document). For PowerPoint documents, leaders and participants see the same page, whereas for Word and Excel documents, leaders and participants must communicate verbally the page to look at. This is because participants can choose which part of a Word or Excel documents to view. More specifically, a Word document is shown as a long, scrollable HTML document, whereas an Excel document is shown as a tabbed custom viewer application with its own navigation buttons. Participants can click on a link to open the Join a Conference web page. 5.2.10 Audio Recording and Slide Show Playback The bridge administrator can play back recordings and their corresponding HTML+TIME slide shows (animated presentations) from the Application Server provisioning web pages. The following functionality is available:
! !

Open the presentation HTML+TIME slide show with audio in a new window. Open the conference recording in the browser (automatically starts the associated audio player, if properly configured). Download the conference recording audio file with a choice of three formats. Obtain the URL for the stand-alone recording playback page. Specify the password used to protect access to the slide show playback web application. Obtain the above-mentioned password. Initiate dial-out from the bridge to a specified phone number, to listen to the recording over the phone. Compose an e-mail with details on how to access the stand-alone recording playback page.

! ! !

! !

!

Most of this functionality must be available to anyone the bridge administrator designates, whether or not they have a BroadWorks account. To support this, a stand-alone web application is provided on the Application Server, access to which is obtained by using a special URL on a per-recording basis. If desired, the bridge administrator can specify a password to protect the slide show playback application, on a per-recording basis. This password is available on the recording playback page on the main web interface on the Application Server, and should be communicated to those allowed to access the standalone slide show playback application, along with the per-recording URL. When a slide show is viewed, a new window opens from the recording playback page. This is a new stand-alone web application in itself. The top part of the new window has commands to start/pause the slide show, and to skip forward or backwards. The remainder of the window contains the slide show. A timer is shown in the upper right corner.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 46 OF 93

5.2.11 Accounting Integration The diagram below shows a simplified BroadWorks-based network, where the Application Server acts as the “service broker” by managing incoming requests to Conference Servers.
Conference Server

SIP SIP SIP

Application Server

SIP

Conference Server SIP

•

Figure 21 Accounting Integration

As conference calls are initiated from IP phones, the Application Server brokers delivery to an appropriate Conference Server in the network based on user and service profiles. The Application Server remains in the call to provide centralized fault, accounting and performance metrics. Centralizing these functions simplifies operations and maintenance procedures and gives the network continuity that makes it easy to deploy and manage. Currently, the accounting information generated by the Application Server is limited in detail. It is aware that the service being invoked is a conference service. It knows the start time and end time of each call into the conference service, and it also knows the participant for each call (who is calling the conference service). It does not know, however, any mid-service detail about the conference. For instance, after the user connects, the Conference Server usually collects a participant code or a moderator code. Once authenticated, the Conference Server retrieves parameters about the conference instance, such as the creator of the conference, the participant and moderator codes for the conference, and so on. The “service-info” event package is designed capture details to generate a much richer service detail record. In this example, the Conference Server is configured to generate “service-info” events and send them to the Application Server at anytime throughout the lifetime of a SIP dialog. The following diagram shows the call flow. Note that in this case, the Conference Server is designed to send only one “service-info” event immediately after it identifies the conference instance.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 47 OF 93

Application Server

Conference Server

INVITE INVITE 200 OK ACK 200 OK ACK 2-way media NOTIFY (service -info) 200 OK BYE 200 OK BYE 200 OK
Application Server cuts CDR 2) 1) Collect conference code (moderator/participant) Send “service -info” event to Application Server

•

Figure 22 Call Flow

For Release 11, the Conference Server can add participants to a conference via outdialing. When the Conference Server dials out, the picture above changes only in the direction the INVITE is sent.

5.3

OSS Enhancements
Feature ID(s): 12339 This feature is to enhance the Application Server OSS Interface service commands to provide a consistent, fast, and fully functional interface.

5.3.1

Description The existing getUser command returns all information (profile and service data) about a user. This is generally lot of information that is also time intensive to retrieve. To address this problem a new command getUserList is introduced. This command returns a list of all users within a group with minimal information for each user. The modifyUser and modifyGroup command names are changed so that they are consistent with other commands. The new names are modifyUserProfile and modifyGroupProfile respectively. A new command getHierarchy is introduced, which returns all groups and users within a service provider.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 48 OF 93

5.4

Performance Enhancements for Troubleshooting
Feature ID(s): 12902 This feature improves visibility of the performance history of the system and captures more information for debugging performance-related issues. New call processing gauges provide the system provider with visibility into call processing cross-office delay and call processing performance. The cross-office delay gauges measure the amount of time for a call processing message to propagate through the Application Server taking internal queuing delays and processing delays into account. The delays are calculated using a rolling window of 100 samples. The performance gauges measure the average call traffic rate on the Application Server and Network Server. The rates are calculated using a rolling window of 100 samples. These new gauges are incorporated into system statistics reports. Overall RAM usage is monitored and the system provider is notified via an SNMP trap when memory usage exceeds a pre-defined threshold. The tech-support tool is enhanced to capture information that is helpful in diagnosing excessive memory usage problems and excessive CPU usage problems.

5.4.1

Description 5.4.1.1 Application Server Gauges

The gauges added to the Application Server measure SIP/MGCP cross-office delays, calltraffic and registration rates, and SIP/MGCP retransmission rates. These gauges are applicable to the system level (that is, they are not measured at the service provider or group level). The gauges measuring delays and rates are calculated by averaging a rolling window of 100 samples. The gauges measuring minimum and maximum delays reflect the minimum and maximum of all delays sampled and can be reset either directly via SNMP, as part of setting the resetAllRegisters MIB variable (prior to this feature, this variable was named resetAllCounters), or when reset is enabled as part of SNMP PM reporting. All new Application Server gauges are included in the History and Recent and Current Server Statistics reports. Names for the delay gauges are based on names established in ITU-T Recommendation E.721. 5.4.1.2 Application Server Statistics Reports

The new gauges are included in the history, recent and current server statistics reports. The gauge values in the historical and recent reports are values as retrieved via the Application Server MIB (that is, they are not differential values as with counters). The report shows average values of these gauges over the report period. 5.4.1.3 Network Server Gauges

A system-level gauge measuring the rate of invitations processed by the application layer is added. The gauge is included in the history, recent and current server statistics reports. 5.4.1.4 Network Server Statistics Reports

New gauges are included in the history, recent and current server statistics reports. The gauge values in the historical and recent reports are values as retrieved via the Application

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 49 OF 93

Server MIB (that is, they are not differential values as with counters). The report shows average values of these gauges over the report period. 5.4.2 Memory Monitoring The bwCPUMon script, which is run as a schedulable maintenance task, is enhanced to monitor memory usage. This script is applicable to all servers. When the script detects that the Execution Server heap usage exceeds 85% (applicable to Application Server only) or that the average scan rate (from Solaris vmstat utility) exceeds 200, it generates a bwPendingMemoryExhaustion trap indicating the tech-support command should be run to gather information for troubleshooting performance-related problems. The default 85% Execution Server heap threshold and the 200 scan rate threshold can be overridden by providing arguments on the command line. The existing bwCPUIdleTimeLimitReached trap text is also updated to indicate that techsupport should be run to gather information for troubleshooting performance-related problems. 5.4.2.1 Tech-Support Enhancements

The tech-support script is enhanced to capture the following information:
! ! !

Swap configuration as output by swap –l and swap –s. /tmp usage Number of CPUs, CPU speed, and RAM installed as output by /usr/platform/`uname – i`/sbin/prtdiag –v Disk mirroring information as output by metastat Contents of public_html/WEB-INF/web.xml System statistics historical report Performance history for day specified − Sar -wpgrqdu output that provides block device activity, paging activity, swapping activity, run queue statistics, memory page and swap page statistics, and CPU utilization Garbage collection logs for the Execution Server or Network Server process Information on all processes running on the server as output by ps -elf Five samples of vmstat output taken two seconds apart Five samples of mpstat output taken two seconds apart Five samples of iostat -xnp output taken two seconds apart Five samples of top output taken two seconds apart (top -b -d5 -s2) Thread dump of the Execution Server (Application Server only), Network Server (Network Server only), and SNMP agent Heap dump and heap usage of the Execution Server (Application Server only) Execution Server queue statistics (Application Server only)

! ! ! !

−
!

Current performance and execution information as follows: − − − − − − − −

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 50 OF 93

An optional -day argument is added to tech support. By default, the sar output section and garbage collection logs section capture data for the current day. A different day of the month can be specified for the sar output and garbage collection logs sections. The complete file date is displayed for the sar output and garbage collection output in case there are rollover issues.

5.5

Service Pack Migration Tools
Feature ID(s): 13023 The Service Pack Migration feature is a powerful tool for service providers to assign and un-assign services and service packs to groups of users. Prior to Release 10, BroadWorks did not support Service Packs, so users were provisioned with individual services. Because Service Packs are a superior provisioning approach, existing customers will likely want to migrate their users to Service Packs as soon as possible. While the conversion could be done manually, the Service Pack Migration feature greatly simplifies the process. The Service Pack Migration feature can be used to convert in bulk, large groups of users matching a specified configuration to any new desired configuration. It is possible to assign or remove any combination of services and service packs. Since the process can be time consuming and processor-intensive, the migration tasks should be scheduled for execution during the night when system load is lightest. All of this is possible through an intuitive web-based interface. Customers who are already using Service Packs can benefit from the Service Pack Migration feature as well. If a service provider decides to repackage the services into different Service Packs, the Service Pack Migration feature can be used to migrate users from the old packs to the new packs. Please refer to the Release 10 User Service Packs functional specification for more information about service packs. 5.5.1 Description The Service Pack Migration feature consists of two parts. There is a web-based user interface to specify the details of the migration, and a migration task to migrate users to the specified configuration at the specified time. When the task is complete, the results are available in a detailed task report. The user-interface provides a step-by-step wizard to guide the service provider in specifying exactly what the migration task will do. The wizard is described in section 4.1 below. After the migration task begins executing, a web screen is available to check the status of the migration. When the migration task ends, the task report can be automatically emailed to a specified email address. There are 3 critical parts to defining a migration: 1) user selection criteria, 2) services and packs to remove, and 3) service and packs to assign. The migration task examines all the users in all the specified groups looking for users whose current configuration matches the user selection criteria. The users selected for migration are assigned and unassigned the services and service packs specified when the migration was setup. Existing user service configuration data is retained when a service is removed and reassigned as part of a service pack. The migration tasks execute within the provisioning server on the primary server only. It is not possible to execute a migration task on the secondary provisioning server. If the provisioning server is not running at the scheduled start time of a migration task, the task

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 51 OF 93

will not execute. Furthermore, the overdue task will not start automatically when the provisioning server is restarted. You must manually reschedule a missed migration task. The Service Pack migration feature does not automatically create Service Packs matching the existing user’s configurations. Instead, service providers must create the Service Packs prior to migrating users to the Service Packs. The decision determining which services belong in which pack is usually driven by marketing and business requirements. In some rare cases, it might be possible to migrate all users with a single migration task when the existing configuration is simple and consistent across all users. But more typically, it will take more than one migration task to completely migrate users to Service Packs. The reason for this is because different Service Packs will have different user selection criteria. The order of execution of the migration tasks is important since a task can add or remove services that can affect the user selection criteria of subsequent tasks. Also, it is possible to execute more than one migration task concurrently, but again, this could lead to undesirable results if one task affects the user selection criteria of the other task. As the migration task executes, it writes a report with the results of the migration attempt for each user. A sample report is shown in figure 11. You can copy a task and reschedule it to execute again. The old task status and task report remains available for inspection. The task status and task report remain available until you delete the task. Customer Support personnel may wish to view the task report after the job completes, as it contains useful information about user configuration changes. Fatal and non-fatal errors are recorded in the task report. Non-fatal errors can prevent a single user from being migrated. This can happen, for example, if a user is manually deleted while the migration task is executing. The migration task can end before it is finished migrating all the users. This can happen for any of the following reasons:
! ! ! !

Exceeded the maximum allowed task duration Exceeded the maximum allowed non-fatal error count Exceeded the service provider’s allocated Service Quantities Violation of system-level service licensing

When a migration task is created, it is possible to configure the task to automatically increment the service quantities for the migrated groups as needed when new services and packs are assigned. When this option is selected, the services and packs are also automatically authorized to the groups. If this option is not chosen, you must manually authorize and allocated sufficient service quantities for all the users to be migrated. Finally, the Service Migration feature can be used to change the configuration of users even when Service Packs are not being used. In this capacity, the Service Pack Migration feature becomes a helpful tool for assigning and un-assigning services regardless of whether Service Packs are being used.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 52 OF 93

6

System

6.1

Call Client Hold Integration
Feature ID(s): 13882 This feature extends the Release 10 Enhanced Call Manager/CAP Support feature. Support of the SIP Remote Control Hold/Retrieve functionality is added per the BroadWorks Advanced Call Control Specification. The CommPilot Call Manager is modified to enable the “Hold” and “Talk” buttons for hold/retrieve purposes when the Remote Control Hold/Retrieve functionality is supported by the user’s intelligent device (for example, a SIP Phone). In addition, external holds/retrieves (hold/retrieve requests from the device) are now detected from BroadWorks users on intelligent devices (for example, SIP Phones). A call is treated as held when an external hold is detected for it. Note that this feature does not affect the hold/retrieve functionality for non-intelligent and network devices. 6.1.1 Description 6.1.1.1 Remote Control Hold

The Remote Control Hold functionality allows a CAP call control client to instruct a device to hold a call. A device specifies that it supports Remote Control Hold by including an Allow-Events header with the “hold” event package in a SIP INVITE, 18x, or 200 OK. This creates an implicit subscription to the “hold” event package. Note that the Allow-Events header is ignored in SIP re-INVITEs and SIP 18x and SIP 200 OK responses to a SIP re-INVITE. The following is an example of the Allow-Events header with the “hold” and “talk” event packages: Allow-Events:hold,talk When an intelligent device specifies that it supports Remote Control Hold, a CAP call control client can allow the user to hold a call or conference via the CAP call control client (for example, the hold button on the client can be enabled for the call/conference if the call/conference is active). When BroadWorks receives a CAP callAction message to hold an active call/conference and the device supports Remote Control Hold, a SIP NOTIFY message including an Event header with the “hold” event package is sent to the device. The device then responds with a SIP 200 OK to the NOTIFY, and a SIP INVITE containing a hold SDP to hold the call/conference. 6.1.1.2 Remote Control Retrieve

The Remote Control Retrieve functionality allows a CAP call control client to instruct a device to retrieve a call. The Remote Control Retrieve signaling is the same as that for Remote Control Hold except that the “talk” event package is used instead of the “hold” event package. Note that the “talk” event package is used to specify support of both Remote Control Answer and Remote Control Retrieve. The Release 10 Enhanced Call Manager/CAP Support feature added remote Control Answer support.
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 53 OF 93

When an intelligent device specifies that it supports Remote Control Retrieve, a CAP call control client can allow the user to retrieve a call/conference via the CAP call control client (for example, the talk button on the client can be enabled for the call/conference if the call/conference is held). When BroadWorks receives a CAP callAction message to retrieve a held call/conference and the device supports Remote Control Retrieve, a SIP NOTIFY message including an Event header with the “talk” event package is sent to the device. The device then responds with a SIP 200 OK to the NOTIFY, and a SIP INVITE containing a full, non-hold, SDP to retrieve the call/conference. 6.1.1.3 CommPilot Call Manager

When using an intelligent device prior to this feature, the “Hold” and “Talk” buttons on the CommPilot Call Manager were always disabled for call hold/retrieve purposes but always enabled for conference hold/retrieve purposes. The “Hold” button on the CommPilot Call Manager is now only enabled for intelligent devices when the device supports Remote Control Hold and the call is in the CAP Active or Remote Held states or the conference is in the CAP Active state. The “Talk” button on the CommPilot Call Manager is now only enabled for intelligent devices when the device supports the Remote Control Retrieve and the call or conference is in the CAP Held state. The new functionality makes the CommPilot Call Manager hold/retrieve behavior consistent for intelligent devices. 6.1.1.4 External Hold/Retrieve Support

Prior to this feature, a call/conference was only treated as held (for example, a CAP call control client sees the call in the CAP Held state) when BroadWorks internally held the call/conference (because of a trigger such as a CAP Call Control Client). When an intelligent device such as a SIP phone held the call/conference itself (an external hold), the call/conference was not treated as held. A CAP call control client would still see the call/conference in the CAP Active state. Now, an external hold from an intelligent device (for example, a SIP re-INVITE with a hold SDP) causes the call/conference to be treated as held. A CAP call control client sees the call/conference in the CAP Held state and can enable the “Talk” button for the call/conference if the device supports Remote Control Retrieve. Similarly, an external retrieve from an intelligent device (for example, a SIP re-INVITE with a full, non-hold SDP) now causes a held call/conference to be retrieved. A CAP call control client sees the call/conference in the CAP Active state again.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 54 OF 93

6.2

Calling Line ID Delivery Enhancements
Feature ID(s): 12676 This feature extends Calling Line ID configuration and presentation. The extended Calling Line ID service enhances calling line identity presentation by adding the following new calling line identity types:
! ! ! !

Operator – for operator-initiated calls. Payphone – for calls originated from pay phones. Overseas – for calls originated from outside of the country. Transfer – for calls being transferred (SIP Diversion).

This feature does not affect BroadWorks Privacy functionality. 6.2.1 Description Calling Line ID Delivery Enhancements (CLID Enhancements) feature extends functionality of calling line identity presentation based on the information available in the GTD MIME extension of the SDP information content – part of the “SIP Invite” message. The enhanced caller ID presentation functionality:
! !

Presents a caller’s name and phone number, if available and unrestricted. Presents a caller’s name as “Operator” and blocks the caller’s number for calls originated by an operator. An “Operator” call works uniformly for national and international types (French, English, German, Russian, Spanish) of “Operator” calls. Presents a caller’s name as “Payphone” and blocks the caller’s number for calls originated from pay phones. Presents a caller’s name as “Overseas: and presents the caller’s number if available and unrestricted for calls originated from outside of the country. Presents a caller’s name as “Transfer” and the caller’s number if available and unrestricted for transferred calls (calls with Diversion Header in “SIP Invite” message). Note that the determination of presenting “Transfer” information is not based on GTD information.

!

!

!

There is no impact on restricted calling line ID functionality (Private/ Anonymous) with this feature. All calling line identity types, except for Transfer, apply to incoming PSTN calls. Transfer applies to inter-group and intra-group calls. The presentation of Operator, Payphone, or Overseas calls has precedence over Transfer information. For example, a transferred overseas call is presented as an Overseas call rather than a Transfer call. This system configuration parameter is configurable (enabled/disabled) at the system level. The default for this parameter is “false”.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 55 OF 93

6.3

Configurable Ringing Timeout
Feature ID(s): 13702 Ringing timeout is used to prevent a phone on an access device from ringing continually. This is a system parameter that is only configurable via the command line interface (CLI). The CLI allows this feature to be activated or deactivated and for the timeout period to be set. When the Ringing Timeout expires the terminating side is released and the originator hears a reorder tone. The Configurable Ringing Timeout does not apply to calls to the PSTN network. It does apply to the following services: Call Waiting, Call Manager-initiated dialing, Hold Recall, and Simultaneous Ring.

6.4

Element Management System
Feature ID(s): 12871 The BroadWorks Element Management System (EMS) is the central component to manage the set of BroadWorks servers: Application Server (AS), Conferencing Server (CS), External Web Server (EWS), Media Server (MS), and Network Server (NS). The EMS provides the capability to auto-discover most of the BroadWorks server types2 and maintains the list of nodes to reflect changes as they occur in the network. The BroadWorks EMS is dedicated to the network management of BroadWorks nodes only and excludes support for any other types of devices. One of the primary goals of the EMS is to provide support for FCAPS functions. The management capabilities include:
! !

Fault Management — alarm handling, correlation, forwarding and filtering. Configuration — auto-discovery, network provisioning, auto backup and recovery, centralized software management, and cut-through to device for configuration. Performance — performance monitoring, report generation, and data collection and correlation. Security — access management and access audit logs. BroadWorks tools — miscellaneous BroadWorks management utilities. Administration tools — service provisioning, configuration, performance tuning. Flexibility — components and services can be added to the deployed solution to meet the performance, scalability, and availability goals. Maintenance and upgrade — fast and low-risk upgrades.

!

! ! ! !

!

The EMS server consists of three tiers of server components, the management server (mediation) tier, which provides protocol mediation with the managed systems, the backend server tier, which provides database transaction and encapsulation service and the front-end server tier, which provides client session management services. Figure 23 Schematic Overview of BroadWorks EMS Functionalities illustrates the Element Management System functionalities and interfaces.

Managing Conference Server nodes requires that the nodes are added manually using the “Add Node” option. This is because auto-discovery does not include Conference Server nodes. However, once a Conference Server node is added manually, the EMS supports fault management for this type of node. BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 56 OF 93

2

•

Figure 23 Schematic Overview of BroadWorks EMS Functionalities

6.4.1 Description 6.4.1.1 Layered Management Model

The TeleManagement Forum defines a Telecommunication Management Network (TMN) layered model with interfaces that map the management functions and communication for the operation, administration, and maintenance (OA&M) of networks and services in a multi-vendor environment. The model includes the following layers:
! ! ! ! !

Network element Element management Network management Service management Business management

BroadWorks EMS focuses only on the first two TMN layers with well-defined northbound interfaces into Layer 3. Section 6.4.1.4 Network Architecture describes the TMN aspects relevant to the BroadWorks EMS. 6.4.1.2 Network Management Areas

In addition to the TMN–layering structure, the ITU–T also splits the general-management functionality offered by management systems into the five key areas of fault, configuration, accounting, performance, and security (FCAPS). This categorization is a functional one and does not describe the business-related role of a management system within the telecommunications network. The concept of FCAPS stems directly from the ITU–T recommendations and describes the five different types of information handled by management systems. The following section summarizes the FCAPS aspects relevant to the BroadWorks EMS.
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 57 OF 93

6.4.1.3

Managed Element

A Managed Element defines any of the nodes presents in a managed network. Hence, any of the BroadWorks server types is a Managed Element for the BroadWorks EMS. 6.4.1.4 Network Architecture

As mentioned earlier, the BroadWorks EMS fits into the TMN-layered management model. In this architecture the EMS simplifies the integration into a service provider network management system by providing a single point of access for managing the fault, performance and configuration components of the BroadWorks servers. The EMS also simplifies access to the management interfaces on the BroadWorks server themselves by providing tools to centralize this task. The EMS does provide multiple human-to-machine and machine-to-machine interfaces. The BroadWorks EMS makes use of the existing interfaces of the BroadWorks managed elements. From an EMS layer perspective, the BroadWorks EMS communicates southbound to the BroadWorks managed element via the following interfaces: SNMP, the Network Server OSS and Portal API, and the Application Server portal API. The BroadWorks EMS acts as an SNMP proxy for BroadWorks managed elements to communicate northbound to the NMS layer (and above). The BroadWorks EMS supplements the northbound interface with its own functionality to report aggregate events and data.

NMS

Network Management Layer Element Management Layer
MS EWS

EMS

NS

AS

CS

BroadWorks Element Management Layer

•

Figure 24 TMN-Layered Management Model View of a BroadWorks Network

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 58 OF 93

North-Bound
Customer database NMS SYSTEM SNMP SNMP Tomcat EMS SNMP NS AS SNMP PS SNMP Tomcat AJP EWS Apache OSS Proxy CAP Proxy PS XML/ Corba XS Apache XML/ Corba MS SNMP CS SNMP OSS OSS Apache Proxy From HTTP/ Operator SSH Workstation EMS Layer NMS/OSS Layer SLA Billing Inventory Trouble Service Surveillance ticketing Activation …

...

...
NE Layer

CAP

End User Interfaces

HTTP

OSS

CAP Public Network

South-Bound
• Figure 25 Interface View of a BroadWorks TMN-Layered Network

6.4.1.5

EMS Core Software Architecture

The BroadWorks EMS is designed to support varying deployment needs.

•

Figure 26 BroadWorks EMS Core Software Architecture

The BroadWorks EMS consists of three tiers of server components, the management server (mediation) tier, which provides protocol mediation with the managed systems, the back-end server tier, which provides database transaction and encapsulation service and the front-end server tier, which provides client session management services. Further Distributed Mediation Servers can be deployed for massive scalability by distributing the network facing functions across multiple Distributed Mediation Servers.
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 59 OF 93

These servers support management of large networks, achieving scalability on both the size of the networks and systems that can be managed. There can be more than one deployment of each of these servers to achieve massive scalability. The servers can be deployed with redundancy so that any failure, results in fail-over to other server components. 6.4.1.6 Functional Description

The BroadWorks EMS offers a list of applications and tools designed to simplify and centralize the management of BroadWorks servers. The EMS enables network monitoring, configuration and troubleshooting of individual BroadWorks servers and resources. An entire BroadWorks network can be supervised from a single platform where multiple users can access the BroadWorks EMS services simultaneously. The BroadWorks EMS has the following characteristics:
!

Proactive alarm and event management with customizable filtering, propagation, and drill down Event correlation and root cause analysis Multi-level thresholding and hysteresis Parameterized XML tasks for streamlining configuration and provisioning functions Powerful configuration management – add, modify, and delete with rollback capability, audit logs Fine-grained security with extensible access control and authorization with support for users, groups, roles, operations, and object views J2EE security model Business rules capability for dynamic control Customizable reporting Additional Product Information

! ! ! !

!

! ! !

6.4.1.7

The BroadWorks EMS product comes with automated procedures to perform installation, upgrades, and configuration dump and restore. It is also composed of a set of processes that ensures the proper level of operability. The most usual maintenance functions can be performed through the server’s command line interface. For more information, refer to the BroadWorks EMS Administration Guide.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 60 OF 93

6.5

G.729 Codec Support
Feature ID(s): 12787 This feature introduces support for Codec G.729a on the Media Server. G.729 is available for IVR, conferencing, and live audio services. 6.5.1 Description This feature introduces the G.729a Codec to IVR, conferencing as well as live audio services. There are no restrictions to the use of G.729a for IVR or conferencing. Using G.729a for the live audio service requires caution in that the G.729a cannot carry music reliably. So, if the live audio source provides a significant amount of music, use of G.729a for live audio is discouraged.

6.6

International Call Screening
Feature ID(s): 12866 The Call Screening function, currently based on NNACL and LCA files, was designed and optimized to only support the North American market. This activity internationalizes the concept of call screening. 6.6.1 Description 6.6.1.1 International Zones and Rate Centers

To support Call Screening outside North America, the Network Server supports zones and rate centers in all countries. National Destination Code (NDC) provisioning is enhanced to accept a zone and a rate center for each NDC. A new set of CLI commands is created to support the definition of zones and rate centers, as follows:
Field cc zone Type Number (1 to 3 digits) String (1 to 32 characters) Description A valid country code (CC) defined in the system under NS_CLI/System/CallP/CountryCodes. The name for a zone. The zone name is unique within a country code. If the zone does not exist when an entry is added, the zone is created after a confirmation is obtained from the CLI user. The name for a rate center. The rate center name is unique within a zone. Many rate centers can be defined in a zone. Description of the rate center/zone entry.

rateCenter

String (1 to 32 characters)

description

String (0 to 64 characters)

The system provider can then make NDCs refer to pre-defined zones/rate centers. After an upgrade to Release 11, no zones or rate centers exist and no NDC refers to zones/rate centers. 6.6.1.2 International Call Screening

The existing CallScreening policy is already internationalized and it can be re-used for the purpose of international call screening. However, it has been enhanced to support call

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 61 OF 93

category determination using zones/NDC rate centers as well as LATA/NNACL rate centers. The new logic is as follows:

Start

CCorig = CCterm?

N

Skip policy, no cat change

Y

N

LATA and RC exist for orig and term?

Y

ZONEorig = ZONEterm?

Y

LATAorig = LATAterm? Y cat=LOCAL N

Y

RCorig = RCterm? N

RCorig = RCterm?

Y

cat=LOCAL

LCAorig = LCAterm? N ZONEorig = ZONEterm?

Y

cat=LOCAL

LCAorig = LCAterm? N

Y

cat=LOCAL

Y

cat=INTRALAT

LATAorig = LATAterm?

Y

cat=INTRALAT

N cat=INTERLAT

N cat=INTERLAT

•

Figure 27 International Call Screening

As described in Figure 27 International Call Screening, this feature does not introduce new call categories. Instead, it re-uses existing call categories and generalizes their meaning. This has the advantage of supporting international call screening without impacting the Application Server or other Network Server routing policies, such as Equal Access. 6.6.1.3 International Local Calling Area

This feature extends to all countries the capability to define local calling areas (LCA). A new CLI level under NS_CLI/System/CallP/CountryCodes/NDC permits the creation of local calling areas. A local calling area entry has the fields shown in the following table. Note that a local calling area cannot cross country code boundaries. The creation of a local calling area is inclusive, meaning that entities added form the local calling area. There is no provision to exclude a smaller entity from a bigger one already included in the local calling area.
Field Cc Lcaid ndcList Type Number (1 to 3 digits) String (1 to 32 characters List of number (1 to 10 digits) Description A valid country code (CC) defined in the system under NS_CLI/System/CallP/CountryCodes. The name given to a local calling area. The LCA name is unique within the entire system. Lists all NDCs that are part of the local calling area defined by Lcaid. 2O-BD5013-00 PAGE 62 OF 93

BROADWORKS FUNCTIONAL SUMMARY

rcList zoneList lcaList

List of string (1 to 32 characters) List of string (1 to 32 characters) List of string (1 to 32 characters)

Lists all rate centers that are part of the local calling area defined by Lcaid. Lists all zones that are part of the local calling area defined by Lcaid. Lists all local calling areas that are part of the local calling area defined by Lcaid. This field allows a wider local calling area to be defined using a smaller local calling area. Recursive definitions are detected and not permitted.

It is then possible to assign an LCA to an NDC entry under NS_CLI/System/CallP/CountryCodes/NDC. An NDC can only refer to a local calling area defined in the same country code as its own. With this feature, call screening finds the NDC entry of the calling number, determines if this NDC has an LCA defined, and if so, extracts its content. It then verifies if the called number falls in the LCA of the originator, for one of the following reasons:
! !

The NDC of the called number is listed in the ndcList of the originator’s LCA. The rate center of the called number’s NDC is listed in the rcList of the originator’s LCA. The zone of the called number’s NDC is listed in the zoneList of the originator’s LCA.

!

If the called number is in the LCA of the calling number, the Network Server flags this call as the Local category. Zones and rate centers used to define local calling area rules can be assigned to NDCs. This allows the Network Server to identify in which zone and rate center an NDC belongs. An NDC cannot belong to a zone alone because a zone can contain many rate centers. An NDC can only be part of one rate center and a zone must also be specified since the rate center is only unique within a zone.

6.7

Line/Port Domain Scoping
Feature ID(s): 14408 This feature adds domain configuration to access-side devices that are “AS Addressing” per BroadWorks device Inventory. AS Addressing devices are devices that use a BroadWorks Application Server alias in the “host’ portion of their address-of-record. For example, a line defined on a SIP IP phone is identified by a lineport@host address-ofrecord; where address must match one of the Application Server aliases. This feature now allows the “host” portion of such an address-of-record (AOR) to be selected from a list of domains defined within BroadWorks that are available to a user. This functionality now requires line/ports to be unique only within a selected domain, as opposed to across an entire Application Server. For example, user1@yourdomain1.com and user1@yourdomain2.com are allowed, previously this was not permitted. Device configuration becomes more manageable, especially in large configurations with subscribers across multiple service provider and group domains. The address-of-records on such AS Addressing devices now mirror user configuration in this respect; a user in BroadWorks is assigned a domain and so is his/her device addressof-record. This capability also allows a user’s user ID and line/port to be the same and permit a Windows Messenger device to be used successfully in conjunction with another (regular phone) device. A Windows Messenger device’s address-of-record is the

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 63 OF 93

userid@domain of that user, and a regular phone’s address-of-record is lineport@address; previously userid could not be the same as lineport without addressing conflicts occurring at execution time. Now, separate addressing spaces for messenger devices versus phones remove such addressing conflicts. It is permitted, for example, to have user1@domain.com as a user’s login ID (and Windows Messenger login ID); along with user1@domain.com as that user’s device address-of-record. 6.7.1 Description 6.7.1.1 Domains for Line/Ports

A domain now is required whenever a line/port is configured on a device using AS Addressing. The domain this line/port is associated with can be selected from a list of domains assigned to the customer group a given subscriber is in. This domain is used as the host portion in an address-of-record lookup, such as when a SIP REGISTER or INVITE message is received by BroadWorks, thus the actual device should be appropriately configured to send this domain value as the “host” in a SIP message. Currently, AS Addressing devices can be configured to use any one of an Application Server’s aliases as the host address in an incoming message. To allow this existing configuration to be valid and permit staged changes in CPE configuration on a system upgrade, a system-wide flag is introduced. This flag is provisioned from the Application Server CLI at the AS_CLI/System/Domain context, and is called useAliasForDomain. This flag does not impact Windows Messenger device addressing in any way. When useAliasForDomain is set to “true”, then:
!

Line/ports defined on an Application Server must continue to be unique across the entire Application Server. This setting allows CPE configuration to remain unchanged, subscriber lookup on an incoming message will work as it does today. Line/ports only need be unique across the domain they are associated with. CPE configurations must be changed at this time, to allow subscriber lookups to be successful on incoming messages from various AS Addressing devices. If there are access devices that have IP addresses or host names similar to a domain in BroadWorks; two line/ports being equal, one on the device and one on an AS Addressing device causes addressing conflicts and subscriber lookups are not be consistent. Device Addresses Versus Domains

When useAliasForDomain is set to “false”, then:
!

!

6.7.1.2

It is not permitted to assign an IP address/hostname to an access device if that address/hostname is equivalent to any domain configured on BroadWorks. The reverse case is also enforced; it is not permitted to create a domain if it conflicts with an existing access device’s address/hostname. This prevents addressing conflicts between devices that use AS Addressing and those that do not. 6.7.1.3 Case Sensitivity for Address-of-Records

According to RFC 3261 (for SIP), the user portion in a SIP URL should be considered case-sensitive, the host portion in a SIP URL is case-insensitive. This rule applies to incoming messages that identify a subscriber via SIP URLs. BroadWorks follows this rule; for example user1@applicationserver.com is equivalent to user1@ApplicationServer.com, but not equivalent to User1@applicationserver.com.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 64 OF 93

According to RFC 2897 (for MGCP), the user/port and address portion in an MGCP message should be considered case-insensitive. BroadWorks follows this rule; for example aaln/S1/1@device.domain.com is equivalent to AALN/s1/1@device.domain.com which is equivalent to aaln/S1/1@Device.Domain.Com. 6.7.1.4 Windows Messenger

A BroadWorks subscriber’s Windows Messenger address-of-record (a format of userid@domain) is now permitted to be the same as that subscriber’s device addressof-record (a format of lineport@host). Previously, this was not supported. Also note that the useAliasForDomain system flag’s setting does not affect this Windows Messenger addressing.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 65 OF 93

6.8

Live Audio Support
Feature ID(s): 12789 The live audio feature allows the Media Server to play live audio during passive and active music on hold. This feature only covers modification to the Media Server. To fully enable this new functionality on BroadWorks, some work is required on the Application Server. However, modifications to the Application Server are outside the scope of this feature. The audio source is physically connected on the Media Server audio line-in jack. Live audio can be streamed for two different scenarios.

6.8.1

Passive Music On Hold The Media Server automatically answers the SIP INVITE directed towards user live audio and starts streaming live audio music to the user put on hold. There is no digit collection during a passive music-on-hold dialog.

6.8.2

Active Music On Hold The Media Server plays live audio, instead of a predefined audio file, while collecting digits when a call center user is put on hold. Digits are collected and sent back to the Application Server.

6.8.3

Description As of Release 10.0, BroadWorks supports an external source for music on hold. The existing feature External Source for Music On Hold allows streaming of live audio to users being put on hold from an external live audio source (for example, VOIP gateway). This feature adds the option to use the Media Server as an external music-on-hold source. Digit collection can either occur or not. This is referred as active and passive music on hold. The operator controls the external audio source, but instead of being connected to a third-party VOIP gateway, the audio source is physically connected to the Media Server audio line-in jack. This new service is only available when an audio line-in jack is available. When a Media Server with a live audio license is unable to open the analog audio port, or if the audio hardware is not present an alarm is raised and the Media Server responds “404 Not Found” to all attempt to access live audio. This applies for both active and passive musicon-hold dialogs. To interoperate with other SIP-aware servers, the Media Server implements this new feature using the following standards:
! ! ! !

SIP (RFC 3261) and SDP (2327) using SIP protocol stack RTP (RFC 2250) NETANNC (draft-burger-sipping-netann-07), basic network media service definitions MSCML (draft-vandyke-mscml-04p), describes the Media Server Control Markup Language

6.8.4

Analog Audio Port A Sun Blade workstation provides the analog audio port for the Media Server. The Sun Blade workstation has a sound card with an audio line-in jack. The external audio source

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 66 OF 93

is physically connected to that audio line-in jack, thus providing the Media Server with an analog audio source. Any device that has an audio line-out jack can be used as the external audio source. 6.8.5 Supported Codecs The Media Server supports four codecs for all of its services. They are:
! ! ! !

G.711 µ-Law G.711 a-Law G.726-32 G.729a

Raw live audio is read from the analog audio port as signed linear PCM 16-bit mono. Conversion to desired codec is done in a lazy manner, meaning that codec conversion is only performed if required. For example, signed linear PCM 16-bit mono would not be converted into G.729a unless at least one user requested G.729a. Once the last user of a codec stopped receiving live audio from the Media Server, the Media Server would stop converting that codec.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 67 OF 93

6.9

Media Server Access Control and Performance Management
Feature ID(s): 12790 This feature has three parts. One part consists of an Access Control List (ACL) that verifies that the call origination from the network side comes from a known location. The list of valid locations is configurable via the command line interface (CLI). Any origination whose source is not found in the configured access control list is ignored. To enable this feature, restrictSIPAccess must be set to “true”. The other part is related to SIP configuration. The SIP port and timers used by the Media Server are configurable via the CLI. The third part concerns SIP performance management. It is possible to monitor inbound and outbound SIP traffic through new performance management counters. 6.9.1 Description This feature is broken down into the following:
! ! ! !

ACL configuration ACL validation SIP configuration SIP performance management counters ACL Configuration

6.9.1.1

The system administrator uses the CLI to enter a list of IP addresses from which SIP messages are honored. Only IP addresses are allowed and fully qualified domain names (FQDNs) are not allowed. By default, ACL is disabled. If ACL functionality is desired, then the system administrator can enable ACL for the SIP interface by setting restrictSIPAccess to “true”. 6.9.1.2 ACL Validation

When ACL is enabled, the Media Server validates that the UDP packet source address matches at least one entry in the access control list. If one match is found, then the SIP message is processed as usual. Otherwise, the message is ignored, no response is generated, the msACLViolationCount performance management counter is incremented, a warning is written to the log file, and SNMP SIP counters are not incremented. 6.9.1.3 SIP Configuration

The system administrator uses the CLI to configure the SIP port used by the Media Server. SIP T1/T2 timers are also configurable. When the SIP port is changed the Media Server must be restarted for the change to be effective, whereas SIP timer modifications are effective immediately. 6.9.1.4 SIP Performance Management Counters

The Media Server tracks incoming and outgoing SIP messages through new performance management counters.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 68 OF 93

6.10 Multiple Country Code Support
Feature ID(s): 13022 This activity enhances BroadWorks to support different country codes on a single Application Server. 6.10.1 Description Before this enhancement, it was assumed that all users on an Application Server were homed in the same country. This enhancement allows explicit assignment of different country codes to groups on the Application Server. Furthermore, the country code assigned to the group determines the tones that are provided to callers to that group (for example, ringback, busy, and so on). As a result, a single Application Server can host users in different countries in a transparent fashion.

6.11 Multiple Language Support
Feature ID(s): 10828 The multiple language support feature allows each BroadWorks Application Server to support multiple languages at the same time. This support is applicable to the web interface and the voice portal. Other parts of the system such as the CLI and alarms and performance measurements remain in English, as they are today. Administrators and users have the option to choose the language they prefer for their web interface and for their voice portal messages. Certain group services also have a language selection that determines the language that the service-specific messages are played in. This feature is important to international customers in areas where multiple languages are spoken such as Europe. 6.11.1 Description This feature allows each administrator or user to select a language preference. The language can be specified when the administrator or user is created. It can also be modified through the profile pages. But the change does not take effect until the administrator or user logs in again. In addition, certain group services are assigned a language to use for their announcements. These services are:
! ! ! !

Auto Attendant Call Center Hunt Group Voice Portal

Note that for the voice portal, only the initial greeting and login process are in the language set for the voice portal. Once the user has successfully logged in, the voice portal switches to the user’s selected language. A list of supported languages is set via the CLI. By default, the Application Server is delivered with English only. When specifying a new language, the corresponding locale and encoding should also be specified. Locale is used to specify a specific geographical, political, or cultural region. The format for locale is: <ISO Language Code>_<ISO Country
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 69 OF 93

Code> or <ISO Language Code> only. An ISO language code is a lower-case two-letter code as defined by ISO-639. You can find a full list of these codes at a number of sites, such as: http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt. An ISO country code is an upper-case two-letter code as defined by ISO-3166. You can find a list of these codes at a number of sites, such as: http://www.chemie.fuberlin.de/diverse/doc/ISO_3166.html. Encoding is a scheme used to represent numeric values for a character set. Encoding is required to display the character set correctly. When adding a language to the system, the system provider or partner is required to add the additional files necessary to support the new language before adding the language using the CLI. It should be noted that the localization process for a single language is modified in Release 11 to support multiple languages. This feature does not change the base functionality of the CLI or OSS interfaces. 6.11.1.1 Language Selection for Announcements Service announcements as well as system treatments are now played back using the user’s own language, when the (BroadWorks) user is originating a call. For terminating calls, the language used is that of the terminating BroadWorks user, so that the language used is the same regardless of whether the call is intra-group or not. For calls to virtual subscribers (such as an Auto Attendant, Call Center, Voice Portal and so on), the language used is the one provisioned for the called service. The only exception is for intra-group calls to the voice portal. In this case, the language of the caller is used. If announcements have not been provided for that language, the default system language is used. If the default language does not have corresponding announcements either, English is used. Note that it is possible to have language-specific directories in /var/broadworks/userfiles (for example, “/en” and “/ja”), as well as language and country directories (for example, “/en_US” and “/en_GB”). A directory like “/en” can be used for any user configured with an English-derived language, such as “en_US” and “en_GB”. This allows re-use of the same announcements for similar languages, if desired. For example, if an Application Server is configured with the following languages: “en_US”, “en_GB”, and “fr_CA”, and has the following user files directories: “/en”, “/en_GB” and “/fr”, languages map to announcements as follows:
Locale “en_US” “en_GB” “fr_CA" /var/broadworks/userfiles /en /en_GB /fr

This shows that the most specific directory (that is, where language and country match the user’s configured locale) is used if possible, otherwise the directory matching the language only is used.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 70 OF 93

6.11.1.2 Custom Service Announcements To support multiple languages, the web pages and command line interface commands that are use to select custom announcements (at a system level) are removed. The list of is as follows:
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

Account/Authorization Codes Announcements and Tones Call Park Customer-Originated Trace Emergency Zones Incoming Plan Instant Conferencing Outgoing Plan Anonymous Rejection Call Forwarding Always Call Forwarding Busy Call Forwarding No Answer Call Return Do Not Disturb Speed Dial 8 Speed Dial 100

The new method is to replace the treatment file in the Application Server announcement directory for each supported language, just like any other announcement. This allows simultaneous support of multiple languages for these announcements. For example, if there was a custom announcement for Customer-Originated Trace (COT) failure, in English, the custom version was (prior to Release 11) in: /var/broadworks/userfiles/COTFail/cot_fail_custom.wav (the file could have any name). During the upgrade to Release 11, the customer would overwrite /var/broadworks/userfiles/en/TrtCOTFailure.wav with the previous .wav file (cp .../cot_fail_custom.wav .../TrtCOTFailure.wav, preferably saving the original TrtCOTFailure.wav before). 6.11.1.3 Localization Files The files listed below are the localization files. The default <locale> provided is “en_US”.
!

Label files Label files contain the majority of the words and phrases that appear on the web pages or are sent in e-mails from various servers. These files reside in the bw_base/conf directory on the Application Server. Additional label files for different locales are placed in the same directory: − − − BroadworksLabels_<locale>.properties BroadworksXSLabels_<locale>.properties BroadworksError_<locale>.properties
2O-BD5013-00 PAGE 71 OF 93

BROADWORKS FUNCTIONAL SUMMARY

!

Online help files Online help is moved from the current directory structure public_html/Help/ to public_html/Help/<locale>/. Each translated language has an entire set of help pages in their appropriate locale directory.

!

Graphics − − − Since graphics can include words, they are required to be localized in addition to just branding the files. The portal graphics are moved from the current directory structure public_html/graphics to public_html/graphics/<locale>. The Call Manager and Attendant Console graphics are moved from the current directory structure public_html/commpilot/images/ to public_html/commpilot/images/<locale>.

!

Navigation and web page titles Two new property files are introduced to support the left navigation and web page title branding and localization: − − bw_base/conf/NavigationLabels_<locale>.properties bw_base/conf/ScreenTitlesLabels_<locale>.properties

Navigation and web page titles can still be customized by web branding. But the displayable text in menu.xml and ScreenTitles.properties are used as labels. These labels are used as the key to look up the real displayable text from two new properties files. When a new folder name or web page title is added for web branding, the appropriate properties files must be updated to add the new labels.
!

Configuration files The files bw_base/conf/StatesList.conf and TimeZoneAlias.conf are still used as configuration files. Two new property files are introduced for each language to support multiple languages: − − − bw_base/conf/StateListLabels_<locale>.properties bw_base/conf/TimeZoneAliasLabels_<locale>.properties

The format of StatesList.conf is changed as follows: #state name=state name label Alabama=ALABAMA North Carolina=NORTH_CAROLINA The state name label is used as the key to look up the displayable state name in StateListLabels_<locale>.properties. The tag on the left should remain in English and is the key stored in the database. If new states or provinces are to be added, a system provider or partner adds the value in the state list file and the label file for each locale. The format of the TimeZoneAlias.conf is the same except the “Time Zone Display Name” column is not optional. A label without space should be put in this column. The real displayable name is looked up in the TimeZoneAliasLabels_<locale>.properties file.
!

Mouse-over text
2O-BD5013-00 PAGE 72 OF 93

BROADWORKS FUNCTIONAL SUMMARY

A new mouse over text property file is introduced for each language: − bw_base/conf/MouseOverTextLabels_<locale>.properties

The existing mouseOverTxt.jsp only has a label for each mouse over string. The displayable text is looked up in the MouseOverTextLabels_<locale>.properties file.
!

Business group phone lists A new property file is introduced for each language: − bw_base/conf/BusinessGroupPhoneListLabels_<locale>.properti es

The existing bglist_detail.xsl and bglist_summary.xsl files are the same as before. There is a label for each displayable text in the .xsl files. The label is used as the key to look up the real displayable text in the BusinessGroupPhoneListLabels_<locale>.properties file.
!

Announcement files Localization of announcements consists of translating and writing each announcement listed in the BroadWorks Announcements Guide in the userfiles/xx or userfiles/xx_YY directory (where xx is the language, and YY is the optional country). For more information, see the BroadWorks Announcements Guide. This document not only lists all announcements that must be translated, but also how sentences, which are made of several smaller phrases, are dynamically constructed. Some languages cannot be translated by simply translating each .wav file directly. For example, some languages do not voice time and dates in a way that is compatible with the current framework. Should this be the case for one of the languages you need to support, please contact your BroadSoft support representative to make specific arrangements.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 73 OF 93

6.12 No-Charge Treatments
Feature ID(s): 12691 Currently, BroadWorks always answers a call with a SIP 200 OK when playing local treatments to network users. This feature allows BroadWorks to play local treatments to network users without answering the call so that the caller is not charged for the call. The ability to play local treatments without answering the call is configurable on a system basis and only applies to no-charge treatments This feature also ensures that the charge indicator (CI) field of the BroadWorks call detail record is set appropriately for call-receiving treatments (that is, it is set to “n” when a nocharge treatment is played). Throughout this document, a network user means that the user is not in the called user’s business group (that is, the call is not intragroup). The network user could either be a true PSTN user, or could be a user in a different business group. 6.12.1 Description 6.12.1.1 Provisioning The noChargeTreatmentWithoutAnswer system parameter is added to the System\CallP\Treatment level of the command line interface and is set to a default value of “false”. When set to “false”, BroadWorks always answers the call when playing local treatments. When set to “true”, BroadWorks does not answer the call when playing no-charge local treatments to network users. The call is still answered when charged local treatments are played or the user is not a network user. 6.12.1.2 No-Charge Local Treatments The following BroadWorks local treatments are no-charge:
! ! !

Incoming Calling Plan (ICP) Intercept Group Intercept User

The charge indicator in the BroadWorks call detail record is always set to “n” for these treatments. When these treatments are played to a network user and noChargeTreatmentWithoutAnswer is set to “true”, the call is not answered unless Intercept Group/Intercept User is configured to transfer on 0. When Intercept Group/Intercept User is configured to transfer on 0, the call is answered so that digit collection can be performed. The charge indicator in the BroadWorks call detail record is still set to “n” however. 6.12.1.3 Charged Local Treatments The following BroadWorks local treatments are charged:
! !

Anonymous Call Rejection Selective Call Acceptance
2O-BD5013-00 PAGE 74 OF 93

BROADWORKS FUNCTIONAL SUMMARY

!

Selective Call Rejection

The charge indicator in the BroadWorks call detail record is always set to “y” for these treatments unless the call is intra-group or City-Wide Centrex (CWC). Intra-group call and CWC calls always have the charge indicator set to “n” (that is, Anonymous Call Rejection, Selective Call Acceptance, and Selective Call Rejection are considered as a no-charge local treatment). When these treatments are played, the call is answered if the charge indicator is set to “y” and not answered if the charge indicator is set to “n”.

6.13 Configurable Tone Upon Disconnect
Feature ID(s): 13824 This capability applies to Media Gateway Control Protocol (MGCP) Integrated Access Devices. The timer is a system-wide configurable setting that starts when the remote call is released. When the timer expires, a message is sent to the access device to inform the device that the off-hook period has expired. It is the responsibility of the access device to apply the appropriate off-hook tone.

6.14 Open Client Interface Proxy
Feature ID(s): 12672 The Open Client Server is a new server in the BroadWorks suite of products. It is intended to simplify and provide a scalable interface to perform service creation using the already available CAP and OSS interfaces (the combination of the CAP and OSS interface make up the Open Client Interface). This server also has the capability to expose multiple interface protocols so that the various clients and interfacing systems can chose the most suitable protocol (that is, SOAP). It is expected that most external clients will take advantage of this server instead of developing third-party proxy servers in the future. The OSS interface requires additional changes to allow for a secure deployment and to enhance the robustness of the solution. 6.14.1 Description The Open Client Server supports two different installation configurations. The first configuration is for labs and demos and has the Open Client Server residing on the same box as the Application Server. The second configuration is installed on the External Web Server so that the Application Server resources are freed up for call processing. In either configuration, the Open Client Server can talk to both Application Servers in the redundant pair. There is no limit to the number of Open Client Servers that can serve a single Application Server. The Open Client Server also supports redundant and non-redundant Application Servers. For Release 11, the Open Client Server supports only a single cluster of Application Servers. The Open Client Server can be configured to be off, support CAP messages only, support OSS messages only or support both types of messages. For most applications, both CAP and the OSS interfaces are required to provide the necessary functionality.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 75 OF 93

S ec onda ry A p plic ation S erver

XS
PS

N etw o rk S erver

NS

C AP

XS

C AP

OCS

PS

O SS

P rim ary A pplic ation S erver

•

Figure 28 Configuration 1 – Open Client Server with Application Server

N e tw o r k S e rv e r

S e c o n d a r y A p p lic a t io n S e r v e r
NS

XS
PS
CAP

OCS

CAP
XS
OSS

PS

E x te rn a l W e b S e rv e r

P r im a r y A p p lic a t io n S e r v e r
P ro x y + E x te rn a l W e b S e rv e r

•

Figure 29 Configuration 2 – Open Client Server with External Web Server

The Open Client Server accepts TCP/IP connections from clients or other applications through the specified port to provide access to the Application Servers it services. The
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 76 OF 93

Open Client Server maintains TCP/IP connections to the Application Servers it services when the CAP interface is enabled. It maintains a CORBA connection to the primary Application Server or secondary Application Server when the OSS interface is enabled. It also maintains a CORBA connection to a Network Server when the CAP interface is enabled and the Application Servers that the Open Client Server services are redundant. The Open Client Server allows clients that connect via the TCP/IP connection to send and receive all CAP messages detailed in the CAP specification. The client is required to log in using the secure login before the Open Client Server sends any other messages. Each client must have a unique user ID, application type, and application ID when logging into an Open Client Server, otherwise the first login receives a duplicate client logout message. If an error occurs (such as lost connections to an Application Server) that prevents the Open Client Server from performing CAP functions, it cleans itself up and sends a logout to the client. It is assumed that the client application attempt to reconnect. If a CAP message is sent along a connection for a user that is not validated, the connection is disconnected. The Open Client Server allows clients that connect via the TCP/IP connection to send and receive OSS messages described in the provisioning specification. For Release 11, only system administrators, provisioning administrators and users are allowed to use the OSS functions. Each client is required to log in before performing any other function. The provisioning server is modified to maintain a list of authorized users and prevent clients from sending requests that are outside of their authorization. If an error occurs (such as lost connections to an Application Server) that prevents the Open Client Server from performing the OSS functions, it cleans itself up and sends an OSS logout message to the client. It is assumed that the client application attempts to reconnect. If an OSS message is sent along a connection for a user that is not validated, the connection is disconnected. In a redundant scenario, if a user is migrated to a secondary Application Server, the CAP message from the primary (logout for redundancy) are relayed to the client. The client is expected to log in again to the Open Client Server to receive messages from the secondary. Note that this does not mean the end user of the client has to be involved. All OSS requests are sent to the primary Application Server unless it is not available. The CAP and OSS interfaces versioning changes starting in Release 11are in sync with the releases. The version changes when a change is made to the interfaces and the new version is in sync with the release where the change is made. It is intended that all changes to these interfaces are backwards compatible for future releases. The Application Server supports as many backwards-compatible versions as possible.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 77 OF 93

6.15 Outgoing/Incoming OTG
Feature ID(s): 12869, 12870 This feature enhances the Network Server in two ways:
!

If the call originator is known in the system, and if it is provisioned with an Originating Trunk Group (OTG), this OTG value is added to each Contact entry in the outgoing 302 Moved temporarily SIP message. If an incoming SIP INVITE message has its source header populated with an OTG parameter, and if the call originator is not known in the system, the Network Server uses this OTG to find the enterprise, user group, or site originating the call. If the Application Server receives an OTG from the Network Server, it adds it to the outgoing SIP INVITE message sent to the destination specified by the Contact entry.

!

This feature also enhances the Application Server as follows:
!

6.15.1 Description 6.15.1.1 Originating Trunk Group (OTG) An OTG, known as sourceId in the Network Server, is another way to identify an enterprise, user group, or site in the system. When a sourceId identifies an enterprise, user group, or site, it can also be used to identify any other subscriber in the system. A one-to-many mapping therefore exists between a sourceId and a Network Server subscriber (enterprise, user group, or site). The sourceId is a string that can contain up to 128 characters, the minimal length being 0 (a 0-length sourceId simply means that the subscriber has no sourceId and does not use the OTG feature). The sourceId can only be composed of alphanumerical characters, as specified by the SIP RFC. A sourceId can be provisioned at the enterprise, user group, and site levels. 6.15.1.2 Outgoing OTG During a call, if the Network Server can identify that the originator has a valid sourceId, that is, the originating entity (enterprise, user group, or site) has a provisioned sourceId, it populates the OTG parameter in each Contact entry, using the following logic:
Site of Caller User Group of Caller Enterprise of Caller sourceId Used in Outgoing OTG in 302 Contact Entry A B C OTG not added

A Not provisioned Not provisioned Not provisioned

Do not care B Not provisioned Not provisioned

Do not care Do not care C Not provisioned

The OTG parameter is only added if the 302 message is to be sent back to a hosting network element that supports the sourceId signaling option. Also, the OTG parameter is only added if the call originator is derived from the From, P-Asserted-Identity, or RemoteParty-ID header. If the Network Server considers that the call originator is identified by the Diversion header, the OTG parameter is not added.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 78 OF 93

The Network Server does not support direct OTG tandeming; the OTG parameter returned in 302 Contact entries is only based on internal processing, regardless of its presence or not in the SIP INVITE message. 6.15.1.3 Incoming OTG Currently, the Network Server route processing phase starts by determining the call originator and then it finds the routing profiles to use. In general, the call originator is taken from one of the following headers, in this order:
1) 2) 3) 4)

Diversion, if present, or P-Asserted-Identity, if present, or Remote-Party-ID, if present, or From

The incoming OTG feature is only triggered if the Network Server derives the call originator from the From or P-Asserted-Identity header. If the call originator as determined by the Network Server is taken from the Remote-Party-ID or Diversion header, incoming OTG is not supported. Once the originating URI is identified, the Network Server uses the user and host portions of the originating URI to map the caller to a known subscriber in the system. With the incoming OTG feature, if no subscriber can be identified from the originating URI, the Network Server finds the subscriber to use by looking at the OTG parameter in the call originator header (From or P-Asserted-Identity) of the SIP INVITE request. If the OTG parameter is present, the Network Server extracts it to find the corresponding subscriber in the system, using the following logic:
OTG Maps to Site Yes Not applicable OTG Maps to User Group Not applicable Yes OTG Maps to Enterprise Not applicable Not applicable Public Profile Used Site profile User group profile Private Profile Used Site’s enterprise private profile User group’s enterprise private profile Enterprise private profile Same logic as today

Not applicable No

Not applicable No

Yes No

Enterprise public profile Same logic as today

Incoming OTG support is always enabled and cannot be turned off. 6.15.1.4 Application Server The Application Server only honors the P-Asserted-Identity header parameter included in a 302 response when it comes from a Network Server. In this case, if the Application Server receives a 302 response in which Contact entries contain a P-Asserted-Identity header parameter, the Application Server replaces the contents of the calling party information with the contents of the P-Asserted-Identity including the OTG URI parameter, if present. The Application Server then populates the resulting INVITE with the calling party information obtained from the Network Server. This information is populated in the FROM header, Remote-Party-ID, or P-Asserted-Identity header as determined by the Application Server SIP network interface configuration (that is, determined by the privacyVersion system parameter).
BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 79 OF 93

6.16 Per-Enterprise LCA
Feature ID(s): 12868 Currently, the Network Server can only work with one local calling area (LCA) file at a time, and all LCA rules are defined system-wide and are shared by all subscribers. This feature creates a framework that allows the Network Server to support one or more concurrent sets of LCA rules that can be assigned to subscribers. 6.16.1 Description 6.16.1.1 Subscriber Local Calling Area Within the current Network Server schema, local calling areas are defined system-wide and are shared by all subscribers in the system. This feature introduces the concept of subscriber local calling areas. This means that a user group or an enterprise can be provisioned with a local calling area (that is, the lcaid). The following rules apply:
User Group LCA specified Enterprise Do not care NDC Do not care Call Screening Choice If the caller is part of a user group that has an LCA specified, Call Screening uses this LCA. If the caller is part of an enterprise that has an LCA specified and none defined at the user group level, Call Screening uses this LCA. Call Screening uses the LCA defined at the system/NDC level if the user group and enterprise of the caller have no LCA specified. Call Screening skips LCA screening if no LCA is specified at the user group, enterprise, or system/NDC level. Note however that LCA screening based on NPANXX/rate center continues to apply if NPANXX/NNACL is used.

No LCA specified

LCA specified

Do not care

No LCA specified

No LCA specified

LCA specified

No LCA specified

No LCA specified

No LCA specified

Currently, the Network Server supports the loading and management of LCA files. Using the commands under NS_CLI/System/CallP/Translation/, the LCA file can be loaded and stored in the Network Server database. The LCA content can then be altered using the commands under NS_CLI/System/CallP/Translation/LCA. This feature continues to support the current LCA management but the LCA file content syntax is enhanced to support the grouping of LCA rules under an LCA ID. This LCA ID can then be used as the subscription key assignable to user groups and enterprises to refer to a set of LCA rules. The Network Server defines a reserved LCA ID called “DFLT_LCA_ID” that cannot be created nor deleted using the CLI. This LCA ID is reserved to support local calling areas defined before the introduction of this feature. By default, after an upgrade, all the LCA rules that currently exist in the system are all grouped under the LCA ID called “DFLT_LCA_ID”. The LCA ID chosen to define a local calling area based on NDC/rate center/zone cannot be used to define a local calling area based on NPANXX/rate center, and vice versa.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 80 OF 93

6.17 Pre-Typing Policy
Feature ID(s): 12867 This feature introduces a new public policy, called PreCallTyping. When used, this policy supersedes call type determination performed by the country code-based CallTyping policy. 6.17.1 Description 6.17.1.1 Policy This feature introduces a new public routing policy, called PreCallTyping. The purpose of the policy is not to find a destination for a call; it is rather to associate a call type to an incoming call. In fact, the new policy performs the same tasks as CallTyping does today. The only difference is the dial plan used to perform the call typing determination. CallTyping uses system-wide, country code-based, dial plans, and PreCallTyping uses a policy instance-specific dial plan. The following figure provides an overview of the processing flow of PreCallTyping and its interaction with CallTyping. As the figure shows, PreCallTyping can be used to override some or all results given by CallTyping, in order to bypass country code-based CallTyping when a more specific, instance-based call typing, is needed. So in a typical deployment, CallTyping continues to be the primary mechanism to derive call types, with PreCallTyping handling special cases or exceptions for some subscribers only. PreCallTyping is a public routing policy that can be assigned to any profile, with or without CallTyping.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 81 OF 93

Policy processing

Start PreCallTyping Start CallTyping

PreCallTyping in profile?

CallTyping in profile? Y
Call typing result already found (result != NIL)?

Y Go in policy instance dial plan and get call typing result

N Call typing result found? N N Go in country code dial plan and get call typing result N Perform called number normalization Call typing result found? Y Perform called number normalization N Call failure

Y

Y

Continue processing

Continue processing

•

Figure 30 Call Typing Policy

Like all policy instances in the system, a PreCallTyping policy instance can be enabled or disabled using the CLI. Also, PreCallTyping is introduced as a multi-instance policy, meaning that more than one PreCallTyping policy instance can exist in the system. 6.17.1.2 Dial Plan Currently, the CallTyping policy accesses system-wide country code-based dial plans to find the call type for calls. With PreCallTyping, each policy instance defines its own dial plans. Dial plan names used in PreCallTyping do not need to be pre-provisioned for them to be used in dial plan entries. The dial plan name in a dial plan entry is simply a string that identifies a dial plan. However, the PreCallTyping policy, when processing a call, always tries to find a dial plan called “dflt”, if the called number is a not an E164 number. Similarly, PreCallTyping always tries to find a dial plan called “dflt_e164”, if the called number is an E164 number. These two names, “dflt” and “dflt_e164”, are therefore the entry dial plan names for PreCallTyping. Other dial plan names can also be created for the support of the dial plan re-entry functionality (DP=xxx action).

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 82 OF 93

A PreCallTyping dial plan entry is like a CallTyping dial plan entry. The only difference is that it has an extra attribute that specifies the policy instance to which it applies.

6.18 Ring Period
Feature ID(s): 13757 Ring Period is a group-configurable time indicating how long the current localized ring back tone is. This value is used to calculate the total ring time (4 rings x Ring Period = total ring time) for services that use the No Answer Timer, for example, Call Forwarding and Voice Mail services.

6.19 SIP Enhancements
Feature ID(s): 11625 This activity enables the BroadWorks Application Server to become fully compliant with RFC 3311. This includes the ability to send and receive the SIP UPDATE request. RFC 3311 support allows call-related information to be updated without having to use a reINVITE. Thus this feature provides the ability to improve performance, to reduce exposure to re-INVITE collisions, and to allow SIP-related updates during the call setup. 6.19.1 Description This feature enables the BroadWorks Application Server to become fully compliant with RFC 3311. This includes the ability to send and receive the SIP UPDATE request. The BroadWorks Application Server sends a “504 Server Time-out” response when unable or unwilling to allow a received UPDATE request to update the SDP information. This response informs the receiver that the re-INVITE mechanism should be used when updating an SDP. The following are some of the SIP headers that the BroadWorks Application Server allows to be updated when it receives an UPDATE request: Allow, Contact, Min-SE, SessionExpires, and Supported.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 83 OF 93

6.20 SIP as Media Server Control Protocol
Feature ID(s): 12357, 10861 To comply with open standards and facilitate integration with third-party partner devices, two proprietary Media Server-related interfaces are replaced with open standards. MCP The proprietary Media Control Protocol (MCP) is abandoned in favor of the SIP (Session Initiation Protocol) protocol. MCP was used for IVR and conferencing control between the Application Server and the Media Server. This section describes the Application Server functional changes necessary to remove MCP in favor of SIP (and MSCML for IVR). Media Server changes are outside the scope of this document. MSS The Media Server Selection (MSS) proprietary protocol is also removed3. This protocol allowed the Application Server to communicate with the Network Server, to request a list of Media Servers to use for a particular media connection. MSS is again replaced with a SIP-based solution (INVITE request and 302 Moved temporarily response). On the Network Server, this feature enhances Media Server Selection processing to have different routing rules based on the service requesting MSS. 6.20.1 Description 6.20.1.1 Protocol Description This feature introduces the support of MSS over the SIP protocol. Currently, MSS requests coming from Application Servers use the proprietary Media Server Selection (MSS) protocol. MSS responses returned by the Network Server also use this protocol. In Release 11, the Network Server supports Media Server Selection over MSS and SIP but in a later release, the MSS protocol will be rendered obsolete. To initiate an MSS request using SIP, the Application Server sends a SIP INVITE message to the Network Server, by using a SIP INVITE message similar to the one it intends to send to the Media Server, and by (optionally) adding the following new proprietary header:
P-Broadsoft-MSSGatewayAddress:<Gateway address>

It also needs to use a Request URI in which the host portion represents a valid Network Server address, as defined under NS_CLI/System/Alias. Notes:
!

The trigger that the Network Server uses to differentiate an MSS request from other requests is contained in the Request URI. The Network Server treats the request as an MSS request if the user part contains one of the known service names, and the host portion is the Network Server address. If the Application Server wants an MSS result based on a provided DN (Directory Number), it should add the number to the From header of the SIP INVITE message to the Network Server, such as “DN@application.server”, where <DN> is an E.164-

!

The Network Server will continue to support MSS for one or two releases, for backward compatibility with older Application Servers. BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 84 OF 93

3

formatted directory number for which closest Media Servers are required. It is possible (although unlikely) in this context to omit the user part in the From header if the Application Server does not want to use a DN (or URL). In this case however, a gateway address would have to be provided (in the new proprietary header PBroadsoft-MSSGatewayAddress).
!

If the Application Server wants an MSS result based on a provided URL, it should use this URL in the From header, this URL being the one for which closest Media Servers are needed. A DN cannot be used in addition to a URL. If the Application Server wants an MSS result based on a provided gateway address, it should add the proprietary header “P-Broadsoft-MSSGatewayAddress:<Gateway address>” to the SIP INVITE message, where <Gateway address> is the address, host, or domain of a Routing network element (NE) for which closest Media Servers are needed. A gateway address can be used in addition to the aforementioned From header containing a DN or URL. The service information that the Network Server needs to perform the MSS request is contained in the Request URI. When the Application Server wants an MSS result for a specific service, it should create a Request URI containing a SIP URI encoded as <service>@<NS address>, where <service> is the specific Media Server service name, and <NS address> is a valid address for the Network Server as defined in NS_CLI/System/Alias. The Network Server uses the first entry of the Via header to identify the source of the MSS request. It uses it to return to the sender the 302 Moved temporarily response containing the MSS results. The Network Server assumes that the MSS request comes from an Application Server, it does not verify that the source address really maps to a Hosting NE address provisioned in the Network Server. Before Release 11, the Network Server did not discriminate between services when processing an MSS request. This feature makes changes in order to support services-based Media Server Selection. With this, it is now possible to create different lists of Media Server addresses depending on the service requesting MSS. Services can now be specified in the routing lists of Media Server Selection policy instances, in Resource NE/Routing NE MSS mapping, and in Media Servers themselves. The (up to now unused) service names previously sent by the Application Server (such as Voice Messaging Group or Simultaneous Ring Personal) are replaced by a service class names (such as “ivr” or “conf”). The new SIP proprietary header P-Broadsoft-MSSGatewayAddress syntax can be defined using the BNF notation. It is: "P-Broadsoft-MSSGatewayAddress" HCOLON host where host is an RFC 3261 SIP host with non-support for IP version 6. This assumes that only one header and host is valid within a SIP message. It also assumes that all characters found after the “:” are part of the host name.

!

!

!

!

!

!

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 85 OF 93

6.20.1.2 Network Server This feature replaces the MSS protocol by the SIP protocol; it does not impact other functions of the Media Server Selection feature or routing policy, except that it now takes under consideration the service name when obtaining Media Server addresses. At the end, the result is returned using SIP instead of MSS. The Network Server returns the result of Media Server Selection in a SIP 302 Moved temporarily message, similar to the one shown below.
SIP/2.0 302 Moved temporarily Via:SIP/2.0/UDP 192.168.13.40;branch=z9hG4bK-BroadWorks.192.168.13.40192.168.13.5V5060-0-109103350-2021982911-1067517579755 From:"JOHN SMITH"<sip:+13331112025@192.168.13.40;user=phone>;tag=20219829111067517579755 To:<sip:ivr@mtlns04.mtl.broadsoft.com:5060> Call-ID:BW0739390755301003044-129939463426@192.168.13.40 CSeq:109103350 INVITE Contact:<sip:ivr@mtlms01.mtl.broadsoft.com:5060>;q=0.5,<sip:ivr@mtlms02.mtl.broadso ft.com:5060>;q=0.25 Content-Length:0

Notes:
!

Each Media Server address found by the Network Server is added to the Contact header. The Network Server never includes the new proprietary P-BroadsoftMSSGatewayAddress header in the response, even if it is present in the SIP INVITE request.

!

Usable Media Server addresses are returned in order of preference in the Contact header. If the Network Server finds no suitable Media Server address, it returns a 404 Not found message. The Network Server can also return other responses if errors are encountered while processing the request. The Media Server Selection transaction initiated by the Application Server ends when the later sends to the Network Server a SIP ACK message. Because Media Server Selection now uses the SIP protocol, the following results are observed:
!

MSS requests are now taken under account as part of the Network Server licensing framework. The bwNSCallGotTreatment alarms can be produced by failed MSS requests, depending on configuration. MSS transactions can now be captured by the Call Logs framework. The SIP performance measurement counters and counter tables (under networkServer/protocol/sip/ in the Network Server MIB) are now incremented by MSS transactions. Therefore, SIP-based MSS transactions are not incremented by the NRS counters (under networkServer/protocol/nrs/ in the Network Server MIB). The vtr tool now used instead of the “vmss” tool to verify and debug Media Server Selection processing. SIP protocol attributes such as T1 and T2 timers (under NS_CLI/Interface/SIP) now impact Media Server Selection processing. Media Server SIP polling is now fully supported.
2O-BD5013-00 PAGE 86 OF 93

!

! !

!

!

!

BROADWORKS FUNCTIONAL SUMMARY

6.20.1.3 Application Server The Application Server is modified to use SIP INVITE instead of MSS to select a Media Server. The new interface is described in the previous section, and this results in the Application Server sending an INVITE similar to the following (if the Application Server wants to obtain a result based on both a DN and a gateway address, for the ivr service):
INVITE sip:ivr@mtlns04.mtl.broadsoft.com SIP/2.0 Via:SIP/2.0/UDP mtlas02.mtl.Broadsoft.com:5060;branch=z9hG4bKBroadWorks.192.168.8.52-192.168.8.22V5060-0-198724658-1857280961-1065549338722 From:"john rb"<sip:+15146981501@mtlas02.mtl.broadsoft.com;user=phone>;tag=18572809611065549338722 To:<sip:ivr@mtlns04.mtl.broadsoft.com> Call-ID:BW1355380722071003041-11434686810@192.168.8.52 CSeq:198724658 INVITE Contact:<sip:mtlas02.mtl.Broadsoft.com:5060> Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER Supported:100rel,timer Min-SE:60 Max-Forwards:10 P-Broadsoft-MSSGatewayAddress:192.168.7.7 Content-Length:0

If the Application Server wanted a result based solely on a URL for a conferencing port (and without a gateway address), it would send an INVITE such as this one:
INVITE sip:conf@mtlns04.mtl.broadsoft.com SIP/2.0 Via:SIP/2.0/UDP mtlas02.mtl.Broadsoft.com:5060;branch=z9hG4bKBroadWorks.192.168.8.52-192.168.8.22V5060-0-198724658-1857280961-1065549338722 From:"john rb"<sip:usereb@broadsoft.net;user=phone>;tag=1857280961-1065549338722 To:<sip:conf@mtlns04.mtl.broadsoft.com> Call-ID:BW1355380722071003041-11434686810@192.168.8.52 CSeq:198724658 INVITE Contact:<sip:mtlas02.mtl.Broadsoft.com:5060> Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER Supported:100rel,timer Min-SE:60 Max-Forwards:10 Content-Length:0

The Network Server to which the INVITE is sent to is defined in AS_CLI/System/Device/NetServer. Eliminating the MSS protocol has several system impacts as follows:
Alarms

The two existing MSS-specific alarms are still used with Media Server selection over SIP. In addition, the bwSipMaxRetriesExceeded alarm can also be generated by the SIP protocol layer when appropriate (typically associated with a bwMssNoResponse).
! !

bwMssNoResponse is raised when all of the Network Servers have failed to respond. bwMssNetworkServerNotResponding is raised a Network Server fails to respond, but there are still Network Servers to try.

Performance Measurements

The following two existing MSS performance measurements continue to be pegged with the new SIP-based Media Server selection:
!

bwNSqueryCommFailure (Application Server could not communicate with the Network Server) bwNSqueryRequestsTransmitted

!

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 87 OF 93

This next one however is removed since MSS protocol retransmissions do not occur anymore4:
!

bwNSqueryRequestsRetransmitted

Protocol Monitor

The “mss” protocol disappears from the list of available protocols in the AS_CLI/Monitoring/ProtocolMonitor tool. Media Server selection messages can now be viewed by monitoring the SIP protocol.
MSS Interface Configuration Parameters

The AS_CLI/Interface/MSS configuration parameters were previously the following ones (with the default value in parentheses):
! ! ! ! !

active (false) localPort (5677) remotePort (5677) maxRetransmissions (3) retransmissionDelay (200)

All these parameters have no meaning anymore with this feature, with the exception of the active parameter. It is still required when statically configured Media Server are used. In this case, no Media Server selection query is made to the Network Server. The parameter changes name and CLI menu however. It is now under AS_CLI/System/Routing/MediaServerSelection and is called useStaticMediaServerDevice. The entire AS_CLI/Interface/MCP CLI level is removed.
Static Media Server Configuration

The CLI menu where static Media Servers were configured is moved from AS_CLI/System/Device/Media to its new location, AS_CLI/System/Routing/MediaServerSelection/Device, where it coexists with the useStaticMediaServerDevice Boolean parameter, along a few other parameters. A Media Server is still configured as before, by providing an IP address, port, and optional description. Only the CLI menu location has changed. Note that a service class is not associated with a given Media Server when statically configured on the Application Server. So, statically configured Media Servers cannot be chosen according to specific service requirements, nor can they be selected according to a user’s DN, URL, or gateway address.
Message Retransmissions

The retransmission strategy used for Media Server selection over SIP differs from that previously used for the MSS protocol. The configured SIP retransmission strategy (based on the T1 and T2 parameters) is used, but total delay is limited by a new timeout value used to advance to the next Network Server should one fail to respond within the configured delay. When the timer times out, the current INVITE is cancelled and is sent to the next Network Server. This is similar to the network routing’s routeTimerLength timer. This timer is used whenever route advancing is still possible, that is, it is started for all but the last Network Server in the list. For the last one, the SIP protocol timers as well as mediaServerTimerLength are used. This newly introduced timer is available from the
4

SIP protocol retransmissions occur as configured for SIP, that is, using the T1 and T2 timer values, but without pegging MSS performance counters. BROADWORKS FUNCTIONAL SUMMARY 2O-BD5013-00 PAGE 88 OF 93

AS_CLI/System/Routing/MediaServerSelection menu and is called mssRouteTimerLength. Note that in addition to the SIP and mssRouteTimerLength timers, the mediaServerTimerLength timer is always used when sending messages to Network Servers (for MSS) or Media Servers, but since its value is typically higher than mssRouteTimerLength, it has no impact when route advancing is possible.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 89 OF 93

6.21 Solaris 9 Support
Feature ID(s): 10869 This activity adds support for Solaris 9 for the BroadWorks installation and upgrade process. BroadWorks servers benefit from Solaris 9 performance and security enhancements by improving server speed and simplifying system installation. Fresh installation can be performed on either Solaris 8 or 9. A system currently installed on Solaris 8 will have to be eventually migrated to Solaris 9 using a live upgrade, which allows a server to be upgraded while running. However, for your convenience this will not be enforced until Release 12. Hence, customers have the flexibility to plan their OS upgrade as Release 11 supports both Solaris 8 and 9. 6.21.1 Description 6.21.1.1 Solaris 9 Build and Packaging Since Solaris 9 maintains binary compatibility with earlier versions of Solaris software, it is not required to build BroadWorks software on Solaris 9. However, dynamic libraries (.so) and binary executables (such as msfe on the Media Server) benefit from being built with the Solaris 9 compilers. Hence, as of Release 12, BroadWorks is built on Solaris 9, while Release 11 continues to be built on Solaris 8. 6.21.1.2 BroadWorks Dual Solaris 8 and 9 Installation Installation for Solaris 8 and 9 is provided by the same installation tarball. In the relevant install scripts, a check is added to discover what version of the OS is running and only install the appropriate software. Otherwise, the installation and upgrade remains the same Even if BroadWorks installation tarballs support both Solaris 8 and 9, it is enforced that fresh installations of Release 11 are done on Solaris 9. 6.21.1.3 Simplified SMC/SUN Package Installation Free software packages can be obtained from http://www.sunfreeware.com for both Solaris 8 and 9. Starting from Release 10, those packages are used as is directly from Sun. This has many advantages, one of them being that it simplifies deployment of updated packages. Another advantage is that Solaris maintains the integrity of installed packages through its software package management (pkgadd, pkgrm, pkginfo). The software package management also handles upgrades. On Solaris 8 system, the following sets of binaries are deployed:
! ! ! ! ! ! ! !

SMClibgcc, version 3.3 SMCzlib, version 1.1.4 SMCgdb, version 5.0 SMCtop, version 3.5beta12.5 SMCpopt, version 1.7 SMCossl, version 0.9.7c SMCossh, version 3.7.1p2 SMCrsync, version 2.5.6
2O-BD5013-00 PAGE 90 OF 93

BROADWORKS FUNCTIONAL SUMMARY

! ! ! ! ! ! !

SMCtcpwr, version 7.6 SUNWjass, version 2_1 SMCexpect, version 5.38 SMClsof, version 4.68 SMCsudo, version 1.6.7p5 SMCncurse, version 5.3 SMCmysql, version 3.23.53 SMClibgcc, version 3.3 SMCzlib, version 1.1.4 SMCgdb, version 5.0 SMCtop, version 3.5beta12.5 SMCpopt, version 1.7 SMCrsync, version 2.5.6 SMCtcpwr, version 7.6 SUNWjass, version 2_1 SMCexpect, version 5.38 SMClsof, version 4.68 SMCsudo, version 1.6.7p5 SMCncurse, version 5.3 SMCmysql, version 3.23.53

On Solaris 9 system, the following sets of binaries are deployed:
! ! ! ! ! ! ! ! ! ! ! ! !

In Solaris 9, SSH and SSL implementations are provided by the operating system as SUNSSH and SUNSSL. 6.21.1.4 Security Hardening with JASS As of Release 11, security hardening is implemented by JASS rather than through BroadWorks installation scripts. However, in order to keep full control of which services are enabled or disabled, the BroadWorks installation drives JASS configuration file (/opt/SUNWjass/Drivers/finish.init). Modification to this file is done before running the JASS security hardening script. The Solaris Security Toolkit, informally known as the JumpStart Architecture and Security Scripts (JASS) toolkit, provides a flexible and extensible mechanism to minimize, harden, and secure Solaris operating environment systems. The primary goal behind the development of this toolkit is to simplify and automate the process of securing Solaris systems. The JASS toolkit performs the following major tasks:
1) 2) 3)

Shuts down all unnecessary services in /etc/inetd.conf. Removes unneeded startup/shutdown scripts in /etc rc0.d, rc1.d, rc2.d, rc3.d. Hardens the IP interface by replacing the nddconfig file.

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 91 OF 93

The JASS package has been modified for compatibility with BroadWorks servers. BroadSoft recommends using JASS as one of the steps in securing your servers and the network. 6.21.1.5 SUN Management Center Upgrade Required with Solaris 9 Solaris 9 requires that the latest SUNWsymon package be installed. The package is available at: http://wwws.sun.com/software/solaris/sunmanagementcenter/ds/ds-sunmc35/index.html. 6.21.1.6 Upgrading to Solaris 9 with Live Upgrade Solaris supports two types of upgrade: standard upgrade and live upgrade. It is also possible to perform a fresh Solaris 9 install.
Standard upgrade or fresh installation

A standard upgrade, or fresh install, requires that the server is booted from Solaris 9 “CD 1 of 2” CD. When requested to choose between “Upgrade or initial”, select “Upgrade”. (Note that this could also be performed with a jumpstart server.) The server is then installed or upgraded, however this could take some time.
Live upgrade

A live upgrade makes it possible to upgrade system with minimal downtime. Basically for a live upgrade you work on a second disk, which could be the mirrored disk. You upgrade and patch it while the OS and BroadWorks are still up and running. When the upgrade is complete, simply reboot the server and Solaris 9 should start. If anything goes wrong when rebooting, it is always possible to fall back to the old boot environment. Solaris documentation describing a live upgrade is available from the following web sites: http://wwws.sun.com/software/solaris/liveupgrade/ http://docs.sun.com/db/doc/806-5205 http://wwws.sun.com/software/whitepapers/wpsolarisinst/solaris_installation_deployment.pdf

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 92 OF 93

6.22 Unregistered Endpoint Announcement
Feature ID(s): 12989 A system -level option is provided to enable the routing of calls made by a user from an unregistered device to a new unregistered user treatment. This treatment provides an announcement indicating that the user is not registered to make calls. The addition of this treatment is part of the ongoing effort to enhance BroadWorks error handling and feedback. 6.22.1 Description This functionality allows the system provider to configure whether non-emergency and non-repair calls originated by a user from an unregistered device are routed to the unregistered user treatment (post-answer). An unregistered device is defined as a device that has at no unexpired registrations for that user and does not have a host name/host address manually configured against it. The source IP address of the SIP INVITE is not screened against the list of registered addresses. The Application Server merely checks that there is at least one valid registration or that a host name/host address has been manually configured for that device. Also note that registrations for only the device the call is placed from, is examined. If the user is assigned to multiple devices in a Shared Call Appearance configuration, the Application Server does not check registrations for any of the other devices assigned to the user. The default status of this functionality is “inactive”, indicating such calls should not be routed to treatment. The unregistered user treatment is a new system-level customizable treatment. When triggered, the treatment is played in the language of the originating user. When active, unregistered user screening occurs after SIP access control list screening but prior to Emergency Zones screening. The following examples illustrate the relationship:
!

If both SIP access control and unregistered user treatment are enabled, and a user originates a call from an unregistered device, the call is denied by SIP access control with no Application Server provided treatment. If SIP access control is disabled and unregistered user treatment is enabled, and a user originates a call from an unregistered device, the call is met by the unregistered user treatment and routed to announcement. If both unregistered user treatment and Emergency Zones are enabled, and a user originates a call from an unregistered device whose IP address is outside the Emergency Zone, the call is met by the unregistered user treatment and routed to its announcement. If unregistered treatment is disabled and Emergency Zones are enabled, and a user originates a call from an unregistered device whose IP address is outside the Emergency Zone, the call is met by the Emergency Zones treatment and routed to its announcement.

!

!

!

BROADWORKS FUNCTIONAL SUMMARY

2O-BD5013-00 PAGE 93 OF 93


				
DOCUMENT INFO
vverge vverge
About