Solved Ver 16.0.5.611 Update - SIP Connection Broken & High CPU Usage

[DonB]

3CX Version, Standard Annual 16.0.5.611
Server OS, Windows 10
On premises install
IP Phone Make/Model/Firmware - n/a
Provisioning Method: Local
Trunk Provider : IT Communications Ltd (UK)
Has the Firewall Checker passed: YES
Are custom Phone Templates being used: NO

After installing this update (from 16.0.4.504), the previously working SIP Trunk is not connecting. No related error is showing in the Event Log.
Also, the CPU is running at about 50 to 75%. Windows Task Manager shows that majority of the load is coming from the process "3CX PhoneSystem 01 SIP Server"
Any thoughts ?
Tks, Don

 

[cobaltit]

It's in several threads in this forum. There appears to be an issue with Update 5 on Windows installs. Restore your backup until 3CX sorts it out.

 

[DonB]

Thanks. I'll give that a try sometime over the weekend. This issue has nobbled two installations I look after - both on Windows. Fortunately my own, which is running on Debian Linux, is fine !

 

[NickD_3CX]

Thanks. I'll give that a try sometime over the weekend. This issue has nobbled two installations I look after - both on Windows. Fortunately my own, which is running on Debian Linux, is fine !

Hey! as cobaltit mentioned we have had a few reports of these and we are in the process of looking into it.
Before proceeding to downgrade, could you switch the logging lvele to Verbose and restart all 3CX Services?
If the issue remains after restarting services, let it sit for 15-20 minutes and if possible please send me the logs in a PM ("Generate Support Info"from the top-right menu).

As we haven't managed to replicate this yet in house, it could potentially help us greatly in understanding what is causing it and get to the bottom of it.

 

[DonB]

NickD - thanks for your interest. I'm collecting verbose logs at the moment.
One other thing I noticed was that the Dashboard shows "Trunks Up 1/2" in green. I would have thought that it should maybe be red. The two trunks are the WebMeeting Bridge (up ok) and my SIP provider (not ok).

 

[DonB]

Further. I'm not right about the "Trunks Up" showing green. Some of my extensions aren't up, and it shows green ok.
I've got a log now, and will send it in a mo.
Don

 

[cobaltit]

Further. I'm not right about the "Trunks Up" showing green. Some of my extensions aren't up, and it shows green ok.
I've got a log now, and will send it in a mo.
Don

Thanks for your help troubleshooting. Mostly people come here to complain. Obviously there's some scenario they didn't forsee or couldn't test and it didn't come up in the alpha or betas so your logs and testing are much appreciated.

 

[DonB]

Thanks for your help troubleshooting. Mostly people come here to complain. Obviously there's some scenario they didn't forsee or couldn't test and it didn't come up in the alpha or betas so your logs and testing are much appreciated.

I know the feeling !
If it gets me going, that's good, and if it helps 3CX and others too, splendid

 

[DonB]

Just a quick update, and a call out for NickD_3CX !
We did a joint remote session on the two systems I'd been having problems with. We came across some possible strangeness when the DNS server was on the same sub-net as the server (ie the router address). Changing this to another one (eg Google DNS 8.8.8.8) did appear to fix one site although, oddly, changing it back didn't break it again.
There were some anomalies with 3CX starting up after a reboot. The computer in question wasn't too powerful, and seemingly it maybe didn't have the IP stack fully running before 3CX was attempting to start network services. Setting all 3CX services to delayed start did the trick here.
There was also a bit of a red herring, as I'd had some erroneous information from my SIP supplier. But it didn't prevent Nick from getting an idea of where the problem may lie.
Result - two Version 16.0.5 systems now running ok on Windows, and some useful knowledge gained on tracking down issues