Outbound Calls Fail after Upgrade to v16 SP3

[knollwood]

Ran the update to v16 SP3 this morning. Suddenly, all outbound calls no longer work. Server appears to be working fine. Inbound calls work.

Event log shows Cause: 408 Request Timeout/INVITE from local.

What could the update have changed to affect me?

 

[StefanW]

Do you use a gateway or a provider, plz state which?

 

[knollwood]

Provider. nexVortex. Didn't change a single setting. Was working before the update but not immediately after.

 

[knollwood]

Changing the "Registrar/Server/Gateway Hostname or IP" to Auto Discovery enables us to make outbound calls now. The port 5060 that was manually entered before worked fine right up until the update, so I'm not sure what caused our problem.

 

[SweetAction]

Isn't netvortex updating their IPs, server names, etc?

Maybe just bad timing?

 

[luckystrikes]

We had this same issue but to SP2 - obviously quite the freakout.

Did a backup/restore and it resolved it... Restarting the server did nothing and not sure what went wrong exactly to this day.

 

[Jón Gauti]

We're experiencing the same issue with a couple of our PBX's. Upgraded to SP3 and a few calls are randomly dropping due to the same error

has failed. 0.0.0.0 replied: 408 Request Timeout; internal

 

[Jón Gauti]

We managed to reproduce the errors from here above. 3CX SP3 introduces TLS for SIP trunks, and there is a field where you can configure it.
If you pick TLS, but don't configure it, you get the error I mentioned above. Similar errors occur if you pick TCP and the SIP Provider is not configured to recieve TCP.
It seems that in some cases, if you have "Any" as a value for the transport protocol, 3CX automatically chooses the transport type of the SIP messages to something other than UDP.

 

[Remip]

We managed to reproduce the errors from here above. 3CX SP3 introduces TLS for SIP trunks, and there is a field where you can configure it.
If you pick TLS, but don't configure it, you get the error I mentioned above. Similar errors occur if you pick TCP and the SIP Provider is not configured to recieve TCP.
It seems that in some cases, if you have "Any" as a value for the transport protocol, 3CX automatically chooses the transport type of the SIP messages to something other than UDP.
View attachment 12714

Same here. We support a few dozen customers. One was reporting issue's last week after the last update. After 32 seconds some outgoing calls dropped. I noticed that some sip traffic became TCP. Changing this setting solved the problems.