Page 1 of 1

Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 5:38 pm
by Two8nine
Vicidial version: 2.14-694a
Vicidial build: 181005-1738
Asterisk version: 13.21.1-vici

Hi -- had a number of threads in the past, and we finally gearing up to go live.

Have new, non test servers to run on, and cannot seem to reproduce a functional environment. (I am following the setup instructions from the paid manual/installation manual). Hoping for some pointers.

Most things are functional, but asterisk if giving this error/warning on load:

Code: Select all
ERROR[4115]: netsock2.c:305 ast_sockaddr_resolve: getaddrinfo("Dial01", "(null)", ...): Name or service not known.
WARNING[4115]: acl.c:835 resolve_first: Unable to lookup 'Dial01'


Dial01 is the hostname set for the telephony server.

Test agents are still able to register, and are joined to the agent conference, but extremely slowly. Outbound calls are not possible.

What should I look at to resolve this? As far as I can tell setup is identical to the testing environment, apart from the vicidial version being newer. (testing was 2.14-650a) Something I need to do differently for Asterisk 13 vs 11?

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 6:44 pm
by williamconley
Dial01 is not a valid domain name and is obviously not an IP address. The prior server either was not using "Dial01" in the carrier setup or had a method by which this was converted to an IP address in /etc/hosts or by DNS resolution.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:05 pm
by Two8nine
Dial01 is not in the carrier setup, its just the hostname set in yast lan. (As per the Vicibox 8.1 installation manual)

This is my carrier setup:

Code: Select all
[carrier]
host=ip of SBC
fromuser=user
secret=secret
context=trunkinbound
type=friend
qualify=1000
dtmfmode=rfc2833
canreinvite=no
allow=ulaw
port=5060
insecure=invite


Globals String:
Code: Select all
name=SIP/carrier


Dialplan Entry:
Code: Select all
exten => _9NXXNXXXXXX,1, AGI(agi://127.0.0.1:4577/call_log)
exten => _9NXXNXXXXXX,n, Dial(${TRUNKloop}/888${EXTEN:1},55,o)
exten => _9NXXNXXXXXX,n, Hangup()

exten => _91NXXNXXXXXX,1, AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,n, Dial(${TRUNKloop}/888${EXTEN:1},55,o)
exten => _91NXXNXXXXXX,n, Hangup()

exten => _81NXXNXXXXXX,1, AGI(agi://127.0.0.1:4577/call_log)
exten => _81NXXNXXXXXX,n, Dial(${TRUNKloop}/887${EXTEN:1},55,o)
exten => _81NXXNXXXXXX,n, Hangup()

exten => _888NXXNXXXXXX,1,Goto(loopback-no-log,9${EXTEN:3},1)
exten => _888NXXNXXXXXX,n,Hangup()

exten => _8881NXXNXXXXXX,1,Goto(loopback-no-log,9${EXTEN:3},1)
exten => _8881NXXNXXXXXX,n,Hangup()

exten => _8871NXXNXXXXXX,1,Goto(loopback-no-log,8${EXTEN:3},1)
exten => _8871NXXNXXXXXX,n,Hangup()


(I am in Canada and use the loopback for setting the callerid.)
According to sip show peers this is successfully connected.

I don't understand where it's pulling 'Dial01' from.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:09 pm
by williamconley
Code: Select all
grep Dial01 /etc/asterisk/*.conf -nF -B 10 -A 10


That should give you the Context it's in which should tell you where it is in the GUI.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:14 pm
by Two8nine
Returns nothing -- this would be run from the telephony server?

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:39 pm
by williamconley
Whichever server has that error in asterisk would theoretically need a reason to look up Dial01. Thus somewhere in sip-vicidial.conf or iax2-vicidial.conf this string *should* appear. But definitly in one of the conf files.

Maybe you should search subfolders (and/or the entire /etc/ tree just for fun).

Unless it's gone now because it was already deleted. Does the error still occur?

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:44 pm
by Two8nine
Error still occurs. I've run the command on all servers and all return nothing. Very strange.

Reinstalling the telephony server currently -- trying to see if I've missed something but everything seems to be the same apart from the asterisk/vicidial version differences.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 7:48 pm
by williamconley
Code: Select all
grep Dial01 /etc/asterisk/*.conf -niF -B 10 -A 10


Added an "i" for case insensitivity. Just in case it's merely a case issue.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 10:05 pm
by Two8nine
Same -- no results on any server, though the error continues the same, even after reinstall of everything.

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 10:12 pm
by williamconley
Code: Select all
grep Dial01 /etc/* -ni


?

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 10:13 pm
by williamconley
Uh-oh ... do you have your server locked down? It would appear this could be a resgistration attempt ...

Re: Telephony server asterisk reload error

PostPosted: Thu Nov 01, 2018 10:31 pm
by Two8nine
williamconley wrote:
Code: Select all
grep Dial01 /etc/* -ni


?


That produces 3 results:

/etc/HOSTNAME:1:tel01.vici.local
/etc/hostname:1:tel01.vici.local
/etc/hosts:24:127.0.0.2 tel01.vici.local tel01

Note that tel01 is the hostname I used on reinstall. Not sure what these files are -- assuming they resulted from the 'yast lan' setup in the tutorial -- but not sure if they should be changed?

I don't think there's any intrusion. Network traffic is behind a firewall, and voice behind a SBC -- both are pretty locked up, and neither have reported any (successful) intrusion attempts.

-------------------

I've changed the above by commenting out the last line and replacing the /24 with 255.255.255.0.

It now works without the error, though the speed is still very slow. (~10-15 seconds for ring to begin vs ~0.1 prior.)

While the call does connect -- the agent immediately goes into the 'LAGGED' state.

Prints the warning "Exceptionally long voice queue length queuing to IAX2/ASTloop-16239" I'm assuming that is related to the slowness of it.

Hardware is the same -- so will have to try and sort that out.