* You are viewing Posts Tagged ‘AMI’

AMI Version Vs. AST Version

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?


Registration Failure Event From AMI

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[24598] chan_sip.c: Registration from ‘”test”‘ failed for ‘’ – Wrong password


How To Get The Original SIP Result Code


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 my AMI application can get the original SIP response of the failed Originate action?

I’m using Asterisk 1.8.22 and slightly tweaked asterisk-java (
https://blogs.reucon.com/asterisk-java/) 1.0.0.

AMI Timeouts


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 to describe.

The fact that we can’t reproduce it in test leads me to think that it’s somehow related to the load on our production system.

I’m hoping that someone else on the list may have seen something similar before, or that an Asterisk developer might read this and think “ah, it’s this bit of code that’s doing it!”. :-)

Anyway, let me try to describe what’s happening.

The Java process has an AMI connection to Asterisk which it keeps open continuously. When sending an AMI request, the process will wait a certain amount of time for a response (I think the timeout is 5 seconds)
and if it hasn’t received it, will retry the request up to 5 times.

Occasionally, the Java process logs show AMI requests timing out (after
5 tries). What I see in packet captures of the AMI traffic is:

1. Java process sends a request (e.g., add member to queue)
2. Retries 5 seconds later
3. Retries again 5 seconds later
4. Retries again 5 seconds later
5. Retries again 5 seconds later
6. Logs a timeout
7. After a few more seconds, Asterisk replies to all five requests
in one go (in a single packet; so, e.g., for “add member to queue”
it would reply “success”, then four failures because the member is
already added); however at this stage, the Java process has given

It feels like Asterisk queues up the AMI responses and then periodically sends out all the responses in the queue in one go. Is something like this going on? Does the frequency at which Asterisk flushes the queue depend on load? Are there any tunable in the config for this?

If anyone has seen this before, or understands what’s happening here, I
would be very grateful for any info!

If you need more details, please do ask and I’ll do my best.

Thanks in advance,


How To Allow AMI Access To Originate Yet Deny Application: System

While doing a security audit on a system I maintain, I stumbled upon an unvalidated use of a variable to compose an Originate request to the local Asterisk instance via AMI. Taking as an example an earlier exploit for FreePBX, I realized that this, combined with Application: System as an injected value, could allow arbitrary code execution. I am in the process of fixing all instances of this bug in our system. However, there are third parties that plug into our system, and that reconfigure the manager.conf file to allow remote access to AMI logins that allow Originate (by default, the manager.conf remains configured to deny login to any system except localhost). I want to have a guideline on how to proceed in order to make these applications work, without allowing malicious users to compromise the system. I know that one way to proceed is to deny remote access to AMI, and build an application-specific proxy that will perform the Originate on behalf of the remote requester, after filtering the values. However, I want to know if there is a simpler way to remove the danger of code execution while allowing applications to use AMI to place calls.

The intended scenario is that a remote desktop application (for Windows) is configured with the AMI credentials, and connects over the LAN to Asterisk in order to place calls and otherwise monitor the system. The attack I want to protect against is that of a malicious user that collects the credentials from the desktop application and proceeds to use the Application: System trick. I know of the SSL support for AMI, but it will not protect against a malicious end user.

AmiDebugger – Might Make Your Life Easier If You Program Through The AMI

Hi all, I have been playing with the AMI quite a bit lately – mostly debugging WombatDialer in production, but that’s a different story – and I have been frustrated by the lack of a simple way to interact CLI-like with the AMI
itself. So I have decided to write something myself to make my life easier, or at least a bit less miserable.

The result is a little webapp that you can use as a sort of CLI-frontend to the AMI itself. It is not pretty, but pretty much effective. So I thought I
could share it and make someone else’s life a bit easier.

You can find it on https://github.com/l3nz/amiDebugger – if you just want to test-drive it get the WAR file an put it into some webapp container, e.g. Tomcat.

Hope you’ll like it. l.