VMware ESXi and vSphere Cluster Management

Asterisk Answer Application

Learn how Answer() changes a ringing Asterisk channel to answered, and how to combine it with Playback() and Hangup() in an inbound dialplan.

Answer() is an Asterisk dialplan application that answers a ringing channel. It changes the call from a pre-answer, ringing state to an answered state so the dialplan can perform established-call processing such as playing prompts, collecting input, or connecting the caller to another destination.

A channel is Asterisk's representation of one call leg or communications path. The dialplan is the call-routing logic organized into contexts, extensions, and priorities. Answer() runs as one application within an extension's priority sequence; it is not a standalone configuration directive.

What Answer() Does

Before a call is answered, the destination can be alerted while the caller receives ringing. This is the ringing or pre-answer state. When Answer() executes, Asterisk accepts the channel and begins the answered portion of the call.

An answered channel is a channel whose call has been accepted and is ready for normal established-call handling. Answering commonly performs the initial channel setup associated with accepting the call and sends answer supervision through the relevant signaling path.

Answer supervision matters because telephone networks and endpoints may use the answer event to determine when a call has been accepted. Depending on the carrier and deployment, that point can affect billing, call-duration records, caller experience, and when media is expected to be delivered.

Basic Answer() Syntax

The standard invocation has no arguments:

Answer()

Place it at a priority in an extension. In modern dialplan syntax, same => n continues the current extension at the next available priority.

[from-internal]
exten => 999,1,Answer()
same => n,Playback(recording-notice)
same => n,Hangup()

Here, 999 is the extension number, 1 is the first priority, and each subsequent same => n line advances to the next priority. The sound name is an example asset name; the corresponding sound file must be installed and available to Asterisk.

Answer Before Call Media Applications

Applications that deliver audio or interact with an established call generally belong after Answer(). Playback() sends a sound prompt to the channel. In the basic inbound pattern, answering first makes the call state explicit before the prompt is sent.

This ordering is especially useful for recording notices, monitoring disclosures, welcome prompts, and IVR instructions. A prompt-first service normally follows this pattern:

1. Answer the incoming channel.
2. Play one or more prompts or collect input.
3. Route the call or terminate it explicitly.

Some applications and signaling methods can provide audio before formal answer, known as early media. Early media is useful for certain announcements, tones, and network-provided messages, but it is not the same as an answered call. If the requirement is an answered announcement, use Answer() at the intended answer point rather than relying on early media.

Example: Answer, Play a Notification, and Hang Up

[from-internal]
exten => 999,1,Answer()
same => n,Playback(recording-notice)
same => n,Hangup()

This extension demonstrates a simple informational line. Replace recording-notice with the name of a sound prompt installed in the Asterisk sounds directory and available for the caller's language.

Execution walkthrough

1. Incoming call: The caller reaches the context and matches extension 999. The destination is initially ringing or otherwise pre-answer.
2. Answer(): Priority 1 accepts the channel and establishes the answered call state. Answer supervision is sent as appropriate for the channel technology.
3. Playback(): The notification prompt is delivered to the caller after the channel has been answered.
4. Hangup(): When playback completes, the final priority ends the current channel or call leg.

How the Applications Work Together

Together, Answer(), Playback(), and Hangup() form a reusable call-flow sequence for announcements, disclosures, and simple service numbers:

Answer() -> Playback(prompt) -> Hangup()

Choosing Where to Answer

Answer() often belongs near the beginning of an inbound call path when the caller should immediately hear an application-generated prompt. Avoid unnecessary delays before it when the service needs immediate audio interaction, such as a recording disclosure or IVR welcome message.

The correct placement depends on the required call flow:

• Use an early Answer() when the call should be accepted before prompts, input, recording, or other established-call processing.
• Keep the channel ringing when the caller should continue to receive ringing while a destination is being selected or alerted.
• Use early media or progress signaling when the design specifically requires audio before formal answer.
• Review carrier, endpoint, and billing behavior because another application, endpoint, or upstream network may answer the call before the dialplan reaches Answer().

Answer() does not represent every possible call-state transition. It is the explicit dialplan choice to move into answered-call handling at that point in the sequence.

Prompt-First Inbound Service Pattern

For an IVR, disclosure, or announcement line, Answer() can be the starting point for media and input applications:

[from-internal]
exten => 999,1,Answer()
same => n,Playback(recording-notice)
; Additional media or input applications can follow here.
same => n,Hangup()

In a larger flow, later priorities might route the caller to another extension, use an input application, or connect the caller to an agent. If the call should end after the final action, keep an explicit Hangup() or otherwise verify the subsequent dialplan behavior.

Troubleshooting

The caller does not hear the expected announcement

• Confirm that the call matches the intended context and extension.
• Verify that Answer() executes before the intended Playback() step for this call flow.
• Check that the referenced sound asset exists, is named correctly, and is available in the configured language.
• Review Asterisk console output and verbose dialplan logs to confirm the executed application sequence.

The call is answered earlier or later than intended

• Review the complete inbound path, including included contexts and applications before the selected extension.
• Check whether an endpoint, upstream signaling system, or another application has already answered the channel.
• Decide whether the requirement is ringing, early media, or a formally answered call, then place Answer() at the corresponding point.
• Inspect signaling and verbose logs to observe channel-state transitions.

The announcement plays but the call does not terminate

• Verify that the final priority includes Hangup().
• Check for a later priority, included context, or continuation rule that redirects the call elsewhere.
• Remember that the caller may disconnect during playback, or another event may alter the channel before Hangup() runs.

Exam-Relevant Notes

• Answer() is a dialplan application used inside an extension priority sequence.
• It changes an inbound channel from ringing or pre-answer to an answered call state.
• In the basic announcement pattern, Answer() comes before Playback(), and Hangup() follows the final media action.
• same => n means continue the current extension at the next priority.
• Answered audio and early media are different: early media occurs before formal answer supervision.
• Answer() placement can affect caller experience, signaling, and billing behavior.

For the complete topic reference, see Asterisk Answer Application.