I am using vultr as my host, and a strange thing happened today with all of my machines. There is a good 10 second delay from the time I press call until the call goes through even from a local extension to another. It takes about 5 seconds until I see the call on the log, and then another 5-second delay until the other phone starts ringing.
Vultr says its not them, but its on multiple machines, and from multiple ISPs, any suggestion?
Below is a capture of the call from my router
Thank you
I saw in a post that it suggested the issue may be with DNS, I edited my /etc/resolve.conf file to be 8.8.8.8 but still doesnt help
TY
Confirm that in Asterisk SIP Settings, the entries related to STUN, TURN and ICE are all blank. These are normally not relevant to a cloud PBX, but if the lookup fails, the call is delayed until it times out.
If that’s not it, paste the Asterisk log for a failed call at pastebin.freepbx.org and post the link here.
A call between extensions would not normally do any DNS lookups, but note that a lookup can take a long time to fail if none of the servers for the domain being queried are responding, regardless of the caching server specified locally.
Thank you. I checked and they are all blank. Here is a copy of my log
https://pastebin.freepbx.org/view/a3616b02
I hung up once the other phone started ringing
The entire log you posted has timestamps for the same second, so nothing obvious there.
However, line 200:
[2021-01-13 18:34:04] ERROR[2048] netsock2.c: getaddrinfo("XXX.XXX.XXX.XXX.vultr.com", "(null)", ...): No address associated with hostname
is really bizarre. I assume that XXX.XXX.XXX.XXX is the IP address of the PBX. If you do a reverse (PTR) lookup for that, Vultr’s DNS servers return XXX.XXX.XXX.XXX.vultr.com and a forward lookup of that name indeed fails.
However, AFAIK Asterisk or FreePBX never does any PTR lookups. Possibly, this is occurring in your client device, or happened once and got stored somewhere.
At the Asterisk command prompt, type
pjsip set logger on
make another failing call and paste the new log, which will now include a SIP trace.