Tag: Asterisk

Why Asterisk-based GUI software should make better use of regular expressions

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Having recently discovered that Asterisk supports regular expressions (with some limitations), I got to wondering why the FreePBX-based GUI’s don’t make better use of them.  For example, in FreePBX, Trixbox, Elastix, etc., the Outbound Route pages all support entering patterns that are then directly used in Asterisk dialplans, in a most inefficient manner.  Let me give you an example.  Let’s say you have created an Outbound Route for toll-free calls, and in the “Dial Patterns that will use this Route” section you have entered these patterns:

1800NXXXXXX
1844NXXXXXX
1855NXXXXXX
1866NXXXXXX
1877NXXXXXX
1888NXXXXXX
800NXXXXXX
844NXXXXXX
855NXXXXXX
866NXXXXXX
877NXXXXXX
888NXXXXXX

Let’s further say that you have specified three trunks in the “Trunk Sequence for Matched Routes” section (this is actually conservative given that there are a number of ways you can route toll-free calls for free).  Anyway, this is an actual representative context that would be generated in extensions_additional.conf:

[outrt-5] ; TollFree
include => outrt-5-custom
exten => _1800NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1800NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1800NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1800NXXXXXX,n,Set(_NODEST=)
exten => _1800NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1800NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1800NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1800NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1800NXXXXXX,n,Macro(outisbusy,)
exten => _1844NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1844NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1844NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1844NXXXXXX,n,Set(_NODEST=)
exten => _1844NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1844NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1844NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1844NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1844NXXXXXX,n,Macro(outisbusy,)
exten => _1855NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1855NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1855NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1855NXXXXXX,n,Set(_NODEST=)
exten => _1855NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1855NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1855NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1855NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1855NXXXXXX,n,Macro(outisbusy,)
exten => _1866NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1866NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1866NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1866NXXXXXX,n,Set(_NODEST=)
exten => _1866NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1866NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1866NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1866NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1866NXXXXXX,n,Macro(outisbusy,)
exten => _1877NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1877NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1877NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1877NXXXXXX,n,Set(_NODEST=)
exten => _1877NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1877NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1877NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1877NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1877NXXXXXX,n,Macro(outisbusy,)
exten => _1888NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1888NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _1888NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _1888NXXXXXX,n,Set(_NODEST=)
exten => _1888NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1888NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _1888NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _1888NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _1888NXXXXXX,n,Macro(outisbusy,)
exten => _800NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _800NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _800NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _800NXXXXXX,n,Set(_NODEST=)
exten => _800NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _800NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _800NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _800NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _800NXXXXXX,n,Macro(outisbusy,)
exten => _844NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _844NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _844NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _844NXXXXXX,n,Set(_NODEST=)
exten => _844NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _844NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _844NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _844NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _844NXXXXXX,n,Macro(outisbusy,)
exten => _855NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _855NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _855NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _855NXXXXXX,n,Set(_NODEST=)
exten => _855NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _855NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _855NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _855NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _855NXXXXXX,n,Macro(outisbusy,)
exten => _866NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _866NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _866NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _866NXXXXXX,n,Set(_NODEST=)
exten => _866NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _866NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _866NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _866NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _866NXXXXXX,n,Macro(outisbusy,)
exten => _877NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _877NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _877NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _877NXXXXXX,n,Set(_NODEST=)
exten => _877NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _877NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _877NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _877NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _877NXXXXXX,n,Macro(outisbusy,)
exten => _888NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _888NXXXXXX,n,Noop(Calling Out Route: TollFree)
exten => _888NXXXXXX,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=””]?default:${MOHCLASS})})
exten => _888NXXXXXX,n,Set(_NODEST=)
exten => _888NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _888NXXXXXX,n,Macro(dialout-trunk,7,${EXTEN},)
exten => _888NXXXXXX,n,Macro(dialout-trunk,10,${EXTEN},)
exten => _888NXXXXXX,n,Macro(dialout-trunk,8,${EXTEN},)
exten => _888NXXXXXX,n,Macro(outisbusy,)

; end of [outrt-5]

That is 112 lines of dialplan generated by only 12 lines of pattern in the Outbound Route and three trunk selections.  If you have more patterns and/or more trunks, the generated dialplan can grow MUCH larger.  At one point I had a dialplan so large that whenever I did an “orange bar” reload, it took two to three minutes to finish reloading.  Clearly, there is something wrong here.

Now, let’s suppose that instead of, or better yet, in addition to the current Outbound Route pages, we had pages called “Outbound Route – Regular Expression”.  It would eliminate the “Dial Patterns that will use this Route” section, replacing it with a “Regular Expression to select this Route” text box, and it would also have a text box that says “Extensions allowed to use this route (separated by the | character – RegEx patterns may be used).

Let’s say that the contents of the first text box are ^1?8(00|44|55|66|77|88)[2-9][0-9]{6}$ and are stored in variable string1. And let’s say that the contents of the second text box are 10[0-4]X|106[5-8] (specifying that extensions 1000-1049 and 1065-1068 may use this route) and are stored in string 2. Assuming that the part of the dialplan that processes this were in some kind of macro, and the called number is in the variable OUTNUM, you could perhaps do something like this:

exten => s,n,ExecIf($[${REGEX(“${string2}” ${CALLERID(num)})} != 1]?MacroExit())
exten => s,n,ExecIf($[${REGEX(“${string1}” ${OUTNUM})} != 1]?MacroExit())
exten => s,n,Macro(dialout-trunk,7,${OUTNUM},)
exten => s,n,Macro(dialout-trunk,10,${OUTNUM},)
exten => s,n,Macro(dialout-trunk,8,${OUTNUM},)
exten => s,n,Macro(outisbusy,)

The first line bails out of the macro if the Caller ID doesn’t match one of the permitted extensions (this would assume you by default use a regex that matches any extension on your system, for example ^[0-9]{4}$ would match any 4 digit extension number. If you don’t assume this, then you’d need an extra bit of code to skip a null value in string2).

The second line bails if the called number doesn’t match the pattern in string1.

If the called number does match on the regular expression for this route, and the call is from a permitted extension, then the three trunks are tried. Note that now you only need to list each of the three trunks once.

Granted this doesn’t account for every line in the original context, but the other lines could also be transferred into the macro, with a bit of thought. Wouldn’t this be simpler for those who know how to use regular expressions? And, it has the potential to generate MUCH shorter dialplans.

Those who understand the power of regular expressions and who have long or complicated dialplans would appreciate the ability to use regular expressions!  If anyone implements this, don’t be stingy with the maximum string length in the Regular Expression text boxes; I guarantee you that 256 characters is not enough, and neither is 1,024 characters! At a MINIMUM I would say that you need to allow a 4,096 character (4K) regular expression, and while I personally can’t conceive of anyone exceeding that, my bet is that sooner or later someone will.  Remember, you are potentially saving a whole bunch of memory and drive space by allowing regular expressions, so you don’t have to be miserly on the space allotted for the expressions themselves.

How to use the FreePBX [macro-dialout-trunk-predial-hook] macro and regular expressions to blacklist or whitelist outgoing calls on all trunks

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission.

DISCLAIMER: Just because I do something a certain way doesn’t mean YOU should, at least not without extensive testing to make sure that it will do what you want. I do not warrant that anything shown here will in any way save you from getting a high phone bill. If that should happen, consider it a happy coincidence, but if it doesn’t work as you expected, don’t come crying to me. I only offer what I think might work, it’s up to YOU to test it on YOUR system.

This is a followup to my article, Did you know that Asterisk has the ability to evaluate Regular Expressions, though not in the same way as Perl or FreeSWITCH? If you have not read that article, you may want to do that first. Both that article and this one are subject to future revision, if I discover more on this subject.

The problem I have always had on the two systems I help administer is that we don’t allow international calls that cost money. In the past I had resorted to putting a complete list of valid area code patterns in each user’s Outbound Route, and since I had to include patterns for both 11 digit and 10 digit calls, it grew to be a pretty long list. Fortunately, when adding a new user, it was easy to copy the list from an existing user’s outbound account, bring it into a text editor to edit the /extension suffix, and paste it into the new user’s Outbound Route. That worked in FreePBX 2.7, and in versions 2.8 and 2.9 if you use the Swiss Army Knife module, but that module won’t work with FreePBX 2.10 and above.

Unfortunately, as you are very well aware if you have read many of my previous posts, starting in FreePBX 2.8 the FreePBX developers changed the entry method for Outbound Route dial patterns, changing it from an incredibly easy process to enter a list of patterns into a painful, totally stupid method involving individual text boxes for each individual part of each line of each Outbound Route dial pattern. That one change was enough to make me hate FreePBX. The FreePBX developers have been totally unresponsive to those who don’t care for the new method (they pretty much try to pretend such users don’t even exist).

One thing I am NOT going to EVER do is enter a long list of dial patterns using their input method! Someone once said of me that I would spend weeks looking for a way around having to re-type something, when it might only take me a few hours to re-type it, and that’s true. I have even abandoned whole articles because my system crashed and there was no backup, and there was no damn way I was retyping what I had already typed. So in that spirit, I started looking for ways to get around having to enter all those dial patterns for each Outbound Route. I’ve used various stopgap measures including weird things like custom trunks, but that was an ugly solution and leaves extra entries in the Call Detail Records. When I found out that Asterisk could use Regular Expressions, I figured out this method, which is actually much faster, and gives me another way to bypass the limitations of FreePBX.

This uses the [macro-dialout-trunk-predial-hook] macro which is already present, but commented out, in /etc/asterisk/extensions_custom.conf. The thing you need to understand about this macro is that it is called AFTER most of the dial plan associated with both the outbound route and the trunk have been applied. So if you change the called number in either the Outbound Route Dial Patterns or the Trunk Dialed Number Manipulation Rules, those transformations will already have been applied by the time this macro is called. Also, if the calling number has been changed (by setting the Outbound Caller ID in the Trunk, for example), that change have been made by the time this macro is called. And finally, this macro is called when a call is about to go out on ANY trunk in your system (at least I think it does, although I haven’t tested it with every possible trunk type. I’m reasonably sure it is called whenever a call is destined for a SIP trunk, but I am not sure that it gets called if you use one of the other available types of trunks. It does NOT seem to get called when a call is destined for an ENUM trunk). If you don’t want it to act on calls from a certain trunk, you need to test for that and bail out of the macro (I show an example of that below).

The interesting thing about this is that because this macro is invoked so late in the progress of an outgoing call, you can use it as a last chance to look for “undesirable things” or to send notifications of certain happenings. For example, although I don’t show exactly how to do it below, you could have it send an instant message or an e-mail notification when someone calls a specific number, such as 911.

What I am showing here is what I have set up on one of my systems. This assumes that the outbound routes only contain the following Dial Patterns (not all Outbound Routes will contain all of these, and I assume that each user has their own outbound route, or that groups of users may share outbound routes):

1NXXNXXXXXX/ext
NXXNXXXXXX/ext
1aaa+NXXXXXX/ext

…where aaa is the user’s local area code for 7 digit dialing , and ext is the user’s extension (which could be a pattern to allow a group of extensions). In addition, if the user’s service allows the *67 code to be used to block outgoing Caller ID, then these patterns might also be used (with the same substitutions):

*671NXXNXXXXXX/ext
*67NXXNXXXXXX/ext
*671aaa+*67|NXXXXXX/ext

The way I have set it up also ignores any number under 10 digits (allowing it to go through) so if you have dial patterns that allow users to dial provider service codes, or extensions on another connected server, or some such thing, those calls won’t be affected — only calls of 10 digits or longer are checked (this is one reason I prepend the area code to 7 digit calls in the Outbound Routes). Note that there are long lines in the following so if you want to see them in their entirety, you need to cut and paste this into a text editor:

[macro-dialout-trunk-predial-hook]
; this macro intentially left blank so it may be safely overwritten for any custom
; requirements that an installation may have.
;
; MACRO RETURN CODE: ${PREDIAL_HOOK_RET}
;                    if set to "BYPASS" then this trunk will be skipped
;
exten => s,1,NoOp(Trunk ${OUT_${DIAL_TRUNK}} selected)
exten => s,n,ExecIf($[${LEN(${OUTNUM})}<10]?MacroExit())
exten => s,n,ExecIf($["${OUT_${DIAL_TRUNK}}"="SIP/TollFree-Future9"]?MacroExit())
exten => s,n,Set(regx=^([*]67)?1?900[0-9]{7}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?premium)
exten => s,n,Set(regx=^([*]67)?1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?tollfree)
exten => s,n,Set(regx=^([*]67)?1?[2-9][0-9]{2}976[0-9]{4}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?premium)
exten => s,n,Set(regx=^([*]67)?1?(201|202|203|205|206|207|208|209|210|212|213|214|215|216|217|218|219|220|223|224|225|228|229|231|234|239|240|248|251|252|253|254|256|260|262|267|269|270|272|274|276|279|281|301|302|303|304|305|307|308|309|310|312|313|314|315|316|317|318|319|320|321|323|325|327|330|331|332|334|336|337|339|346|347|351|352|360|361|364|380|385|386|401|402|404|405|406|407|408|409|410|412|413|414|415|417|419|423|424|425|430|432|434|435|440|442|443|445|458|463|469|470|475|478|479|480|484|501|502|503|504|505|507|508|509|510|512|513|515|516|517|518|520|530|534|539|540|541|551|559|561|562|563|564|567|570|571|573|574|575|580|585|586|601|602|603|605|606|607|608|609|610|612|614|615|616|617|618|619|620|623|626|628|629|630|631|636|641|646|650|651|657|660|661|662|667|669|678|680|681|682|701|702|703|704|706|707|708|712|713|714|715|716|717|718|719|720|724|725|726|727|731|732|734|737|740|743|747|754|757|760|762|763|765|769|770|772|773|774|775|779|781|785|786|801|802|803|804|805|806|808|810|812|813|814|815|816|817|818|828|830|831|832|838|843|845|847|848|850|854|856|857|858|859|860|862|863|864|865|870|872|878|901|903|904|906|907|908|909|910|912|913|914|915|916|917|918|919|920|925|928|929|930|931|934|936|937|938|940|941|947|949|951|952|954|956|959|970|971|972|973|978|979|980|984|985|986|989)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?usa)
exten => s,n,Set(regx=^([*]67)?1?(204|226|236|249|250|289|306|343|365|367|403|416|418|431|437|438|450|506|514|519|548|579|581|587|604|613|639|647|705|709|778|780|782|807|819|825|867|873|879|902|905)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?canada)
exten => s,n,Set(regx=^0118835100[0-9]{8}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?inum)
exten => s,n,NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a NOT a permitted call)
exten => s,n,Jabbersend(asterisk,system_administrator_address@gmail.com,${CALLERID(num)} attempted to call ${OUTNUM} at ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z on %A %B %e)})
exten => s,n,Playback(custom/sorry-outside-us-canada)
exten => s,n,Macro(hangupcall,)
exten => s,n,Set(PREDIAL_HOOK_RET=BYPASS)
exten => s,n,MacroExit()
exten => s,n(premium),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a premium number call - NOT perrmitted)
exten => s,n,Jabbersend(asterisk,system_administrator_address@gmail.com,${CALLERID(num)} attempted to call a premium number ${OUTNUM} at ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z on %A %B %e)})
exten => s,n,Playback(silence/1&sorry-cant-let-you-do-that3)
exten => s,n,Macro(hangupcall,)
exten => s,n,Set(PREDIAL_HOOK_RET=BYPASS)
exten => s,n,MacroExit()
exten => s,n(usa),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a USA call)
exten => s,n,MacroExit()
exten => s,n(canada),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a Canada call)
exten => s,n,MacroExit()
exten => s,n(tollfree),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a toll free call)
exten => s,n,MacroExit()
exten => s,n(inum),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is an inum call)
exten => s,n,MacroExit()
exten => h,1,Macro(hangupcall,)

Now here’s a breakdown of the above, in which I try to explain what I have done. I will note at the outset that some may think I am using two lines where one will do, by putting the regular expression into a variable when I could just evaluate it directly in the REGEX function in the following line. However, when I was researching the use of regular expressions in Asterisk, I read on several pages that at least some versions of Asterisk have issues parsing a regular expression if it contains certain characters that also have a meaning to Asterisk, unless you put the regex into a string variable first and then use that in the REGEX function. I don’t know if that’s always true but I figured better safe than sorry, and besides, it’s much less confusing to me when I do it that way. But if you want to try combining the two-line pairs into one, feel free — it’s your system, and your headache if it doesn’t work. Also, remember that Asterisk doesn’t parse regular expressions in the same way that some other software (such as Perl) does, so if you try to simplify my regex patterns you might run into trouble. So with that said, let’s begin our tour.

This part of the macro is already present in extensions_custom.conf. You only need to uncomment the lines that are not obviously comments:

[macro-dialout-trunk-predial-hook]
; this macro intentially left blank so it may be safely overwritten for any custom
; requirements that an installation may have.
;
; MACRO RETURN CODE: ${PREDIAL_HOOK_RET}
;                    if set to "BYPASS" then this trunk will be skipped
;
exten => s,1,NoOp(Trunk ${OUT_${DIAL_TRUNK}} selected)

The next line is the first of many places we will use MacroExit() to bail out of the macro. This checks to see in the number called was 9 digits or less. We don’t want to block 911 calls, intra-company calls to other extensions, calls to another network that uses extensions of 9 digits or less, etc.:

exten => s,n,ExecIf($[${LEN(${OUTNUM})}<10]?MacroExit())

This bails out if the call is going out a specific trunk. In this case we don’t want to mess with toll-free calls going to Future9 because they are sent using a rather unusual pattern that would not be recognized by the regular expressions below.

exten => s,n,ExecIf($["${OUT_${DIAL_TRUNK}}"="SIP/TollFree-Future9"]?MacroExit())

Here’s an example of blocking a call that conforms to a specific pattern, in this case 1-900-XXX-XXXX or just 900-XXX-XXXX. It will block calls with or without the *67 (privacy) prefix, and with or without the leading “1”. If you don’t allow *67 calling then just remove the [*]67)? from the start of the expression. If it matches that pattern, it is transferred to the label “premium”, which we’ll get to in a bit:

exten => s,n,Set(regx=^([*]67)?1?900[0-9]{7}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?premium)

Here’s an example of allowing a call that matches a specific pattern, in this case a NANP toll-free call, again with or without the *67 (privacy) prefix (as is the case with most of these regular expressions — note that your outbound route(s) would also need to allow the *67 pattern). These calls are transferred to the label “tollfree”, which we’ll also talk about later:

exten => s,n,Set(regx=^([*]67)?1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?tollfree)

Here we block calls that match the pattern 1-[2-9]XX-976-XXXX or just [2-9]XX-976-XXXX (with or without a *67 prepend) and send them to “premium”:

exten => s,n,Set(regx=^([*]67)?1?[2-9][0-9]{2}976[0-9]{4}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?premium)

Here we test to see if the call is going to any USA area code. This is a really long regex but it works. If the pattern matches, it transfers to the “usa” label

exten => s,n,Set(regx=^([*]67)?1?(201|202|203|205|206|207|208|209|210|212|213|214|215|216|217|218|219|220|223|224|225|228|229|231|234|239|240|248|251|252|253|254|256|260|262|267|269|270|272|274|276|279|281|301|302|303|304|305|307|308|309|310|312|313|314|315|316|317|318|319|320|321|323|325|327|330|331|332|334|336|337|339|346|347|351|352|360|361|364|380|385|386|401|402|404|405|406|407|408|409|410|412|413|414|415|417|419|423|424|425|430|432|434|435|440|442|443|445|458|463|469|470|475|478|479|480|484|501|502|503|504|505|507|508|509|510|512|513|515|516|517|518|520|530|534|539|540|541|551|559|561|562|563|564|567|570|571|573|574|575|580|585|586|601|602|603|605|606|607|608|609|610|612|614|615|616|617|618|619|620|623|626|628|629|630|631|636|641|646|650|651|657|660|661|662|667|669|678|680|681|682|701|702|703|704|706|707|708|712|713|714|715|716|717|718|719|720|724|725|726|727|731|732|734|737|740|743|747|754|757|760|762|763|765|769|770|772|773|774|775|779|781|785|786|801|802|803|804|805|806|808|810|812|813|814|815|816|817|818|828|830|831|832|838|843|845|847|848|850|854|856|857|858|859|860|862|863|864|865|870|872|878|901|903|904|906|907|908|909|910|912|913|914|915|916|917|918|919|920|925|928|929|930|931|934|936|937|938|940|941|947|949|951|952|954|956|959|970|971|972|973|978|979|980|984|985|986|989)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?usa)

Same as the previous except now we’re testing for Canadian area codes, and if successful transferring to the “canada” label:

exten => s,n,Set(regx=^([*]67)?1?(204|226|236|249|250|289|306|343|365|367|403|416|418|431|437|438|450|506|514|519|548|579|581|587|604|613|639|647|705|709|778|780|782|807|819|825|867|873|879|902|905)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?canada)

(NOTE: It should be noted that a few new area codes are added every year. You can see a list of the most recently added ones here: NPAs Introduced over the Last 10 Years. You should check this periodically and add the new USA and Canadian area codes to the appropriate sections above.)

Google Voice used to complete calls to iNum numbers for free, so this test allowed for those. Now I don’t use this section, but leave it here as an example. Back when these calls were free, this was the only “international” format call that was permitted on our system:

exten => s,n,Set(regx=^0118835100[0-9]{8}$)
exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?inum)

If we get here, the call failed all the tests that would indicate it might be a permitted call. I play a custom recorded message that tells the caller that their call is not allowed, possibly because it’s not to a destination in the United States or Canada. Just prior to playing the message, I use the Jabbersend function to send myself an instant message showing that a call failed. I mainly do this so I can determine whether the caller really tried to dial a number that’s not permitted, or if there’s an error in my logic. For example, someone could be trying to place calls to a valid area code that somehow got omitted from the regular expression. Note that Jabbersend will only work if you have jabber.conf configured correctly AND the res_jabber.so module is loading when Asterisk starts up. If you have ever configured your server to place Google Voice calls using Asterisk’s jabber/gtalk support, those things are probably true, but it still may be a bit tricky to get working, however I’m not going to discuss that in this article — just search for Asterisk Jabbersend in a search engine if you need help:

exten => s,n,NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a NOT a permitted call)
exten => s,n,Jabbersend(asterisk,system_administrator_address@gmail.com,${CALLERID(num)} attempted to call ${OUTNUM} at ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z on %A %B %e)})
exten => s,n,Playback(custom/sorry-outside-us-canada)
exten => s,n,Macro(hangupcall,)
exten => s,n,Set(PREDIAL_HOOK_RET=BYPASS)
exten => s,n,MacroExit()

One further note about the last three lines in the above section: Setting the PREDIAL_HOOK_RET variable and the MacroExit() are probably superfluous because the Macro(hangupcall,) will terminate the call, but I left them there for safety. Note that if you were to comment out the Macro(hangupcall,), the last two lines would execute, and then if more than one trunk was specified in the Outbound Route, it would keep retrying the call on each of those trunks (and the caller would hear the error message multiple times, and you’d get multiple IM’s). Although I can’t personally envision such a situation, there might be situations where trying the additional trunks would be desirable.

Next is where the call goes if the caller attempted to dial a premium (900 or 976) number. This is similar to the previous section, except the recording played to the caller is one second of silence followed by a standard system recording. The silence is necessary to keep the first word or two of the recording from being cut off on some clients. Also the IM I send to myself is slightly different. And the same comment applies on the last three lines. I know, I could have done a Goto to the same three lines in the previous section, but that would have only saved me two lines, and since the last two lines are superfluous anyway, if you are that tight on space you can just delete them.

exten => s,n(premium),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a premium number call - NOT perrmitted)
exten => s,n,Jabbersend(asterisk,system_administrator_address@gmail.com,${CALLERID(num)} attempted to call a premium number ${OUTNUM} at ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z on %A %B %e)})
exten => s,n,Playback(silence/1&sorry-cant-let-you-do-that3)
exten => s,n,Macro(hangupcall,)
exten => s,n,Set(PREDIAL_HOOK_RET=BYPASS)
exten => s,n,MacroExit()

The next sections contain the usa, canada, tollfree, and inum labels. All they do is print an appropriate message to the CLI and exit. Rather than jump to these labels, I could have simply used statements of the form ExecIf($[${REGEX(“${regx}” ${OUTNUM})} = 1]?MacroExit()) and left out this entire next section, but I like the idea of being able to see which regex allowed the call in the CLI, and this also allows for the possibility of additional code. For example, I could insert code that keeps a running tally of calls broken down by their destination. I have no need to do anything like that, but maybe you do:

exten => s,n(usa),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a USA call)
exten => s,n,MacroExit()
exten => s,n(canada),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a Canada call)
exten => s,n,MacroExit()
exten => s,n(tollfree),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a toll free call)
exten => s,n,MacroExit()
exten => s,n(inum),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is an inum call)
exten => s,n,MacroExit()

This last line is important and was omitted from the default macro. It handles the case where the caller hangs up while this code is executing. Although that window is only a small fraction of second, bad things could happen if the caller does manage to hang up within that window and this statement isn’t present:

exten => h,1,Macro(hangupcall,)

Well, that’s how I’m doing it right now. It may not be how I do it two months from now, but this seems better than any method I have used thus far.

I will point out, for whatever it’s worth, that you COULD use an Asterisk dial command right in this macro. So, for example, let’s say you had a trunk that was real expensive at a certain time of the day but much cheaper during another. You COULD test to see if the call is being made within the “cheap” time and if so just exit, but if not you could execute a dial command that looks like the one normally executed, which is…

exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM},300,${DIAL_TRUNK_OPTIONS})

…except that in place of ${OUT_${DIAL_TRUNK}} you could specify a different trunk, for example SIP/OtherTrunk. And of course you could use this macro to change the dial trunk options for specific trunks, or to play a recording to callers if their call is going out over an “expensive” trunk. In fact, I can see where this macro could be used to get to get around some of the FreePBX syntax checking that has plagued me in the past.

It should probably be noted that if you watch these macros execute in the Asterisk CLI, every time one of them is executed you may see a WARNING message such as this:

[2012-11-22 11:48:12] WARNING[30588][C-00000055]: pbx.c:1585 pbx_exec: The application delimiter is now the comma, not the pipe. Did you forget to convert your dialplan? (Set(regx=^([\*]{2}1)?([\*]67)?W?1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$))

This warning doesn’t apply in this situation because the pipe IS the correct character to use in a regular expression, when you are matching a single regular expression out of several possible regular expressions. See this page on Alternation with The Vertical Bar or Pipe Symbol for more information, with the caveat that Asterisk’s expression engine is a bit different from that used in other software, and therefore may not recognize syntax that would be perfectly valid in another application. Therefore, not all examples shown on various regular expression tutorials or reference pages will work. If you wish to try a particular syntax, be sure to do a test run or two and make sure it works. But, Asterisk’s regular expression engine DOES recognize the pipe character when used as shown in the above examples, but spits out these warning messages anyway, even though the pipe characters are part of the regular expression, and are not being used as application delimiters. You can safely ignore the warnings – they are a nuisance, but are meaningless in this particular situation. If you really don’t want to see those warnings, use a text editor to go to /etc/asterisk/asterisk.conf and uncomment this line:

;dontwarn = yes                 ; Disable some warnings.

This will disable some non-essential warnings such as this one. If it were me, I would have named this option “stopwhining” rather than “dontwarn”, because Asterisk does tend to complain a lot about things that don’t matter and that you can’t do anything about. 🙂

Once again, I will mention that articles in this blog (and especially one such as this) are subject to future editing as I discover more about the subject. If you find any neat uses for the [macro-dialout-trunk-predial-hook] macro (ESPECIALLY if they allow you to do something that FreePBX tries to stop you from doing, but that’s perfectly allowable in Asterisk), feel free to leave a comment!

Did you know that Asterisk has the ability to evaluate Regular Expressions, though not in the same way as Perl or FreeSWITCH?

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

I happened to be searching the Asterisk issue tracker a few minutes ago (trying to figure out why the Asterisk Blacklist suddenly stopped working for no apparent reason on one of my systems) and happened to notice this issue which had just been posted today:

REGEX function ignores shorthand character starting with backslash

Wait, you mean Asterisk can evaluate Regular Expressions? I didn’t think it had that capability. So, working off the example shown in that issue report (the working expression, naturally) I tried putting this in the FreePBX extensions_custom.conf [macro-dialout-trunk-predial-hook] context (I had to uncomment some existing lines and add others). This is just example code and not meant to do anything useful. NOTE: Many of the lines in code blocks below won’t fit on the screen due to the way WordPress formats this blog, but if you copy and paste the lines into a text editor you should see them in their entirety:

[macro-dialout-trunk-predial-hook]
; this macro intentially left blank so it may be safely overwritten for any custom
; requirements that an installation may have.
;
; MACRO RETURN CODE: ${PREDIAL_HOOK_RET}
;                    if set to "BYPASS" then this trunk will be skipped
;
exten => s,1,NoOp(Trunk ${OUT_${DIAL_TRUNK}} selected)
exten => s,n,Set(tftest=^1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX("${tftest}" ${OUTNUM})} = 1]?tollfree)
exten => s,n,NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a NOT a toll free call)
exten => s,n,MacroExit()
exten => s,n(tollfree),NoOp(${CALLERID(num)} is calling ${OUTNUM} which is a toll free call)
exten => s,n,MacroExit()

If you place an outgoing call and watch the Asterisk CLI, you will see that if you place a call it knows what trunk was selected and what number the call came from, and prints that it is or is not a toll-free call. And I assume you could get other information about the call from other system variables. This could be handy for extended call routing, or for blocking of certain calls.

The thing to note here is that the dialplan only uses only one line to test for all the possible NANP toll-free area codes, both with and without a “1” prefix — you could do this without using a regular expression, but you’d need one line per area code to test. If you’ve ever looked at the FreePBX generated dialplan (in extensions_additional.conf) you know that much of the dialplan is lines upon lines of pattern specifications. I’ve mentioned in the past the problem of specifying every USA or Canadian area code in an outbound routes (so you can disallow calls to NANP points not covered by your calling plan) but it occurs to me that if FreePBX utilized regular expressions, it MIGHT be possible to condense many lines into one. Of course this would partly depend on whether there is a length limit on a regular expression, but in later testing I tried setting REGEX variables for the USA and Canada, like this:

This line that would create a regex that would test for USA calls (50 states + D.C.):

exten => s,n,Set(usatest=^1?(201|202|203|205|206|207|208|209|210|212|213|214|215|216|217|218|219|220|223|224|225|228|229|231|234|239|240|248|251|252|253|254|256|260|262|267|269|270|272|274|276|279|281|301|302|303|304|305|307|308|309|310|312|313|314|315|316|317|318|319|320|321|323|325|327|330|331|332|334|336|337|339|346|347|351|352|360|361|364|380|385|386|401|402|404|405|406|407|408|409|410|412|413|414|415|417|419|423|424|425|430|432|434|435|440|442|443|445|458|463|469|470|475|478|479|480|484|501|502|503|504|505|507|508|509|510|512|513|515|516|517|518|520|530|534|539|540|541|551|559|561|562|563|564|567|570|571|573|574|575|580|585|586|601|602|603|605|606|607|608|609|610|612|614|615|616|617|618|619|620|623|626|628|629|630|631|636|641|646|650|651|657|660|661|662|667|669|678|680|681|682|701|702|703|704|706|707|708|712|713|714|715|716|717|718|719|720|724|725|726|727|731|732|734|737|740|743|747|754|757|760|762|763|765|769|770|772|773|774|775|779|781|785|786|801|802|803|804|805|806|808|810|812|813|814|815|816|817|818|828|830|831|832|838|843|845|847|848|850|854|856|857|858|859|860|862|863|864|865|870|872|878|901|903|904|906|907|908|909|910|912|913|914|915|916|917|918|919|920|925|928|929|930|931|934|936|937|938|940|941|947|949|951|952|954|956|959|970|971|972|973|978|979|980|984|985|986|989)[2-9][0-9]{6}$)

Yes, that is all one single line (which you won’t see in its entirety if you don’t copy and paste the part you do see into a text editor, but it’s humongous)! But it seems to work if you use the ${usatest} variable instead of ${tftest} in the line containing the REGEX function! And here’s one for Canada that puts the expression into ${cdntest}:

exten => s,n,Set(cdntest=^1?(204|226|236|249|250|289|306|343|365|367|403|416|418|431|437|438|450|506|514|519|548|579|581|587|604|613|639|647|705|709|778|780|782|807|819|825|867|873|879|902|905)[2-9][0-9]{6}$)

Of course you could test for all three types of calls in the same block of code. Just remember that the code as shown above is handling calls destined for ALL your trunks, so if you only want it to operate on a single trunk you’ll have to test for that trunk only, and bail out if the call is headed for any other trunk.

For the moment all I will say is that this opens up interesting possibilities, including possibly new ways to get around some of the developer-imposed limitations of FreePBX, and also to streamline custom dialplan. Unfortunately it appears that Asterisk’s REGEX function support is not much used nor well documented, so you may have trouble finding other examples of working code that uses this function.

Also, Matt Jordan commented on the issue linked above, noting that “REGCOMP is built on the GNU extended regular expressions library (see regex.h). That library does not support the shorthand characters (see this comparison of regular expression libraries). As such, this is not a bug, but a limitation of the library that provides the regular expression functionality.” What this apparently means is that you cannot use something like d or [:digit:] to represent any digit, as you can do in other software that recognizes regular expressions, but [0-9] works just fine for that purpose. However, it would not be correct to say that backslashes can never be used, as I found these uses of REGEX in extensions_additional.conf:

exten => s-fixed,1,ExecIf($["${REGEX("^[+]?[0-9]+$" ${DB(RINGGROUP/${NODEST}/fixedcid)})}" = "1"]?Set(__TRUNKCIDOVERRIDE=${DB(RINGGROUP/${NODEST}/fixedcid)}))
exten => s-fixed,n,Return()
exten => s-extern,1,ExecIf($["${REGEX("^[+]?[0-9]+$" ${DB(RINGGROUP/${NODEST}/fixedcid)})}" == "1" & "${FROM_DID}" != ""]?Set(__TRUNKCIDOVERRIDE=${DB(RINGGROUP/${NODEST}/fixedcid)}))
exten => s-extern,n,Return()
exten => s-did,1,ExecIf($["${REGEX("^[+]?[0-9]+$" ${FROM_DID})}" = "1"]?Set(__REALCALLERIDNUM=${FROM_DID}))
exten => s-did,n,Return()
exten => s-forcedid,1,ExecIf($["${REGEX("^[+]?[0-9]+$" ${FROM_DID})}" = "1"]?Set(__TRUNKCIDOVERRIDE=${FROM_DID}))
exten => s-forcedid,n,Return()

Note the use of [+] in the REGEX expressions above. That “escapes” the + character, which otherwise would have a meaning in a regular expression, but for some reason the escaped character has to be enclosed in square brackets.  This can lead to some non-obvious regex constructions.  For example, look again at the line that creates a regex that would test for USA calls.  It begins like this:

exten => s,n,Set(usatest=^1?(201...

The question mark after the “1” means it’s optional. But what if the provider also accepts calls prefixed with *67 to block the Caller ID? You could allow for that possibility like this in most software that accepts regular expressions, but not in Asterisk…

exten => s,n,Set(usatest=^(*67)?1?(201...

The backslash would escape the * character, and therefore the string *67 would be considered optional. But in Asterisk, you have to enclose the * in square brackets to make this work, like so:

exten => s,n,Set(usatest=^([*]67)?1?(201...

Anyway, I just wanted to bring this to your attention, in case that you (like me) were thinking that Asterisk doesn’t interpret regular expressions. It DOES, but not in the same manner as Perl, nor FreeSWITCH for that matter. If anyone knows of an online reference or “cheat sheet” for this particular variety of regular expression library, I’d appreciate the link.

Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk

 

Notice
(May, 2018): FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware. The information in this article is VERY outdated and probably will not work.

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

If you have been less than thrilled with the Google Voice support in another software PBX, such as Asterisk or FreeSWITCH, you could try using YATE as a Google Voice Gateway.  It can be installed on either a separate server, or on the same server as your FreeSWITCH or Asterisk installation, however if you are running virtual machines then I recommend the separate server approach.  In fact, that may be the only way to do it with FreeSWITCH if you installed FreeSWITCH under Debian or Ubuntu, since the YATE install requires CentOS.  If you are a Linux expert you may be able to get around this, but don’t ask me how.

To install YATE, see this article from Nerd Vittles:

YATE in a Flash: Rolling Your Own SIP to Google Voice Gateway for Asterisk

EDIT: You may want to upgrade YATE to the latest version.

Just follow the instructions there, and the ones that you see after running the script to add a Google Voice user, and you should be fine, if you are using Asterisk.  The only things I would suggest that are not shown in those instructions are that you set your Trunk “Maximum Channels” to 2, because a Google Voice account will only permit two simultaneous channels of usage maximum, and that if YATE is on a separate server with a static IP address then I’d suggest adding permit/deny lines to the Asterisk Trunk PEER details to enhance security, like so:

permit=xx.xx.xx.xx/255.255.255.255
deny=0.0.0.0/0.0.0.0

Make sure the lines appear in that order, and replace xx.xx.xx.xx with the static IP address of the YATE server.  This may not help much because Asterisk is registering with the YATE server, but it can’t hurt either.

Also, you might want to consider changing the context statement to

context=from-pstn-e164-us

to remove the +1 from the start of the Caller ID number on incoming calls.

The instructions don’t tell you to add a Dialed Number Manipulation Rule to your trunk configuration, but if you want to allow ten digit calls from any of your endpoints then you should add one rule that prepends 1 to 10 digit calls:

1+NXXNXXXXXX (The 1 goes in the first field, the NXXNXXXXXX in the third field)

If you are using the CallerID Superfecta module, and you use “Trunk Provided” as one of your data source, then after adding a Google Voice account to YATE I suggest editing /usr/local/etc/yate/regexroute.conf on the YATE server. You may need to install an editor first. For example, to install nano and then edit the file:

yum install nano
nano /usr/local/etc/yate/regexroute.conf

Look for the [contexts] section and there you will see a line for each of your Google Voice accounts that looks like this:

${in_line}GV1234567890=;called=GV1234567890;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833

Just add ;callername to the end of each such line:

${in_line}GV1234567890=;called=GV1234567890;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833;callername

This will make sure that nothing is sent for a Caller ID name, so that Caller ID Superfecta will recognize that there is no “Trunk Provided” name and attempt to do a name lookup (note that you could also use ;callername=something to set the Caller ID name to a specific value). If you want to have ;callername
automatically appended whenever you create a new account, just use an editor to edit the script you use to add users, and find the line that looks like this (it should be near the bottom of the script):

${in_line}GV’$acctphone’=;called=GV’$acctphone’;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833

Add ;callername to the end of the line, like so:

${in_line}GV’$acctphone’=;called=GV’$acctphone’;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833;callername

Save the modified file, and any time you add a new user it will automatically write that line with ;callername appended.

Thanks to Bill Simon for telling me about this method of sending the blank Caller ID name. Alternately, if you don’t want to mess with the YATE configuration, you could add a new Caller ID Scheme in Caller ID Superfecta that is only used with your Google Voice DID’s and that doesn’t include “Trunk Provided” as a data source.

Whether you are connecting from Asterisk or FreeSWITCH, if YATE is running on a separate server and the other system can’t register with YATE, it may be a firewall issue on the YATE server.  After I did the install I found that iptables was configured to only allow incoming ssh connections.  I modified that rule to only allow incoming ssh from a particular IP address (the one I’d be coming in from) and then added rules to permit traffic from the two servers allowed to talk to that YATE server.

EDIT: Hopefully this will not affect you if you have upgraded YATE to the latest version, but if you have a moderate number of Google Voice accounts, you may experience another issue.  If you start seeing messages like this when you telnet to YATE and then use debug on to see what is happening:

<sip:MILD> Flood detected: 20 handled events

And if every so often, the server appears to go into a semi-catatonic state, where calls come in but they don’t go out (this happened to me at least twice before I figured out what was happening), then you may have this issue.  It occurs when you have the same Asterisk server using multiple trunks to connect to YATE.  It turns out that whenever you reload Asterisk (as you might after making a configuration change, for example the “orange bar reload” in one particular GUI), it resends all of the registrations at once, and gives them all a default timeout of 120 seconds, so they all attempt to re-register at the exact same intervals.  And if you have several trunks, there are a LOT of SIP packets sent.  Plus, with qualifyfreq value set to 240, that means that every other time the registrations are taking place, qualifies are also taking place at the same time.  It appears that this is sufficient to cause that warning to appear once in a while.

The method I found that seems to fix this may not be the best way (feel free to comment if you know a better way), but it’s one way to deal with it.  What you need to do is change the registration expiration on each individual trunk so they are not all the same.  In Asterisk this can be accomplished by adding both of these settings to the trunk configuration (susbtitute nn with some random number of seconds, say between 90 and 120, and make it the same for both settings in each trunk, but different for different trunks)

In the trunk PEER details, add:

defaultexpiry=nn

In the Register String, add  ~nn  to the end of the line, replacing nn with the same value used in the defaultexpiry setting, like so:
GV1234567890:password@exampleaddress.com:5060/1234567890~nn

You might also need to vary the qualifyfreq value a bit in each trunk, so that it’s a bit under the specified 240 seconds and different for each trunk.  If doing those things doesn’t fix the issue, and you still get the <sip:MILD> Flood detected: 20 handled events message frequently, that could mean you are being subjected to an actual SIP attack.  The YATE installation includes a script with the filename /usr/src/yate/share/scripts/banbrutes.php that can be used to deal with that issue, but it’s not enabled by default.  View the banbrutes.php script in a text editor, and you’ll find instructions at the beginning of the script.  Or, you could tighten up the iptables firewall to only allow traffic from systems that are supposed to be talking to your YATE server.

END OF EDIT.

As for FusionPBX, when you create a new Google Voice account on the YATE server using the provided add-yate-user script, at the end it will give you a bunch of configuration information for Asterisk.  These translate to FusionPBX Gateway settings as follows (showing what the script prints and the equivalent FusionPBX Gateway settings):

Trunk Name: YIAF1 ; or increment 1 if more than one (in FusionPBX I suggest you don’t use this; instead use the same setting as the Username for the Gateway name, particularly if you plan on having more than one Google Voice account)

host=x.x.x.x (Proxy in FusionPBX)
username=GV1234567890 (Username in FusionPBX)
secret=password (Password in FusionPBX)
type=peer (Not needed in FusionPBX)
port=5060 (Not needed in FusionPBX)
qualify=yes (Not needed in FusionPBX)
qualifyfreq=240 (Not needed in FusionPBX)
insecure=port,invite (Not needed in FusionPBX)
context=from-trunk (Not needed in FusionPBX)

Register String: … (Not needed in FusionPBX)

In FusionPBX, set Register to True and Enabled to True, and leave other Gateway settings at the defaults (EDIT: however, if you have several gateways to YATE, you might want to use the Expire seconds setting in FusionPBX to vary the registration timeouts a bit so that all your accounts aren’t trying to re-register at exactly the same time — see the longer EDIT section above for details).  Note that after you save the settings, it may take a few seconds for the state to change to REGED, so refresh the Gateways page after a bit and it should be okay if everything is configured properly and there are no firewall issues.

For your Inbound Route in FusionPBX, just use the Trunk Name/Username as the Destination Number (including the leading “GV“, which you can also use it in the Inbound Route name field if you like) and then choose the appropriate Action. When you first create the Inbound Route it will complain if you try to save a Destination Number that is not completely numeric, so just use any number and save the settings, then go back and edit the Destination Number field and also the Data field for the destination_number condition (which should be something like ^GV1234567890$, substituting your Google Voice number for the digits, of course).

For your Outbound Route, select your Google Voice trunk as the Gateway, and then select “11 digits long distance” from the dropdown in the “Dialplan Expression” setting. Save that, and if you only have one Google Voice trunk for all users on the system, that is all you need to do.  However, if you want to have multiple Google Voice trunks and have certain extensions only have access to certain trunks, the edit the Outbound Route you just created, and in the “Conditions and Actions” section at the bottom of the page, edit the last action on the page (the “bridge” action).  You want to change the Data field – it will contain something like sofia/gateway/GV1234567890/$1 and you want to change that to sofia/gateway/${accountcode}/$1 — save that change, and then when the Outbound Route page reappears, you may want to change the name to ${accountcode}.11d and add a Description like “Google Voice: Extension Account Code = Gateway Name” so you understand what the route is doing.  This single Outbound Route will handle all your Google Voice calls from all your extensions, if the Account Code setting for each Extension is set to the name of the Gateway for the Google Voice account you want that extension to use.

Note that if you are running PBX in a Flash, you can use the “Caller ID Superfecta” module to try to get a Caller ID name.  IF YATE itself has any ability to do Caller ID name lookups, someone will have to tell me how to enable and configure it, because at this point I would have no clue.  If you know, please leave a comment!

EDIT: To keep the YATE log file from growing too large over time, copy the file /usr/src/yate/packing/yate.logrotate into /etc/logrotate.d as “yate” (get rid of the .logrotate extension).  That file instructs the system logrotate job to roll the yate log file when it gets to 100 MB.  Thanks to Bill Simon for that tip!

EDIT 2: If you have ignored the advice given almost everywhere to create a new, separate Gmail account, and then use that account when you create your Google Voice account, then you have probably run into the issue of not receiving your incoming calls when you are logged into that Google account and for some time thereafter.  That problem, and one possible fix (along with the drawbacks) were discussed in a post in the thread “YATE in a Flash 1.2 Ready” on the PBX in a Flash Forum, which unfortunately disappeared from that site due to a server crash.  The post, originally by user Marian on Aug 6, 2012, read as follows:

Gmail sets a greater resource priority when you connect and don’t advertise unavailable for a while after you disconnect.
So, if you connect to GMail using the same account as yate the calls will be sent there until GMail advertise resource unavailable.
You can set priority=10 in accfile.conf, gmail account section.
But, if you do that you might not see your chat in GMail or another jabber client connected to GMail for the same account (like GTalk or Yate Client).
Unfortunately, the jabber protocol don’t allow setting different priorities for the same resource for different services (e.g. you can’t set a priority for chat and another one for another capatibility, like jingle calls).
I didn’t found a workaround for this situation: having, for the same account, a resource for chat and another one for jingle calls.
This would require a custom jabber client or a custom jabber server.

That, coupled with information from other posts around the web, means the best advice is to add a line of the form:

priority=127

in each of your Google Voice accounts in the file accfile.conf (in the /usr/local/etc/yate directory).

If you want that line to be added by default when you add a new Google Voice account to your YATE server, open the add-yate-user script (which is probably in your /root directory) in a text editor such as nano, and find this line:

echo “options=allowplainauth” >> accfile.conf

and underneath it add this:

echo “priority=127″ >> accfile.conf

Then save the edited file.  I make no guarantees that this will actually work, but it’s worth a try. NOTE: The thread mentioned above suggested setting the priority to 10, however, the Asterisk developers are now using 25. As this wiki page explains:

More about Priorities

As many different connections to Google are possible simultaneously via different client mechanisms, it is important to understand the role of priorities in the routing of inbound calls. Proper usage of the priority setting can allow use of a Google account that is not otherwise entirely dedicated to voice services.

With priorities, the higher the setting value, the more any client using that value is preferred as a destination for inbound calls, in deference to any other client with a lower priority value. Known values of commonly used clients include the Gmail chat client, which maintains a priority of 20, and the Windows GTalk client, which uses a priority of 24. The maximum allowable value is 127. Thus, setting one’s priority option for the XMPP peer in res_xmpp.conf to a value higher than 24 will cause inbound calls to flow to Asterisk, even while one is logged into either Gmail or the Windows GTalk client.

Outbound calls are unaffected by the priority setting.

This would be true in Asterisk OR YATE, therefore the recommendation is to now use at least 25 as the priority value, up to the maximum of 127 as suggested above.

Two things I wish you could do in Asterisk or FreePBX, or ANY free software PBX

 

Important
This is a heavily edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

I want to explain a problem that apparently exists in current implementations of Asterisk and FreePBX (and by extension, all distributions based on those pieces of software).

Let’s say you have several extensions on your system and many, if not all of them, have a specific “trunk” associated with that extension.  It may be a provider account or a Google Voice account that’s used exclusively by that extension.  Routing INCOMING calls is usually not difficult at all, you simply use the trunk’s DID in an Inbound Route and then route the calls from that DID directly to the desired extension.  However, OUTBOUND is another matter.  You have to create an Outbound Route, and in that route you have to put your dial patterns and use the /extension suffix. It can still be difficult to set up the dial patterns the way you need them.  In 2.8 and later it is much harder because of the individual boxes for each segment of each pattern.

Let’s say you want certain extensions to only be able to call numbers in U.S. area codes, but each of those extensions has its own trunk. And let’s say your extensions are numbered 1000 through 1099. Oh, and you want to support both 10 and 11 digit dialing. So in your outbound route for extension 1000, you might have a list of patterns like this (please scroll down to the end of this long list — it’s only about 600 lines!):

1201NXXXXXX/1000
1202NXXXXXX/1000
1203NXXXXXX/1000
1205NXXXXXX/1000
1206NXXXXXX/1000
1207NXXXXXX/1000
1208NXXXXXX/1000
1209NXXXXXX/1000
1210NXXXXXX/1000
1212NXXXXXX/1000
1213NXXXXXX/1000
1214NXXXXXX/1000
1215NXXXXXX/1000
1216NXXXXXX/1000
1217NXXXXXX/1000
1218NXXXXXX/1000
1219NXXXXXX/1000
1224NXXXXXX/1000
1225NXXXXXX/1000
1228NXXXXXX/1000
1229NXXXXXX/1000
1231NXXXXXX/1000
1234NXXXXXX/1000
1239NXXXXXX/1000
1240NXXXXXX/1000
1248NXXXXXX/1000
1251NXXXXXX/1000
1252NXXXXXX/1000
1253NXXXXXX/1000
1254NXXXXXX/1000
1256NXXXXXX/1000
1260NXXXXXX/1000
1262NXXXXXX/1000
1267NXXXXXX/1000
1269NXXXXXX/1000
1270NXXXXXX/1000
1274NXXXXXX/1000
1276NXXXXXX/1000
1281NXXXXXX/1000
1301NXXXXXX/1000
1302NXXXXXX/1000
1303NXXXXXX/1000
1304NXXXXXX/1000
1305NXXXXXX/1000
1307NXXXXXX/1000
1308NXXXXXX/1000
1309NXXXXXX/1000
1310NXXXXXX/1000
1312NXXXXXX/1000
1313NXXXXXX/1000
1314NXXXXXX/1000
1315NXXXXXX/1000
1316NXXXXXX/1000
1317NXXXXXX/1000
1318NXXXXXX/1000
1319NXXXXXX/1000
1320NXXXXXX/1000
1321NXXXXXX/1000
1323NXXXXXX/1000
1325NXXXXXX/1000
1327NXXXXXX/1000
1330NXXXXXX/1000
1331NXXXXXX/1000
1334NXXXXXX/1000
1336NXXXXXX/1000
1337NXXXXXX/1000
1339NXXXXXX/1000
1347NXXXXXX/1000
1351NXXXXXX/1000
1352NXXXXXX/1000
1360NXXXXXX/1000
1361NXXXXXX/1000
1364NXXXXXX/1000
1385NXXXXXX/1000
1386NXXXXXX/1000
1401NXXXXXX/1000
1402NXXXXXX/1000
1404NXXXXXX/1000
1405NXXXXXX/1000
1406NXXXXXX/1000
1407NXXXXXX/1000
1408NXXXXXX/1000
1409NXXXXXX/1000
1410NXXXXXX/1000
1412NXXXXXX/1000
1413NXXXXXX/1000
1414NXXXXXX/1000
1415NXXXXXX/1000
1417NXXXXXX/1000
1419NXXXXXX/1000
1423NXXXXXX/1000
1424NXXXXXX/1000
1425NXXXXXX/1000
1430NXXXXXX/1000
1432NXXXXXX/1000
1434NXXXXXX/1000
1435NXXXXXX/1000
1440NXXXXXX/1000
1442NXXXXXX/1000
1443NXXXXXX/1000
1458NXXXXXX/1000
1469NXXXXXX/1000
1470NXXXXXX/1000
1475NXXXXXX/1000
1478NXXXXXX/1000
1479NXXXXXX/1000
1480NXXXXXX/1000
1484NXXXXXX/1000
1501NXXXXXX/1000
1502NXXXXXX/1000
1503NXXXXXX/1000
1504NXXXXXX/1000
1505NXXXXXX/1000
1507NXXXXXX/1000
1508NXXXXXX/1000
1509NXXXXXX/1000
1510NXXXXXX/1000
1512NXXXXXX/1000
1513NXXXXXX/1000
1515NXXXXXX/1000
1516NXXXXXX/1000
1517NXXXXXX/1000
1518NXXXXXX/1000
1520NXXXXXX/1000
1530NXXXXXX/1000
1534NXXXXXX/1000
1539NXXXXXX/1000
1540NXXXXXX/1000
1541NXXXXXX/1000
1551NXXXXXX/1000
1559NXXXXXX/1000
1561NXXXXXX/1000
1562NXXXXXX/1000
1563NXXXXXX/1000
1567NXXXXXX/1000
1570NXXXXXX/1000
1571NXXXXXX/1000
1573NXXXXXX/1000
1574NXXXXXX/1000
1575NXXXXXX/1000
1580NXXXXXX/1000
1585NXXXXXX/1000
1586NXXXXXX/1000
1601NXXXXXX/1000
1602NXXXXXX/1000
1603NXXXXXX/1000
1605NXXXXXX/1000
1606NXXXXXX/1000
1607NXXXXXX/1000
1608NXXXXXX/1000
1609NXXXXXX/1000
1610NXXXXXX/1000
1612NXXXXXX/1000
1614NXXXXXX/1000
1615NXXXXXX/1000
1616NXXXXXX/1000
1617NXXXXXX/1000
1618NXXXXXX/1000
1619NXXXXXX/1000
1620NXXXXXX/1000
1623NXXXXXX/1000
1626NXXXXXX/1000
1630NXXXXXX/1000
1631NXXXXXX/1000
1636NXXXXXX/1000
1641NXXXXXX/1000
1646NXXXXXX/1000
1650NXXXXXX/1000
1651NXXXXXX/1000
1657NXXXXXX/1000
1660NXXXXXX/1000
1661NXXXXXX/1000
1662NXXXXXX/1000
1667NXXXXXX/1000
1669NXXXXXX/1000
1678NXXXXXX/1000
1681NXXXXXX/1000
1682NXXXXXX/1000
1701NXXXXXX/1000
1702NXXXXXX/1000
1703NXXXXXX/1000
1704NXXXXXX/1000
1706NXXXXXX/1000
1707NXXXXXX/1000
1708NXXXXXX/1000
1712NXXXXXX/1000
1713NXXXXXX/1000
1714NXXXXXX/1000
1715NXXXXXX/1000
1716NXXXXXX/1000
1717NXXXXXX/1000
1718NXXXXXX/1000
1719NXXXXXX/1000
1720NXXXXXX/1000
1724NXXXXXX/1000
1727NXXXXXX/1000
1731NXXXXXX/1000
1732NXXXXXX/1000
1734NXXXXXX/1000
1737NXXXXXX/1000
1740NXXXXXX/1000
1747NXXXXXX/1000
1754NXXXXXX/1000
1757NXXXXXX/1000
1760NXXXXXX/1000
1762NXXXXXX/1000
1763NXXXXXX/1000
1765NXXXXXX/1000
1769NXXXXXX/1000
1770NXXXXXX/1000
1772NXXXXXX/1000
1773NXXXXXX/1000
1774NXXXXXX/1000
1775NXXXXXX/1000
1779NXXXXXX/1000
1781NXXXXXX/1000
1785NXXXXXX/1000
1786NXXXXXX/1000
1801NXXXXXX/1000
1802NXXXXXX/1000
1803NXXXXXX/1000
1804NXXXXXX/1000
1805NXXXXXX/1000
1806NXXXXXX/1000
1808NXXXXXX/1000
1810NXXXXXX/1000
1812NXXXXXX/1000
1813NXXXXXX/1000
1814NXXXXXX/1000
1815NXXXXXX/1000
1816NXXXXXX/1000
1817NXXXXXX/1000
1818NXXXXXX/1000
1828NXXXXXX/1000
1830NXXXXXX/1000
1831NXXXXXX/1000
1832NXXXXXX/1000
1843NXXXXXX/1000
1845NXXXXXX/1000
1847NXXXXXX/1000
1848NXXXXXX/1000
1850NXXXXXX/1000
1856NXXXXXX/1000
1857NXXXXXX/1000
1858NXXXXXX/1000
1859NXXXXXX/1000
1860NXXXXXX/1000
1862NXXXXXX/1000
1863NXXXXXX/1000
1864NXXXXXX/1000
1865NXXXXXX/1000
1870NXXXXXX/1000
1872NXXXXXX/1000
1878NXXXXXX/1000
1901NXXXXXX/1000
1903NXXXXXX/1000
1904NXXXXXX/1000
1906NXXXXXX/1000
1907NXXXXXX/1000
1908NXXXXXX/1000
1909NXXXXXX/1000
1910NXXXXXX/1000
1912NXXXXXX/1000
1913NXXXXXX/1000
1914NXXXXXX/1000
1915NXXXXXX/1000
1916NXXXXXX/1000
1917NXXXXXX/1000
1918NXXXXXX/1000
1919NXXXXXX/1000
1920NXXXXXX/1000
1925NXXXXXX/1000
1928NXXXXXX/1000
1929NXXXXXX/1000
1931NXXXXXX/1000
1936NXXXXXX/1000
1937NXXXXXX/1000
1938NXXXXXX/1000
1940NXXXXXX/1000
1941NXXXXXX/1000
1947NXXXXXX/1000
1949NXXXXXX/1000
1951NXXXXXX/1000
1952NXXXXXX/1000
1954NXXXXXX/1000
1956NXXXXXX/1000
1970NXXXXXX/1000
1971NXXXXXX/1000
1972NXXXXXX/1000
1973NXXXXXX/1000
1978NXXXXXX/1000
1979NXXXXXX/1000
1980NXXXXXX/1000
1984NXXXXXX/1000
1985NXXXXXX/1000
1989NXXXXXX/1000
201NXXXXXX/1000
202NXXXXXX/1000
203NXXXXXX/1000
205NXXXXXX/1000
206NXXXXXX/1000
207NXXXXXX/1000
208NXXXXXX/1000
209NXXXXXX/1000
210NXXXXXX/1000
212NXXXXXX/1000
213NXXXXXX/1000
214NXXXXXX/1000
215NXXXXXX/1000
216NXXXXXX/1000
217NXXXXXX/1000
218NXXXXXX/1000
219NXXXXXX/1000
224NXXXXXX/1000
225NXXXXXX/1000
228NXXXXXX/1000
229NXXXXXX/1000
231NXXXXXX/1000
234NXXXXXX/1000
239NXXXXXX/1000
240NXXXXXX/1000
248NXXXXXX/1000
251NXXXXXX/1000
252NXXXXXX/1000
253NXXXXXX/1000
254NXXXXXX/1000
256NXXXXXX/1000
260NXXXXXX/1000
262NXXXXXX/1000
267NXXXXXX/1000
269NXXXXXX/1000
270NXXXXXX/1000
274NXXXXXX/1000
276NXXXXXX/1000
281NXXXXXX/1000
301NXXXXXX/1000
302NXXXXXX/1000
303NXXXXXX/1000
304NXXXXXX/1000
305NXXXXXX/1000
307NXXXXXX/1000
308NXXXXXX/1000
309NXXXXXX/1000
310NXXXXXX/1000
312NXXXXXX/1000
313NXXXXXX/1000
314NXXXXXX/1000
315NXXXXXX/1000
316NXXXXXX/1000
317NXXXXXX/1000
318NXXXXXX/1000
319NXXXXXX/1000
320NXXXXXX/1000
321NXXXXXX/1000
323NXXXXXX/1000
325NXXXXXX/1000
327NXXXXXX/1000
330NXXXXXX/1000
331NXXXXXX/1000
334NXXXXXX/1000
336NXXXXXX/1000
337NXXXXXX/1000
339NXXXXXX/1000
347NXXXXXX/1000
351NXXXXXX/1000
352NXXXXXX/1000
360NXXXXXX/1000
361NXXXXXX/1000
364NXXXXXX/1000
385NXXXXXX/1000
386NXXXXXX/1000
401NXXXXXX/1000
402NXXXXXX/1000
404NXXXXXX/1000
405NXXXXXX/1000
406NXXXXXX/1000
407NXXXXXX/1000
408NXXXXXX/1000
409NXXXXXX/1000
410NXXXXXX/1000
412NXXXXXX/1000
413NXXXXXX/1000
414NXXXXXX/1000
415NXXXXXX/1000
417NXXXXXX/1000
419NXXXXXX/1000
423NXXXXXX/1000
424NXXXXXX/1000
425NXXXXXX/1000
430NXXXXXX/1000
432NXXXXXX/1000
434NXXXXXX/1000
435NXXXXXX/1000
440NXXXXXX/1000
442NXXXXXX/1000
443NXXXXXX/1000
458NXXXXXX/1000
469NXXXXXX/1000
470NXXXXXX/1000
475NXXXXXX/1000
478NXXXXXX/1000
479NXXXXXX/1000
480NXXXXXX/1000
484NXXXXXX/1000
501NXXXXXX/1000
502NXXXXXX/1000
503NXXXXXX/1000
504NXXXXXX/1000
505NXXXXXX/1000
507NXXXXXX/1000
508NXXXXXX/1000
509NXXXXXX/1000
510NXXXXXX/1000
512NXXXXXX/1000
513NXXXXXX/1000
515NXXXXXX/1000
516NXXXXXX/1000
517NXXXXXX/1000
518NXXXXXX/1000
520NXXXXXX/1000
530NXXXXXX/1000
534NXXXXXX/1000
539NXXXXXX/1000
540NXXXXXX/1000
541NXXXXXX/1000
551NXXXXXX/1000
559NXXXXXX/1000
561NXXXXXX/1000
562NXXXXXX/1000
563NXXXXXX/1000
567NXXXXXX/1000
570NXXXXXX/1000
571NXXXXXX/1000
573NXXXXXX/1000
574NXXXXXX/1000
575NXXXXXX/1000
580NXXXXXX/1000
585NXXXXXX/1000
586NXXXXXX/1000
601NXXXXXX/1000
602NXXXXXX/1000
603NXXXXXX/1000
605NXXXXXX/1000
606NXXXXXX/1000
607NXXXXXX/1000
608NXXXXXX/1000
609NXXXXXX/1000
610NXXXXXX/1000
612NXXXXXX/1000
614NXXXXXX/1000
615NXXXXXX/1000
616NXXXXXX/1000
617NXXXXXX/1000
618NXXXXXX/1000
619NXXXXXX/1000
620NXXXXXX/1000
623NXXXXXX/1000
626NXXXXXX/1000
630NXXXXXX/1000
631NXXXXXX/1000
636NXXXXXX/1000
641NXXXXXX/1000
646NXXXXXX/1000
650NXXXXXX/1000
651NXXXXXX/1000
657NXXXXXX/1000
660NXXXXXX/1000
661NXXXXXX/1000
662NXXXXXX/1000
667NXXXXXX/1000
669NXXXXXX/1000
678NXXXXXX/1000
681NXXXXXX/1000
682NXXXXXX/1000
701NXXXXXX/1000
702NXXXXXX/1000
703NXXXXXX/1000
704NXXXXXX/1000
706NXXXXXX/1000
707NXXXXXX/1000
708NXXXXXX/1000
712NXXXXXX/1000
713NXXXXXX/1000
714NXXXXXX/1000
715NXXXXXX/1000
716NXXXXXX/1000
717NXXXXXX/1000
718NXXXXXX/1000
719NXXXXXX/1000
720NXXXXXX/1000
724NXXXXXX/1000
727NXXXXXX/1000
731NXXXXXX/1000
732NXXXXXX/1000
734NXXXXXX/1000
737NXXXXXX/1000
740NXXXXXX/1000
747NXXXXXX/1000
754NXXXXXX/1000
757NXXXXXX/1000
760NXXXXXX/1000
762NXXXXXX/1000
763NXXXXXX/1000
765NXXXXXX/1000
769NXXXXXX/1000
770NXXXXXX/1000
772NXXXXXX/1000
773NXXXXXX/1000
774NXXXXXX/1000
775NXXXXXX/1000
779NXXXXXX/1000
781NXXXXXX/1000
785NXXXXXX/1000
786NXXXXXX/1000
801NXXXXXX/1000
802NXXXXXX/1000
803NXXXXXX/1000
804NXXXXXX/1000
805NXXXXXX/1000
806NXXXXXX/1000
808NXXXXXX/1000
810NXXXXXX/1000
812NXXXXXX/1000
813NXXXXXX/1000
814NXXXXXX/1000
815NXXXXXX/1000
816NXXXXXX/1000
817NXXXXXX/1000
818NXXXXXX/1000
828NXXXXXX/1000
830NXXXXXX/1000
831NXXXXXX/1000
832NXXXXXX/1000
843NXXXXXX/1000
845NXXXXXX/1000
847NXXXXXX/1000
848NXXXXXX/1000
850NXXXXXX/1000
856NXXXXXX/1000
857NXXXXXX/1000
858NXXXXXX/1000
859NXXXXXX/1000
860NXXXXXX/1000
862NXXXXXX/1000
863NXXXXXX/1000
864NXXXXXX/1000
865NXXXXXX/1000
870NXXXXXX/1000
872NXXXXXX/1000
878NXXXXXX/1000
901NXXXXXX/1000
903NXXXXXX/1000
904NXXXXXX/1000
906NXXXXXX/1000
907NXXXXXX/1000
908NXXXXXX/1000
909NXXXXXX/1000
910NXXXXXX/1000
912NXXXXXX/1000
913NXXXXXX/1000
914NXXXXXX/1000
915NXXXXXX/1000
916NXXXXXX/1000
917NXXXXXX/1000
918NXXXXXX/1000
919NXXXXXX/1000
920NXXXXXX/1000
925NXXXXXX/1000
928NXXXXXX/1000
929NXXXXXX/1000
931NXXXXXX/1000
936NXXXXXX/1000
937NXXXXXX/1000
938NXXXXXX/1000
940NXXXXXX/1000
941NXXXXXX/1000
947NXXXXXX/1000
949NXXXXXX/1000
951NXXXXXX/1000
952NXXXXXX/1000
954NXXXXXX/1000
956NXXXXXX/1000
970NXXXXXX/1000
971NXXXXXX/1000
972NXXXXXX/1000
973NXXXXXX/1000
978NXXXXXX/1000
979NXXXXXX/1000
980NXXXXXX/1000
984NXXXXXX/1000
985NXXXXXX/1000
989NXXXXXX/1000

(Note the above does not include the “toll free” area codes nor Canadian area codes; I have separate routes for those).

Now THAT is bad enough, but then imagine having to duplicate this list for each of your extensions (changing only the extension number after the / character), because each will need its own outbound route in order to select its own trunk. In pre-2.8 versions of Asterisk, you could simply copy this list into a text editor, do a search and replace on the /1000 (replacing it with the next extension number), and paste the changed list into a new outbound route. However, with the new way of entering dial plans, you have to enter each line in each field manually, OR (in 2.9 and later) mess with .CSV files, which although easier than manual entry are still a lot harder to deal with than simple cut-and-paste.

But that is actually not the subject of this article; it just sets the stage for what I’m thinking SHOULD be part of Asterisk (or any other soft PBX that requires entering patterns in a similar manner, that is, one line for each pattern). There are actually TWO ways this could be handled, but neither will work at present, as far as I know.

1) Stacking Routes

Let’s suppose you had an outbound route that had all the USA patterns, but did NOT include the extension field. You could have it near the top of your Outbound Route list. And let’s say that you could make the destination of that trunk another “group” of outbound routes rather than a trunk. In that second group, you could have routes with just two patterns per extension:

1XXXXXXXXXX/1000
XXXXXXXXXX/1000

So the call would be effectively pre-screened in the first (primary) group of outbound routes, then sent to the second group (NOT part of the primary group) which would route by extension. That way, you’d only need ONE route with a list of USA patterns, one route with a list of Canada patterns, one route with a list of “toll free” patterns, etc. Each could go directly to a trunk, or to a secondary group of outbound routes.

I think Asterisk might actually be capable of doing something like this (though I’m uncertain of that), but FreePBX definitely is not. So some FreePBX users literally have THOUSANDS of lines of dial patterns in their configuration. Does this slow things down? You betcha, at least when making a configuration change! It takes forever for that darn frog to stop eating flies (if a real frog ate that many flies in that short a time, its gut would probably explode!).

2) Macros

Now here we have a solution that would likely need to be implemented in Asterisk itself. The basic idea is to allow macros in dial patterns. For example, you create a list such as the one above (but without the /extension field – just the number patterns only) and call it [pattern-USA]. Then in your outbound routes, you do something like this:

[pattern-USA]/1000

Changing the extension as needed for each Outbound Route. As noted, this would require implementing this type of macro feature in Asterisk, but it would also necessitate a way to turn off the syntax checking in FreePBX, which is currently impossible.

EDIT: For another way to handle this that probably will work, see How to use the FreePBX [macro-dialout-trunk-predial-hook] macro and regular expressions to blacklist or whitelist outgoing calls on all trunks.

Link: FreePBX: Inbound number not working help [might also be useful for other SIP-based PBX administrators]

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This may be of some help to those of you still using “that” software, that are having problems getting a new DID (inbound number) to work.  Note this tip might be equally useful for all Asterisk users, or even for administrators of other SIP-based PBX software.

FreePBX: Inbound number not working help (sysadminnet)

Related article

PHP Bug can cause FreePBX Inbound Routes and Asterisk Phonebook entries to not work as expected

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

It appears there is a nasty bug in certain versions of PHP (almost certainly in version 5.3.3, and perhaps other versions as well) that can cause SOME inbound and outbound routes in FreePBX to be ignored.  Add this to the list of difficulties to plague some FreePBX users, but for once it’s not something the FreePBX developers did.

The symptom appears to be that you have an inbound route with a DID that starts with the number “2”, or an Asterisk Phonebook entry that starts with a “2”, but it doesn’t work as expected or gets changed to a negative number.  Not all patterns starting with “2” appear to be affected, but ten digit numbers in certain area codes (such as 248 here in Michigan) definitely are.  In the case of inbound routes, it appears that the numbers get stored in the MySQL database correctly, but when they get written out to extensions_additional.conf (the dialplan file that F—PBX generates for Asterisk to use) they get transformed into negative numbers.  Therefore, when a call comes in on that DID, Asterisk doesn’t recognize it and the call gets dropped (or if you accept calls for any DID then it’s handled as such a call, but a warning message is posted to the CLI and the log file).

For a discussion of this issue, see these threads in the PBX in a Flash forum:

Inbound DID routing (only catchall works)
(240) area code in Asterisk Phonebook

Just wanted to alert you to this in case you happen to have the buggy PHP version and things just aren’t working as they should be. The best fix is probably to upgrade PHP to a later version but that can cause other issues, or you may encounter unmet dependencies when trying to upgrade (in fact, if you come across a foolproof way to upgrade PHP on Centos, please let us know). If you are using PBX in a Flash, they’re aware of the issue and one would hope they’ll have a fix real soon now. If you are using any other FreePBX-based distro then you will have to bug the distributors of that distro for a fix. If you rolled your own, then good luck to you in upgrading PHP!

I no longer recommend using Asterisk’s Google Voice support — try these methods instead!

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

EDIT (May, 2018): FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

This article was originally written in January of 2012, and has been heavily edited in an attempt to update it a bit.

Not that anyone probably cares what I think, but anyone who regularly reads this blog (or any of the other VoIP-related blog that cover Asterisk) may have noticed that prior to the release of Asterisk 11, Asterisk’s support for Google Voice had become less and less reliable over time, particularly for incoming calls. You have to do all sorts of “tricks” to make it work, and these usually involve adding delays that don’t always fix the problem, inconvenience your callers, and possibly cause more hangups as people get tired of waiting for you to answer the phone.

Therefore, I suggest that if you are using a version of Asterisk earlier than Asterisk 11, you stop using Asterisk’s Google Voice support completely. Assuming that you feel you must keep using an older version of Asterisk, I suggest trying one or more of the following:

  1. Use YATE as a gateway between Asterisk and Google Voice. See Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk, this article and this forum thread on YATE in a Flash, and this thread on YATE Tips & Tricks). YATE is what powers Bill Simon’s gateway (mentioned below). See comments by Bill and pianoquintet under this article.
  2. Use Bill Simon’s Google Voice-SIP gateway to handle your Google Voice calls. Some people may not want to rely on an external service for this, while others may very much appreciate having the option. I mention it for those in the latter group. For more information see Bill Simon’s Free SIP-to-XMPP Gateway Easily Puts Google Voice on Your VoIP Phone (Voxilla). While the linked articles talk about using the gateway with a SIP device, it can be used as an Asterisk trunk.  EDIT: As of April 7, 2015 the Google Voice Gateway has been relaunched and there is now a one-time fee to sign up.
  3. If your only issue is with incoming calls, you could use a DID to bring the calls into your system.  But keep in mind that Google Voice does not like it when calls are answered the moment they connect, so in your FreePBX Inbound Route be sure to set the “Pause Before Answer” option to at least 1.  I have found that a 1 second pause is sufficient, but I’m not saying that is the correct value for everyone, or even that everyone will need to include such a pause (some DID providers may delay the call sufficiently before connecting through to your system that the pause isn’t needed).

At this point, any of those would likely produce better results than using the Google Voice support in any version of Asterisk prior to Asterisk 11.

EVERYTHING in this article is my personal opinion.  Nothing here should be taken as a statement of fact.

EDIT:  Ward Mundy reports that he just may have found a workaround for the incoming calls issue — see this thread in the PBX in a Flash forum.

How to install the BIND DNS Server using Webmin, so Asterisk extensions (hopefully) will work even when your Internet connection fails

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

If you run Asterisk you may have encountered this issue: Your Internet connection goes down, and so does your ability to call from extension to extension, even between extensions on your local network. This is a long-standing bug in Asterisk (exactly the sort of bug that drives people to try alternatives such as FreeSWITCH) but let’s say that for whatever reason you need to stick with Asterisk, so you’d like to find a way to make that bug go away.  Without going into all the technical details, the reason that calls fail is that Asterisk can’t access a DNS server.  I’ve read several reports that say the easiest solution is to install the BIND DNS server  on the same machine as your Asterisk server.  If you are also running Webmin on the server, installing and configuring BIND is a relative piece of cake.  So here’s how it’s done.  Please note that most of the images below can be enlarged by clicking on them, and that I have installed the StressFree theme in Webmin, so if it looks a little different from what you’re used to seeing, that’s probably why.

To start with, log into Webmin, click on “Servers”, then click on “BIND DNS Server” (if you don’t find it there, try looking in “Un-used Modules”):

Webmin Servers page — click on "BIND DNS Server"

Assuming you have not previously installed BIND, you’ll get a screen like this.  Just click where it says “Click here”:

Webmin BIND DNS Server error page — click where it says "Click here"

You will then see this screen come up as BIND is installed. Just let it run to completion and (assuming it installs successfully) click on “Return to BIND DNS Server” at the bottom of the page:

Webmin "Install Package" page — click on "Return to BIND DNS Server"

Next, because you don’t yet have an /etc/named.conf file, you’ll see this page.  Click the button for “Setup nameserver for internal non-internet use only” (don’t worry, we’ll fix it in the next steps), then click the bar that says “Create Primary Configuration File and Start Nameserver”:

Webmin — click "Setup nameserver for internal non-internet use only"

At this point BIND is installed and running, but it probably isn’t doing what you want it to, and your system isn’t using it. So the first thing we need to do is tell it where to go when it needs to do a DNS lookup. You should be seeing a page that looks like this — click on “Forwarding and Transfers”:

Webmin BIND DNS Server page — click on "Forwarding and Transfers"

When you get to the following screen, check “Yes” next to “Lookup directly if forwarders cannot?”  You also need to enter one or more addresses of DNS servers that BIND can access when it needs to pull a DNS record.  You might want to give some thought to which DNS servers you want to use, and in what order, before you start entering them. You can enter up to three IP addresses of DNS servers, and then click “Save”. This will throw you out to the previous screen, and if by some chance you want to enter even more DNS servers, you can click on “Forwarding and Transfers” again to come back and enter up to three more servers, until you are finished.  In this example, I have already entered the IP addresses of my router’s DNS Server as the top priority pick,  followed by two Google DNS Server addresses.

Webmin — BIND DNS Server — Forwarding and Transfers page

Once you have done this, you are through configuring BIND directly, but there are two more things we need to do. The first is to make sure that the BIND server starts each time we restart the machine. To do that, go to Webmin’s “System” page and then click on “Bootup and Shutdown”:

Webmin System page — click on "Bootup and Shutdown"

This is a long page so I’m not showing all of it — what you have to do is find the entry for named and check the box next to it:

Webmin Bootup and Shutdown page — check the box next to "named"

Then go to the bottom of the page and click “Start on Boot”:

Bottom of Webmin Bootup and Shutdown page — click "Start on Boot"

At this point BIND is running, and should be using the correct DNS servers, and is set to start at bootup, but your server still isn’t using it for its DNS queries. To get it to do that, go to Webmin’s “Networking” page and click on “Network Configuration”:

Webmin Networking page — click on "Network Configuration"

Once on the Network Configuration page, click on “Hostname and DNS Client”:

Webmin Network Configuration page — click on "Hostname and DNS Client"

Once on the Hostname and DNS Client page, what you need to do is make the first entry in the DNS Servers list 127.0.0.1. If you trust BIND to always be operating, that’s the only entry you need. I didn’t quite trust BIND that much (actually, what I didn’t trust was my ability to set this up correctly) so I set the DNS server in the router as the secondary DNS address. You could use any DNS server as the secondary, or you could choose to just enter the 127.0.0.1 address to use BIND and let it go at that. Personally, I feel a lot more comfortable having a “fallback” DNS. Don’t forget to click “Save” when you are finished making changes here:

Webmin Hostname and DNS Client page - 127.0.0.1 must be first DNS server

That’s all there is to it, as far as I know (if you think I’ve missed anything or done something wrong, the comment section is open!). If you’re like me, the next question you will have is, “How do I know it’s working?” And the easiest way to do that is to go to a Linux command prompt and “dig” some site you have not been to recently twice in a row. Here’s an example, using cnn.com — the part we are interested in is in red:

dig cnn.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> cnn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8274
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 9

;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                287     IN      A       157.166.224.25
cnn.com.                287     IN      A       157.166.224.26
cnn.com.                287     IN      A       157.166.226.25
cnn.com.                287     IN      A       157.166.226.26
cnn.com.                287     IN      A       157.166.255.18
cnn.com.                287     IN      A       157.166.255.19

;; AUTHORITY SECTION:
.                       76691   IN      NS      i.root-servers.net.
.                       76691   IN      NS      j.root-servers.net.
.                       76691   IN      NS      k.root-servers.net.
.                       76691   IN      NS      l.root-servers.net.
.                       76691   IN      NS      m.root-servers.net.
.                       76691   IN      NS      a.root-servers.net.
.                       76691   IN      NS      b.root-servers.net.
.                       76691   IN      NS      c.root-servers.net.
.                       76691   IN      NS      d.root-servers.net.
.                       76691   IN      NS      e.root-servers.net.
.                       76691   IN      NS      f.root-servers.net.
.                       76691   IN      NS      g.root-servers.net.
.                       76691   IN      NS      h.root-servers.net.

;; ADDITIONAL SECTION:
b.root-servers.net.     386178  IN      A       192.228.79.201
d.root-servers.net.     402826  IN      A       128.8.10.90
d.root-servers.net.     230000  IN      AAAA    2001:500:2d::d
f.root-servers.net.     370827  IN      A       192.5.5.241
g.root-servers.net.     463754  IN      A       192.112.36.4
h.root-servers.net.     374116  IN      A       128.63.2.53
h.root-servers.net.     517382  IN      AAAA    2001:500:1::803f:235
j.root-servers.net.     185528  IN      A       192.58.128.30
j.root-servers.net.     578747  IN      AAAA    2001:503:c27::2:30

;; Query time: 26 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 12:45:41 2011
;; MSG SIZE  rcvd: 512

# dig cnn.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> cnn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8277
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 9

;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                223     IN      A       157.166.255.19
cnn.com.                223     IN      A       157.166.224.25
cnn.com.                223     IN      A       157.166.224.26
cnn.com.                223     IN      A       157.166.226.25
cnn.com.                223     IN      A       157.166.226.26
cnn.com.                223     IN      A       157.166.255.18

;; AUTHORITY SECTION:
.                       76627   IN      NS      c.root-servers.net.
.                       76627   IN      NS      d.root-servers.net.
.                       76627   IN      NS      e.root-servers.net.
.                       76627   IN      NS      f.root-servers.net.
.                       76627   IN      NS      g.root-servers.net.
.                       76627   IN      NS      h.root-servers.net.
.                       76627   IN      NS      i.root-servers.net.
.                       76627   IN      NS      j.root-servers.net.
.                       76627   IN      NS      k.root-servers.net.
.                       76627   IN      NS      l.root-servers.net.
.                       76627   IN      NS      m.root-servers.net.
.                       76627   IN      NS      a.root-servers.net.
.                       76627   IN      NS      b.root-servers.net.

;; ADDITIONAL SECTION:
b.root-servers.net.     386114  IN      A       192.228.79.201
d.root-servers.net.     402762  IN      A       128.8.10.90
d.root-servers.net.     229936  IN      AAAA    2001:500:2d::d
f.root-servers.net.     370763  IN      A       192.5.5.241
g.root-servers.net.     463690  IN      A       192.112.36.4
h.root-servers.net.     374052  IN      A       128.63.2.53
h.root-servers.net.     517318  IN      AAAA    2001:500:1::803f:235
j.root-servers.net.     185464  IN      A       192.58.128.30
j.root-servers.net.     578683  IN      AAAA    2001:503:c27::2:30

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 12:46:45 2011
;; MSG SIZE  rcvd: 512

Notice how on the first run, it takes 26 msec to do the lookup, because BIND doesn’t have that address cached yet, whereas on the second run it only takes 1 msec to do the lookup!  Could that perhaps improve system performance?  I’ll bet it could! And the SERVER line tells us that it is indeed using our BIND server (127.0.0.1) – if it were using, say, our router’s DNS server then that line would show this:

;; SERVER: 192.168.0.1#53(192.168.0.1)

The idea here is that when your Internet connection takes a dive, Asterisk will still be finding a working DNS server and therefore won’t tank.  That, at least, is the theory I’ve seen on several web sites.  The ONLY thing I am showing here is how to set up BIND using Webmin, and I won’t even guarantee that I’m doing that 100% correctly.  I definitely do not guarantee that it will actually work as intended — you’ll have to test that yourself.  Doing a real test would mean disconnecting your cable or DSL modem, etc. from your router for several hours or days to see if the phones continue to work, and in most households or businesses that idea will go over like a lead balloon.  However, feel free to give it a good test if you like and report the results in the comments.

You may wonder why I selected “Setup nameserver for internal non-internet use only” in the fourth screenshot.  Obviously, that description is not entirely accurate.  The real difference is that if you select that instead of the default “Setup as an internet name server, and download root server information”, it won’t create a “root” DNS zone, which you simply don’t need for this application.  You can use the other option if you want to, but it will download additional information and increase the complexity of your setup.  Either way, you should be able to access the Internet, because we set up DNS forwarding.  If by some chance this BIND server is going to act as a nameserver for your entire network, and you don’t mind the additional traffic and complexity (and it’s the additional traffic that scares me the most, since I have no idea what it’s actually downloading nor how often it’s doing it), then by all means feel free to use the second option.  All I will say is that I used the first. and it works fine, and I’ve seen at least one instance where this same thing is set up using a method other than Webmin, and except for the order of statements it uses an /etc/named.conf file that is identical to what Webmin produces when configured as I have shown here (in other words, no “zones” at all).  I’m just waiting for some Linux purist to say this isn’t the “right” way to do this but keep the goal in mind here — all we are trying to do is work around a bug in Asterisk that should have been fixed years ago, not set up a DNS server to feed an entire subnet.  But again, you can feel free to use whichever of the options you like — it should work either way.

(By the way, if after reading the above you have “setup remorse” — you know, that feeling you get after you’ve installed something that you should have picked a different option — you can get a “do-over” by simply deleting or moving/renaming /etc/named.conf.  If you then exit Webmin’s BIND module and come back in, it should see that named.conf doesn’t exist and start you over at the fourth screen shown above.  Of course, you will lose anything you have already configured from within that module.  If you originally selected the option to download the root server information, I think that’s at least partly stored in the file /etc/db.cache, so you could move or remove that file to make sure it’s not used, however I’m not sure if any other files are or were also downloaded.  That particular file is very small so I’m not worried about that one per se, it’s just that the way things are worded on a couple of pages I read, I don’t know if that’s all it downloads, or if at some point in the middle of the night it rises up and tried to cache all the DNS information for the Internet, or just exactly what it does.  Sometimes I wish people would just give a sentence or two of additional information, so you have a better idea of what’s the right thing to do when you’re setting up something like this.)

Now, if you are a True Linux Geek who somehow stumbled across this article, and are disappointed that it isn’t much more complicated, I’ll refer you to this page.  If you can figure all THAT out, you should be getting paid the big bucks as the networking expert that you are! 🙂

How to give a particular extension or group of extensions access to a specific trunk or group of trunks for outgoing calls in FreePBX

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Dial Patterns that will use this Route
Dial Patterns section of new FreePBX Outbound Route

I’m going to lift a bit of preliminary text from a page on the FreePBX site entitled “How to give a particular extension different or restricted trunk access for outgoing calls“:

IMPORTANT: When implementing any sort of restrictions on extensions, using the method described here or any other method, please be absolutely certain that you do not inadvertently restrict access to emergency services numbers (such as 911 in the U.S./Canada)!

There is a recurring question that comes up every so often, regarding how to give one particular extension (or a group of extensions) access to a different trunk for specific outgoing calls, or perhaps to restrict access to a particular trunk. Usually this involves an extension that is accessible to people that might want to make calls that cost money, and you don’t want them to do that. But there are many other reasons to route calls differently for different extensions, while still keeping all extensions on the same system so they can call each other.

Usually when someone asks about this, a common suggestion is to use the unsupported third-party Custom Contexts module. While this module is very versatile and lets you have a high degree of control over what each extension may access, there are at least two downsides. One is that it’s not part of the official distribution and therefore, a future upgrade of FreePBX might “break” it.

(This is probably less likely now, because it appears some of the FreePBX developers have taken an interest in maintaining it, but it’s still not beyond the realm of possibility.)

The other issue is that you have to go through and check (and maybe change) all the priority dropdowns if you add, remove, or move a route, and that can get to be a pain in the butt very quickly if you are in the habit modifying your routes with any frequency.

The problem with this page is that although it discusses several alternatives to using Custom Contexts (and you may wish to read it just to learn about those other possibilities), it is getting rather dated and therefore does not mention the use of the fourth field in Outbound Routes, a.k.a the “CallerID” field, which is by far the easiest way to implement this.

Let’s say you have an existing outbound route, over which your outbound calls normally travel, and it has a particular selection of trunks.  But you also have an extension, let’s say it’s extension 234, and you want it to use a different trunk or group of trunks.  In FreePBX 2.9 or later, all you have to do is this:

  • Go to the settings page for the Outbound Route that is currently used for outgoing calls.
  • At the bottom of the page, next to the “Submit Changes” button, there is a new “Duplicate Route” button.  Click on “Duplicate Route”.
  • Move the duplicated route to be higher in priority than the original route (it should appear just above the original route in the right-hand column).
  • Optionally rename the duplicated route to something more to your liking.
  • In the duplicated route, under “Dial Patterns that will use this Route“, add the extension number (or pattern matching a group of extensions) to the fourth (CallerID) field of EVERY dial pattern on the list.  Or, if using the Swiss Army Knife Module and you have checked the “Turn On Old (Pre 2.8) Dial Plan Textbox” checkbox (EDIT: or if you have FreePBX 12 or later, and under Settings | Advanced Settings, in the “GUI Behavior” section you have set Enable The Old Style FreePBX Dial Patterns Textarea to True), then add the extension number or pattern to the end of every existing pattern, separated by a forward slash.  As an example, an existing pattern of 1+NXXNXXXXXX would become 1+NXXNXXXXXX/234.  Again, you must do this to every pattern in the pattern list.
  • And finally, in the duplicated route, change the the “Trunk Sequence for Matched Routes” to include only those trunks that you want that extension or group of extensions to use.

If there are additional Outbound Routes for which you want to change the trunk selection for the same extension, repeat the above, starting with the other outbound route(s).  If you have additional extensions and you want one or more of them to have different trunk usage, repeat the above, using the different extension number(s) in the CallerID field and the different trunk selections.

If you want to block an extension’s ability to make toll calls, use the same procedure but only give them access to an ENUM trunk.  ENUM is pretty broken then days, it it would be rare for a call to actually complete, but if it does it’s not going to cost you anything.  This particular usage is discussed in more detail in “How to block a single extension’s ability to make outgoing toll calls in FreePBX“. (EDIT: In the most recent versions of FreePBX you can simply not select any trunks at all in the “Trunk Sequence for Matched Routes” section of the Outbound Route, and then optionally select a failure announcement or whatever treatment you want to give the call in the “Optional Destination on Congestion” section.)

And again, please note that you can use a single extension number OR a pattern in the CallerID field.  For example, if you had a pattern like 1NXXNXXXXXX, you could do something like:

  • 1NXXNXXXXXX/100 – match on the pattern only if the call is from extension 100
  • 1NXXNXXXXXX/2[45]X – match on the pattern only if the call is from an extension in the range 240-259
  • 1NXXNXXXXXX/3XX – match on the pattern only if the call is from an extension in the range 300-399

And if you wanted to allow the call only if it came from extension 100, 240-259, or an extension in the 300’s then you could use all three of the above rules in the same outbound route.

I will offer my opinion that using the Swiss Army Knife Module and checking “Turn On Old (Pre 2.8) Dial Plan Textbox” is the only way to go if you happen to have several hundred dial patterns!  Well, maybe not the only way (you could export a .CSV file, edit it, and import it back in), but definitely the easiest, because you can simply cut all the patterns from the textbox and paste them into a text editor, then use search-and-replace to add the extension numbers, then copy the changed patterns from the text editor and paste them back into the textbox in the Outbound Route.  If the search-and-replace function supports regex matching then it’s easy – set the find string to n and set the replace string to /234n (assuming 234 is the extension number you want to add), and replace all occurrences (be sure to check the first and last lines to make sure they look as they should, in case there was a missing or extra newline character somewhere).

EDIT: We have been informed that the old-style textboxes are once again available in FreePBX 12 and later. You have to click on the Settings tab, then Advanced Settings, then find the “GUI Behavior” section and change the Enable The Old Style FreePBX Dial Patterns Textarea setting to True.

Related Articles:

Featured Article:

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez

%d bloggers like this: