VMware ESXi and vSphere Cluster Management

Asterisk Channels: Channel Drivers, Device Configuration, and Dialplan Routing

Learn how Asterisk channels, channel drivers, endpoints, contexts, and dialplans work together to route inbound and outbound calls.

An Asterisk channel is Asterisk’s representation of an active communications path, or call leg. It is the object Asterisk uses to handle signaling and media for a connected telephone interface, SIP endpoint, trunk, or another telephony resource.

A channel is not the same thing as a user, telephone number, extension, endpoint, or dialplan context. These concepts work together, but each has a different responsibility.

How channels represent a call

A call can contain more than one channel. For example, when endpoint 100 calls endpoint 200, Asterisk receives the call on an inbound channel such as PJSIP/100. The Dial() application then asks Asterisk to create an outbound channel such as PJSIP/200. After the destination answers, Asterisk bridges the two channel legs so that the parties can communicate.

The channel name commonly contains a technology and a resource, followed by an internally generated unique identifier for the active channel. The identifier helps distinguish simultaneous calls using the same endpoint.

Channel technologies and channel drivers

A channel technology is the protocol or interface family used for signaling and media. A channel driver is an Asterisk module that implements that technology and creates or controls channels.

Technology availability is not guaranteed. It depends on the Asterisk version, compiled or installed modules, and enabled features. A target such as PJSIP/endpoint-name selects the PJSIP technology and the endpoint resource. In a legacy installation, SIP/device-name selects the chan_sip technology and device resource.

Endpoint and channel configuration

Channel configuration tells Asterisk how to identify, authenticate, reach, and handle a device or trunk. Depending on the technology, it can include credentials, network address information, codecs, caller identification, permitted dialing behavior, and the dialplan context assigned to incoming calls.

Configuration and dialplan have different responsibilities. Endpoint configuration describes who or what is connecting and where inbound processing starts. The dialplan describes what Asterisk should do next.

Legacy chan_sip configuration

In a legacy chan_sip installation, sip.conf contains global driver settings and per-device or peer definitions. A peer section can identify a device, define authentication, describe whether its address is known statically or through registration, and assign an inbound context.

; sip.conf - legacy chan_sip example
[general]
; Global SIP settings would be defined here.

[100]
type=friend
secret=use-a-strong-secret
host=dynamic
context=internal-users
disallow=all
allow=ulaw

[200]
type=friend
secret=another-strong-secret
host=dynamic
context=internal-users
disallow=all
allow=ulaw

This example shows the relationship, not a complete production configuration. The device named 100 authenticates with its secret, may register dynamically, and enters the internal-users context for inbound calls. Device 200 is configured as a possible destination.

Modern PJSIP objects

PJSIP separates responsibilities into several related objects. An endpoint describes how a device or trunk behaves. An authentication object contains credentials. An address-of-record (AOR) stores contact or registration information. A transport defines how SIP messages use a network transport. An identify rule helps associate incoming traffic with the correct endpoint, often using source information.

; pjsip.conf - simplified conceptual example
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

[auth100]
type=auth
auth_type=userpass
username=100
password=use-a-strong-secret

[100]
type=endpoint
context=internal-users
disallow=all
allow=ulaw
auth=auth100
aors=100

[100]
type=aor
max_contacts=1

[auth200]
type=auth
auth_type=userpass
username=200
password=another-strong-secret

[200]
type=endpoint
context=internal-users
disallow=all
allow=ulaw
auth=auth200
aors=200

[200]
type=aor
max_contacts=1

A real deployment may add transport references, NAT settings, encryption, voicemail behavior, codec policy, registration options, and identification rules. The important routing concepts are that endpoint 100 has an inbound context and AOR, while endpoint 200 has contact information that lets Asterisk attempt an outbound call.

Dialplan concepts and the channel relationship

The dialplan is Asterisk’s call-processing logic. In traditional configurations, it is stored in extensions.conf. A context is a named collection of extension-processing rules. An extension is a dialed number or pattern, such as 200. A priority is an ordered step within that extension.

; extensions.conf
[internal-users]
exten => 200,1,NoOp(Call from an internal user to 200)
 same => n,Dial(PJSIP/200,20)
 same => n,Hangup()

For a legacy chan_sip destination, the dialing line would normally be:

same => n,Dial(SIP/200,20)

The endpoint name in the dialplan must match the configured resource, and the technology prefix must match the channel driver that owns that resource. A context assignment also must match the context containing the intended extension.

Inbound call flow

When a call arrives, Asterisk follows a sequence that connects channel configuration to dialplan execution.

Inbound SIP example: calling extension 200

1. A SIP phone configured as endpoint 100 sends a call to Asterisk and requests number 200.
2. The SIP channel driver receives the signaling. In a modern installation this is normally PJSIP; in a legacy installation it may be chan_sip.
3. Asterisk matches the source to endpoint 100. The endpoint configuration assigns the call to internal-users.
4. The dialplan searches [internal-users] for extension 200.
5. The matching rule runs Dial(PJSIP/200,20) in a PJSIP deployment, or Dial(SIP/200,20) in a chan_sip deployment.
6. The channel driver consults endpoint 200 and its contact or registration information, then attempts to create the outbound call leg.
7. If endpoint 200 answers, Asterisk bridges the inbound and outbound channels. If it is unavailable, does not answer within the timeout, or rejects the call, Dial() returns with a corresponding call outcome and subsequent dialplan priorities can provide fallback handling.

Outbound call flow

Outbound routing starts with a dialplan application, rather than with an endpoint’s inbound context. A rule may select a technology and resource directly, or use a trunk and number pattern.

[internal-users]
exten => 200,1,Dial(PJSIP/200,20)
 same => n,Hangup()

[from-provider]
exten => 1555010200,1,Dial(PJSIP/200,20)
 same => n,Hangup()

In the first route, Dial() selects endpoint 200. In the second, an incoming provider number is matched in the dedicated from-provider context and sent to endpoint 200. The PJSIP configuration supplies endpoint reachability; the dialplan supplies the routing decision.

Trunk contexts and security boundaries

An inbound provider trunk should normally use a narrowly scoped context such as from-provider. That context can match provider-delivered numbers, route them to an IVR, or send selected calls to internal destinations.

[from-provider]
exten => 1555010200,1,Answer()
 same => n,Dial(PJSIP/200,20)
 same => n,Hangup()

Do not place unauthenticated or untrusted traffic directly into an unrestricted internal context or an outbound-capable context. Context assignment controls which extensions and applications the caller may reach. It is therefore a security control as well as a routing choice.

• Use strong, unique SIP credentials.
• Limit network access to trusted signaling sources where practical.
• Use authentication and source identification appropriate to the provider or device.
• Separate internal phones, provider trunks, and special-purpose integrations into suitable contexts.
• Review outbound dialing permissions to reduce toll-fraud risk.

Configuration files and reload behavior

Traditional Asterisk systems commonly use extensions.conf for dialplan logic and sip.conf for legacy chan_sip settings. Modern SIP deployments commonly use pjsip.conf for transports, endpoints, authentication, AORs, contacts, and identification rules.

Configuration may be split across included files or generated by an external provisioning system. Before editing a file, determine whether it is the authoritative source; a generated file may be overwritten later.

After a controlled change, reload the relevant subsystem. The exact command and supported behavior depend on the installed modules and Asterisk version.

asterisk -rvvv

dialplan reload
pjsip reload
sip reload

Inspecting channels and endpoints

The Asterisk CLI can show whether channel drivers, endpoints, contacts, and dialplan rules are active.

core show channels
core show channels verbose
pjsip show endpoints
pjsip show contacts
sip show peers
module show like chan_
dialplan show internal-users

sip show peers is a legacy chan_sip command and may not exist when chan_sip is absent. For PJSIP, use the PJSIP commands to inspect endpoint and contact state.

Active-channel output can reveal the technology, channel state, caller, destination, and relationships between call legs. Increase CLI verbosity during a controlled test call and inspect Asterisk logs when a call fails. Signaling or protocol logging can help identify registration failures, endpoint matching problems, rejected requests, and incorrect dialplan entry.

Troubleshooting channel and routing problems

The phone connects, but the call does not reach the expected extension

• Inspect the endpoint or peer and confirm its assigned context.
• Run dialplan show context-name or dialplan show internal-users and verify that the number exists there.
• Check whether the dialed format matches the extension or pattern.
• Raise CLI verbosity and place a test call to observe the selected endpoint, context, and extension.
• For PJSIP, check whether an identification rule selected an unexpected endpoint.

Dial() reports that the destination is unavailable

• Check whether the destination endpoint is registered or has a reachable contact.
• Confirm that the technology prefix is correct: use PJSIP/200 for a PJSIP endpoint and SIP/200 only for a chan_sip resource.
• Verify that the endpoint name in the dialplan exactly matches the configured name.
• Inspect network, firewall, transport, NAT, and authentication settings.
• Read protocol and Asterisk logs for the actual call attempt and response.

The call enters an unauthorized or incorrect flow

• Review the source endpoint or trunk’s context assignment.
• Check for a broad or catch-all pattern that matches before the intended route.
• Review context includes and pattern ordering.
• Validate PJSIP identification rules or legacy peer matching.
• Move untrusted sources into restricted contexts.

Legacy SIP commands or changes have no effect

• Check loaded modules with module show like chan_.
• Determine whether the installation uses PJSIP or chan_sip.
• Confirm whether the endpoint is defined in pjsip.conf or sip.conf.
• Use the matching inspection and reload commands.

Configuration relationship summary

Endpoint configuration determines identity, authentication, reachable contacts, codecs, and the inbound context. Dialplan configuration determines which extension matches and which applications execute. Outbound dialing connects the two: the dialplan names a technology and resource, and the channel driver uses that resource’s configuration to place the call.

A useful mental model is:

Incoming signaling
    -> channel driver
    -> endpoint or trunk identification
    -> configured inbound context
    -> matching dialplan extension and priority
    -> Dial() or another application
    -> outbound channel driver and destination endpoint
    -> bridge between call legs

Exam-relevant notes

• A channel is an active communications path or call leg, not a user or extension.
• A channel driver implements a channel technology such as PJSIP, chan_sip, IAX, H.323, or Skinny/SCCP.
• Modern Asterisk SIP deployments generally use PJSIP; chan_sip and sip.conf are legacy concepts.
• An inbound endpoint’s context determines where dialplan processing begins.
• An extension is a dialplan match, and a priority is an ordered application step.
• Dial() creates or attempts an outbound channel and can connect it to the current call.
• A single call may contain an inbound channel and an outbound channel that Asterisk bridges.
• Context assignment is both a routing mechanism and a security boundary.