Chapter 5
Using the underscore (_) character warns Asterisk that the extension number will include pattern matching. When matching patterns, the X character represents any number (0-9), the Z character will match the numbers 1-9, the N character represents numbers 2-9, and the period (.) represents a string of any number of digits.
Also, we can use certain variables in our dialplan. One such variable is ${exten}, which represents the extension that was used.
So, for this example, we could use the following definition:
exten => _1XXX,1,Macro(normal|${exten}|SIP/${exten})
This one line of code has now defined 1000 extensions, from 1000 to 1999. All we have to do is ensure that our voicemail user, extension, and SIP user are all the same number. Pretty cool, huh?
One other note: if we wish to modify the behavior of all extensions, all we have to do is modify the macro. This should help us quite a bit as we tweak Asterisk to fit our business needs.
Creating Outgoing Extensions
With this dialplan, we have only catered for incoming calls. Of course we will want to create extensions to dial out.
How these outgoing extensions look depends on the plan we made earlier. It also depends on how you want the switch to act for your users. We always want to make it as similar to any old system as possible to reduce the need to retrain users.
Most phone systems require a user to dial a certain digit to designate the call as one that has a destination outside the switch. In our legacy PBX, we accessed outgoing lines by dialing a 9. To copy this behavior, we could do something like:
[outgoing]
exten => _9.,1,Dial(Zap/g1/${EXTEN:1})
Notice that we are using pattern matching as we did before. Notice also that we used g1 as the Zaptel interface. This is a good use for a group. This simply means "any free interface in group 1". Thus, if we put all of our outgoing lines in group 1, then when we dial an outside number, we do not have to guess which channel is free.
Remember that the variable exten represents the extension that we are in. If a user dials 95555555, then exten is equal to 95555555. By using ${EXTEN:1}, we instruct Asterisk to strip the first (leftmost) digit. Thus, ${EXTEN:1} equals 5555555. If we wanted to strip the two leftmost digits, it would be ${EXTEN:2}.
Many discount long distance carriers will charge the same for local calls as long distance. In a case like that, we would want to make sure that local and toll-free calls went out on lines connected to the local telephone company, while calls destined for long-distance
75
Creating a Dialplan
locations should go out through our discount carrier. For this example, we will assume that the discount carrier is Zaptel group 1, and the local telephone company is Zaptel group 2.
[outgoing]
exten => _9N.,1,Dial(Zap/g2/${EXTEN:1}) exten => _91.,1,Dial(Zap/g1/${EXTEN:1})
Therefore, if the number dialed is preceded with a 9 and a 1, then the call will go out through our Zaptel group 1 lines, and if it does not have a 1, it will go out through our group 2 lines.
What if we had used:
[outgoing]
exten => _9X.,1,Dial(Zap/g2/${EXTEN:1}) exten => _91.,1,Dial(Zap/g1/${EXTEN:1})
Notice that this is a problem. When we dial 9, followed by 1, we have two statements that match. When you start Asterisk, you will notice that the system parses the extensions.conf (and included files) and immediately reorders all of the extensions before building a database file. Therefore, it is ambiguous as to which statement it will execute.
While this method is technically functional, it is not the best way to do it. A better way would be:
[outgoing]
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1})
This does not allow for medium distance dialing. It also does not handle the case of all lines being busy in one of the groups. Let's see how we could take care of that:
[outgoing]
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXNXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXXXXX,2,Dial(Zap/g2/${EXTEN:1})
This is getting much better, but what about when all of our lines are busy, for both groups? We should probably notify the user that their call didn't go through because all lines are in use. We could do something like this:
[outgoing]
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _9NXXXXXX,3,Congestion
exten => _91NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXNXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXNXXXXXX,3,Congestion
exten => _91NXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXXXXX,3,Congestion
76
Chapter 5
Imagine a phone switch in which all extensions were exactly four digits long. How would this knowledge affect our outgoing lines? Perhaps the fundamental question is whether we really need to dial the 9 at all. While people generally expect to dial a 9 at work, they do not seem to care to do so from home. Maybe we should do this:
[outgoing]
exten => _NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _NXXXXXX,3,Congestion
exten => _1NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _1NXXNXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _1NXXNXXXXXX,3,Congestion
exten => _1NXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _1NXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _1NXXXXXX,3,Congestion
There is a drawback to this configuration. If you are using Zaptel interfaces, and people are touch-tone dialing, Asterisk will have to wait for a timeout period to complete dialing some four-digit extensions. The reason for this is simple. Any extension number that partially matches the beginning of the patterns above will have to be held to see if more digits are coming. However, SIP and IAX phones do not seem to suffer the same issue.
Because of this issue, from here forward we will assume that all outgoing calls are preceded with the digit 9.
We have already discussed that contexts can provide security for outgoing phone calls, but this example fails to describe such security. Suppose you have two groups of employees, those who may make toll calls, and those who may not. All employees have an individual handset. The most logical choice is to make two contexts:
[longdistance]
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _9NXXXXXX,3,Congestion
exten => _91NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXNXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXNXXXXXX,3,Congestion
exten => _91NXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXXXXX,3,Congestion
[local]
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _9NXXXXXX,3,Congestion
We simply place each handset into one of the two contexts, based upon what numbers we want them to be able to dial. While this would work, we duplicated three lines between the contexts. Remember when we discussed contexts, and I mentioned that we can use the include directive? Here's a good place to do so. So now, we have:
[longdistance]
exten => _91NXXNXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXNXXXXXX,2,Dial(Zap/g2/${EXTEN:1})
77