Name the calling channel and every requested outbound leg
Dial(Technology/Resource&...,timeout,options) places calls to one or more requested channels. When one destination answers, Asterisk answers the originating channel if needed, bridges the answering channel and hangs up the other requested channels. With parallel destinations, one customer call can therefore contain several distinct outbound channel attempts.
Record the calling channel, each created channel name and unique identifier, the dial string, endpoint or resource, creation order and final business outcome. A dial string, endpoint label or shared linked identifier does not make the legs interchangeable.
Treat timeout, provisional progress, answer and bridge as separate states
The primary timeout bounds how long Dial attempts the requested devices. If it is omitted, the current generated reference describes an effectively indefinite default. A returned application does not by itself identify whether no channel could be called, every leg ended, the timeout expired, the caller cancelled or an answered bridge later ended.
Keep the first ringing event, first progress event, final response, answer, bridge entry, bridge exit and application return timestamp separate. Ringing or early media is not answer, answer is not proof of two-way media, and a bridge identifier is not proof that the intended people communicated.
Read Dial status and timing on the channel that owns them
Immediately after Dial returns on the calling channel, preserve DIALSTATUS together with DIALEDTIME, ANSWEREDTIME, RINGTIME, PROGRESSTIME and their millisecond variants when the installed branch exposes them. The current reference documents status values including CHANUNAVAIL, CONGESTION, NOANSWER, BUSY, ANSWER, CANCEL, privacy results and INVALIDARGS.
These values summarize the application contract. DIALEDPEERNAME and DIALEDPEERNUMBER identify the answering outbound channel when one exists, but a final status is not a transcript of every parallel leg or its exact SIP response. Preserve per-channel causes and wire messages for that question.
Put pre-dial work on the intended channel
The uppercase B() option runs a Gosub on the current caller channel before callee channels are created. Lowercase b() runs a Gosub on each newly created callee channel before the call is placed. That ownership difference matters for caller variables, inherited state and outbound PJSIP operations.
A pre-dial handler must end with Return(). Asterisk warns that these routines should remain short and should not move the channel into applications that violate the dialing application’s assumed state. Handler entry or return does not prove that a later INVITE was sent, accepted or answered.
Keep post-answer work and post-bridge continuation distinct
U() runs a Gosub on the called channel after answer and before the bridge. The lowercase g option tells Dial to continue at the next priority on the calling channel when the destination channel hangs up. F() and G() have different party-transfer semantics, while CHANNEL(after_bridge_goto) belongs to one selected channel after it exits its next bridge.
Choose the mechanism from the channel that must survive and the event that should trigger continuation. Do not combine options by analogy: the current Dial reference explicitly restricts G() from use with other post-answer actions.
Retain losing-leg causes and verify the final outcome independently
For parallel or sequential attempts, retain every HANGUPCAUSE_KEYS() channel and its technology-specific and translated cause before the evidence is cleared or replaced. Correlate those records with the relevant SIP exchange rather than assigning the final DIALSTATUS to every attempted channel.
For an authorized test, confirm created legs, expected provisional and final signaling, selected answer, bridge membership, media in both directions, teardown owner, immediate status and intended next priority. No host, module, dialplan, channel, endpoint, trunk, packet, bridge, media stream or live call was inspected or tested for this guide.
Do not merge Originate with a later Dial
The Originate guide separates the first created channel and destination handoff from every outbound leg created by a later Dial.
Do not pass a Dial resource to Bridge
The Bridge guide requires a live channel name, prefix or unique ID rather than an endpoint resource string.
Treat DIALGROUP as one input to Dial
The DIALGROUP guide records the named list immediately before Dial while keeping DIALSTATUS and per-leg causes as later evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 Dial application ↗
- Asterisk 22 Dial application ↗
- Asterisk pre-dial handlers ↗
- Asterisk hangup-cause overview ↗
- Asterisk HANGUPCAUSE_KEYS function ↗
- Asterisk CHANNEL function ↗
- Asterisk 23 Originate application ↗
- Asterisk 22 Originate application ↗
- Asterisk 23 AMI Originate action ↗
- Asterisk ARI interface overview ↗
- Asterisk 23 Bridge application ↗
- Asterisk 22 Bridge application ↗
- Asterisk Bridge application overview ↗
- Asterisk 23 CHANNELS function ↗
- Asterisk ARI bridge overview ↗
- Asterisk DIALGROUP dialplan function ↗
- Asterisk PJSIP_DIAL_CONTACTS dialplan function ↗
- Asterisk HANGUPCAUSE dialplan function ↗
- Asterisk HangupCauseClear application ↗
- Asterisk command-line interface ↗
- Asterisk func_dialgroup implementation ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.