VoIP.info Troubleshooting

Asterisk Originate reports success but the call or second leg is missing

Find the first divergence among loaded Originate arguments, channel creation, answer, destination handoff, a later Dial attempt, bridge and final workflow result.

Reviewed 2026-10-19Current Asterisk branch-23-generated and branch 22 Originate references, pre-dial-handler guidance, Dial reference, AMI Originate reference and ARI interface overview reviewed October 15, 2026; installed branch, channel driver, loaded dialplan, channel technology, destination, endpoint, signaling, application, bridge, codec negotiation and media remain deployment specific; no host, module, dialplan, channel, endpoint, packet, bridge, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one invocation as a channel-owned timeline

Record timestamp, installed branch, executing channel and identifiers, loaded context and priority, exact redacted Originate arguments, app or exten form, timeout, options, created channel, progress, answer, application return, immediate ORIGINATE_STATUS, destination entry and caller-visible result. Protect numbers, credentials and application data.

Classify the symptom before editing: no channel created, early failure, async return misread as answer, first channel answered but destination did not run, destination ran but its later Dial failed, bridge missing, or correct signaling with a media or business-workflow failure.

Prove the installed contract and the loaded positional arguments

Check local application help on the running system and prove the active channel entered the expected context, extension and priority. Compare the runtime values with source or generated configuration, including empty argument positions, option case and the type field.

For app, verify application and data; for exten, verify context, extension and priority. A correct source file or GUI entry does not prove that this channel executed that form. Correct a loaded-target or positional error before changing endpoints, transports or NAT.

Interpret return status under the selected wait model

Mark application entry, channel creation, provisional state, failure or answer and return. Without a, relate ORIGINATE_STATUS to the documented blocking boundary. With a, treat prompt continuation as asynchronous control flow, not proof that the remote channel answered or reached its destination.

Capture the status immediately on its owning caller channel. If UNKNOWN appears, retain version and bounded evidence for an upstream report. Do not rewrite SUCCESS, RINGING, BUSY or another summary into an undocumented SIP code; use the created channel’s cause and protocol exchange.

Follow the originated channel into its real destination

Prove which newly created channel answered and whether it entered the requested application or extension. For B(), prove entry and return on the current channel before creation. For b(), prove entry and return on the created channel before the call is placed. Confirm any destination variables, caller identity and codec restriction on the channel that owns them.

If destination entry is absent, stay with channel outcome, hangup timing, target resolution and handler behavior. If it is present, the originate boundary succeeded; continue through that application or dialplan as a separate evidence path.

Treat a later Dial as a second call stage

When the destination invokes Dial(), retain its dial string, every second-stage outbound channel, provisional and final responses, DIALSTATUS, answer, bridge and hangups. The originated channel answering does not prove that any later peer rang or answered. Likewise, a bridge does not prove two-way media or business completion.

Keep Local-channel halves and optimized survivors attached to their own identifiers. Compare dialplan Originate with AMI, ARI or call-file evidence only when the incident actually used that control surface; their acknowledgement and retry boundaries are not interchangeable.

Fix the first proved boundary and retest through the promised outcome

Correct only the first demonstrated divergence: loaded syntax, destination form, channel address, wait mode, timeout, handler ownership, destination variable, caller identity, codec restriction, downstream Dial target, bridge or application logic. Preserve rollback and remove temporary verbose or protocol logging after the bounded capture.

Repeat one authorized success and the relevant expected failure. Confirm the first channel, immediate status, destination entry, any second leg, bridge, bidirectional media and final application result independently. No host, module, dialplan, channel, endpoint, packet, bridge, media stream or live call was inspected or tested for this diagnostic.

Trace the channel lifecycle after originate acceptance

The channel lifetime diagnostic distinguishes a never-created, short-lived, optimized or wrong call leg.

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.