FOOD FOR THOUGHT resolv.conf

[Brianmac]

IPBX20-20, on Vultr - having delay on incoming\outgoing calls and believe its DNS related. What "normally" should be in the resolv.conf file? does 127.0.0.1 need to be in there? Right now I only have both google DNS servers in the file, 8.8.8.8, 8.8.4.4
Thanks,
brian

 

[atsak]

127.0.0.1 normally shouldn't be unless you're running a recursive DNS server, at least the way I set it up. Why do you think it's DNS related?

 

[Brianmac]

In all the forums(here, freepbx), most people say its a network issue relating to DNS. I can't figure out why there is a delay on incoming and outgoing calls. sometimes 8 or 9 seconds...

 

[atsak]

In all the forums(here, freepbx), most people say its a network issue relating to DNS. I can't figure out why there is a delay on incoming and outgoing calls. sometimes 8 or 9 seconds...

You could try 1.1.1.1 as well as the first one. If you do an nslookup or ping does the lookup seem fast or ?? I've also seen caller ID superfecta hold things up. Do you see the call in the log and if so do you see the delay in the timecode?

 

[Brianmac]

if I putty into PBX, nslookup is fast....

WARNING: Always run Incredible PBX behind a secure firewall.
root@noreply:~ $ nslookup www.ibm.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
www.ibm.com     canonical name = www.ibm.com.cs186.net.
www.ibm.com.cs186.net   canonical name = outer-ccdn-dual.ibmcom.edgekey.net.
outer-ccdn-dual.ibmcom.edgekey.net      canonical name = outer-ccdn-dual.ibmcom.edgekey.net.globalredir.akadns.net.
outer-ccdn-dual.ibmcom.edgekey.net.globalredir.akadns.net       canonical name = e2874.dscx.akamaiedge.net.
Name:   e2874.dscx.akamaiedge.net
Address: 104.64.210.60
Name:   e2874.dscx.akamaiedge.net
Address: 2600:141b:5000:6aa::b3a
Name:   e2874.dscx.akamaiedge.net
Address: 2600:141b:5000:6a8::b3a

WARNING: Always run Incredible PBX behind a secure firewall.
root@noreply:~ $

 

[Brianmac]

This has also been popping up to me in log. I'm using BulkVS and they have 4 servers to connect to:

[2020-06-18 12:15:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:15:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:15:19] WARNING[5115] acl.c: Unable to lookup '76.8.29.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("69.12.88.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("69.12.88.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] WARNING[5115] acl.c: Unable to lookup '69.12.88.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("162.249.171.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("162.249.171.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] WARNING[5115] acl.c: Unable to lookup '162.249.171.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known

 

[atsak]

Wonder why it's doing a name lookup on an IP address? That shouldn't happen.

 

[atsak]

But what does an actual call look like though (like does the delay happen before it starts logging or in the middle?)

 

[Brianmac]

in the middle:

[2020-06-18 13:59:26] VERBOSE[13562][C-0000022a] app_dial.c: SIP/BulkVS-199.255.157.198-00000403 is making progress passing it to SIP/999-00000402
[2020-06-18 13:59:38] VERBOSE[13562][C-0000022a] app_macro.c: Spawn extension (macro-dialout-trunk, s, 28) exited non-zero on 'SIP/999-00000402' in macro 'dialout-trunk'

 

[atsak]

Outgoing PDD (post dial delay) is pretty common these days because the phones are a lot busier. I have also noticed longer PDD with BulkVS than AnveoDirect, for example, I guess due to timeout settings being shorter for carriers that Anveo uses? (not really sure). That is showing the call going out but not yet being accepted (I think) - would need to see the whole thing.

What about inbound though?

 

[Brianmac]

inbound same thing... Atsak, sorry, I'm a newbie with the logs and such, but trying...

 

[atsak]

Let's try the entire log for a call. That might reveal more - the snippit above is only a little bit. Anonymize the data if you'd like with the DID. (just get everything with VERBOSE[13562])

 

[Brianmac]

ok, will get that to you - thanks for the help!!!!

 

[Brianmac]

User says outgoing 2-3 seconds now, waiting to actually talk to him before i report back...

 

[phonebuff]

This has also been popping up to me in log. I'm using BulkVS and they have 4 servers to connect to:

[2020-06-18 12:15:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:15:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:15:19] WARNING[5115] acl.c: Unable to lookup '76.8.29.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("69.12.88.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("69.12.88.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] WARNING[5115] acl.c: Unable to lookup '69.12.88.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("162.249.171.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("162.249.171.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] WARNING[5115] acl.c: Unable to lookup '162.249.171.198'
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known
[2020-06-18 12:20:19] ERROR[5115] netsock2.c: getaddrinfo("76.8.29.198", "(null)", ...): Name or service not known

You have IP addresses where the system expects to fine Host Names.. Probably in your Trunk configurations -

 

[Brianmac]

ok, a follow up...
I tried everything I know(which is not a lot..), i finally put a onsite iPBX2020 to rule out hosting and internet causing the issue, same delay. So I finally added callcentric into the mix and made it the enabled trunk, incoming and outgoing are instant. The only difference is callcentric uses registration string and BulkVS, I was using IP based reg. Put a ticket in, will report back.

 

[Starburst]

ok, a follow up...
I tried everything I know(which is not a lot..), i finally put a onsite iPBX2020 to rule out hosting and internet causing the issue, same delay. So I finally added callcentric into the mix and made it the enabled trunk, incoming and outgoing are instant. The only difference is callcentric uses registration string and BulkVS, I was using IP based reg. Put a ticket in, will report back.

I was looking at BulkVS, did you ever get that problem solved wit the delay?

 

[Brianmac]

no, i put a softphone on a pc and no delay. I thought maybe its the grandstream phones, went there today and added an extension and used a spa112 with analog phone and seemed to work. Had employee make a ton of calls and he said incoming was fine, but outgoing still 8-10 second delay.
Now, im going to do a backup and switch providers to skyetel and see if that fixes the issue. weird, never had this type of issue before...I'll update monday or tuesday. I have other people on BulkVS with ZERO issues...

 

[Starburst]

Are you running a firewall like iptables, etc?

Maybe try to whitelist the BulkVS IP's.

 

[Brianmac]

yes and yes