Skip to end of metadata
  • Created by Former user, last modified by Former user on Nov 01, 2010
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Introduction

"BLF" stands for "Busy Lamp Field", which means "a light on one phone tells you whether another extension is in use". Most phones offer a "manual" configuration method by which you can configure the phone even if the sipX Configuration Server does not support that variety of phone. With most phone features, manually configuring the phone is simple. Sometimes this is the case with BLF, if the phone sets up the necessary subscriptions itself. But most phones that support BLF do so by making a single subscription to a "resource list" in order to get all the necessary information. This more common BLF implementation requires cooperation between the sipX Resource List Server and the phone displaying the BLF information.

Prerequisites

  • The phones which are being monitored must accept subscriptions for dialog events according to RFC 4235, and must generate the correct responses.
  • The phones which display BLF information must generate subscription requests for dialog events aggregated into resource list events according to RFC 4662, and must process the responses to drive the BLF display. There are two alternative data formats that the phone can request from Resource List Server:
    • Full RFC 4662 format: This format uses the full flexibility allowed by RFC 4662. In particular, for any given monitored extension, it reveals each appearance of that extension (and its activity) separately.
    • Consolidated or "Broadworks" format: This format is a subset of the RFC 4662 rules that resembles the resource list events generated by Broadworks. In particular, all activity of all appearances of an extension is grouped together into one "instance", and each instance always has at least one dialog listed (to carry the display name of the extension).
  • The sipX Resource List Server must be configured to generate the resource list events and to make the necessary dialog event subscriptions to get the information required for the resource list events.

Configuration

In the sipX configuration model, a phone is expected to display BLF information for a list of extensions. The list for a given phone is the BLF list associated with the first line appearance on the phone. Your first job is to create the desired BLF list for some extension, preferably (but not necessarily) the first extension appearing on the phone that you want to display BLF. (For phones with BLF configured by the Config Server, the BLF list must belong to the user of the first line appearance on the phone, but if you manually configure the BLF URI of the phone, these can differ.)

The BLF list for an extension is created by entering the extensions to be monitored into the speed dial list of the sipX user in question, and then checking "Subscribe to presence" for those extensions. The extensions in the speed dial list that are checked become the BLF list. (The un-checked extensions are put into the ordinary speed dial list.)

For each BLF list that is configured, there is a corresponding BLF URI that the displaying phone can subscribe to in order to get the BLF information. The URIs are described below. You must configure the appropriate resource list URI into your phone.

BLF URIs for version 3.11 and later

The URI for the full RFC4662 format is <sip:~~rl~F~[xecsuserV4r2:USER]@[xecsuserV4r2:DOMAIN]>, where [xecsuserV4r2:DOMAIN] is the sipX's SIP domain, and [xecsuserV4r2:USER] is the name of the user for which you created the BLF list.

The URI for the consolidated ("Broadworks-style") format is <sip:~~rl~C~[xecsuserV4r2:USER]@[xecsuserV4r2:DOMAIN]>, where [xecsuserV4r2:DOMAIN] is the sipX's SIP domain, and [xecsuserV4r2:USER] is the name of the user for which you created the BLF list

BLF URIs for version 3.10 and before

The URI for the full RFC4662 format is <sip:~~rl~[xecsuserV4r2:NNN]@[xecsuserV4r2:DOMAIN]>, where [xecsuserV4r2:DOMAIN] is the sipX's SIP domain, and [xecsuserV4r2:NNN] is the internal user number for the owning extension.

There is no direct way to make the Configuration Server tell you what the correct internal user number is, but once the BLF list has been configured, you can look in /etc/sipxpbx/resource-lists.xml to find the extension list and its internal user number. For example, if resource-lists.xml contains:

<?xml version="1.0" encoding="UTF-8"?>
<lists xmlns="http://www.sipfoundry.org/sipX/schema/xml/resource-lists-00-00">
<list user="~~rl~6">
<name>205</name>
<resource uri="sip:201@example.com">
<name>201</name>
</resource>
</list>
<list user="~~rl~2">
<name>201</name>
<resource uri="sip:200@example.com">
<name>200</name>
</resource>
<resource uri="sip:201@example.com">
<name>201</name>
</resource>
<resource uri="sip:202@example.com">
<name>202</name>
</resource>
</list>
</lists>

you can see that the BLF list for extension 205 contains only extension 201, but the BLF list for extension 201 contains extensions 200, 201, and 202. The full-format resource list URI for the first list is <sip:~~rl~6@example.com>.

The Broadworks-format resource list URI is made by inserting "c" after the user number in the full-format resource list URI. For example, the Broadworks-format URI of the first list described above is <sip:~~rl~6c@example.com>.

Maintenance

The Resource List Server is designed to track the changing configuration of your sipX system automatically – for example, if you change the contents of a BLF list, the Resource List Server should update its subscriptions within seconds. Similarly, if a new phone registers an appearance of a monitored extension, the Resource List Server will incorporate its status into the proper BLF lists automatically. However, some phones will not correctly update their display of the extensions in their BLF lists until they are rebooted.

  • No labels