Choose one answered-action form
AMI Originate creates the channel named by Channel, then sends an answered channel either to Exten plus Context plus Priority, or to Application with optional Data. Model those as mutually exclusive application choices even though the protocol lists all fields. The first leg and the work performed after it answers are different call stages.
Prefer a controlled dialplan context for business workflows. Let the integration select a small approved operation and validated destination rather than accepting arbitrary channel strings, contexts, applications, data or variables from an untrusted caller. AMI is a management surface, not a public click-to-call API.
Make every request independently traceable
Supply a client-generated, unique ActionID on every action. The AMI specification recommends it and requires related success or failure events to carry the same value. Keep that request ID separate from channel Uniqueid, any caller ID, account code and the application's own idempotency key.
Store the sanitized request, send time, connection identity, action response, correlated OriginateResponse, channel identifiers and final workflow result. A reconnect can interrupt observation without proving that Asterisk did not act, so reconcile by idempotency key and retained events before retrying an ambiguous request.
Decide whether the client waits for origination
Async: true requests fast origination. That improves connection responsiveness, but moves the result boundary into the event stream. A successful immediate response is not evidence that the target answered; wait for the correlated OriginateResponse, then follow channel and dialplan evidence for the outcome you actually need.
Without asynchronous origination, the action can occupy the request path while Asterisk attempts the call. Set the millisecond Timeout deliberately and put a separate deadline around the client connection. Do not infer a safe duplicate retry merely because the socket timed out or disconnected.
Interpret OriginateResponse narrowly
The documented OriginateResponse carries the originating ActionID when present, a Success or Failure response, a numeric Reason, channel and destination fields, and Uniqueid. Treat it as the originate attempt's result. It is not a receipt that a second dialed party answered, audio was exchanged, an announcement completed or an external transaction committed.
If the answered path contains Dial, queues, Local channels, AGI or another application, correlate the resulting channel and dialplan events with CDR, CEL or the application's own record. Preserve the raw reason value and Asterisk version instead of assigning an undocumented universal label to the number.
Control identity, variables and early media
CallerID, Account, repeated Variable headers, ChannelId, OtherChannelId, Codecs, EarlyMedia and PreDialGoSub all change the request or its correlation surface. Allow-list only what the use case owns. Validate values, block header injection, prevent protected channel-variable or caller-identity override, and avoid letting an external user supply a general-purpose pre-dial subroutine.
EarlyMedia: true can bridge on early media, which is not the same evidence as answer. Codec restriction can also change negotiation. Record these options alongside the action so later media or answer analysis starts from the actual request rather than a default assumption.
Give the AMI identity the smallest viable surface
AMI users are configured in manager.conf; write permissions govern action classes and read permissions govern event classes. Create a dedicated integration identity with the minimum action and event classes, event filtering where appropriate, an address ACL and secret handling that matches the deployment. Confirm the effective command authorization on the running version instead of copying a broad sample permission set.
Asterisk's security guidance says to keep AMI in a safe environment or protect access with SSH or another VPN, and notes permit and deny ACLs. Restrict network reachability, rotate credentials, bound connection and originate rates, and alert on unusual destinations or volume. No AMI connection or call was tested for this guide.
Do not apply AMI response semantics to the dialplan application
The dialplan Originate guide runs inside an executing channel and returns ORIGINATE_STATUS; AMI remains an external action and event contract.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 AMI Originate action ↗
- Asterisk 23 OriginateResponse event ↗
- Asterisk AMI v2 specification ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk network security guidance ↗
- Asterisk API boundary overview ↗
- Asterisk 23 Originate application ↗
- Asterisk 22 Originate application ↗
- Asterisk pre-dial handlers ↗
- Asterisk 23 Dial application ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.