VMware ESXi and vSphere Cluster Management

Asterisk Architecture: Core, Modules, Channels, Dialplans, and Applications

Learn how Asterisk works internally: the core, loadable modules, channels, call legs, dialplans, applications, bridges, and CLI inspection.

Asterisk is a modular software PBX and communications engine. It is not one fixed-function telephone system. Instead, a central runtime coordinates independently supplied capabilities for signaling, media, call routing, voicemail, protocols, and other communications features.

This architecture lets an installation support only the technologies and features it needs. It also means that a missing configuration file, disabled module, or unavailable channel driver can affect whether a particular call-flow feature works.

Architecture at a glance

A call typically follows this path:

1. An endpoint, trunk, interface, or another system connects through a channel technology.
2. Asterisk creates an inbound channel representing that call leg.
3. The channel is assigned a dialplan context and a dialed destination selects an extension.
4. The dialplan executes ordered applications such as Answer(), Playback(), or Dial().
5. An application may create an outbound channel to another endpoint or trunk.
6. Asterisk bridges channels when the parties should communicate.
7. A fallback path, such as voicemail or an announcement, may run if the call is unanswered or fails.
8. The channels are released and the call ends with an application such as Hangup() or through normal call termination.

The Asterisk core

The Asterisk core is the central runtime that initializes and coordinates the PBX system. It starts the process, establishes shared call-processing infrastructure, manages channels and bridges, and makes common services available to modules and dialplan execution.

During startup, Asterisk generally reads its configuration, initializes services, loads configured modules, and makes dialplan logic available. The exact sequence and available services depend on the release and build.

The core does not contain every protocol and feature as one large fixed program. Many protocol-specific and feature-specific capabilities are supplied by modules. Consequently, a configuration or module-loading problem can prevent a feature from becoming available even though the core itself is running.

Loadable modules

A module is a separately loadable shared component that adds a focused capability to Asterisk. On Linux and other Unix-like systems, modules commonly use the shared-object format .so.

Common module categories include:

• Applications: Dialplan actions such as dialing, voicemail, playback, recording, or conferencing.
• Channel drivers: Connections to endpoint and trunk technologies.
• Codecs and format support: Encoding, decoding, and storage or transport of media formats.
• Resource modules: Supporting services used by other components.
• Functions: Dialplan functions that read or manipulate channel data.
• PBX features: Capabilities such as bridging, queues, or other call-processing behavior.

At startup, Asterisk discovers modules in its configured module directory and loads them according to its module-loading policy. The conventional configuration file is modules.conf, but its exact path is installation-dependent. A typical policy may autoload modules, explicitly load selected modules, or prevent selected modules from loading.

[modules]
autoload=yes
; load => app_voicemail.so
; noload => chan_sip.so

This example illustrates policy only. The module name, file location, and availability depend on the Asterisk release and how it was installed. A module may also depend on other modules or libraries. It can be loaded, inspected, and in some cases unloaded at runtime, but changing modules in a production system should be done carefully because active calls or dependent features may be affected.

Representative examples include a voicemail application module, a PJSIP channel implementation for endpoint support, and call-processing application modules. Module names and availability vary by release. Older technologies such as chan_sip may be deprecated or absent in current installations.

Channels and call legs

A channel is Asterisk's representation of one active communications path or call leg. A channel can represent a connection to an endpoint, trunk, analog or digital interface, or another communications system.

The connection to one endpoint is not necessarily the complete call. A two-party call commonly has at least two channels:

• An inbound channel for the party or system that initiated the call into Asterisk.
• An outbound channel created when Asterisk calls the other endpoint or trunk.

Channels have names, states, technology-specific attributes, and an association with a dialplan location. A channel's location normally includes a context, extension, and priority while dialplan execution is in progress. Asterisk uses a bridge to connect channels so the participants can exchange media and signaling as appropriate.

A channel technology is the protocol or interface family used to connect Asterisk to an endpoint or system. A channel driver is the implementation that supplies that technology.

Dialplan fundamentals

The dialplan is Asterisk's programmable call-routing and call-treatment logic. It determines what Asterisk does when a channel reaches a destination.

The classic dialplan is commonly stored in extensions.conf, although deployments may split definitions across included files or use other configuration mechanisms. The path and layout are not universal.

Contexts

A context is a named dialplan section. It controls which extensions and patterns a channel may access. Context boundaries are an important security control: an internal phone should not automatically be able to reach every external or premium-rate route.

Extensions and priorities

An extension is a dialplan destination and its ordered processing steps. It is not necessarily a physical phone. A numeric extension can represent a phone, a service code, an announcement, a queue, or an outbound route. Patterns can match groups of dialed numbers.

A priority is the sequence position of a step within an extension. Labels can identify logical positions for branching, and variables hold values used while the call is processed. An include makes definitions from another context available according to dialplan rules.

[internal]
exten => 200,1,Answer()
 same => n,Playback(hello-world)
 same => n,Hangup()

When an inbound channel enters the internal context and the caller dials 200, Asterisk matches the extension and executes its priorities in order. The call is answered, an audio prompt is played, and the channel is hung up.

Dialplan applications

An application is an executable call action invoked by a dialplan step on the current channel. Applications can read or modify channel state, perform media operations, create another call leg, branch call flow, or end the call.

A dialplan application and a module are related but different concepts. The application describes the call-flow action, while a module commonly supplies the implementation and exposes that action to the dialplan. Therefore, a dialplan can refer to an application only when the required implementation is installed and loaded.

• Answer() answers the current channel.
• Dial() requests one or more destinations and commonly creates an outbound channel.
• Playback() plays an audio prompt.
• VoiceMail() provides voicemail handling when the appropriate voicemail support is installed.
• Hangup() ends the current call or channel.

Use the Asterisk CLI to discover installed applications and their syntax:

asterisk -rvvv
core show applications like Dial
core show application Dial

Tracing a sample call

Consider a caller using a registered PJSIP endpoint to dial extension 201. The endpoint's signaling creates an inbound PJSIP channel. Asterisk assigns that channel to a configured context, such as internal, and uses the dialed digits to select extension 201.

[internal]
exten => 201,1,Dial(PJSIP/alice,20)
 same => n,VoiceMail(alice@default,u)
 same => n,Hangup()

Dial() asks the PJSIP channel technology to create an outbound channel to the endpoint named alice. If Alice answers, Asterisk bridges the inbound caller channel and the outbound Alice channel. The two call legs can then communicate through the bridge.

If Alice does not answer within 20 seconds, Dial() returns control to the next priority. The dialplan invokes VoiceMail(), which may let the caller leave a message, and then executes Hangup(). Similar branches can handle busy results, unavailable endpoints, or other return states.

Configuration and operational inspection

The conventional files are modules.conf for module-loading policy and extensions.conf for classic dialplan definitions. Exact paths depend on operating-system packages, source builds, containers, and configured installation prefixes. Do not assume that a file exists in the same directory on every host.

Safe first checks can be performed through the Asterisk CLI:

asterisk -rvvv
module show
module show like voicemail
core show applications like Dial
core show application Dial
dialplan show internal
core show channels

• module show lists loaded modules.
• module show like voicemail searches for a relevant module.
• core show applications like Dial searches installed applications.
• core show application Dial displays application syntax and help.
• dialplan show internal displays the loaded internal context.
• core show channels shows active channels and their states.

After editing configuration, validate the change and reload the relevant subsystem according to the operational policy. A dialplan change does not automatically require a full service restart, and a module change may have different runtime implications. Avoid treating a restart as the first diagnostic step, particularly on a system carrying active calls.

Troubleshooting architecture problems

An application is unavailable

If the dialplan reports that an application cannot be found, the providing module may not be installed, may have been disabled, may have failed to load, or may use a different application name in the installed Asterisk version.

• Check loaded modules with module show or module show like.
• Search available applications with core show applications like.
• Read application help to confirm the installed syntax.
• Review startup output and module-loading configuration.

A call receives an invalid extension response

The channel may be entering the wrong context, the expected extension or pattern may be absent, or a dialplan edit may not have loaded successfully. Inspect the channel's context and destination, display the relevant context with dialplan show, then validate and reload the dialplan according to local policy.

Dial() cannot reach an endpoint

Check whether the endpoint is registered or reachable, whether the endpoint name and channel technology are correct, and whether the required channel driver is available. Authentication, network connectivity, and codec negotiation can also prevent call setup. Inspect endpoint status, active channels, loaded modules, and verbose CLI output during a controlled test call.

A configured module is absent after startup

The module file may be missing from the configured module directory, a dependency may be unavailable, the module may be incompatible with the Asterisk build, or a modules.conf rule may prevent loading. Review the configured module path, startup load errors, package or build options, and dependency messages.

Exam-relevant distinctions

• The core coordinates the runtime; it is not the implementation of every feature.
• A module is a loadable component; an application is an action executed by the dialplan.
• A channel represents one active call leg, not necessarily the entire call.
• A bridge connects channels so parties can communicate.
• An extension is a dialplan destination and sequence, not necessarily a physical telephone.
• A context controls which destinations a channel can access and is central to dialplan security.
• PJSIP is a modern commonly used SIP channel stack; chan_sip is historically common and should be treated as legacy where present.
• A missing or unloaded module can make a dialplan application, channel technology, or other feature unavailable.

Once these relationships are clear, configuration becomes easier to reason about: channel technology supplies the call leg, the core coordinates it, the dialplan chooses the path, applications perform the actions, and bridges connect the resulting legs.

Continue with Asterisk architecture and call-flow concepts as a reference while studying endpoint configuration, routing, voicemail, queues, and debugging.