Asterisk AMI Originate returns no call or the wrong call leg

Freeze one request before sending another

Capture the unique ActionID, application idempotency key, send time, AMI identity, connection and reconnect times, sanitized headers, immediate response and every event carrying that ActionID. Record Async, Timeout, Channel, the chosen extension/context/priority or application/data path, variables, caller identity, account code, early-media setting and requested channel IDs.

Classify the symptom precisely: rejected action, accepted action with no OriginateResponse, OriginateResponse: Failure, successful first leg with no expected dialplan work, wrong destination, duplicate call or correct signaling with a media problem. Do not retry while the first request remains ambiguous.

Prove authentication, authorization and event visibility

Confirm that the client reached the intended Asterisk instance and authenticated as the intended manager.conf user. Inspect that user's source ACL plus effective write permission for the Originate action and read permission for the call-class OriginateResponse event. An event filter, missing read class, disconnected socket or consumer backpressure can hide evidence even when the action ran.

Correlate server-side bounded logs with the client timestamp. If the action is denied, correct the specific identity, ACL or class authorization; do not grant broad all or command permissions as a diagnostic shortcut.

Separate the immediate response from the originate event

Parse AMI frames through the empty-line delimiter and associate them by ActionID, not arrival position. AMI is asynchronous: unrelated events can appear around the response. An immediate success means the action was accepted for execution, not that a phone answered. For Async: true, the correlated OriginateResponse is the attempt result boundary.

If it never arrives, verify that the original action actually carried ActionID, that the event consumer stayed connected, and that permissions or filters did not remove the event. Reconcile server-side channel evidence before classifying a missing client event as a failed call.

Validate the requested first leg and answered action

For OriginateResponse: Failure, preserve Reason, Channel, Uniqueid, timestamp and running Asterisk version. Check the channel technology and resource syntax, endpoint/contact state, route response, timeout and permitted codecs without inventing a meaning for an undocumented reason number. Follow the exact channel identity; a Local channel can introduce two halves.

For success, confirm which first channel answered and where it was sent. Validate either the extension/context/priority triplet or the application/data pair. A first-leg success can coexist with an invalid downstream extension, a busy second Dial target, an application error or a later hangup.

Trace the outcome the application promised

Use channel Uniqueid and Linkedid with Newchannel, Newstate, Dial, bridge and Hangup events, then CDR, CEL or application records as appropriate. If the product promise is a two-party conversation, prove both legs and the bridge. If it is an announcement, prove the playback or workflow completion signal. If it is merely queueing a request, define that smaller result explicitly.

Keep early media distinct from answer, and signaling success distinct from two-way audio. Move to the RTP, NAT and codec diagnostic path only after channel and dialplan state show the intended parties and bridge.

Correct one boundary and prove safe recovery

Correct only the demonstrated defect: AMI identity or ACL, action/event class, event filter, framing, unique ActionID, channel address, controlled dialplan destination, timeout, codec policy or downstream logic. Send one approved non-production request and trace it from submission through the promised final result.

After a disconnect or client timeout, query retained application and call records using the idempotency key before retrying. Verify rate limiting and duplicate suppression, remove temporary verbose traces and retain sanitized evidence. No manager account, event stream, channel, endpoint, dialplan, media path or call was tested for this diagnostic.

Identify which originate surface the incident used

For an in-dialplan Originate() call, use the dialplan diagnostic; keep AMI ActionID and OriginateResponse evidence on the AMI path.