Contexts, Extensions, and Variables! Oh My!

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 tangled 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
certain 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 yes or no, but for some reason, only yes has been implemented.This will eventually control Asterisk from rewriting the extensions. conf every time an extension is added or deleted.The next setting is writeprotect. This can also be set to either yes or 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,COMMAND(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).

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).

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 n syntax.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 executed. 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 extension 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, followed 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.

Dial Plan Commands
The commands are the heart of any dial plan.They are what actually cause Asterisk to answer the call, ring the phone, transfer the call, play the menu, and do numerous other things. See Table 3.4 for a look at some of the more common ones.

Variables
Variables in extensions.conf are nothing special.They act like variables in any other language.Variables are set via the Set() command and are read via the variable name encased in ${}:

[example]
exten => s,1,Set(TEST=1)
exten => s,2,NoOp(${TEST})

Variables are common in simple dial-plan applications and Asterisk uses certain variables for internal functions, but their use is somewhat uncommon in regular dial plan usage.

Tying It All Together
All of these pieces of dial plans make little to no sense when thinking about them in the abstract, so you may be scratching your head right now. Let’s take a look at how all of these would be used in an everyday environment, by looking at a simple extensions.conf:

When a call enters the [default] context, it is answered by Asterisk. Asterisk then starts playing the
 mainmenu sound file while waiting for the caller to enter digits. At this point, the caller can either enter 100
and be connected to the channel SIP/10 or 20 and be connected to the channel SIP/20. If the menu finishes
playing and the user has not entered any digits, the call will be hung up on.

Using Special Extensions
Now, hanging up on your caller if they wait to listen to the whole menu seems kind of rude, doesn’t it? So
let’s take the file we had before and use some special extensions to have the menu replay if the user hasn’t
entered an extension and inform them if the extension they entered is invalid.

That’s much nicer. Now the behavior of the dial plan is the same, up until the main menu ends. At that point,
the menu repeats. Also, now if the caller dials an incorrect extension, the dial plan will play a menu that
informs them the extension they entered is not valid.

Creating Submenus
Normally, most small to medium-sized companies only require a single menu, but let’s say your boss wants
to have a support menu that allows customers to direct their questions to the appropriate support group.We
can accomplish this by creating a second context that contains the appropriate menu and extensions. Let’s
build on the previous example again and add a second menu that allows callers to be connected to the
Blivet,Widget, or Frob support lines.

In this example, we’ve added a third option to the main menu. If a caller dials 3, they are connected to the [supportmenu] context with a Goto() statement. Goto() can be called many different ways.You can jump between priorities in the same extension by just specifying Goto(priority) or you can jump between extensions in the same context by specifying Goto(priority,extension). Lastly, you can switch contexts by specifying Goto(context, extension, priority).