(03-23-2018 03:50 AM)preterion Wrote: I hope someone has an explanation for this weird behavior:
We have two separate 3CX installations using Yealink T22P phones. Until upgrading to latest 3CX version and latest Yealink T22P firmware, things were ok.
After the upgrade, we have the following behavior that occurs after a while:
- Phones stop responding to Remote Control commands (CTI mode in 3CX)
- The phones web interface also becomes unavailable
After a reboot, the phones behave normally, until after a while when they lock down again.
We have tried using the phones in various configurations - provisioned by the 3CX system or manually configured.
We made sure remote control is allowed from "any".
It seems to me that the firmware pushed by 3CX (7.73.0.60) is at fault - either causing the phone to blacklist the local subnet (or any IP) or by simply crashing the web server after a while. I would guess it is the latter based on the behavior (i.e. works and then stops working after random number of minutes).
I find this issue really disturbing - regardless of the fact that the phones are not supported anymore. Any vendor has an obligation to make sure older equipment can still be used in the long term and the fact that the latest versions (3CX + Firmware) are basically rendering the phones useless is deeply upsetting..
We did extensive testing and it looks like the firmware version pushed by 3CX is heavily customised and causes this behavior. Apparently, 3CX has reported this issue to Yealink but there was no action taken.
Whilst I understand this model is EOL, I can't understand why a vendor would ignore reports of a fault that renders the product useless. It is basic duty of care - you sell a product and provide a firmware upgrade, at least make sure IT WORKS!
i have experienced this same behavior in the past, i could exacerbate the problem by removing the 3cx server from the local network for a time, by unplugging the network cable for 5 - 10 min, the affected phones would not be able to re-provision unless i power cycled them.
the first thing i would try is removing all the blf keys/lamps, in my quest to find the cause i found that phones with no blf keys for shared parking extensions etc are immune to the issue.
i never did find the cause and ended up just moving all the phones to a new vlan, which helped the issue but did not remove it completely as anytime the server is down for 5 plus min some of the phones will still "stick" and need to be power cycled.
best of luck.
