From Snom User Wiki

< Interoperability | PBX(Redirected from Broadsoft)
Jump to: navigation, search


Snom phones are fully interoperable with the Broadsoft BroadWorks application server. This page explains the settings required to take full advantage of the BroadWorks feature set. Only those features requiring a specific setting are listed.


Busy Lamp Field

Busy Lamp Field (BLF) is supported in application firmware version 7.0 and higher.

The Busy Lamp Field feature allows a user, such as an attendant, to monitor the hook status of a list of users. snom phones support this feature by illuminating the LED of an Extension key associated with the monitored user whenever this user goes to a non-idle state. This makes the snom extension keyboard an ideal BLF panel.


Provisioning the BLF feature requires the following steps:

Step 1: BroadWorks Provisioning

First the BLF feature must be provisioned on the BroadWorks server. Please refer to the BroadWorks documentation on how to do this. The result of the provisioning will be a SIP URI which represents a list of resources which are to be monitored.

Step 2: Provisioning the BLF Keys

For every monitored user a function key must be provisioned on the snom phone or snom extension keybord:

The Context field must be set to the Identity owning the BLF resource list.

Step 3: BLF List Subscription

Finally, the Event List Subscription must be enabled. Specify the name of the list in the Extension Monitoring Call Pickup List URI field. This is done on the SIP tab of the Identity Configuration screen.

Shared Call Appearance

The Shared Call Appearance feature allows a line, that is an address-of-record, to place and receive calls on multiple endpoints. Although the endpoints each register with the BroadWorks server with different unique URIs, the call appears to the other party to be originating from or terminating at the same line, no matter which of the endpoints sharing the line is used.

Call Appearances

The BroadWorks application server allows for multiple calls to be active on a single shared line when Multiple Call Arrangement and/or Call Waiting is activated (see below). snom phones support multiple call appearances on a shared line by associating multiple shared line keys with the same shared line (see Provisioning). When there is more than one call active on a shared line, the BroadWorks server assigns a Call Appearance Index to each call. The snom phone correlates the call appearance index with the shared lines keys associated with the shared line and lights the corresponding LED in accordance with the call progress state signalled from the BroadWorks switch. If no corresponding key is found, the message is ignored. This means that endpoints sharing a line may have differing numbers of call appearances provisioned since the phone will only display the LED status for those appearance indexes for which it has a key. Therefore, in a scenario where two endpoints share a line, and one has three, whereas the other has only two call appearances provisioned, when the first phone makes a call using the third shared line key, this will not be reflected on the second phone since it has only two shared line keys. Ideally, all endpoints sharing a line should have the same number of call appearances provisioned.

Multiple Call Arrangement

Multiple Call Arrangement (MCA) is a BroadWorks feature that allows for multiple calls to be originated concurrently from the same shared line. Practically speaking, this means that a second endpoint may place an outgoing call on the same shared line already in use by another endpoint. To achieve a non-blocking configuration for a group of endpoints sharing a line (meaning that all endpoints in that group can always place an outgoing call) every endpoint in that group must have as many shared line keys provisioned as there are endpoints in the group.

Conversely, if an exclusive use the the shared line is desired, this feature should be disabled. Additionally, only one call appearance should be provisioned on each phone sharing the line. This ensures that only one endpoint at a time can use the shared line.

Call Waiting

Call Waiting is, in the context of SCA, the inverse of MCA: It allows for multiple calls to be accepted concurrently on the same shared line. Typically this means that a second endpoint can answer a call coming in on the same shared line on which another endpoint is busy in a call. To enable this feature Call Waiting must be activated on both the BroadWorks server and the snom phone. Additionally, the snom phone must have as many call appearances provisioned as concurrent incoming calls are allowed on the shared line. Note that this number may be greater than the number of endpoints sharing the line. The shared line is considered busy only when no more call appearances are available to accept the call on any of the the phones sharing the line.

Visual and Audible Indicators

When an incoming call is received on a shared line, all the endpoints sharing the line are alerted. Since enpoints sharing a line are typically located in separate rooms or offices and out of each other's sight and hearing, the call progress state of the line for both incoming and outgoing calls is reflected on the LEDs associated with the shared line of all the endpoints sharing the line by the following LED states. If the shared line has multiple call appearances, the LED represents the status of the call appearance; if the line has only one call appearance the LED also represents the status of the shared line itself:


the shared line or call appearance is idle

blinking, fast

the shared line or call appearance is alerting (incoming call)

blinking, slow

one of the endpoints sharing the line has placed the call on hold


the shared line or call appearance is in use by one of the endpoints sharing the line (line seized or talking)

Line Seizure

snom phones support the BroadWorks Line Seize event package. This means that when the line is provisioned to be shared (on both the BroadWorks server and the phone) and a shared line key has been associated with this line (see Provisioning) the snom phone will attempt to seize the line before applying dial tone after it has been taken off-hook. Only when the BroadWorks server has signalled that the line has been successfully seized does the snom phone play dial tone. This causes a small delay between selecting a line and hearing dial tone, but this delay is usually imperceptible to the user. If the line seizure fails (because another enpoint has seized the line at the same time), the snom phone plays busy tone. In this case the user must hang up and wait for the line to become available or select another call appearance.

A seized line is automatically released when the user goes back on-hook, or, if the user stays off-hook but does not dial, after about 45 seconds. The latter mechanism is a precaution against blocking the line for an indefinite amount of time by an inadvertent line seizure (such as knocking the handset off the hookswitch). After the line has been released, the phone plays busy tone if it is still off-hook.

Because the phone is required to seize the line before using it when it is provisioned with a shared line on a BroadWorks server, the phone will look for an idle shared line key associated with this line when it is taken off-hook in the idle state. If none is found (because all are busy), the off-hook event is ignored and the user hears silence. Hearing silence after lifting the headset (or pressing a shared line key) therefore means one of two things: Either the line is unavailable, i.e. all available call appearances are in use by other endpoints, or the BroadWorks server has not responded to the line seizure request (which would indicate network problems).

On the other hand, if the user hears busy tone after going off-hook, this indicates that either a race condition has occurred where two endpoints try to seize the same call appearance at the same time, or the endpoint is not authorized to use the shared line (the text "Forbidden" should be displayed in this case).

The dial tone, therefore, in the context of SCA, is a true dial tone in the traditional sense: it indicates that the resources are available to place a call.

Public and Private Hold

The BroadWorks SCA feature allows a call that was put on hold by one endpoint to be retrieved by any other endpoint sharing the same line. snom phones support this feature: simply press the the flashing shared line key and a message is sent to the BroadWorks server to retrieve the call.

The BroadWorks SCA feature distiguishes between a public and a private hold. When a call is put on public hold, other endpoints that share the line may retrieve the call. When a call is put on private hold, it can be retrieved only by the endpoint that prevoiusly put the call on hold, not by others sharing the same line. The key function F_HOLD_PRIVATE has been defined for the snom phones to support the private hold function. There are two methods for placing a call on hold: either by pressing the Hold key, or by pressing the line key. Pressing the line key will always effect a public hold; pressing the Hold key will execute the function assigned to the key (F_HOLD being the public hold). Setting the Hold key function to F_HOLD_PRIVATE will therefore provide the user a means to perform a private hold, while pressing the line key is still available for effecting a public hold.

Attempting to retrieve a privately held call from another endpoint will produce busy tone and an error message is displayed.

Shared Call Appearance Bridging

Starting with release 14 of the BroadWorks application server, the SCA feature allows a second endpoint to barge in on an existing call on the shared line. This feature is called Shared Call Appearance Bridging. It must be enabled for the shared line on the BroadWorks server. snom phones support this feature without any additional configuration. The feature is invoked by pressing the shared line key associated with the active call appearance as indicated by a steadily lit LED. If the feature is enabled on the BroadWorks server, a three-way call is established; if the feature is disabled, busy tone is applied and an error message is displayed ("Forbidden").

Note: When the shared line is in the seized or ringing state the LED associated with this call appearance on the other endpoints sharing the line will also be steadily lit. Pressing the shared line key in this state on one of the other endpoints will have no effect.


Provisioning the SCA feature requires the following steps:

Step 1: BroadWorks Provisioning

First the SCA feature must be provisioned on the BroadWorks server. Please refer to the BroadWorks documentation on how to do this. The result of the provisioning will be a primary line with the SCA activated plus a number of secondary devices that share the line, each represented by its own unique SIP URI.

Step 2: Provisioning the Shared Line on the snom Phone

Note that it is transparent to the snom phone whether it is a primary or secondary device on the shared line.

Provision the line as usual (using the devices unique SIP URI if it is a secondary device). On the SIP tab of the Identity Configuration Screen enable Shared Line and set the Server Type Support to Broadsoft.

Step 3: Assign Call Appearances

For each call apppearance you wish to enable on the phone you must assign one Shared Line key. The Context field must be set to the identity of the shared line. The Number field must contain the SIP URI of the device's unique SIP URI. You must provision at least one Shared Line key or the shared line extension will not work.

This example has three call appearances provisioned. Note also that the Hold key has been configured to invoke a private hold.

Device Feature Key Synchronisation

Many Session Initiation Protocol (SIP) phone users prefer to use the buttons on their phone to activate features, such as Do Not Disturb (DND), rather than the BroadWorks web portal. This feature permits these SIP phone users to use the buttons on their phones in just this way. With this feature installed, supported SIP phones can synchronize with the BroadWorks Application Server on the status of the following features: Do Not Disturb, Call Forwarding Always (CFA), Call Forwarding Busy (CFB), Call Forwarding No Answer (CFNA), and Call Center Agent ACD State. If a user changes the status of one of these features via the web portal or a feature access code (FAC), the Application Server notifies the phone about the status change. Conversely, if the user changes the feature status via a button on his phone, the phone notifies the Application Server of the status change. The synchronization protocol is based on the SIP events framework. To use this capability, the phone user must have a SIP phone that supports the “as-feature-event” event package.

Enabling the feature

In the Webinterface of the snom telephone, set Identity -> SIP -> Device Feature Key Synchronisation. Be sure that the Server Type is set to Broadsoft. Reboot required.

Synchronisation of Call Forwarding Timeout/NoAnswer

A ring count value serves as a parameter for the timeout on the broadsoft application server. However, snom phones demand a value in seconds. Therefore, no direct synchronisation is possible. A indirect synchronisation has been implemented that works as follows. If the ring count value is been changed on the application server, the snom phone converts the ring count value to a time value in seconds:

timout(s) = ring_count * cycle_duration

The cycle duration depends on the selected tone scheme. Most cycle durations are 3-6 seconds. On the other hand, if the user edits the timout on the snom phone, the ring count is converted and send to the application server via:

ring_count = round_down ( (timeout + cycle_duration)/cycle_duration )

Call Agent ACD State

The phone can be used as a Call Agent that distinguishes 5 states:

  • AgentLoggedOnEvent (Sign-In)
  • AgentLoggedOffEvent (Sign-Out)
  • AgentNotReadyEvent (Unavailable)
  • AgentReadyEvent (Available)
  • AgentWorkingAfterCallEvent (Wrap-Up)

These states are governed by the functions key ACD, which is configured in the Function Keys section of the webinterface.

The agent states can be changed by navigating trough the ACD menu and select the state.


Broadsoft Specifics

  • The broadsoft server does not accept empty forwarding destinations if forwarding is enabled. Snom phones allow this setup by treating it in the same manner as if forwarding is disabled. For this reason, if a line has broadsoft server type support and the user enables CF with an empty destination, the phone sends out a SUBSCRIBE with CF disabled. As a consequence, CF is switched off as well when the phone receives the confirmation NOTIFY from the server. Unfortunately, this broadsoft specific has a unlucky drawback. Normally, if you use the GUI of the phone, you enable CF before you specify the destination. In this case CF is still disabled, as the turn-on-procedure results in a CF off SUBSCRIBE as no destination had been specified before.
  • The broadsoft server does not accept ring count values less than 2 or greater than 20. For this reason, if the calculated ring count falls below 2, 2 is send to the server. A calculated ring count value above 20 is considered to be absurd, and a default ring count value of 20 is send to the server.

Directory Access

Snom telephones can access the Broadsoft directory via the Open Client Interface-Provisioning (OCI-P) that allows third-party applications to peform all business functions peformed by BroadWorks. The OCI is available on the Provisioning Server (PS), which is part of the Application Server (AS) and the Open Client Server (OCS) that resides on the Application Server Web Server Farm and the Element Management System (EMS).

Enabling the feature

Step 1: Enabling Broadsoft server support.

At least one identity needs to have Broadsoft server support. Using the Webinterface goto Identity x -> SIP and set Server Type Support to Broadsoft.

Step 2: Configuring the Provisioning Server

Goto Advanced -> OCI-P (Broadsoft) and specify server and login details.

Step 3: Configuring the Directory Key

Goto Function Keys and set the directory key event to OCIP. By default this is done by setting Server Type" to Broadsoft.

Search behaviour

  • search is peformed on the last name only
  • search is case-insensitive
  • if the server returns more contacts than the specified maximum hits, the search list remains empty.
  • a user appears in the search list for each number he has. It is therefore recommended to set the Number Display Style (Preferences) to Full Contact or any other entry that contains the number rather than just the name.

XML Provisioning Template

The following XML templates can be used as example for setting up auto provisioning for snom3x0/7xx/8xx phones in Broadsoft environments.

Personal tools