Hi Tony

Ok, got this solved.

I discovered my AMI message was corrupt due to a bug in our third party dialer app we wrote ourselves…!

E. g. this worked on Asterisk 1.8:

ActionID=12edad43-e817-427b-aa21-31a9659f86e1
&Action=Originate
&Channel=SIP/local/3035@local
&Exten=7777
&Context=local
&Priority=1
&CallerID=3035
&Account=recordinglisten
&ChannelID=12edad43-e817-427b-aa21-31a9659f86e1
&OtherChannelID=12edad43-e817-427b-aa21-31a9659f86e1B
&Variable=CallLimit=3600,recfile=/var/spool/asterisk/monitor/archive/1901/15/201901151654r1g4679,altfile=/var/spool/asterisk/monitor/archive/1901/15/201901151654r1g4679
&Async=true

But doesn’t on Asterisk 13 – for a very good reason:

&Channel=SIP/local/3035@local

was acceptable to Asterisk 1.8, but NOT to Asterisk 13 – and I kind of agree.

It was a bug in our third party dialer app that instead of passing to Asterisk 13

&Channel=SIP/3035@local

was passing

&Channel=SIP/local/3035@local

which is just WRONG.

This was why 13 was replying

[Jan 15 18:19:23] ERROR[10519]: netsock2.c:305 ast_sockaddr_resolve: getaddrinfo(“local”, “(null)”, …): Name or service not known
[Jan 15 18:19:23] WARNING[10519]: chan_sip.c:6316 create_addr: No such host: local

which makes perfect sense…!

So I fixed the incorrect variable reference in our app that was generating the wrong SIP/local/3035@local

channel, and recording playback started working correctly and no more of the above error messages.

So all not Asterisk fault, though 13 does appear to interpret the channel name differently as SIP/local/3035@local

DOES work on 1.8.32.3 (which it shouldn’t, but it does.)

Thanks for taking the time to reply.

Regards

Stefan

—
Date: Tue, 15 Jan 2019 17:32:40 +0000 (UTC)
From: tony@softins.co.uk (Tony Mountifield)
To: asterisk-users@lists.digium.com Subject: Re: [asterisk-users] Cannot originate to extension unless
/etc/hosts is edited constantly?
Message-ID:

In article <018201d4acef$898a4b10$9c9ee130$@verishare.co.za>, Stefan Viljoen wrote:

What does your sip.conf look like? (without comments, e.g. grep -v ‘^;’ sip.conf | grep -v ‘^$’)

Particularly, do you have a separate section for each phone, e.g. [3015] ?

I don’t understand why it should be trying to look up the address of “local”. If you change your dialplan context to another name and refer to that name in Context in your original request, does it try looking up this new name, or still “local”?

Cheers Tony
—
Tony Mountifield Work: tony@softins.co.uk – http://www.softins.co.uk Play: tony@mountifield.org – http://tony.mountifield.org

——————————

Subject: Digest Footer