Yealink phones blf indicators quit showing extensions status. Reboot the phones and will start working.
Same issue here… Been troubleshooting internally for a few days. Trying to determine if its a Vital problem or Yealink problem. My tests are inconclusive so far. My environment is difficult to troubleshoot as I use the VPN client on the phones. All the SIP traffic is in the tunnel. So PCAP is useless.
Any input as to what may be causing this would be greatly appreciated.
There has not been any change here. My customer is living with it but it does not look good on the system. I’ve had multiple issues BLF included with PJSIP which we are forced to use now.
Try updating to the latest VitalPBX version that comes with Asterisk 18.17.1
The latest version of Asterisk 18 seems to come with a fix related to your issue.
It appears the BLF is still intermittent after the the update.
We are experiencing the same issue in VitalPBX v3 latest update with Fanvil devices. We noticed, that VitalPBX stops sending SIP.METHOD NOTIFY after a short amount of time.
Please help in resolving this issue.
You can try reporting that to Asterisk Team. In the end, VitalPBX is an abstraction layer for Asterisk.
On the other hand, make sure your Network restrictions or Phone configurations don’t interfere with the Asterisk Notifications.
Still having issues with the notifications. Same phones worked great with another system and SIP settings. On another system VitalPBX3.x I initially set them all up under PJSIP. Had all kind of issues with no audio, one way audio, lights not working and had to move them all to SIP. I have license on both of these systems. Are there any experts with VitalPBX that can help with the issues? I have other very large users with enterprise license on the vitalpbx. Having to move them to PJSIP will be a nightmare.
Confirming that this is still an issue with the latest version of VitalPBX4 (with Asterisk 18.17.1)
We can only file an issue if we use the current version of Asterisk, which is 18.19.0… So there is no way we can file an issue if VitalPBX is two versions behind.
Perhaps there is a dev repo we can use to test?
Does the version 18.19.0 fix the issue? Have you tested?
I don’t know if it is fixed in that version. But in order to be able to report this as an issue on the Asterisk issue tracker we need to use that version.
OK. I made some progress. I tested with another Asterisk Distro and I think I see the issue.
On the other distro, when DND is enabled, we see:
[root@asterisk9 ~]# asterisk -x"core show hints" | grep 6406 6406@ext-local : PJSIP/6406&PJSIP/996 State:Busy Presence:available Watchers 1
When DND is disabled:
[root@asterisk9 ~]# asterisk -x"core show hints" | grep 6406 6406@ext-local : PJSIP/6406&PJSIP/996 State:Idle Presence:available Watchers 1
With VitalPBX, when DND is enabled, we see:
root@VitalPBX3:~# asterisk -x"core show hints" | grep DND_105@T3 DND_105@T3_extension: Custom:T3_DND_105 State:InUse Presence:not_set Watchers 4
BUT… When DND is disabled, we see:
root@VitalPBX3:~# asterisk -x"core show hints" | grep DND_105@T3 DND_105@T3_extension: Custom:T3_DND_105 State:Unavailable Presence:not_set Watchers 4
Notice the Unavailable.
Is there a way we can set that to Idle?
When your phone is unregistered, you will see what you said:
After connecting the phone, you will see the Idle status:
As far as I remember, someone requested to change from Idle to Unavailable because of queues.
I am referring to the DND_EXT (DND_105) hint, it is a total different hint.
The ticket is related to the BLF in general. It has nothing to do with the status used for the DND hints.
Indeed. However, no one mentioned here what type of BLFs they were using. So… I am doing the work to dig deeper.
Jose, have you tried reproducing what I mentioned?
The DND was changed from “IDLE” to “UNAVAILABLE” because when the agents got disconnected/unreachable the extension was flagged as “Idle” because of the DND status. So, the queues tried dialing un-register agents logged in as “Static Members.”
But again, I guess this has nothing to do with the initial issue.
Anyway, if you want, you can update to the latest Asterisk version(18.19.0) using the Linux CLI. We uploaded the packages today.
Since the last upgrade I have not heard complaints on this so hopefully this is working better.