+- Yealink Forums (http://forum.yealink.com/forum)
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: General topics (/forumdisplay.php?fid=15)
+--- Thread: T27G - Fall Back issues - Successive setting [Solved] (/showthread.php?tid=42417)
T27G - Fall Back issues - Successive setting [Solved] - BobBluePackets - 01-24-2019 12:45 AM
We are working with two FreePBX systems - configuration is identical on the two, at least in terms of FreePBX/Asterisk base settings and Extensions settings - basically a poor mans redundancy
All phones are on the following firmware, 69.84.0.10, but we have also tested a few of the phones on the latest 69.84.0.15 firmware (just in case).
The phones are auto provisioned, and we have setup the phones to work in fallback mode e.g.
1) SIP Server 1 and SIP Server 2 set (ip addresses for the moment - no DNS names used) - keeping it simple
2) No Proxy setup
3) Registration type set to 1 (successive) - not concurrent
Approximately 140 of 151 Yealink T27G phones Register with the Primary Server correctly and do not register with the Secondary Server (exactly what is expected)
Remove the Primary Server, and they all switch over to and register with the Secondary Server, bring the Primary Server online and within a short time, they are all registered back on the Primary server and deregistered with the Secondary Server
However I have 11 -13 of the T27G models that when brought online, they register to both Primary and Secondary (almost as though they are set to concurrent registration).
I have checked configuration, exporting the configuration from a unit that works correctly and one that does not - performed a diff and found no differences other than the password and extension number details.
Anyone else come across this issue....any thoughts....
Regards
Bob
RE: T27G - Fall Back issues - Successive setting [SOLVED] - BobBluePackets - 01-28-2019 06:03 AM
Finally got a bit of time to test / retest / changing one thing at a time.
Now have all phones working correctly.
The main upshot is that the phones must be factory reset and re-provisioned.
It most likely has something to do with a non-gui provisioned configuration line that was upsetting things, especially as I had been configuring with the proxy set (although not for successive).
With a factory reset and a re-provision of the phone from a correctly set auto provisioning file, the phone no longer tries concurrent registration.
Hope it helps someone in the future.
Regards
Bob
RE: T27G - Fall Back issues - Successive setting [SOLVED] - Jensen_Yealink - 01-28-2019 06:16 AM
(01-24-2019 12:45 AM)BobBluePackets Wrote: We are working with two FreePBX systems - configuration is identical on the two, at least in terms of FreePBX/Asterisk base settings and Extensions settings - basically a poor mans redundancy
All phones are on the following firmware, 69.84.0.10, but we have also tested a few of the phones on the latest 69.84.0.15 firmware (just in case).
The phones are auto provisioned, and we have setup the phones to work in fallback mode e.g.
1) SIP Server 1 and SIP Server 2 set (ip addresses for the moment - no DNS names used) - keeping it simple
2) No Proxy setup
3) Registration type set to 1 (successive) - not concurrent
Approximately 140 of 151 Yealink T27G phones Register with the Primary Server correctly and do not register with the Secondary Server (exactly what is expected)
Remove the Primary Server, and they all switch over to and register with the Secondary Server, bring the Primary Server online and within a short time, they are all registered back on the Primary server and deregistered with the Secondary Server
However I have 11 -13 of the T27G models that when brought online, they register to both Primary and Secondary (almost as though they are set to concurrent registration).
I have checked configuration, exporting the configuration from a unit that works correctly and one that does not - performed a diff and found no differences other than the password and extension number details.
Anyone else come across this issue....any thoughts....
Regards
Bob
Hi Bob,
Please try with below parameter and test:
account.x.fallback.redundancy_type=1
Let me the result.
BR
Jensen
RE: T27G - Fall Back issues - Successive setting [SOLVED] - BobBluePackets - 01-31-2019 12:11 AM
Jensen,
Appreciate the reply....
However the line you recommended was already in my provisioning file. That's the reason for my question, as it appeared that having performed some previous work on concurrent registration and using proxy settings, the phone appeared to have a left over glitch (even though I performed a configuration export and performed a diff between a phone that worked and one that didn't and showed no difference.
It should be noted that the 15 or so phones that were exhibiting this issue, I went through one by one, making sure that their provisioning file was correct, performing a remote factory reset of the each phone, and make sure that it read the provisioning file. Once done on each phone, I no longer have any phones registering to the secondary PBX in normal operation.
Regards
Bob
RE: T27G - Fall Back issues - Successive setting [Still an issue] - BobBluePackets - 04-14-2019 05:24 AM
This issue returned a few days later - highly unusual
Since then have done a lot more testing and diagnosis (however but of the issue is that the system in question is in full production use, in a remote location, so normal range of diagnostics is a little restricted.
As I did before the work, all of this mechanism was tested and tested again, before this was put into production.
Since then, we have implemented a full test replica again in a lab setup. It works perfectly...with both systems online - Phone only registers to the Production PBX. Shutdown the production PBX, and the phone registers to the Backup PBX. Bring the Production back online, within a minute or two, the phone unregisters from the Backup PBX and registers back to the Production system
Have confirmed that the T27G Phones on both the Production system and the Replica that we setup are identical. FIrmwares identical, configurations identical (except for registration details) - using diff against exported configurations.
In case I have not mentioned it, it is using Asterisk based system - same versions.
Now to be fair, this does not look like a Yealink issue entirely, however it is only the Yealink with the failover capability. Anybody seen this issue before???
RE: T27G - Fall Back issues - Successive setting [Still an issue] - jolouis - 04-15-2019 12:42 PM
Since you have replicated this in your lab/test environment, have you tried doing a full syslog dump on one of the suspect phones to see what it actually shows on the local side? That would probably go a long way to help get an idea of what is actually happening.
RE: T27G - Fall Back issues - Successive setting [Still an issue] - BobBluePackets - 05-28-2019 04:47 AM
Just posting back now that I have a reason and a solution.....Thank you for all the posts.
As mentioned, in a simple setup (Lab) the fail over function works and works as expected.
To resolve this issue, I completely built up a complete working replica of what we had setup in a production environment (sans as many phones).
Again, with the simple setup, it worked as was the expectation....
However with this setup, I went further and performed the manual sync we do on the production systems. As soon as I completed this, the issue appeared. Phones appear to be registered on both systems.
After a lot of debugging and at least some clearer direction of what could be the possible cause....
Found that the restore of the Primary PBX to the Secondary PBX, is also restoring the Asterisk database. This database contains the Registration states of all the phones, which is naturally carried across the to the Secondary PBX.
Now I have not had time to look at further, but from what I can see, the PBX is sending a keep alive to the phone, getting a response, keeping the record/state in play, and when a phone goes to make a call, it appears to be randomly selecting which PBX to make the call out on...(which could be based on registration refresh vs Qualify timings)..probably something to research on the next rainy weekend.
Anyhow.....the fix is when restoring the database, perform
database deltree registrar/contact on the secondary PBX
This will clear the registrations.....
After this all testing worked perfectly. Killed the primary server, phones started registering with the secondary. Bring the primary back online, phones deregister on the secondary and re-register on the primary - perfect.
Hope it helps someone....
Regards
Bob