Solved Hosted 3CX - VOIP.MS registration status unregistered

[wrick]

Merry Christmas !

We are an automotive group deploying a 3cx instance to replace old analog phones.

Through my testing, all instances were local or self hosted. To ensure stability ( and hey, a year of free hosting is a year of free hosting, right ? ) we went with a pro subscription, and 3CX hosting.

The VOIP.MS privider is a recognized Canadian SIP trunk provider.

Here's a snippit of logs :

Trunk L:10001(*****) has changed status to registered.

SIP Server ID: 4100 12/24/2021 1:47:44 AM
Registration at ***** has failed. Destination (sip:208.100.60.28:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.

SIP Server ID: 12293 12/24/2021 1:45:35 AM
Trunk L:10001 ***** has changed status to unregistered. This means that no more calls will pass via this trunk. Please check your network connection and the voip provider or other SIP PBX

SIP Server ID: 4100 12/24/2021 1:45:35 AM
Trunk L:10001(*****) has changed status to registered.

SIP Server ID: 4100 12/23/2021 9:37:44 PM
Registration at ***** has failed. Destination (sip:208.100.60.28:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.


The **** are just to blank identifiable information.

I've used different servers with VOIP.MS, same result. As per Voip.MS support, I've replaced the domain name with the direct IP ( as shown above ). We are still getting connectivity issues.

As the instance is hosted, there isn't much diagnostics I can do on my end, and I thought I'd run the issue through the forum before going towards support. I haven't had any complaints from staff about dropped lines ( yet ) but I also have a backup SIP trunk setup since this started. I've tried rebooting the instance, services, changing servers for the SIP Trunk, you name it.

Any input appreciated !

 

[Evolute IT]

Hi,

So, this is something we experienced recently with a Hosted instance as well, and it ended up getting fixed by itself. We were using Telnyx.

If you don't have dropped calls and such, you can probably ignore the errors, but only if they happen from time to time. If it's everyday or every hour, definitely something is wrong.

I suggest you open a support ticket so that they can take a look at the backend. They use DigitalOcean as provider so maybe they have network issues.

 

[NikosT_3CX]

@wrick Merry Christmas to you too !!
These messages PBX generates mean that the PBX does not get a response back to the packets that have been initiated.
What you may do is to open the Management Console on a second tab also, go to Activity Log, check on the right side and press Capture.
Go back to your 1st tab and refresh Registration of your provider.
When done stop the capture and download it on your PC.
Open it with Wireshark and you may filter directly with the ip address of your provider and check if you get any response back ( ip.addr == x.x.x.x ) .
With this way if you see packets going one way, this means your provider does not respond back to the packets that have been sent from the PBX side to them. Give them the capture also and ask them to clarify why they don't respond back to the sip packets.
I can not see any issues with your machine or network delays.

 

[wrick]

Could the registration timeout cause an issue here ? It is set at 120s.

 

[Evolute IT]

Could the registration timeout cause an issue here ? It is set at 120s.

It shouldn't, but you can try setting it to 60 or 30 to test.

 

[wrick]

Voip.ms is having me switch it to an international server to run tests.

Voip.ms support ;

I am trying to look for any kind of block on our side, tho I am not able to, the only thing I can see is that the IP your provider for the 3CX is using is a VPN, that may cause issues, as a quick test can you try using an international server? Just for testing, like paris1.voip.ms.

I'll set it overnight as our offices are closed and look for any failed registrations.

 

[AlexisV_3CX]

Hello Rick!

note that we have no private network interfaces configured in any of our deployments! I have also checked your instance again for any networking issues or delays, and everything is stable.