BroadWorks Functional Summary - CommPartners Connect

BROADWORKS 

FUNCTIONAL SUMMARY 

RELEASE 11 

Version 1

BroadWorks ® Guide 

Copyright Notice 

Trademarks 

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. 

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 Introduction............................................................................................................6 

2 User Services .........................................................................................................7 

2.1 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 


PAGE 3 OF 93

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 Call Capture and Trace Utility ....................................................................... 40 

5.1.1 Description ........................................................................................... 40 

5.2 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 

5.3 OSS Enhancements...................................................................................... 48 

5.3.1 Description ........................................................................................... 48 

5.4 Performance Enhancements for Troubleshooting....................................... 49 

5.4.1 Description ........................................................................................... 49 

5.4.2 Memory Monitoring.............................................................................. 50 

5.5 Service Pack Migration Tools ....................................................................... 51 

5.5.1 Description ........................................................................................... 51 

6 System ..................................................................................................................53 

6.1 Call Client Hold Integration............................................................................ 53 

6.1.1 Description ........................................................................................... 53 

6.2 Calling Line ID Delivery Enhancements....................................................... 55 

6.2.1 Description ........................................................................................... 55 

6.3 Configurable Ringing Timeout ...................................................................... 56 

6.4 Element Management System ..................................................................... 56 

6.4.1 Description ........................................................................................... 57 

6.5 G.729 Codec Support.................................................................................... 61 

6.5.1 Description ........................................................................................... 61 

6.6 International Call Screening .......................................................................... 61 

6.6.1 Description ........................................................................................... 61 

6.7 Line/Port Domain Scoping ............................................................................ 63 


PAGE 4 OF 93

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 


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. 


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 


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. 


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”. 


PAGE 7 OF 93

2.3 Holiday Schedule for Auto Attendant 


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. 


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. 


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 


PAGE 9 OF 93

2.4 Enhanced Business Hour Support 


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. 


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. 


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. 


PAGE 11 OF 93

2.5 Caller ID Restriction Override 


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. 


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. 


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.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. 


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. 


PAGE 14 OF 93

2.7 Auto Callback 


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. 


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


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 


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. 


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. 


PAGE 16 OF 93

2.9 User Category Service 


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. 


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 

Description 

Ordinary User has no special characteristics 

Payphone User represents a smart payphone 

Prison User is from a prison 

Hotel User is from a hotel or motel 

Hospital User is from a hospital 

Special 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. 


PAGE 17 OF 93

2.10 Call Waiting 


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. 


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 


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. 


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. 


PAGE 18 OF 93

2.12 Configurable Calling Line ID for Emergency Calls 


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 


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” 

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

− 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” 


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. 


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. 


PAGE 20 OF 93

3 Group Services 

3.1 Department Music On Hold 


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. 


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. 


PAGE 21 OF 93

System 

Service Provider(s) Enterprise(s) 

Group(s) 

• Figure 7 Enterprise Layer 


3.2.1.1 Introducing the Enterprise 

Group(s) 

User(s) User(s) 

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: 


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. 


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

the enterprise. 


PAGE 23 OF 93


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. 



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. 


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. 


PAGE 26 OF 93

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


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. 

3.2.1.5 Priority Alert: 

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. 


PAGE 28 OF 93

3.3 Originating Fully Restricted 


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.1 Applicability of Enhancement 

The configuration of the Outgoing Calling Plan is enhanced as follows: 

Group – Originating User – Originating 

Group – Fwd/Transfer is renamed to 

Group – Forwarding/Transferring 

User – Fwd/Transfer is renamed to 

User – Forwarding/Transferring 

Group – Being Forwarded/Transferred (new) 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. 

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

� 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 


PAGE 29 OF 93

“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. 

3.3.1.2 Scope of Applicability of the OCP-Restriction 

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 

� the transferred user: 

− is reconnected with the transferring user if the user answers 

− is dropped otherwise 

3.3.1.6 Conferences 

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. 


PAGE 30 OF 93

3.4 Terminating Fully Restricted 


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 Release 10 Release 11 

A Option checked Option set to Y (yes) 

B Option unchecked Option set to P (partial) 

C Not applicable 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. 


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


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. 


PAGE 32 OF 93

4 Messaging Services 

4.1 Callback Returns to Voice Mail 


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. 


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. 


PAGE 33 OF 93

4.2 Send to VM Feature Access Code 


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. 


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 


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.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. 


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 


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. 


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. 


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) Wait for the prompt to timeout, or enter the # without entering any digits. The user is 

returned to the Voice Portal main menu. 

2) 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. 


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 

4.4.1.3 Terminate-Call Function 

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 

1 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. 


PAGE 37 OF 93

“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. 

SIP/MGCP 

Called VP 

Party User 

• Figure 17 Terminate-Call Function 

MSCML Repeater commands 

Repeater 

Function 

Voice Portal 

IVR Digit 

Collection 

Function 

Application Server 

MSCML IVR commands 

Media Server 

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. 


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. 


PAGE 39 OF 93

5 Operations, Administration, and Maintenance 

5.1 Call Capture and Trace Utility 


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. 


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. 


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


PAGE 41 OF 93

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. 

End-User 

http ajp 

http 

Public 

EWS Pair 

Application CS Pair 

• Figure 18 Accounting Integration 

Private 

5.2.4 Bridge Provisioning Enhancements 

http 

NS Cluster 

AS Cluster 

Media CS Cluster 

http 

http 

Administrator 

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. 

Created 

by 

View/ 

Modify 

Bridge Admin A 

Bridge Admin B 

Bridge Admin C 

• Figure 19 Release 9.1 and 10 Relationship Model 

Conference 1 

Conference 2 

Conference 3 


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. 

Created 

by 

View/ 

Modify 

Bridge Admin X 

Bridge Admin Y 

(Delegate of X) 

Bridge Admin Z 

• Figure 20 Release 11 Relationship Model 

Conference I 

Conference II 

Conference III 

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. 

2) Existing bridge administrators are designated as delegates of the default 

administrator. This cannot be undone. 

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. 


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. 


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


PAGE 45 OF 93

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. 


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. 

SIP 

SIP 

SIP 

• Figure 21 Accounting Integration 

Application Server 

SIP 

SIP 

Conference Server 

Conference Server 

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. 


PAGE 47 OF 93

INVITE 

• Figure 22 Call Flow 

Application Server Conference Server 

INVITE 

200 OK 

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 


This feature is to enhance the Application Server OSS Interface service commands to 

provide a consistent, fast, and fully functional interface. 


200 OK 

ACK 

BYE 

200 OK 

2 - way media 

ACK 

NOTIFY 

(service -info) 

200 OK 

BYE 

200 OK 

Collect conference code 

(moderator/participant) 

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. 

1) 

2) Send “service -info” 

event to Application 

Server 

Application Server cuts CDR 


PAGE 48 OF 93

5.4 Performance Enhancements for Troubleshooting 


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.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 


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 

� Current performance and execution information as follows: 

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


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 


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. 


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 


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. 


PAGE 52 OF 93

6 System 

6.1 Call Client Hold Integration 


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.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. 


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. 


PAGE 54 OF 93

6.2 Calling Line ID Delivery Enhancements 


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. 


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”. 


PAGE 55 OF 93

6.3 Configurable Ringing Timeout 


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 


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 types 2 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. 

2 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. 


PAGE 56 OF 93

• Figure 23 Schematic Overview of BroadWorks EMS Functionalities 


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. 


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. 

NS MS 

EWS 

AS 

EMS 

NMS 

CS 

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

Network 

Management 

Layer 

Element 

Management 

Layer 

BroadWorks 

Element 

Management 

Layer 


PAGE 58 OF 93

NMS SYSTEM 

NS 

Customer 

database 

SLA Billing Inventory 

EMS 

AS 

SNMP 

SNMP 

Tomcat OSS 

Proxy 

OSS 

Trouble 

ticketing 

Surveillance Service 

Activation 

From 

HTTP/ Operator 

SSH Workstation 

MS CS 

. . . SNMP PS SNMP Tomcat PS XS Apache SNMP SNMP . . . 

End 

User 

Interfaces 

SNMP 

EWS 

North-Bound 

AJP 

Apache 

XML/ 

Corba 

OSS 

Proxy 

XML/ 

Corba 

Apache 

CAP 

CAP 

Proxy 

HTTP OSS CAP 

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 

… 

NMS/OSS Layer 

EMS Layer 

NE Layer 

Public Network 

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. 


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 

6.4.1.7 Additional Product Information 

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. 


PAGE 60 OF 93

6.5 G.729 Codec Support 


This feature introduces support for Codec G.729a on the Media Server. G.729 is available 

for IVR, conferencing, and live audio services. 


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 


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.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 Type Description 

cc Number (1 to 3 digits) A valid country code (CC) defined in the system 

under NS_CLI/System/CallP/CountryCodes. 

zone String (1 to 32 characters) 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. 

rateCenter String (1 to 32 characters) 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 String (0 to 64 characters) Description of the rate center/zone entry. 

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 


PAGE 61 OF 93

category determination using zones/NDC rate centers as well as LATA/NNACL rate 

centers. The new logic is as follows: 

ZONEorig = 

ZONEterm? 

N 

LCAorig = 

LCAterm? 

N 

ZONEorig = 

ZONEterm? 

N 

cat=INTERLAT 

Y 

Y 

N 

Y 

RCorig = 

RCterm? 

cat=LOCAL 

Y 

cat=INTRALAT 

• Figure 27 International Call Screening 

Start 

CCorig = 

CCterm? 

Y 

LATA and RC exist 

for orig and term? 

cat=LOCAL 

N 

Skip policy, 

no cat change 

Y 

LATAorig = 

LATAterm? 

N 

LCAorig = 

LCAterm? 

N 

LATAorig = 

LATAterm? 

N 

cat=INTERLAT 

Y 

Y 

Y 

RCorig = 

RCterm? 

cat=LOCAL 

Y 

cat=INTRALAT 

cat=LOCAL 

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 Type Description 

Cc Number (1 to 3 digits) A valid country code (CC) defined in the system 

under NS_CLI/System/CallP/CountryCodes. 

Lcaid String (1 to 32 characters The name given to a local calling area. The LCA 

name is unique within the entire system. 

ndcList List of number (1 to 10 digits) Lists all NDCs that are part of the local calling area 

defined by Lcaid. 


PAGE 62 OF 93

cList List of string (1 to 32 characters) Lists all rate centers that are part of the local calling 

area defined by Lcaid. 

zoneList List of string (1 to 32 characters) Lists all zones that are part of the local calling area 

defined by Lcaid. 

lcaList List of string (1 to 32 characters) 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 


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 


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.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. 

When useAliasForDomain is set to “false”, then: 

� 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. 

6.7.1.2 Device Addresses Versus Domains 

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. 


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. 


PAGE 65 OF 93

6.8 Live Audio Support 


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 



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 


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. 


PAGE 67 OF 93

6.9 Media Server Access Control and Performance Management 


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. 


This feature is broken down into the following: 

� ACL configuration 

� ACL validation 

� SIP configuration 

� SIP performance management counters 

6.9.1.1 ACL Configuration 

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. 


PAGE 68 OF 93

6.10 Multiple Country Code Support 


This activity enhances BroadWorks to support different country codes on a single 



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 


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. 


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

Code> or 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 /var/broadworks/userfiles 

“en_US” /en 

“en_GB” /en_GB 

“fr_CA" /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. 


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 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_.properties 

− BroadworksXSLabels_.properties 

− BroadworksError_.properties 


PAGE 71 OF 93

� Online help files 

Online help is moved from the current directory structure public_html/Help/ to 

public_html/Help//. 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/. 

− The Call Manager and Attendant Console graphics are moved from the current 

directory structure public_html/commpilot/images/ to 

public_html/commpilot/images/. 

� 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_.properties 

− bw_base/conf/ScreenTitlesLabels_.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_.properties 

− bw_base/conf/TimeZoneAliasLabels_.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_.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_.properties file. 

� Mouse-over text 


PAGE 72 OF 93

A new mouse over text property file is introduced for each language: 

− bw_base/conf/MouseOverTextLabels_.properties 

The existing mouseOverTxt.jsp only has a label for each mouse over string. The 

displayable text is looked up in the 

MouseOverTextLabels_.properties file. 

� Business group phone lists 

A new property file is introduced for each language: 

− bw_base/conf/BusinessGroupPhoneListLabels_.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_.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. 


PAGE 73 OF 93

6.12 No-Charge Treatments 


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.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 


PAGE 74 OF 93

� 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 


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 


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. 


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. 


PAGE 75 OF 93

Secondary Application Server 

XS 

PS 

PS 

CAP 

OSS 

CAP 

XS 

OCS 

Primary Application Server 

Network Server 

• Figure 28 Configuration 1 – Open Client Server with Application Server 

Secondary Application Server 

XS 

XS 

PS 

PS 

CAP 

Prim ary Application Server 

CAP 

OSS 

NS 

Network Server 

OCS 

NS 

External 

W eb Server 

Proxy + External W eb Server 

• 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 


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. 


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. 

This feature also enhances the Application Server as follows: 

� 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. 


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 Do not care Do not care A 

Not provisioned B Do not care B 

Not provisioned Not provisioned C C 

Not provisioned Not provisioned Not provisioned OTG not added 

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 Remote- 

Party-ID header. If the Network Server considers that the call originator is identified by the 

Diversion header, the OTG parameter is not added. 


PAGE 78 OF 93

OTG Maps to 

Site 

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) Diversion, if present, or 

2) P-Asserted-Identity, if present, or 

3) Remote-Party-ID, if present, or 

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

User Group 

OTG Maps to 

Enterprise 

Public Profile Used Private Profile Used 

Yes Not applicable Not applicable Site profile Site’s enterprise 

private profile 

Not applicable Yes Not applicable User group profile User group’s 

enterprise private 

profile 

Not applicable Not applicable Yes Enterprise public profile Enterprise private 

profile 

No No No Same logic as today 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). 


PAGE 79 OF 93

6.16 Per-Enterprise LCA 


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.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 Enterprise NDC Call Screening Choice 

LCA specified Do not care Do not care If the caller is part of a user group that 

has an LCA specified, Call Screening 

uses this LCA. 

No LCA specified LCA specified Do not care 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. 

No LCA specified No LCA specified LCA specified Call Screening uses the LCA defined at 

the system/NDC level if the user group 

and enterprise of the caller have no 

LCA specified. 

No LCA specified No LCA specified 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. 

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. 


PAGE 80 OF 93

6.17 Pre-Typing Policy 


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.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. 


PAGE 81 OF 93

Start 

PreCallTyping 

PreCallTyping in 

profile? 

Y 

Go in policy 

instance dial plan 

and get call typing 

result 

Call typing 

result found? 

Y 

Perform called 

number 

normalization 

Continue 

processing 

• Figure 30 Call Typing Policy 

N 

N 

Y 

Policy processing 

Start CallTyping 

CallTyping in 

profile? 

Y 

Call typing result 

already found 

(result != NIL)? 

N 

Go in country 

code dial plan and 

get call typing 

result 

Call typing 

result found? 

Y 

Perform called 

number 

normalization 

Continue 

processing 

N 

N 

Call failure 

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


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 


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 


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 re- 

INVITE. 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. 


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, Session- 

Expires, and Supported. 


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 removed 3 . 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.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: 

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 is an E.164- 

3 The Network Server will continue to support MSS for one or two releases, for backward compatibility with older 

Application Servers. 


PAGE 84 OF 93

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 P- 

Broadsoft-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:” to the SIP INVITE message, where 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 

@, where is the specific Media Server service 

name, and 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. 


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.40- 

192.168.13.5V5060-0-109103350-2021982911-1067517579755 

From:"JOHN SMITH";tag=2021982911- 

1067517579755 

To: 

Call-ID:BW0739390755301003044-129939463426@192.168.13.40 

CSeq:109103350 INVITE 

Contact:;q=0.5,;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-Broadsoft- 

MSSGatewayAddress 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. 


PAGE 86 OF 93

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

BroadWorks.192.168.8.52-192.168.8.22V5060-0-198724658-1857280961-1065549338722 

From:"john 

rb";tag=1857280961- 

1065549338722 

To: 

Call-ID:BW1355380722071003041-11434686810@192.168.8.52 


Contact: 

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 


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

BroadWorks.192.168.8.52-192.168.8.22V5060-0-198724658-1857280961-1065549338722 

From:"john rb";tag=1857280961-1065549338722 

To: 

Call-ID:BW1355380722071003041-11434686810@192.168.8.52 


Contact: 

Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER 

Supported:100rel,timer 

Min-SE:60 

Max-Forwards:10 


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 


PAGE 87 OF 93

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

anymore 4 : 

� 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. 


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. 


PAGE 89 OF 93

6.21 Solaris 9 Support 


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.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 


PAGE 90 OF 93

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

� 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 

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) Shuts down all unnecessary services in /etc/inetd.conf. 

2) Removes unneeded startup/shutdown scripts in /etc rc0.d, rc1.d, rc2.d, rc3.d. 

3) Hardens the IP interface by replacing the nddconfig file. 


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 


PAGE 92 OF 93

6.22 Unregistered Endpoint Announcement 


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. 


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. 


PAGE 93 OF 93

BroadWorks Functional Summary - CommPartners Connect

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?