I created a set of Docker images running Asterisk and exposing AMI / ARI ports that i found to be quite useful for ARI / AMI development and regression.
As they are based on Docker with whaleware, adding new configuration files to roll your own dialplan / queues / voicemail etc is pretty easy. And you can run quite a lot on the same box to simulate clusters.
There is no SIP / RTP configured at the moment.
Maybe somebody else might find them useful. There is Asterisk 1.8, 11, 12 and 13. Thanks l.
Is there a mapping of AMI versions to Asterisk versions somewhere? For example, Asterisk 1.4 includes AMI version 1.0 (at least that's what I see when I connect to Ast 1.4 via telnet to the AMI port)
Also, doe the AMI version changes reflect changes to the AMI commands? If so, is there also a list of what commands changed by AMI version?
Is it possible to detect the failure of an agent to register with Asterisk via the AMI ?
When I try to register with Asterisk 1.4 using an invalid password I don't see any event in the AMI, but see this in the messages log:
[2013-10-05 22:05:03] NOTICE chan_sip.c: Registration from '"test"
Hello, i'm using AMI Originate action (with async=true) to send outgoing calls to a SIP trunk (using asterisk-java library to connect to AMI).
The problem is that in case of failed originate, OriginateResponse event is returning only the reason code which is sometimes not sufficient to determine the real cause of failure. Also, there's no way to link between the channel that was trying to dial and failed and the original Originate request, because OriginateResponse is issued only after the failed channel was hang up. Only successful OriginateResponse will contain the unique id of the established channel.
Is there any way that…
We're using Asterisk 1.8.0 to run a call centre. There is a Java process which talks to Asterisk through AMI, which is part of the software stack that presents a user interface to the call centre agents.
We're seeing a strange issue with AMI. Most of the time, it doesn't cause problems, because the Java code is written to cope with it, but occasionally it does, and, in rare cases, may even result in calls being dropped.
The main problem with the issue is that we haven't been able to reproduce it in a test environment, and that it's not that easy…