Solved Voip trunks not resolving since updating to 16.5 yesterday

[NickG]

We use Voipfone here in the UK to provide three trunks, all working fine for years until we updated to V16.5 yesterday. Voipfone hasn't seen a registration since that time on any of them and the log for one of them is below

04/23/2020 10:07:51 AM - Lc:10001(@dsi[<sip:0/UDP>]): Registration postponed until target's destination is resolved

04/23/2020 10:07:51 AM - Registering Line Lc:10001(@dsi[<sip:0/UDP>])

04/23/2020 10:07:51 AM - Unregister: ADS for 10001 is not found

04/23/2020 10:07:51 AM - Unregistering Line 10001

04/23/2020 10:07:50 AM - Lc:10001(@dsi[<sip:0/UDP>]) Resolving targets: primary - sip:sip.voipfone.net:5060, no secondary over +UDP+IPv4+IPv6

04/23/2020 10:07:50 AM - Lc:10001(@dsi[<sip:0/UDP>]) is enabled now

04/23/2020 10:07:50 AM - Line 10001: Request for registration in 1141 ms

 

[NickG]

Tried that, no different. We have three trunks, set one back to sip.voipfone.net, the other two left on the ip address, set all services to delayed start, rebooted, trunk set to sip.voipfone.net not connected or resolving, the other two fine

 

[accentlogic]

We are a SIP provider and one of our customers is seeing the same issue. I was able to create a workaround for them by setting the Outbound Proxy to the IP address of one of our SIP servers. Auto Discovery also had to be disabled for both the Registrar/Server/Gateway and the Outbound Proxy and port set to 5060.

As previously indicated, this seems to point to a DNS resolver issue with the 3CX software.

Waiting to hear a resolution from the ticket with 3CX.

This also worked for one of our clients running a Windows server using SIPTRUNK.COM. We were able to work around the issue for one of the customer trunks by having the provider change it to IP AUTH.

We first tried setting all 3CX services to delayed start but that did not work.

 

[AWS2P]

As i experienced same behavior with French SIP provider Openip, i paste here to stay in same problem with others.
Hi,
using supported sip provider Openip, randomly I get on different W10 pbxs on premise, trunk become in unregistred state alone.
For now my pbx has lost his registration at 4.49:33 AM and PBX never sent any new attempt to sip provider since this time.
Got a mail notification from PBX

Trunk sip is from 3CX template, and pbx is latest version 16 SP5 but this random behavior was existing before.

So in trunk sip template , registration is set from DNS name (voip.myopenip.fr) . When this failure occurs , it's impossible to refresh registration, a click on refresh registration seems to do absolutely nothing. Date and time doesn't refresh on time you click on it. SIP provider side receive nothing.

In same time, have a beronet analog gateway used as trunk and even gateway is registred green, it's impossible to dial out. Got a 503 error from 3CX each try to dial out, message like , you need to ask to admin......
Of course rules are done properly to be used by gateway and port on gateway was free.

The only way to register SIP trunk is to edit settings and change domain name and replace with IP 94.143.87.216. SIP registration instantly reach sip provider and trunk passes green.
A nslookup on sip provider domain name is resolved on PBX (this to exclude a DNS resolution problem)

This behavior is not new but never been fixed since a while between 3CX and OpenIp, it looks like a bug on 3cx side IMO, do you have any infos for this behavior?
is there any investigations on this ?

In my case , this ramdom failure is only happening on windows PBXs on premise. Got this on two PBXs

Problem seen in Teamviewer session with @YiannisH_3CX .

 

[YiannisH_3CX]

@aws2p

Did you experience the issue again after the TV session? If so did you take any troubleshooting steps? Did you restart the server and did you try to set your services to delayed start?
Also as i mentioned in our session if you have another system that is currently experiencing the issue i would like to see it.

 

[sifi999]

Hi thanks for your email, our issue was exactly the same as @aws2p

We rebooted the server twice to no avail. DNS lookups were fine but as you say after the first error there were no further errors even after refreshing registration or reboot.

We didn't try putting in the IP address. May give that a go this evening but i'm wary as the underlying IP address may change. @YiannisH_3CX i am happy to restore it tonight after hours and run any tests you want.

 

[YiannisH_3CX]

Hi @sifi999

That sounds great. I will sent you a p.m now to arrange the tests.

 

[AWS2P]

Did you experience the issue again after the TV session? If so did you take any troubleshooting steps? Did you restart the server and did you try to set your services to delayed start?
Also as i mentioned in our session if you have another system that is currently experiencing the issue i would like to see it.

Hello Yiannis,
No, for now , nothing bad happens again, didn't change services to delayed start, as for me it's not while pbx start problem has occured but randomly in the night .

Yes, i got exactly same problem on a second pbx (windows on premise too) but it was before SP5 , so for now no recidive on this one too.

This morning on this one i got something I thought it was same problem but no , this time trunk was up green in console and registred on SIP manager view, refresh button for registration was working but on SIP provider side it was something wrong they can't explain in details , they just say pbx was registred but with a wrong public adress so calls were forwarded to degraded conditions number set on SIP manager. This PBX uses Same static Public IP since months.
I needed to stop services, SIP provider cleared their registration cache, restarted services on 3CX, refreshed register, done.

Like I said this kind of behavior is not often for me but this is existing almost since V14.

 

[JParo]

I'm seeing the same problems after the update as well. Flowroute, Windows Server 2016, running on AWS with 1.1.1.1 as my DNS. I changed my SIP to the IP and we're working now. Being that it's Monday morning, the system is in use and can't change back to the DNS to troubleshoot until later, which I plan to do. I've already set services to delayed start. Just can't restart right now.

I'm also noticing the CPU is at 25% now where before it was under 5% most of the time.

 

[daveatgower]

OMG it's so nice to see this thread... I have been hammering the provider thinking it was an issue on their end but we just can not get this working.

Edit 1: Changing the DNS to IP address has fixed our issue for now but it's not a good setup.

I hope in the future 3CX does more testing before a release like this especially when everyone is working remotely.

Edit 2: Email from Provider after the temp fix. "Signaling via IP address is not a long term solution. You may have issues with inbound calls due to our system relying heavily on DNS NAPTR/SRV."

FYI for anyone that makes this adjustment and to get back up and running.

 

[sst_ekell]

I tried all the work arounds listed, but ultimately the fix for us was to change the SIP trunk connection from the FQDN to the IP adress. This isn't ideal, but it works for the moment.

Also, since the update we are having an issue with our iPhone app clients where they ignore the dialing rules and append an extra 1 to numbers. All other clients are working a-okay.

 

[mpersak]

I've got exactly same issue, it does register through IP address but not DNS.
DNS resolution is OK.
We have 2 network cards (one dedicated for voip traffic) but it just doesn't send anything through that card when I am registering via DNS. When I do it through IP it works... now trying to find v16.04 to restore...

 

[sifi999]

3CX support logged in yesterday and were really helpful. It appears it is a DNS issue where the trunk provider's address returns a SRV record instead of a IP address, it appears it is waiting for an IP Address to return, sometimes it works as well so it is intermittent.

As many have suggested it works if your provider can give you an IP address that will be maintained and won't change.

I understand they'll now fix the bug. I have reverted to 16.04 for now.

 

[daveatgower]

We had another phone system that updated over the weekend show signs this morning of this issue just like our other ones. Once I changed it to the IP Address we were back up and running. Not a good solution, 3CX please fix asap.

 

[NickD_3CX]

Hello everyone,

We have been working with some of the users in this thread to get to the bottom of this.

Just an update on this matter, we believe we have found the root cause of the issue that causes this to happen and we are working on a solution.
It seems that it is triggered whenever the PBX sends a DNS query, but the response packet is never received.

We will keep you updated on the progress.

 

[AWS2P]

glad to hear you found a gnawing bone

 

[JParo]

FYI, @YiannisH_3CX logged in and put a patch on our system and looked around to gather info. It seems to be working fine now with the patch installed.

Thanks for the help!

 

[AWS2P]

Hi 3CX team,@YiannisH_3CX @NickD_3CX
is it possible on pbxs using bridge links to have same problem origin in link loss between both ends of bridge?
Most of the time bridge link is down almost once a day, stay down 2 minutes and back up alone. It starts with DNS resolution like for trunks

bridge in same time goes down

2 minutes later brigde and trunk goes UP alone


What you think about this ?

 

[YiannisH_3CX]

First i would like to thank all of you for your time and your assistance on this and to apologise for any inconvenience this might have caused.
We have just released a new version of update 5 that addresses the issue. The update will only be available for Windows since only Windows installations were affected by this. Debian users will not see an update and do not need to do anything.
The update should be available in the next few hours in the update section of the management console. Please update your PBX and let us know if you face any more issues.

 

[Alphabetic]

Great stuff!

 

[AWS2P]

Thanks Yiannis ,already started to apply .612 release