Asterisk ARI channel origination: create, dial and prove application control

Choose direct originate or create-then-dial

POST /channels originates a channel and immediately returns a channel snapshot. Use it when one bounded request should start dialing. Since Asterisk 14, POST /channels/create can allocate a channel for a Stasis application without dialing it; a later POST /channels/{channelId}/dial starts the call. Use that staged path when the application must establish correlation or other owned state before dialing.

Creation, dialing and answer are separate lifecycle facts. A successful create response proves neither that a dial was attempted nor that the endpoint answered. A duplicate requested channel ID can return conflict, so reconcile an ambiguous request before choosing a fresh ID or retrying.

Choose one answered destination

For direct origination, send the answered channel either to an ARI application through app and optional appArgs, or to a dialplan destination through context, extension and priority or label. The API documents those destinations as mutually exclusive, and label supersedes priority. Treat the choice as an application boundary, not a set of interchangeable fields.

The create-without-dial operation requires an ARI application. If the actual requirement is a dialplan-controlled workflow with management events, compare AMI Originate rather than recreating a dialplan controller in ARI.

Assign correlation before the action

Supply a client-generated channelId and keep it distinct from the business request's idempotency key. If an endpoint creates a Local channel, otherChannelId identifies the second half. The originator field can associate the new channel with an existing one and inform its format capabilities; without an originator, formats declares a capability list. Neither field proves the codec or media path ultimately used.

Store the sanitized request, endpoint, application and arguments, requested IDs, timestamps, HTTP status and returned channel snapshot. Preserve both Local-channel IDs and follow their separate lifecycle events rather than treating the pair as one channel.

Gate application control on the event connection

ARI combines the HTTP interface, the dialplan Stasis handoff and a WebSocket event connection. Establish and monitor the WebSocket for the exact application name before handing it a channel. When a channel enters the application, expect StasisStart; when it leaves, expect StasisEnd, after which ARI no longer controls it unless another subscription provides observation.

If no WebSocket is connected for a Stasis application, Asterisk can eject the channel back to the dialplan immediately. A previously broken connection can also leave an application appearing registered while the client misses events. A returned HTTP snapshot therefore does not prove that the controller received ownership.

Prove answer, bridge and outcome separately

For an app-directed originate, the documentation says the answered channel is passed to the Stasis application. Treat answer and StasisStart as their own gates. If the use case needs two parties, create or locate the second channel and explicitly add the intended channels to a bridge; the ARI bridge examples do not make membership an automatic consequence of origination.

Then prove the result actually promised: bridge membership, two-way media, completed playback, downstream transaction or clean hangup. A channel snapshot, answer event or bridge object alone is not that final result. Retain StasisEnd, hangup and destruction evidence so cleanup ownership is auditable.

Bound inputs, timeouts and privileges

Allow-list endpoint technologies and resources, application names, arguments and channel variables. The direct originate timeout is in seconds, defaults to 30, and accepts -1 for no timeout; set a deliberate limit instead of inheriting an unbounded business wait. Treat request-body variables as controlled input and do not expose a general-purpose ARI proxy to untrusted callers.

The Asterisk HTTP server is disabled by default and must be configured separately from ari.conf. A read-only ARI user permits only GET and OPTIONS, so an origination client needs narrowly scoped write capability. Protect HTTP signaling with TLS and the event stream with WSS, restrict network reachability, rotate credentials, rate-limit origination and record the running version. No ARI channel or call was tested for this guide.

Create External Media as its own correlated channel

The External Media channel has its own requested ID, Stasis lifecycle, driver and bridge membership. Keep it distinct from the endpoint channel created or originated for the call, and correlate both before interpreting media or cleanup events.

Join the originated channel only after Stasis owns it

The ARI bridges guide treats originate, StasisStart, add-channel response, ChannelEnteredBridge and usable media as separate evidence. Keep the original and dialed channel IDs distinct and make bridge cleanup idempotent.

Start playback only after the intended channel is controllable

The ARI playbacks guide keeps originate, StasisStart, answer or early-media state, playback start and audible output distinct. Choose a playback ID before the request so events can be correlated even when they arrive before the HTTP response.

Treat the replacement originate as one transfer stage

The ARI-owned REFER workflow separates a requested destination, originate result, bridge membership, NOTIFY state and connected media.

Choose ARI only when an external app owns the channel lifecycle

The dialplan Originate guide covers an in-dialplan channel-creation boundary, not REST acceptance, Stasis ownership or ARI bridge control.