[VoiceOps] Broadsofts BLF List URI Implementation is Unique?

[Colton Conor]

Here is Polycom's guide explaining the differences between the two types of
BLF:
http://community.polycom.com/polycom/attachments/polycom/VoIP/19112/1/Technical%20Brief%20-%20Busy%20Lamp%20Field.pdf



On Sat, Sep 2, 2017 at 12:37 PM, Colton Conor <colton.conor at gmail.com>
wrote:

> I did some more research, and it looks like Grandstream's UCM which is
> based on Asterisk supports this as well! They call it Event List BLF or BLF
> resource list. Its RFC4662 which is what I am looking for:
>
> Although SIP protocol (RFC3261) was not provide the semantics to support
> the Busy Lamp Field (BLF) but there’s a way around to make the Busy Lamp
> Field function works on our phone by using the proper instantiation and the
> appropriate extension of the SIP Specific Event Notification framework
> (RFC3265). RFC4235 - Dialog Event Package is the instantiation RFC3265
> which defined the mechanism of how the endpoint can subscribes for the
> status of any dialog including another endpoint. Busy Lamp Field feature is
> useful but can create a lot of overhead when trying to subscribe for the
> status of a large number of the resources. Event List BLF or BLF resource
> list is the solution to solve the overhead problem by reducing the number
> of request. Instead of generating an individual SUBSCRIBE request for each
> resource status, the concept of the Event List is combining all of those
> requests into a single request that query the resources status from the
> Event List. RFC4662 – Resource List defines an aggregating mechanism that
> allows for subscribing and notifying for a list of resources. This
> mechanism is useful when the device needs to subscribe to a large number of
> resources. The overhead of generating individual SUBSCRIBE requests and the
> overhead of processing individual NOTIFY requests can be reduce by
> aggregating resources using a resource list concept.
>
> The above is from this  PDF. It shows how you could configue this on their
> UCM IP PBX as well as their phones : http://www.grandstream.com/
> sites/default/files/Resources/GXP21x0_Eventlist_BLF_Guide.pdf
>
> So anyone else support RFC4662 besides grandstream and Broadsoft?
>
> On Sat, Sep 2, 2017 at 11:37 AM, Colton Conor <colton.conor at gmail.com>
> wrote:
>
>> I asked this question in 2015, so I am wondering if anyone has an update.
>>
>> Is the the way that Broadsoft implements Busy Lamp Field (BLF) using list
>> URI unique only to Broadsoft, or have any other softswitch providers now
>> implemented this method?
>>
>> With a Broadsoft switch and a Polycom or Yealink phone, all that needs to
>> be done on the phones config is to enter the BLF list URI server address.
>> Then on the Broadsoft server you select the users you want to monitor, and
>> the BLF list instantly updates on the phone. I think this reduces overall
>> signaling too which is a big issue with BLF status updates. There is no
>> rebooting or going into the phones configuration file once the BLF List URI
>> is set.
>>
>>  For an example on how easy BLF is setup on Yealink phones with Broadsoft
>> see this http://www.yealink.com/Upload/UCOne/features/Quick_Setu
>> p_BLF_List_on_Yealink_IP_Phones_with_BroadSoft_UC_ONE_v1.0.pdf
>>
>>
>> Compare this to most other platforms I have seen based on Asterisk and
>> Freeswitch. I think 3CX and Metaswitch are the same. In all these
>> platforms, on the phones confige its self, you have to manually create a
>> key on the phone to monitor a user. That might be done through the
>> provisioning interface itself, but it still static adds a BLF line key to
>> the phones configuration. Any updates to BLFs are usually not dynamic, and
>> adding or removing a BLF requires a reboot to the phone as you have to
>> change the config file.
>>
>> Example of this method on a Yealink using a Asterisk based service like
>> Virtual PBX see this https://www.virtualpbx.com/sup
>> port/dash/topics/t48g-blf/
>>
>>
>> Anyone have BLF List URI working on a non Broadsoft switch?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20170902/b8f370bd/attachment-0001.html>