Solved REOPEN: New phones not appearing under "Phones"

[ESA-AT]

It's the exact same problem as last time (1 month ago): https://www.3cx.com/community/threads/new-phones-not-appearing-under-phones.120999/

Last time I updated 3cx to the newest Version and that somehow fixed our problem. Today this problem resurfaced, no unprovisioned phones are being detected. We were able to provision new phones up until today. We didn't change anything, same version and same network infrastructure.
Restarting Windows didn't help.

Version 18.0 (Build 441)

 

[Charles_3CX]

Regarding your question and the issue mentioned, if the phones do not appear as new in the management console's phone node, they could be related to several factors.

Firstly are these phones supported with 3CX, and is their firmware the correct version?
Check this guide: https://www.3cx.com/docs/phone-firmwares/

If the above points are correct, proceed with the following:

• Check that these phones have not been added to the system or any system as remote Stun or SBC in the last 14 days.
• Then check that the Phones and 3CX systems are on the same VLAN, as multicast will not work across routed networks or when multicast traffic is not allowed between network locations.
• Then also check that there is no DHCP option 66 enabled on the network, so the phones are automatically directed to a provisioning URL.

All the points mentioned above are where you can start checking for where the issue may be.

 

[ESA-AT]

I found that dhcp option 66 is enabled. Its value is an URL to our local 3cx, it seems very specific. It was probably done some time ago by someone who does not work with us anymore.

Are you saying this shouldn't exist or are there any correlating options/settings I should check in our 3cx management interface?

 

[Charles_3CX]

Well whether it should exist or not is up to you and if you want phones to auto provision or not.

See the guide here: https://www.3cx.com/sip-phones/dhcp-option-66/

 

[ESA-AT]

Thanks, I was able to solve the error using your guidelines.

For future readers:

We are using Yealink Phones. Our old option 66 rule was configured to apply to specific MAC-addresses. 805E0C* & 001565*. I guess since those were the only phones we were using then. The new Yealink phones we are using have MAC-addresses like 805EC0*. That last one was missing. Adding it fixed our problems.

 

[Charles_3CX]

You are welcome, glad your issue is resolved and to have helped.

 

[SweetAction]

Thanks, I was able to solve the error using your guidelines.

For future readers:

We are using Yealink Phones. Our old option 66 rule was configured to apply to specific MAC-addresses. 805E0C* & 001565*. I guess since those were the only phones we were using then. The new Yealink phones we are using have MAC-addresses like 805EC0*. That last one was missing. Adding it fixed our problems.

Can you share more details? What DHCP server are you running that allows you to specify option66 for specific macs only?

 

[ESA-AT]

Windows Server 2012 R2 - using the dhcp-snap-in you can create guidelines (certain ip range and options such as option66) that only apply if specified conditions are met, such as the MAC starting with 805EC0*

 

[SweetAction]

Windows Server 2012 R2 - using the dhcp-snap-in you can create guidelines (certain ip range and options such as option66) that only apply if specified conditions are met, such as the MAC starting with 805EC0*

TIL. Thank you.