Solved 503 DNS timeout on pbx

[OCWI]

All of our setups look like this:

OVH hosted, onsite pi SBC, Telnyx as trunk providor. All latest firmware/software

Lately , on two of them we get following intermittently:



Image also attached.

I submitted a ticket to 3cx and they gave me the generic reply of we need a trace - fine but with the symptom being intermittent i cant reproduce it on demand.

The customer states that they can receive inbound calls when this is going on, but not make outbound calls.

We suspected it to be a bad vps on ovh so we spun up a different one, which seemed to fix that one (for a day so far...) , however since then it started happening on another one.

Anyone else run into this or have any idea what could be causing this?

 

[OCWI]

to add tho this, also intermittent - the PBX's in question will randomly not be able to update with the error of cannot reach updates server. They also wont be able to email out (using a known working gmail account).

 

[StefanW]

I submitted a ticket to 3cx and they gave me the generic reply of we need a trace

Well, you might can understand that we don’t have a magic crystal ball to know what the issue is in your network setup / config. That you have a DNS or network connectivity issue I think you know. So, as generic it appears to you, as much it is needed to assist you, better to see it this way...

 

[OCWI]

Stefan,

Thanks for your reply.

The difficult part is its intermittent and cannot be currently reproduced. Im wondering if any other users have ran into this in their experience and could point me in the direction. Since OVH is such a popular hosting platform for the PBX i was hoping someone has seen this in that context and could throw some ideas out.

Ill be happy to provide a trace through the ticket, just as soon as i can reproduce the symptom, but my intent of posting on here was to have multiple irons in the fire so i can tell the customer im doing everything i can for them. There are many users who have very similar to deployments to mine. It is my hope they say "yes, we are also experiencing this with OVH starting last week, here is what he tried, or better yet here is what we did to fix it".

The point of the post to the community forum was to try and get some collaborative effort towards a resolution, please understand i was not attacking you or 3cx.

 

[Sopock]

Anyone else run into this or have any idea what could be causing this?

We can guess

Spoiler: How Telnyx Leverages VXCs

The meteoric rise of cloud providers and cloud services, however, has changed the infrastructure of the internet. Nowadays, large hosting services like AWS, Azure, and Softlayer move too much traffic to rely on multiple ISPs as middlemen. Instead, they’ve built up infrastructure connecting their services to each other and to carriers directly. These connections, called virtual cross connects, provide fast, secure ways to manage traffic without relying on the public internet.

Most VoIP providers today are not true providers; they’re VoIP resellers who rely on another company’s infrastructure or resources, often connecting with them on the same public Internet connection that they use to connect to their customers.

• When you think of SIP trunking, you may think it refers to sending phone calls over your company’s public Internet connection. Which is one way of delivering SIP calls to your phone system. And you’re right, this method is about as reliable as your child, telling you their room is clean.

 

[Sopock]

but my intent of posting on here was to have multiple irons in the fire so i can tell the customer im doing everything i can for them.

Disable that trunk and create another one which will register to IP instead of server name?

I hope that at least we can find a way to solution which by V18 will handle such errors more seamlessly. For example, 3CX should remember all resolved IPs in array which can be used in case of DNS timeout.

It looks up the SRV record, attempts with the highest priority record, but if a failure occurs (or this server is down) 3CX fails the call.

Spoiler: Cisco Support Community

Assiming your environment doesn't change so much, it's superfluous to detect parameters again and again.

 

[OCWI]

This is brilliant!! It worked and solve my issue! THANK YOU SO MUCH @Sopock !

 

[YiannisH_3CX]

Glad the issue is now resolved