VoIP.info Guide

Asterisk AMI Originate: correlate acceptance, channel outcome and workflow result

Initiate a bounded call through AMI while keeping the action response, OriginateResponse event, channel identifiers and downstream dialplan result as separate evidence.

Reviewed 2026-10-15Current Asterisk 23 AMI Originate and OriginateResponse references plus AMI protocol, authorization, network-security and API-boundary documentation reviewed October 9, 2026; no manager account, ACL, transport, host, channel, endpoint, dialplan, application, event stream, media path or call was inspected or testedAdvancedDocumentation based · not lab tested

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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.