VMware ESXi and vSphere Cluster Management

Asterisk Goto Application: Redirecting Dialplan Execution

Learn how Asterisk Goto redirects dialplan execution by priority, extension, or context, with syntax, examples, reload steps, and troubleshooting.

What the Goto Application Does

Goto is an Asterisk dialplan application that redirects the current channel's dialplan execution to another location. It does not place a new call, bridge the caller to another endpoint, or create a second channel. Instead, Asterisk stops processing at the current priority and continues at the destination selected by Goto.

The destination can be another priority in the same extension, another extension in the same context, or an extension in a different context. This makes Goto useful for non-linear call flows, menu branches, validation results, shared handling extensions, and routing decisions made earlier in a call.

A dialplan location is identified by three components:

• Context: A named grouping of extensions that defines a routing scope.
• Extension: A dialable pattern or identifier with one or more priorities.
• Priority: An ordered execution step within an extension.

A fully specified destination therefore has the form context,extension,priority.

Understanding Dialplan Locations

Before using Goto, identify the channel's current context and current extension. The current context is the context in which Asterisk is executing. The current extension is the extension currently being processed. If a Goto argument does not specify one of these values, Asterisk uses the corresponding current value.

Priorities normally appear as numbers such as 1, 2, and 3. They define the order in which applications run. Asterisk dialplans can also use named priorities or labels where supported by the syntax and dialplan version. Labels can make branches easier to understand, but numeric priorities remain common in introductory configurations.

Goto Argument Forms

The number of comma-separated arguments determines how Asterisk interprets the destination. Argument position matters.

One-Argument Form

Goto(priority) keeps both the current context and current extension. Only the execution priority changes.

[local]
exten => 100,1,NoOp(Start)
exten => 100,2,Goto(4)
exten => 100,3,NoOp(This priority is skipped)
exten => 100,4,Playback(demo-thanks)

When a caller reaches extension 100, priority 1 runs first. Priority 2 jumps directly to priority 4. Priority 3 is not executed, and playback begins at priority 4.

Two-Argument Form

Goto(extension,priority) keeps the current context but changes the extension and priority.

[local]
exten => 200,1,Goto(300,1)
exten => 300,1,Playback(demo-congrats)

A caller executing extension 200 is redirected to extension 300, priority 1, in the same local context. This is useful when multiple entry extensions should share a handling extension.

Three-Argument Form

Goto(context,extension,priority) explicitly selects all three destination components. Use this form when crossing contexts or when the destination must not depend on the channel's current location.

[local]
exten => 555,1,Goto(test-routing,555,1)

[test-routing]
exten => 555,1,Playback(you-have-reached-a-test-number)

The first argument is the context, the second is the extension, and the third is the priority. For example, writing Goto(555,test-routing,1) would reverse the context and extension positions and would not select the intended destination.

Cross-Context Routing Example

Consider a caller whose inbound route enters the local context and who dials 555. The source extension invokes Goto with a fully qualified destination:

[local]
exten => 555,1,NoOp(Starting cross-context route)
exten => 555,2,Goto(test-routing,555,1)

[test-routing]
exten => 555,1,Playback(you-have-reached-a-test-number)

1. The caller dials 555.
2. Asterisk matches extension 555 in the local context.
3. Priority 1 runs NoOp().
4. Priority 2 executes Goto(test-routing,555,1).
5. Execution moves to context test-routing, extension 555, priority 1.
6. Playback() plays the named sound prompt to the caller.
7. After playback, execution proceeds to priority 2, where Hangup() ends the call.

This is a change in dialplan execution context, not a transfer to a different telephone device.

Same-Context Routing Examples

Jumping to a Later Priority

A validation or menu decision may determine that an intermediate step should be skipped:

[local]
exten => 100,1,NoOp(Begin validation)
exten => 100,2,Goto(4)
exten => 100,3,Playback(validation-failed)
exten => 100,4,Playback(validation-passed)

In this example, the decision at priority 2 sends execution to priority 4. In a real dialplan, the decision would normally be produced by an application or conditional branch before the Goto.

Redirecting to Another Extension

A shared handling extension can centralize common behavior:

[local]
exten => 200,1,NoOp(Menu selected option 200)
exten => 200,2,Goto(300,1)
exten => 300,1,Playback(demo-congrats)
exten => 300,2,Hangup()

Here, execution remains in local but moves from extension 200 to extension 300. This pattern is useful when several menu choices should reach one shared extension.

Execution Flow and Control-Flow Design

Without a jump, Asterisk normally proceeds through the next priority in the current extension. Goto replaces that sequential behavior with an explicit destination. Once the destination is found, normal processing resumes at the target priority and continues according to the priorities defined there.

Good dialplan control flow should make every branch understandable and reachable:

• Use a direct destination when a branch has a clear outcome.
• Avoid leaving important priorities unreachable because an earlier Goto always skips them.
• Check that jumps do not form accidental loops between priorities, extensions, or contexts.
• Keep cross-context destinations fully qualified with context,extension,priority.
• Use comments or NoOp() descriptions to document why a branch jumps.
• Ensure each intended path eventually reaches a useful action, hangup, or another deliberate next step.

A loop can occur when one priority jumps to another extension and that extension jumps back to the original priority. Such a loop can keep a call active indefinitely or repeatedly execute applications.

Dialplan Syntax and Reload Workflow

Extension definitions are commonly stored in extensions.conf, although a deployment may use another configured dialplan source. The basic extension syntax is:

exten => extension,priority,Application(arguments)

For example:

[local]
exten => 555,1,Goto(test-routing,555,1)

After editing the dialplan:

1. Save the applicable configuration file.
2. Check the syntax and target definitions carefully.
3. Reload the dialplan from the Asterisk CLI.
4. Test using a registered endpoint or an inbound route that enters the source context.

dialplan reload
dialplan show local
core set verbose 3

dialplan show local helps confirm that the source context and its extensions are loaded. During testing, core set verbose 3 provides useful call-flow detail in the Asterisk console. Use an appropriate verbosity level for your environment and reduce it after testing if necessary.

Failure Behavior and Diagnostics

A requested destination must exist in the loaded dialplan. If the context, extension, or priority does not exist, Asterisk cannot continue normally at that requested location. The resulting call behavior depends on the surrounding dialplan and channel state, so inspect the console output rather than assuming that execution will fall back to the previous priority.

When a redirect fails, verify the exact destination and the loaded configuration:

• Confirm that the context name is spelled exactly as defined.
• Confirm that the target extension exists in that context.
• Confirm that the requested priority exists for that extension.
• Count the arguments and verify their order.
• Check for incorrect comma placement.
• Reload the dialplan after making changes.
• Review verbose execution output to identify the destination Asterisk attempted.

Common Symptoms

The call does not continue after Goto: The destination context, extension, or priority may be absent from the loaded dialplan. Use dialplan show, inspect the console output, and confirm that the configuration was reloaded.

Goto lands in an unexpected location: A one- or two-argument form may have reused the current context or extension when a cross-context destination was intended. Identify the current location before the jump, count the arguments, and use the fully qualified form when appropriate.

The call repeatedly returns to the same extension: A routing loop probably exists. Map every Goto target and remove the path that returns to an earlier execution point.

Playback does not run after a redirect: First confirm that execution reaches the intended target priority. Then verify that the sound name is valid and that the corresponding prompt is installed and readable by Asterisk.

Exam-Relevant Notes

• Goto(priority) changes only the priority.
• Goto(extension,priority) changes the extension while retaining the current context.
• Goto(context,extension,priority) specifies the complete destination.
• The current context and current extension are used when omitted by the selected argument form.
• Goto redirects dialplan execution; it does not place a new call.
• Argument order is positional, so a context name and extension number must not be swapped.
• Cross-context routing is clearer and safer when written with all three destination components.

For related branching and reuse patterns, see Asterisk dialplan control-flow applications.