Chapter 4

Summary

This chapter has walked through the process of configuring the key parts of Asterisk needed by most PBX setups. We looked at settings for:

•Zapata (zapata.conf) and Zaptel (zaptel.conf)

•Session Initiation Protocol, SIP (sip.conf)

•Asterisk's homebrew protocol, Inter-Asterisk eXchange, IAX (iax.conf)

•Voicemail (voicemail.conf)

•Music on hold (musiconhold.conf)

•Call queues (queues.conf)

•Conference rooms (meetme.conf)

The next step, as we discover in the next chapter, is to create a dialplan to tell Asterisk how to handle any particular incoming call.

67

5

Creating a Dialplan

Congratulations! We have now installed Asterisk, and configured most of your new open-source phone system. Some readers may now be asking, "Are we there yet?" Well, quit whining—it's not far now and we have already come a good way. Let's pause for a moment and review the plan that we created in Chapter 2, where we should have decided what extensions and services we'll provide. Relax, the hard part is behind us, and now we might even start having fun!

In this chapter, we are going to create a full dialplan together. What is a dialplan? Asterisk is a powerful and flexible solution for many different telephony needs. Did you ever wonder how we use all of these features? This is how. At this point, programming experience may well give you an advantage, but it is by no means essential.

When calls come in to the switch, we tell Asterisk step-by-step how to handle the call. Steps can be as simple as playing a sound file to running a customized script. We are limited mostly by our imaginations at this point!

We define all of the steps we want Asterisk to perform in our extensions.conf file, in the customary location of /etc/asterisk.

Before we begin, we need to set priorityjumping=yes in the [general] section of extensions.conf. This will allow the tips and tricks in this chapter to work with Asterisk 1.2.X.

Creating a Context

What is a context? Simply said, a context is a group of extensions. Each extension must exist within a context. There is more to contexts than grouping extensions though.

In our extensions.conf file (or any included files), a context is denoted by square brackets "[]", like so:

[mycontext]

. . .

Creating a Dialplan

So, if a context is a group of extensions, why do we need more than one? Let's think for a minute. Not all employees should be able to dial every phone. Would you trust your 16year old intern with the ability to dial international calls? I wouldn't. Also, do you want your president to be bothered by customers in the waiting room who use a courtesy phone and misdial? We could find that hazardous to our continued employment!

So, contexts allow us to hide or make inaccessible certain extensions from other extensions. This gives us some level of security. It also allows us to host multiple phone systems on a single server.

Imagine you have two businesses on the same phone system, each with only two handsets. It'd be a pain to have each dial four digits to reach the other handset. We can use contexts to treat each company as if it were on a separate server.

Something very important about contexts is that we can include other contexts through the use of the include directive. This means that all extensions in an included context are available. The value of this may not be immediately apparent, but soon we will see the full power of this tool.

Suppose we have some context named bob. If we wanted bob to include default, then we would have the following in our extensions.conf:

[bob]

include => default

This single line placed in any context gives that context the ability to dial any extension in the default context, as well as all contexts included in the default context. This means that if the default context included the foo context, then anybody in the bob context could dial extensions in the foo context.

Suppose we had the following in our extensions.conf file:

[foo]

exten => 1,1,Playback(tt-monkeys) include => bar

[bar]

exten => 1,1,Playback(tt-weasels)

Now I know that we haven't yet discussed the definition of extensions yet. That's OK. All we need to know is that extension 1 in foo will play back a file that sounds like monkeys, and extension 1 in bar will play back a file that says that weasels have taken over our phone system.

If we are in context foo and press 1, which file will we hear play? This shows us the danger of includes. We should be careful to not include multiple matches for the same extension. If we do include multiple contexts, the first included context with a match will win. Consider the following file:

[foobar1] include => foo include => bar

70