Solved Yealink T54W re-provision delay for Hot Desking

[jameshs]

We are testing out Hot Desking with the Yealink T54W phone, F/W 96.86.0.45, 3CX 18.0.237
When we log out or login to the phone it takes nearly exactly 6 minutes before the phone starts requesting data from the 3CX server. The Phones are on the same VLAN and Subnet as 3CX so use PnP with the Local LAN method of provisioning.

I have been running packet captures on the 3CX server and I can see 3CX sends the SIP Notify Event: check-sync;reboot=false to the phone immediately after logging in or logging out and then the phone seems to do nothing for around 360 seconds when it sends out an ARP request for 3CX IP Address and then starts requesting the provisioning files.

Is there some setting that determines when the phone should respond to the check-sync command? Is this a firmware or configuration bug?

I've searched the forum and only suggestion I can see is to check time sync but both the phone and 3CX server are set to use the same NTP server and are in correct time zone. They both show correct time on phone screen and in 3CX.

 

[ChrisC_3CX]

I just tested this with a Yealink T54W on 96.86.0.45 connected via the 3CX SBC to a cloud 3CX PBX running v18.0.1.237 and can confirm that this is not an issue. It took approximately 20 seconds to complete provisioning when either logging in or out. To start requesting the file it took less than 5 seconds.

That said, I'd recommend not only performing a packet capture on the PBX but also on the IP Phone to compare them and determine if the SIP NOTIFY message is perhaps arriving late to the device. If this is the case, you could then probably also perform packet captures on intermediate network nodes to pinpoint the cause or at least narrow it down.

If there is no significant delay between the two, you might want to consider comparing the HTTP GET sent by the IP Phone on both captures and then the actual data for the file.

 

[jameshs]

Thanks Chris. I have just compared a capture on the phone itself to the server and it is definitely getting the SIP NOTIFY message straight away. The devices are on the same VLAN and are connected with about 4 switches between them, no routing occurs (Hyper-V VM Switch, Top of Rack, Core, IT Office).

Testing the 3CX Phones Reprovision button and I can see it sends the SIP NOTIFY command as well and the phone again receives it straight away but still delays when it sends the HTTP GET requests to 3CX.

Further I just tried directly pressing the Auto Provision Now button in the phone interface and it shows reprovisioning screen for 6 minutes.

I've now opened a case with Yealink and sent them the debug files from a SIP Notify and pressing Auto provision in UI so will see what they say.

 

[jameshs]

Just to post a resolution in case anyone else experiences this.
The problem was caused by DHCP Option 043 that was configured on our DHCP server to auto-Configure phones for our existing NEC phone system. We had configured DHCP options based on this page DHCP options for SIP server and SIP port but it appears this breaks the Auto-Provision on Yealink phones so it has to wait for multiple timeouts before it downloads the files.

To solve it I created a Policy on the DHCP Server to only apply the NEC Option 043 value to clients whose MAC address starts with F8B7* which matches all our NEC Handsets.

 

[ChrisC_3CX]

Glad to see you managed to track this down and thanks for sharing!

This info will definitely prove helpful to people with similar setups in the future!