Asterisk Originate: channel creation, destination and result evidence

Model Originate as one outbound channel and one destination handoff

Originate(tech_data,type,arg1,[arg2,[arg3,[timeout,[options]]]]) creates an outbound channel using the requested technology and data, then connects that channel to a specified application or dialplan location. Record the calling channel, exact redacted tech_data, created channel identity and the destination form separately.

Originate is not an alias for Dial(). Dial normally calls resources for the current calling channel and can bridge an answering outbound leg to it. Originate creates an outbound channel and hands that channel to an application or extension. If that destination later uses Dial, the second outbound attempt is a new stage with its own channels, status and outcome.

Keep app and exten argument shapes mutually exclusive

For type app, arg1 is the application and arg2 is its data; arg3 is ignored. For type exten, the same positions mean context, extension and priority. Preserve the resolved type and all positional values because an apparently valid string can mean something different under the other form.

Prefer a controlled context or a narrowly selected application over accepting arbitrary technology, destination or application data from an untrusted source. A loaded destination proves only where the originated channel is intended to go after the originate boundary; it does not prove that later dialplan priorities or applications completed.

Choose synchronous or asynchronous return deliberately

Without option a, the application blocks until the outgoing call fails or is answered, then sets the status variable and dialplan processing continues. The timeout is expressed in seconds and defaults to 30. With a, the caller continues without waiting for the originated channel to answer.

Capture application entry and return times, whether a was present, timeout, channel creation, progress, answer and destination entry as separate events. An asynchronous return cannot serve as proof of answer, destination execution, a later Dial result, bridge formation or media. Even a synchronous answer boundary remains narrower than a completed downstream workflow.

Read ORIGINATE_STATUS immediately and narrowly

The current generated references document FAILED, SUCCESS, BUSY, CONGESTION, HANGUP, RINGING and UNKNOWN. They also say UNKNOWN should not normally occur and should be reported if observed. Preserve the exact value on the channel that executed Originate, immediately after return.

Interpret that value together with sync or async mode and the created channel evidence. It summarizes the application’s origination boundary; it is not a transcript of every SIP response, proof that a destination application finished, or evidence that a second party answered. Retain channel causes, protocol messages and application records for those questions.

Put handlers and destination values on their intended channels

Uppercase B() runs a Gosub on the current channel before the outgoing channel is created. Lowercase b() runs a Gosub on the newly created channel before the outgoing call is placed. Each pre-dial handler must Return() and should remain short enough to preserve the originating application’s expected channel state.

The v() option sets variables on the destination channel. Caller-ID number and name options and the codec-list option also shape the attempt, but do not prove that a remote party accepted the identity or negotiated a listed codec. Record effective values and inspect the created channel rather than inferring inheritance or negotiation from source text.

Keep dialplan Originate separate from AMI, ARI and workflow success

The dialplan application runs inside an executing Asterisk channel and returns ORIGINATE_STATUS there. AMI Originate uses an external manager action and correlated event model, while ARI exposes REST and event-driven channel control. Do not transplant acknowledgement, identifier or retry semantics among these interfaces.

For an authorized test, verify exact loaded arguments, created channel, response, answer, destination entry, any later Dial legs, bridge, bidirectional media, teardown and promised business outcome independently. No host, module, dialplan, channel, endpoint, packet, bridge, media stream or live call was inspected or tested for this guide.

Correlate the created channel before acting on it

The channel identity guide separates originate acceptance from a later live channel, bridge and application result.