The dialplan is the heart of your Asterisk system. Asterisk system defines how calls flow into and out of the system. A form of scripting language, the dialplan contains instructions that Asterisk follows in response to external triggers. In contrast to traditional phone systems, Asterisk’s dialplan is fully customizable.
The Asterisk dialplan is specified in the configuration file named extensions.conf.
The dialplan is made up of four main concepts: contexts, extensions, priorities, and applications. After explaining the role each of these elements plays in the dialplan.
Dialplans are broken into sections called contexts. Contexts keep different parts of the dialplan from interacting with one another. An extension that is defined in one context is completely isolated from extensions in any other context, unless interaction is specifically allowed.
As a simple example, let’s imagine we have two companies sharing an Asterisk server. If we place each company’s automated attendant in its own context, they will be completely separated from each other. This allows us to independently define what happens when, say, extension 0 is dialed: callers dialing 0 from Company A’s voice menu will get Company A’s receptionist, while callers dialing 0 at Company B’s voice menu will get Company B’s receptionist.
Please note that the space is conspicuously absent from the list of allowed characters. Don’t use spaces in your context names—you won’t like the result! Contexts are defined by placing the name of the context inside square brackets ().The name can be made up of the letters A through Z (upper- and lowercase), the numbers 0 through 9, and the hyphen and underscore.
At the beginning of the dialplan, there are two special contexts named [general] and [globals].
In Asterisk, an extension is far more powerful, as it defines the unique series of steps (each step containing an application) through which Asterisk will take that call.
Within each context, we can define as many (or few) extensions as required. When a particular extension is triggered (by an incoming call or by digits being dialed on a channel), Asterisk will follow the steps defined for that extension. It is the extensions, therefore, that specify what happens to calls as they make their way through the dialplan Although extensions can, of course, be used to specify phone extensions in the traditional sense (i.e., extension 153 will cause the SIP telephone set on John’s desk to ring), in an Asterisk dialplan, they can be used for much more.
extension has three components:
The name (or number) of the extension
The priority (each extension can include multiple steps; the step number is called the “priority”)
The application (or command) that will take place at that step
These three components are separated by commas, like this:
exten => name,priority,application()
Here’s a simple example of what a real extension might look like:
exten => 123,1,Answer()
Each extension can have multiple steps, called priorities.The priorities are numbered sequentially, starting with 1, and each executes one specific application.
As an example,the following extension would answer the phone (in priority number 1), and then hang it up (in priority number 2):
exten => 123,1,Answer()
exten => 123,2,Hangup()
Applications are the workhorses of the dialplan. Each application performs a specific action on the current channel,such as playing a sound, accepting touch-tone input, looking something up in a database, dialing a channel, hanging up the call, and so forth. In the previous example, you were introduced to two simple applications: Answer() and Hangup().
Some applications, including Answer() and Hangup(), need no other instructions to do their jobs. Most applications, however, require additional information. These additional elements, or arguments , are passed on to the applications to affect how they perform their actions. To pass arguments to an application, place them between the parentheses that follow the application name, separated by commas.