Strange PnP behaviour for Yealink T40G phone taking 4 DAYS to appear in Phones node?

[LiscardGP]

Does anyone have any suggestions why it took 4 DAYS for a correctly configured yealink phone, set to factory defaults, to appear as a new phone in the Phones node?

I am looking for a solution because I would like to prevent it occuring again.

Background
3CX debian 9, latest stable version, running in on Google Cloud Platform. Single newtork interface with static IP. Local Range of IP addresses are in the "White list". Ports are correctly configured.
Local network, dedicated to IP phones with dedicated internet connection, connects to 3CX via SBC running on a dedicated Windows 10 PC with single NIC not running any other software or antivirus programs (except windows defender). Disabling firewall made no difference.
Phone running correct firmware and reset to factory default settings.
Problem identified when I decided to move the phone to another extension. Threfore reset phone to factory default and expected it to appear in Phones node, ready for reassingment, but it took 4 days to appear? Once it did appear it provisioned normally.
This pattern of behaviour was replicated on a second yealink phone but, as it was needed, I reprovisioned by adding the provisioning link into the phone's web browser.

Thanks in advance for any feedback.

 

[Alphabetic]

You've failed to mention what networking device your phones plug in to.

Have you got a smart switch that is manipulating multicast?

https://www.3cx.com/docs/plug-and-play-ip-phone/

 

[ChrisC_3CX]

@LiscardGP
Kieferschild may be onto something, before investigating this any further, you might want to confirm if this may be the case by checking if the multicast messages sent by the IP Phones when booting up are actually reaching the 3CX SBC. If you perform a packet capture on the SBC while booting up an affected IP Phone, you should see a SIP SUBSCRIBE message sent from the IP Phone to multicast IP 224.0.1.75. This message will then be forwarded from the 3CX SBC to the 3CX PBX via the 3CX Tunnel.

Note: Make sure that the IP Phones in question are running the latest 3CX Supported firmware.

 

[LiscardGP]

You've failed to mention what networking device your phones plug in to.

Have you got a smart switch that is manipulating multicast?

https://www.3cx.com/docs/plug-and-play-ip-phone/

It is a Cisco SPA502G managed PoE switch running with factory default settings.

Thank you very much for this very helpful feedback. Much appreciated.

I will investigate and reply when I have more information.

 

[LiscardGP]

@LiscardGP
Kieferschild may be onto something, before investigating this any further, you might want to confirm if this may be the case by checking if the multicast messages sent by the IP Phones when booting up are actually reaching the 3CX SBC. If you perform a packet capture on the SBC while booting up an affected IP Phone, you should see a SIP SUBSCRIBE message sent from the IP Phone to multicast IP 224.0.1.75. This message will then be forwarded from the 3CX SBC to the 3CX PBX via the 3CX Tunnel.

Note: Make sure that the IP Phones in question are running the latest 3CX Supported firmware.

Sounds like a job for wireshark installed on the Windows PC running 3CX SBC. Am I correct ?

I was hoping to avoid this but your advice to look for SIP SUBSCRIBE will be very helpful.

Thank you for your helpful feedback.

 

[ChrisC_3CX]

Sounds like a job for wireshark installed on the Windows PC running 3CX SBC. Am I correct ?

That is correct! Hopefully you'll be able to at least narrow it down.

 

[LiscardGP]

I have done further testing and it appears the problem has resolved itself, even though there has been no change to the network configuration ! However the Cisco Switch and the Draytek Router were both rebooted in the interim.

So it looks like it is just a matter of waiting to see if the problem recurs, but at least I know how to investigate should it do so.

Wire Shark showed the correct multicast mesages are being recieved on the PC running the 3CX SBC. Additionally the test handset appears in the Phones node as a "New Phone" awaiting configuration.

I confirmed the multicast settings on the Cisco Switch are disabled, but I did find the Draytek Router is functioning as an "IGMP Proxy" and also has "IGMP Snooping" enabled. There are no VLANs active on the network so I am not sure if these options could be implicated?

Disabling IGMP Proxy, and Snooping, on the Draytek Router does not appear to affect multicast packets getting trough to the PC running 3CX SBC.

So it's a bit of a mystery unless there are any other suggestions.

Thanks for the advice.

 

[ChrisC_3CX]

@LiscardGP

I cannot confirm or deny if those settings you mention will affect this specific scenario, though, if it does happen again, running the packet capture on the 3CX SBC as you have already done will at least tell you if the issue is within the LAN. You could simultaneously run a packet capture on the 3CX PBX to check if it gets sent over via the 3CX Tunnel by the 3CX SBC and therefore determine if the issue is between 3CX SBC and PBX too. For the 3CX PBX packet capture though, you would have to check the loopback IP (127.0.0.1) instead of multicast IP (224.0.1.75).

Hope this helps!

 

[LiscardGP]

@LiscardGP

I cannot confirm or deny if those settings you mention will affect this specific scenario, though, if it does happen again, running the packet capture on the 3CX SBC as you have already done will at least tell you if the issue is within the LAN. You could simultaneously run a packet capture on the 3CX PBX to check if it gets sent over via the 3CX Tunnel by the 3CX SBC and therefore determine if the issue is between 3CX SBC and PBX too. For the 3CX PBX packet capture though, you would have to check the loopback IP (127.0.0.1) instead of multicast IP (224.0.1.75).

Hope this helps!

Thanks for your help.

 

[ChrisC_3CX]

@LiscardGP
You're very welcome!

Do let us know if there is anything else we can do to help should this issue persist!