AMI Events 184

AMI events tell an external application what Asterisk is doing right now. Watch them when you need call state, bridge membership, queue activity, endpoint changes, device state, or startup and shutdown signals. For most integrations, the useful model is simple: subscribe narrowly, keep the connection reading, correlate events with Uniqueid and Linkedid, and treat the event stream as state changes rather than a database.

A busy PBX can generate a lot of AMI traffic. Use manager permissions and event filters so each client only receives the events it needs. Start with call lifecycle events, add bridge or queue events when the workflow needs them, and avoid broad feeds for dashboards that only need a few signals.

A basic AMI client opens a TCP connection to the manager port, logs in, reads header blocks continuously, and handles each Event: message without blocking the socket reader. Keep action responses and events separate in your client code, because both arrive on the same connection.

Action: Login
Username: ami-monitor
Secret: strong-password
Events: on

Action: Events
EventMask: call,system

For production, define a dedicated AMI user in manager.conf and remove any read or write classes your client does not need. Advanced event filters are more efficient and easier to reason about than old payload-wide regex filters.

[ami-monitor]
secret = strong-password
read = system,call,agent,user
write = system,call,log,verbose,command,agent,user
eventfilter(action(include),name(Newchannel)) =
eventfilter(action(include),name(Newstate)) =
eventfilter(action(include),name(Hangup)) =
eventfilter(action(exclude),header(Channel),method(starts_with)) = Local/