Yealink Forums

Full Version: T27G - Fall Back issues - Successive setting [Still an issue]
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
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
(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
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
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???
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.
Reference URL's