T46G BLF Keys Issue

[fdtcloud]

We have deployed 15 T46G phones on a FreePBX 2.11 server. All 15 phones have DSS/BLF keys for each others extensions on 3 pages (no side cars). After reboot the BLF keys are all working great then as time passes the phones begin to change all BLF keys to unmonitored "red x" icons. I don't see any "Queued" notifications in asterisk so this leads me to the phone being a possible issue.

Firmware 28.72.0.45.
Asterisk 11.7

I can try going to 28.73.X.X firmware but I would rather not introduce further bugs. Any thoughts?

[raphael]

We have the similar issue in combination with FreeSWITCH. The BLF keys are working fine and after some time/some situation the led don't switch to red and therefore the call can't be picked up.
At the moment we have the V72 Firmware installed and we will try to upgrade to the V73 in the next weeks, because of the BLF key issues, in the hope that that resolve the issue.

Are you able to reproduce the issue? Maybe with that you can create a logfile with that the yealink support can work identify the issue.

We made 6 installations (from 5 to 70 phones) in the last 4 month, 5 installations with Yealink Phones (T46/T41/T26/T28) and all 5 installations are working fine besides the blf keys. All customers reported that from time to time they can not pickup the ringing phone. So it would be a big help for us if you can reproduce the issue.

Thanks

[Elaine_Yealink]

Dears,
Would you please repeat the issue and send the pcap, syslog(level 6) and config.bin to us? I will ask RD to find out solution for that.

About how to get them, please refer to:

http://forum.yealink.com/forum/showthrea...og#pid5356

Thanks and regards
Elaine

[blueadmin]

I have the same issue on an installation with 3CX and firmware of both 28.71.0.224 and 28.73.0.48. Any progress on this one? Happens only on this installation and i have others with same 3CX version and same firmware. I modify the provisioning file with the following changes:
 voice.headset_send = 20
 voice.ring_vol= 4
 network.vlan.internet_port_enable = 0
 network.vlan.internet_port_vid = xx
 auto_provision.mode = 0
 transfer.dsskey_deal_type = 1
 security.user_password = admin:xxxxxx
 features.call_completion_enable = 1
 features.intercom.allow = 1
 features.remote_phonebook.enable = 1
 phone_setting.ring_type = Resource:Ring3.wav - To give distinctive ring for internal calls
 phone_setting.inter_digit_time = 2
 phone_setting.active_backlight_level = 7
 phone_setting.inactive_backlight_level = 3
 phone_setting.backlight_time = 0
 distinctive_ring_tones.alert_info.6.ringer = 1
 account.1.outbound_proxy_enable = 0

[davyvdm]

I actually see the same behavior.

When the phone receives a NOTIFY the light work correctly, and the phones keeps the state of the light, UNTIL the phone sends out a NEW subscribe. Then the phone 'forgets' the status of the subscribed uri. Upon a new NOTIFY, the light/status is correct again.

It is asif the phone expects to receive NOTIFY's upon every SUBSCRIBE. Which most systems don't do out of the box.

I didn't go through the RFC to see if this would be according to specs or not.

To reproduce just make sure the phone does regular SUBSCRIBEs .

I see the same behavior on a T22.

[Bryan Nelson]

I have previously worked with Yealink support to resolve a similar BLF issue we had.

We use DNS-SRV, and the BLF subscribe requests would not return to the primary server after a failover event. The solution was to use the outbound proxy server (same SRV address as the registration server). This forced the BLF subscribe events to always use the proxy address, rather than just continuing a valid subscription on the failover server. A side effect was that this "reset" the subscription as well, resolving any state issues it was having on the primary server as well. So, a combination of outbound proxy, and a short subscribe interval should clean things up a bit for you.

Happy troubleshooting!