Phone provisioning/Phone not visible in "phones" section...

[narrington]

I am setting up several new phones in a new office... I was able to set up 3 phones with no issues; I plug the phone into the switch, phone gets DHCP IP, phone appears in the "Phones" section in the 3CX web UI, click the phone, click "Firmware", firmware updates, phone reboots, add phone to extension, done.

But now, New phones aren't appearing in the "Phones" section... period.

I would "maunally" provision them, except the "manual provisioning process directs me to select the phone to be provisioned in the "phones" section...

What the heck?

 

[cobaltit]

So the simple answer could be that you need to refresh the tab. I don't believe the phones page is 'dynamic' so it won't show new phones that might pop-up when you have that tab already open.

 

[narrington]

So the simple answer could be that you need to refresh the tab. I don't believe the phones page is 'dynamic' so it won't show new phones that might pop-up when you have that tab already open.

Yeah, you replied just as I was typing up the solution. sorry.

The issue was multicast. We have bonded nics (3CX debian install) for load balancing and redundancy. the bond is slow to start so the 3cx service tends to start before the bond. thus the multicast doesn't bind to the bond interface. theres a "solution" (not reliable) and a work around (inconvenient).

"Solution": Link
Work Around: Run the firewall checker, which will stop the SIP server for a minute or so.

 

[cobaltit]

Ahh ok. I was going to move to that but wanted to rule out the easy stuff and you didn't mention having rebooted the box. Glad you found the solution and apparently 3CX either hasn't resolved it yet per the thread you linked or the resolution is something they've done in the 3CX ISO and not the 3CX deb (assuming you installed manually).

@YiannisH_3CX @JohnS_3CX

Any info as far as progress on the issue? It was mentioned by Yiannis in the linked thread that 3CX was aware of this.

 

[JohnS_3CX]

Hi @cobaltit

We are aware of this but I'm not sure if there is a good way to do this yet. On one hand, it only affects a small amount of machines, on the other hand if we implement delayed start then a lot of installs will be affected without good reason (and at the risk of breaking other things). At the current stage I think it makes more sense for an admin to implement the delays on a per-case basis as such or use a different NIC if that is feasible

 

[cobaltit]

Thanks for the response. I'm not a unix expert but wouldn't something simple like putting 'After=network.target' in the service unit file for the 3CX services do the trick without slowing down the startup unnecessarily?

 

[JohnS_3CX]

The main thing to consider is that since specific NIC & driver combinations are the reason for the delay in initialization (because different manufacturers will do things in different ways), it goes out of the scope of the PBX, and becomes more of a specific hardware-related matter.

We will still look for ways to improve it however, if it can be done without affecting many customers unnecessarily. Currently I would agree that it should be up to the hardware admin, given that there are so many NIC chips and drivers out there and the PBX should remain agnostic of the chip and only speak to the OS.

 

[cobaltit]

Understood, but with standard configurations adding that parameter shouldn't slow down most installs and it would resolve the edge cases no? Or maybe at least a 3CX article on which service to add that value to if folks are experiencing the issue. That way there is at least a standardized approach.

 

[JohnS_3CX]

We probably could, but since it's edge cases then it might not be worth the risk of upsetting other users. I still think its best done on a per-case basis, so no plans for the time being at least.

 

[narrington]

<sarcasm>
How about a simple option to restart services in the dashboard, or settings module. I know it's a "big red button" but simply having it as an option rather than firing off a firewall test would make "catch-all" troubleshooting an option...

"Have you tried turning it off and back on again?"
</sarcasm>

In all seriousness restarting the SIP services is not really that big a deal. the only thing I would recommend is adding a "delay service" start option for each service within the dashboard. I'm not sure how to best implement such an option... But I cant imagine it would be anywhere near as complicated as trying to accommodate each and every install scenario of 3CX.