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

Learn how the Asterisk core, loadable modules, channels, dialplans, and applications work together to process calls and configure a PBX.

Asterisk is a modular telephony platform. It is not one monolithic program that contains every protocol and feature. The central runtime coordinates smaller loadable components, represents calls as channels, applies routing rules from a dialplan, and executes applications that perform call-control actions.

This architectural model helps administrators troubleshoot problems. A missing module, an incorrect channel technology, a wrong dialplan context, and a failed application are different problems even though they can all appear as “the call did not work.”

Architecture overview

The five principal concepts are the core, modules, channels, dialplans, and applications.

Core — The central runtime that initializes Asterisk, coordinates subsystems, reads relevant configuration, and makes call-processing facilities available.

Modules — Dynamically loadable components that add protocols, codecs, applications, functions, file formats, and other capabilities.

Channels — Runtime representations of individual communication connections or call legs.

Dialplan — The routing and call-control logic that decides what happens to a channel.

Applications — Actions invoked by the dialplan, such as dialing another endpoint, playing audio, recording voicemail, or ending a call.

A simplified relationship is:

channel enters Asterisk
        -> context and extension are selected
        -> dialplan priorities execute applications
        -> core and modules provide the required capabilities
        -> another channel may be created and bridged
        -> the call ends and resources are released

These concepts operate at different times:

Configuration time: administrators define endpoints, contexts, extensions, module choices, and other behavior in configuration files or generated configuration systems.
Startup time: the core initializes the service, reads configuration, and loads modules according to the installation and module-loading policy.
Runtime: signaling creates channels, the dialplan selects call logic, applications act on channels, and Asterisk handles media, bridging, and termination.

The Asterisk core

The Asterisk core is the central runtime responsible for initialization and coordination. It starts the platform, reads relevant configuration, manages the execution environment, and loads or coordinates available modules.

The core provides the framework in which dialplan logic can run. It tracks channels and call state, provides scheduling and internal coordination, and connects dialplan execution with channel and resource implementations.

The core does not, by itself, implement every endpoint protocol or optional feature. SIP connectivity, voicemail, many codecs, file formats, and numerous call features are normally supplied by modules. This separation lets an installation load the capabilities it needs instead of treating every feature as part of one fixed binary.

Loadable modules

A module is a dynamically loadable software component that contributes a specific capability. On Linux, a module commonly uses the .so shared-object filename extension. A shared object is a library that can be loaded into a running program or loaded during startup.

Common module categories

app_ — Dialplan applications that perform actions. Example: app_voicemail.so provides voicemail-related application functionality.

chan_ — Channel drivers that implement connectivity for a signaling or endpoint technology. Example: a SIP-related channel implementation.

res_ — Resource modules that provide shared services used by other components.

codec_ — Audio or media codec implementations used to encode and decode media.

format_ — Sound-file or media-format support.

func_ — Dialplan functions that retrieve or set values rather than acting as complete call-control applications.

Other optional modules can provide database integration, call recording, protocol support, parking, conferencing, and similar features. The exact set depends on the Asterisk version, build choices, packages, and operating system.

Controlling module loading

The traditional module-loading file is /etc/asterisk/modules.conf. Its policy can allow automatic loading, explicitly load selected modules, or suppress modules that should not be loaded.

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

autoload=yes tells Asterisk to load available modules according to its normal module-loading behavior.
load => explicitly requests a module.
noload => suppresses a module, even when automatic loading would otherwise find it.

Module dependencies matter. A feature may require a resource, codec, format, or database module. Do not disable a module merely because its filename looks unrelated to the feature being tested. Check startup errors and dependency messages before changing the loading policy.

Voicemail and SIP connectivity illustrate the separation clearly. A voicemail module family such as app_voicemail supplies voicemail behavior, while a SIP channel implementation supplies signaling and channel creation. These are distinct capabilities and do not belong solely to the core.

Module files are not guaranteed to be in one universal directory. A traditional location is /usr/lib/asterisk/modules, while 64-bit systems commonly use /usr/lib64/asterisk/modules. Distribution packages, source-build prefixes, architecture, and package splitting can all change the path. Verify the active installation instead of assuming a path.

Channels and channel technologies

A channel is Asterisk’s runtime representation of one active communication path or call leg. It may represent a physical telephone line, an endpoint call, a trunk connection, or a logical IP-based call.

A channel technology is the protocol or interface family used by a channel. It is not the same thing as an individual channel instance. For example, PJSIP is a technology or stack used to communicate with SIP endpoints; a call from endpoint 200 creates a particular channel instance using that technology.

Technologies historically associated with Asterisk include SIP, IAX, Skinny, and H.323. Current deployments commonly use PJSIP for SIP connectivity. Older systems may use chan_sip, a legacy SIP channel driver that administrators often encounter while maintaining existing installations.

Conceptual channel lifecycle

A channel driver receives signaling or another connection event.
Asterisk creates a channel instance and records its initial state.
The channel changes state as it rings, answers, sends or receives media, is placed on hold, or enters another call-control condition.
The dialplan and applications route the channel or create another call leg.
Channels may be associated in a bridge, allowing participants to communicate.
When the call ends, signaling and media resources are released and the channel is destroyed.

For an internal call, the inbound channel represents the caller. The Dial application asks a channel technology to create an outbound channel toward the destination endpoint. If the destination answers, Asterisk can bridge the two legs.

Dialplans

A dialplan is the set of rules that determines call routing and call-processing behavior. It tells Asterisk which applications to execute when a channel reaches a destination.

The traditional dialplan file is /etc/asterisk/extensions.conf. Alternative configuration systems, templates, database-backed systems, and generated dialplans can also be used, so the file is traditional rather than mandatory in every deployment.

Dialplan building blocks

Context: A named scope that controls which extensions a channel may access. Context isolation is an important security boundary.
Extension: A destination or pattern matched for a call. An extension can be a literal value such as 200 or a pattern for a class of numbers.
Priority: The execution order of steps within an extension. The first step commonly uses priority 1, followed by n for the next priority.
Label: A name that can identify a point in dialplan execution.
Pattern: A matching rule for variable dialed digits, such as internal or external number ranges.
Variable: A value used to carry information through call processing.
Include: A way for one context to make extensions from another context available.
Conditional flow: Logic that selects different actions based on variables, application results, caller state, or other conditions.

How a number reaches a dialplan step

Inbound channel settings select a dialplan context. When a caller dials 200, Asterisk searches that context for an extension or pattern matching those digits. It then executes the matching priorities in order.

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

This example forms a sequence of applications. It first attempts to call endpoint 200, then follows an unanswered path to voicemail, and finally terminates the call. The endpoint name and voicemail configuration must match the local installation.

Use explicit routes, assign endpoints to the correct contexts, isolate internal and external access, define failure paths, and include a final termination action where appropriate. A context that is too permissive can expose trunks or premium destinations, while a context that is too restrictive can make legitimate routes unreachable.

For additional dialplan fundamentals, see What Is A Dialplan, Contexts, Extensions, and Priorities.

Dialplan applications

An application is a callable dialplan action executed on the channel currently running dialplan logic. Applications receive arguments, perform an operation, and generally return a result or leave a channel state that later dialplan logic can evaluate.

Dial: Attempts to establish an outbound call leg and may bridge it to the current channel. Its arguments commonly identify a channel technology and destination, along with a timeout.
Playback: Plays an audio prompt or sound file to the current channel. It can be used for greetings, instructions, or announcements.
Hangup: Terminates the current channel and ends the current call flow.
Voicemail-related applications: Record, leave, or manage messages through voicemail module functionality.

Applications execute in order, but call states must be considered. A Dial attempt can be successful, unanswered, busy, rejected, or interrupted because the caller terminated the call. A robust dialplan sends each relevant result to an intentional next step rather than assuming that every attempt is answered.

Applications and functions are different. An application performs an action, such as playing audio or dialing an endpoint. A function generally retrieves or sets a value used by the dialplan. This distinction is useful when reading dialplan syntax and troubleshooting execution.

See The Dial Application, The Playback Application, The Hangup Application, and The Voicemailmain Application for application-specific study.

End-to-end call flow

1. Call arrival — A channel driver receives signaling from an endpoint, trunk, or other interface. Example: PJSIP receives an incoming SIP request.

2. Channel creation — Asterisk creates an inbound channel representing the caller’s call leg.

3. Context selection — Endpoint or trunk configuration assigns the channel to an allowed dialplan context.

4. Extension matching — The dialed digits are matched against a literal extension or pattern in that context.

5. Application execution — The core runs the dialplan priorities, invoking applications supplied by the core or loaded modules. Example: Playback plays a greeting.

6. Second-leg dialing or media action — Dial may ask a channel driver to create an outbound channel. A playback-only flow may instead continue without a destination endpoint.

7. Bridging or service completion — Answered legs may be bridged. A greeting, announcement, queue, or voicemail flow may complete its service without a live second endpoint.

8. Hangup and cleanup — Applications or remote signaling end the call. Asterisk tears down channels, bridges, media handling, and associated resources.

Protocol signaling, media handling, routing logic, and call-control actions are related but separate responsibilities. A channel driver handles technology-specific connectivity, the dialplan selects behavior, applications perform actions, and the core coordinates the runtime. Modules can participate at several points without replacing the overall architecture.

Example: internal extension call

A SIP endpoint dials 200.
The PJSIP-capable channel implementation receives the call and creates an inbound channel.
The endpoint’s assigned context is selected.
The dialplan matches extension 200.
Dial(PJSIP/200,20) asks the SIP technology to create an outbound channel toward endpoint 200.
If endpoint 200 answers, Asterisk bridges the caller and destination channels.
When either side hangs up, both call legs are released according to the resulting call state.

Example: greeting and voicemail fallback

An inbound extension can invoke Playback before routing continues. If Dial does not receive an answer, the dialplan can enter a voicemail action. The voicemail module records or manages the message, and the call ends through Hangup or normal service completion. This flow demonstrates that a live destination endpoint is not required for every call: playback and voicemail can operate on the current channel alone.

Configuration and filesystem orientation

Configuration directory — /etc/asterisk. Traditional location for Asterisk configuration files. Distribution or source-build choices may change it.

Module-loading configuration — /etc/asterisk/modules.conf. Controls automatic, explicit, and suppressed module loading.

Dialplan configuration — /etc/asterisk/extensions.conf. Traditionally defines contexts, extensions, priorities, and applications.

Module directory — /usr/lib/asterisk/modules is a traditional default; /usr/lib64/asterisk/modules is another common location.

Loaded-module verification — From the Asterisk CLI, use module show or module show like voicemail.

Dialplan verification — From the Asterisk CLI, use dialplan show to inspect the active loaded dialplan.

Runtime verification is more reliable than assumptions about filesystem paths. Connect to the running console and inspect the active system:

asterisk -rvvv
module show
module show like voicemail
dialplan show
core show channels

asterisk -rvvv connects to the running Asterisk console with increased verbosity.
module show lists loaded modules.
module show like voicemail filters the module list.
dialplan show displays the loaded dialplan.
core show channels displays active channels.

Troubleshooting architecture problems

A feature expected from a module is unavailable

Confirm that the corresponding package or module is installed.
Run module show and module show like <name> in the CLI.
Review startup messages and module-load errors.
Inspect modules.conf for an explicit noload directive.
Check dependencies before suppressing a related module.

A call reaches Asterisk but does not follow the expected extension

Verify that the endpoint or trunk uses the intended context.
Use dialplan show to confirm the active context and extension.
Check literal and pattern matching for the dialed digits.
Confirm that the edited dialplan was reloaded using the installation’s approved operational procedure.
Increase console verbosity while reproducing the call.

Dial cannot reach an endpoint

Check whether the destination is registered and available using technology-specific CLI commands.
Confirm that the Dial target uses the correct technology, such as PJSIP/200.
Verify that the target name matches the configured endpoint name.
Inspect signaling, authentication, network connectivity, and trunk configuration.
Use core show channels to see whether the expected call legs exist.

The documented module path does not exist

The system may use a 64-bit library directory, distribution-specific package paths, a custom source-build prefix, or a separate optional-module package. Check installed package contents or build configuration, then use the CLI module list to establish whether the module is present and loaded. Do not treat one filesystem path as universal.

Exam-relevant summary

The core coordinates the runtime; it is not the sole implementation of every protocol or feature.
Modules add capabilities such as channel drivers, applications, codecs, resources, formats, and functions.
A channel is one runtime call leg, while a channel technology is the protocol or interface family used by that leg.
The dialplan selects routing and call-control logic through contexts, extensions, priorities, patterns, variables, includes, and conditions.
Applications perform actions on the current channel; functions generally retrieve or set values.
Dial commonly creates a second channel and may bridge it with the current channel.
PJSIP is common in current deployments; chan_sip is commonly encountered in legacy systems.
Use the Asterisk CLI to verify loaded modules, active channels, and the dialplan instead of assuming configuration or module paths.

Further study: Install Modules With Menuselect, Required Configuration Files, Registering Phones To Asterisk, and The Voicemail Conf File.