extensions.conf can be broken down into three major parts: contexts, extensions, and variables. Each has their own unique and important function and needs to work together for a good dial plan to function.
Contexts
To put it simply, contexts are the fences that keep your extensions from getting tan-gled up in a big mess. A context is a simple way for grouping extension commands based on what the user has dialed.To begin a context, put the name of a context by itself in square brackets. Each context then contains a list of commands. In
extensions.conf there are two special contexts called [general]and [globals] in which cer-tain settings can be set.
general has a few special settings that define how extensions.conf behaves. First off is the static setting.This, can be set to either yesor no, but for some reason, only yes has been implemented.This will eventually control Asterisk from rewriting the exten-sions.confevery time an extension is added or deleted.The next setting is writeprotect. This can also be set to either yesor no, and this controls the ability of someone at the CLI to rewrite your dial plan via the save dialplan command.This may seem handy, but doing so will delete all comments in the file.
Each extension follows a similar syntax.exten => EXTENSION,PRIORITY,COM-MAND(ARGS).exten => precedes every extension.This is a directive that tells Asterisk to define an extension, as opposed to a context.The next three parts of an extension are EXTENSION,PRIORITY, and COMMAND(). Let’s cover these three portions.
Extensions
Extensions can be broken down into three types: a constant extension, a wildcard extension, and a special extension. A constant extension is an extension that when coded to a literal constant is the dial plan. A wildcard extension is a context that uses
wildcards to match multiple possibilities for the extension. Wildcards can be either internal Asterisk wildcards or RegEx-like patterns (see Table 3.2).
Table 3.2 Extension Wildcards Used in Asterisk Wildcard Patterns Matched
[0126-9] Any digit within the pattern. (In this case: 0,1,2,6,7,8, and 9).
X Any number 0 through 9. The equivalent of [0-9].
Z Numbers between 1 through 9. The equivalent of [1-9].
N Numbers between 2 through 9. The equivalent of [2-9]. This scheme is used most commonly in Area Code and Prefix assignments.
. Any number, one or more times.
So with Wildcard extensions, it is simple to reroute numerous extensions with one line of code. Let’s say a department in your building, the ever-important widget department, have moved to another division and wanted to leave a message at their old extensions informing callers that they had moved.They previously occupied Extensions 300 through 329 on your PBX. Rather than rewrite 30 lines; you can add a single extension of
exten => 3[0-2]X,1,Playback(WidgetDeptHasMoved)
This will have any caller dialing the department’s former extensions greeted by a message informing them of the move. Playback is a command that plays back a sound file stored on the system; we’ll cover it and its counterparts later.
In addition to wildcard and literal extensions, there are also special extensions that correspond to special events in the dial plan (see Table 3.3).
Table 3.3Special Extensions Used in Asterisk Extension Name Description
S Start Used when a caller is put in a context before dialing a number.
I Invalid Used when a caller dials an extension not defined in the current context.
H Hangup Used when a caller hangs up.
T Time Out Used when a caller does not respond within the response timeout period
Continued
Table 3.3 continuedSpecial Extensions Used in Asterisk Extension Name Description
T Absolute Used when a caller does not respond within the Time Out about timeout period
O Operator
Extensions do not necessarily need to be numbers either.They can be made with any type of text. While extensions like “fuzzybunnydept” cannot be dialed by a caller if included in your context, it can be used internally by your dial plan. We’ll see how this can come in handy later in the chapter.
Priorities
PRIORITY controls the flow in which commands are executed. For each extension, this is either controlled by an increasing number or a special nsyntax.The n syntax tells Asterisk to execute the extension one line after the other:
[incomingcall]
exten => s,1,Answer()
exten => s,n,Playback(mainmenu) exten => s,n,Hangup()
In this example, any call being routed to the “incomingcall” extension in Asterisk would have its call answered, a menu would then play, and then the call would be terminated. After Asterisk finishes executing one line, the next line would be exe-cuted. Numbering the steps provides greater flexibility with the dial plan since it is possible to control the flow logically rather than line by line. For example, the exten-sion shown earlier could be rewritten with a numbered sequence
[incomingcall]
exten => s,2,Playback(mainmenu) exten => s,1,Answer()
exten => s,3,Hangup()
Asterisk still answers, plays the menu, and hangs up because it executes by line number rather than by the order in which the lines appear. It executes step 1, fol-lowed by steps 2, and then 3.These steps could be scattered throughout the context and intertwined with hundreds of extensions. As long as they are numbered correctly, Asterisk will execute them in order for that context.