BLF behavior when phones unavailable


(Cyberdocwi) #1

Hello,

FreePBX 14 / Asterisk 16

We have an office with Digium D50 / D70 series phones, and with the Virus changing the world, the staff wishes to work from home.

The Digium BLFs are green when the real phones are online, and turn red when busy. When the phone becomes unavailable, either by network disruption or a power off, the BLF becomes dark. This is ideal behavior.

Unfortunately, if we have a softphone, either the Desktop Zulu Client, or one of the other softphone clients (3CX, X-Lite), the BLF button stays green all the time, unless the phone is in use, which it turns red. If the remote user closes Zulu or the other softphone application, or the VPN collapses, I would like the BLF to become dark, just like a real phone would.

I think this is a hint problem. Any suggestions out there on how to power off the Digium BLF light when the soft phone disappears, just like a hard phone?

Thanks,

Christian


(Tom Ray) #2

Out of curiosity, SSH into the system and then log into the Asterisk console and let’s see the hint being used for this extension.

database show AMPUSER/<exten> hint <-- Run that command with <exten> being the extension you are trying to monitor.


(Cyberdocwi) #3

Hello Tom,

Here is the data:

/AMPUSER/140/hint : SIP/140&PJSIP/90140&Custom:DND140,CustomPresence:140

I created x140 as a Chan_SIP extension for Zulu to tie into. Not sure where the PJSIP assignment came from.

So, I decided to make a new x131 PJSIP and try that.

/AMPUSER/131/hint : PJSIP/131&PJSIP/90131&Custom:DND131,CustomPresence:131

And I got this to work! Zulu on, and light comes on. Zulu out, and light goes out. Until I rebooted the phone. Now it doesn’t work anymore.

I am thinking the answer lies in having the Zulu clients being PJSIP, and maybe they need to be “fresh” extensions.

More testing.

Christian


(Tom Ray) #4

So that would mean this hint is watching the states of both those devices. You have to remember ZULU creates a second extension to work along side the existing one, that’s why you still have a PJSIP/90XXX in the hint with the PJSIP extension. It still makes two (why I don’t know) for PJSIP.


(Cyberdocwi) #5

Hello,

With a lot of experimentation, we may close this ticket. Thank you Tom for your suggestions. I ended up doing packet sniffs, and found that yes, Zulu does communicate with the server when the client closes. Thus, there is a “signal” to close down the connection.

Our implementation kind of breaks the idea of Zulu - I believe the creators of Zulu desired one extension per person, and use Zulu and a desk phone to tie into that single extension. Zulu and the real phone see the voicemails. Zulu and the real phone see the contact lists, and the missed calls and so forth.

Because our office is scattered due to the virus (and job locations), we decided to separate the extensions depending if you are a real phone, or a Zulu. For example, my Digium D70 desk phone is x150 and my Zulu extension is x160. We did this so that when I am not “at” x160, that BLF button dies on the Digiums in the office, and people will know not to transfer calls to me. When my software and VPN is up, the BLF glows green, and I am open for conversations.

By testing, the Zulu extensions had to be SIP and not PJSIP. A PJSIP extension didn’t toggle the BLFs on the Digium phones.

Unfortunately, our Sangoma S700 series phones doesn’t notice these actions. The Sangoma BLF buttons stay solid green no matter what the status of the phone is. Sangoma’s phones also do not change the little user symbol for status changes. Performing a packet sniff, I do see packets fly to the Sangoma when Zulu comes up and down.

In the end, we achieved our goal: Light the BLF on Digium phones when Zulu is active, and make it dark when the client is logged out.

Hope others may find this useful.