Lines unregistered and wouldnt register until re-provisioned

[jrodcpwk]

Yesterday evening I had my 5 desk phones operating just fine until we left at 8pm. I came in at 8am this morning and they were all unregistered? Our cellphone apps and desktop apps were working fine though. A little background to our setup, we're site to site to our datacenter which hosts the 3CX instance. I doubled checked our site to site and its uptime still stated 80 days+ so that wasnt the issue. I restarted all the 3CX services and they still were down. Last part was to factory reset the deskphones then re-provision them, voila it worked just as normal. Any idea how this would happen?

The one thing I noticed is that I have a couple of other clients using 3CX instances we host on our datacenter except I put them all on their own vlans for their instances. I tried to share a smaller company with ours and it tested out just fine but they had a drop as well earlier in the week and now us. Im guessing this may be the culprit as other clients have been operable just as long if not longer and had no issue similar to this. Any other insight would be appreciated.

 

[eddv123]

we're site to site

We have had similar issues with IPSec VPN's either one of the following is the issue/fix and both are network related and nothing to do with 3CX.

As you maybe aware with SIP once a connection is established its effectively left idle until an event has occurred (such as a phone call) the majority of our issues have been discovered first thing in the morning too, opening of the office - all phones de-registered.

I think your re-provisioning aspect of this is just a red herring and performing this process simply re-generates the idle connection.

Stale VPN connection:

In some cases the reason for this is due to a stale VPN connection and a bounce of the VPN solves it temporarily.

The permanent fix was changing the VPN's Phase 2 time rekey to a higher value (a short or mis-matched rekey timer has been found to be the root cause) however in some circumstances this does not always solve the issue and the phones stay de-registered (even after a VPN bounce).

UDP transport for SIP:

On some sites the only real fix had been to change all the phones Account SIP transport type from UDP to TCP (this puts a lot of strain on resources however) and this solves the issue.

Where I have a suspicion (despite the LAN >> LAN nature of VPNs) that the firewall/network is playing
a part there is very little that can be done about this as I believe it is in relation to the already mentioned SIP idle time-out.

Despite the network related issue I think we would see more positive results in these areas if 3CX natively put in an option for deskphones to support TCP traffic (only available currently with manual configuration or custom template) - after all networks generally are friendlier to traffic on TCP than traffic on UDP.

 

[Rhys Haskell]

If you change the UDP nat time out to 193 seconds it may fix it, it did for us.