Anda di halaman 1dari 92

Table of Content

Basic usage of route prefixes to reroute calls from specific


extensions

Configuring IMAP voicemail for FreePBX

Hints and Tips

Hints on Route Dial Patterns and Trunk Dial Rules

How to access additional advanced extension options

How to automatically reject calls from telemarketers and other


"junk" callers

How to bypass Grand Central's requirement to press 1 to accept


the call

How to change incoming CallerID

How to create a system-wide speed dial number

How to execute a custom dial plan fragment before sending a call


to a trunk (for playing an announcement, etc.)

How to get the DID of a SIP trunk

How to get the DID of a SIP trunk when the provider doesn't send
it (and why some incoming SIP calls fail)

How to give a particular extension different or restricted trunk


access for outgoing calls

How to increase the execution time and/or memory allowed for


"orange bar" reloads

How to increase the time allowed between characters on in-call


functions (such as ## to transfer, *1 to record, etc.)
How to install BIND, so that SIP extensions continue to work when
Internet connectivity is lost

How to make multiple extensions use a common voicemail box

How to make voicemail accessible from an outside line

How to send calls to different trunks at different times of day

How to set up a Linksys PAP2 or Sipura SPA-2000 for use with


FreePBX

How to set up a Skype gateway

How to set up notification (Caller ID popup) on Mac OS X, Linux and


other systems

How to set up per-use Caller ID blocking (*67)

How to strip or replace the + character at the beginning of a called


number

How to upgrade Asterisk

How to use callgroups and pickgroups

HOW TO: Using FreePBX Back End for trixbox CE Authentication

How-Tos and Tutorials on Other Sites

HOWTO Install HylaFax with iaxmodem on a running CentOS 4.3 +


Asterisk 1.2.7.1 system with FreePBX 2.1

HOWTO Setup A Remote SIP Extension

HOWTO: Create custom feature codes to read back the feature


status of extensions

HOWTO: Free Directory Assistance in the USA

HOWTO: Linksys SPA-3102/Sipura SPA-3000 + FreePBX


Howto: Linksys/Sipura SPA-3000 + FreePBX

HowTo: Linux Tips and Tricks

HOWTO: MythTV CallerID OSD

HOWTO: New FreePBX users guide to diagnosing problems

HOWTO: Patching Asterisk for incoming fax functionality

HOWTO: Resolve FreePBX and Sipura/Linksys Feature Code


Conflicts

HOWTO: Resolving Audio Problems

HOWTO: Route Dial Patterns and Trunk Dial Rules

Howto: Setting up VOIP Provider Trunks

HOWTO: SPA-3102 and FreePBX

When an internal extension user dials one of my DID's, how do I


keep the call from using external trunks?

Where to Get Free Classical Music on Hold


HOWTOs
Another venerable open source tradition are the HOWTOs.

Short tutorials on subjects that span multiple modules for the purpose of doing something.

If you found something difficult to do, and eventually learned how to do it, think about writing an article and postin it here.

Basic usage of route prefixes to reroute calls from specific extensions


Basic usage of route prefixes to reroute calls from specific extensions
This document is to explain the usage of route prefixes to select a specific route for outgoing calls. It assumes you already have a good working knowledge of how FreePBX
Outbound Routes and Trunks work - if your not certain of that, you may want to read Hints on Route Dial Patterns and Trunk Dial Rules before reading this document.

In the old days of telephone-company supplied PBX's, it was a common practice to require PBX users to dial "9" to get an outside line. Although you may not have viewed it
this way, this was an early example of using a prefix to select a route - in this case, a route for local outgoing calls. By the way, it's no longer considered good practice to
require users to dial a prefix for local calls, but you still find this relic of the past on many existing PBX systems.

Sometimes a company would purchase a "foreign exchange" (FX) line in another city. For example, a company in Detroit that had many customers in Windsor, Ontario might
purchase a Windsor FX number. It would be set up to use a different prefix on the PBX, so employees might dial "9" for a local call in Detroit, and "8" for a local call in
Windsor.

In a similar manner, a company might have wanted a line specifically dedicated for the use of certain executives. This might be "hidden" behind a code that regular
employees weren't supposed to know. For example, dialing "77" might give the executives access to "their" line.

Note that in all cases, the routing prefix could not conflict with any other number in the user's number space. For example, if you used three digit extensions in the range
100-899, then you couldn't use "8" or "77" as dialing codes. You might have to use something like "99" for local calls, "98" for the FX line, and "977" for the "secret" trunk.

All of these were examples of using a prefix to route calls at the time of the call. The problem, of course, was that employees wouldn't always use the correct prefixes. The
employee in Detroit might dial 9+1-519-NXXXXXX (where NXXXXXX is the local number) to place a call to Windsor, effectively making an expensive international call
instead of a cheap local call. Or, a bored regular employee might start dialing random digits and discover the bosses' "secret" line. So, as soon as electronic switching came
into use, methods were devised to take control away from the end user and put it in the system itself. The user would simply dial the number; the system would figure out
how to route it (and whether the user should have access to any "special" trunks).

Now, one thing FreePBX excels in is selecting trunks based on the pattern dialed. And if you really want to (and still have your head stuck in the 1950's), you can still use the
old-style manual prefixes with FreePBX. For example, if someone dials 9+1-800-555-1212, you can easily strip the 9 at either the route or trunk level (for now we will
concentrate on routes). So in your route, you might have a pattern like 9|1800NXXXXXX, and similar patterns for other toll-free prefixes. Numbers before the | character are
not sent to the trunk, so the 9 would be stripped off.

But, we don't NEED to use prefixes to select routes. Suppose we were actually replacing an old PBX in Detroit, and we brought the Detroit number into FreePBX on a
ZAP/DAHDI channel, and the Windsor FX line in on on a second ZAP/DADHI channel. We'd have a trunk for each channel, and a route for each trunk. We'd then use a
pattern like 1313NXXXXXX and/or 313NXXXXXX in one route to send Detroit area calls to the Detroit trunk. We could use patterns like 1519NXXXXXX and/or
519NXXXXXX in a different route to send all area code 519 calls to the Windsor trunk (I know that doesn't take into account that not all area code 519 calls are local to
Windsor, but this is just an example).

So, users are relieved of the burden (or responsibility, depending on your point of view) of selecting the correct trunk for calls to a specific area. The system does that for
them. And as noted above, out of the box FreePBX handles this very well.

The problem is that if we want to give a specific user's calls (or the calls of a group of users) different handling, up until recently there's been no way to do it natively in
FreePBX. Sure, we could set up a manual prefix that the executives would dial to access the "boss route" and then strip it at the route level, but these are busy people (in
their own eyes, anyway) and don't want to be bothered dialing prefixes. The problem is even worse if you have different departments that use different groups of trunks -
sooner or later someone in one department will find out the "secret" dialing prefix that the other department's employees are supposed to use, and mischief will result.

Now you may be thinking ahead a bit and realize that if forcing users to dial 9 for a local call is no longer acceptable practice, then you need some way to distinguish between
calls that stay on your system and calls that do not. In North America, many system administrators have adopted the practice of numbering all local extensions starting with
11 or 10, because no area code begins with 0 or 1. So, extensions might be numbered from 1000 through 1199, which allows for 200 extensions (and no conflict with any ten
or eleven digit pattern used for "outside" calls). If you don't have anywhere near 200 extensions (and don't expect to), you might appropriate some of those unused extension
numbers as dialing prefix codes. But that assumes that users would actually be dialing those codes, and that exactly what we'd like to avoid. (By the way - consider this a
slightly off-topic sidebar - you can also use dialing timeouts on local extension numbers, and use the # key as a shortcut to avoid the timeout, which actually gives you more
available extensions for the same amount of button depressions - but some people just can't seem to get the hang of pressing the # key at the end of a local extension
number).

In any case, the principle is this. By default, if you dial a particular "outside" number, it will go out on the route that matches that pattern exactly, and that route would select
one or more specific trunks. But you could have a second route, with the same dial patterns except prefixed by (for example) 1199| and then if someone dials 1199+that same
"outside" number, the call would go out that route, the prefix would be stripped and the call would go out the trunks associated with that route. And you could have as many
additional routes and route prefixes as you need.

If you're still following along at this point, let's now consider this: Suppose the user didn't have to dial the route prefix? In many endpoints, you can set up the dial rules so that
if you dial a specific pattern, it will prepend a prefix before sending it to FreePBX. Since the user isn't manually dialing the prefix, we can use something a bit longer and
perhaps more obscure. For example, we might use something like 000001 to access the first alternate route, 000002 for a second alternate route, etc. Since no "normal"
number in any country that we're aware of begins with that many zeroes, it's safe to use something like that as a prefix pattern without risk of conflicting with something a
user might actually dial. This also makes it easier to actually key the prefix to a particular extension, for example a route specifically for use by extension 1123 could be given
the prefix 000023 (or even 000123), which makes it a bit more mnemonic when you are trying to figure out which route goes with a particular extension.

But instead of forcing the user to dial this prefix, or programming it into each endpoint individually, we now have the option to do this directly from within FreePBX.
Unfortunately, the methods to do this are not part of the "official" FreePBX distribution yet.

1 of 89 5/22/2009 11:12 PM
The easiest method is to use the (at this point unsupported, third-party) Outbound Route Permissions module. When you use this module, it adds a new section to each
extension's configuration page that lists each of your Outbound Routes. For each extension, you can allow or deny access to each route. But there is a third option - if you
choose to deny access to the route, you can specify a "Redirect Prefix". This simply adds a route prefix to the number, the same as if the user had dialed it manually, and
sends it back through the dialplan. So, you simply give "regular" users access to the "regular" routes, but deny access to the "special" routes (so even if they happen to know
your internal routing prefix, it won't do them any good). Then you could give other users access to the "special" routes, but deny them access to the "regular" routes, while
using a "Redirect Prefix" so that when they dial a call normally associated with that (regular) route in the normal manner, it will prepend the prefix and send the call through
the system again, so the call will be processed just as if the user had dialed the prefix manually.

Now you may be wondering why you need the prefix at all - if you deny access to one route and use the same dialing patterns in another route, won't the call go out over the
second route without the prefix? Well, we might wish it worked that way, but it doesn't. Remember that we are using Asterisk underneath FreePBX, and Asterisk doesn't
work that way. At the ROUTE level, all numbers must be unique - if two routes have overlapping patterns, Asterisk will only match on the first.

So what you do is, you prepend the routing digits - but you let FreePBX do it instead of requiring the user to do it - and then send the call through a Outbound Route that
strips the routing digits before sending the call to the appropriate trunk(s).

There are other methods to accomplish this. Instead of using the Outbound Route Permissions module, you can manually add the prefix using code in extensions_custom.conf
- see How to give a particular extension different or restricted trunk access for outgoing calls for details. And, there is a third-party, unsupported Custom Contexts module
that uses a different method of route selection. That module arguably allows more precise control, but many users (including the author of this document) find it more
difficult to use if all you want to do is change the route access for certain extensions. Plus, the author of that module apparently has not had the time or interest to keep it
updated, and there have already been issues with it not working after a FreePBX version update, although a patched version was released that corrected that issue. It is a
more powerful module, but very few users really need all the functionality it provides (again, in the opinion of the author).

I hope this document has helped you understand a bit of the theory (and history) behind adding a prefix to certain calls to force them to use a particular Outbound Route
(and, therefore, a particular trunk or group of trunks), and how this can be used to our advantage to force calls from a particular extension (or group of extensions) to use
certain specific trunk(s) instead of the default trunk(s).

Note that although this document describes the rerouting of calls from particular extensions, the same technique can be used in other situations. As an example, one user had
calls for two companies coming in on two different DID's, but at night they wanted to forward the calls to an answering service. In order for the answering service to get a
different Caller ID for each company (so they could answer the call using the correct company name) it was desired to send the calls for each company out via a different
trunk. But, FreePBX would only use the first Outbound Route that it found that matched the pattern for the answering service telephone number.

Originally, at night the calls were being sent to a single Misc. Destination that went to the answering service telephone number. Let's say that the answering service number
was 5552368. Instead of making a single Misc. Destination forwarding to 5552368, the trick was to make two Misc. Destinations using (for example) 0000015552368 and
0000025552368 as the respective destinations, the creating two new Outbound Routes, with 000001|5552368 as the dial pattern for the first route, and 000002|5552368 as
the dial pattern for the second route. Each new Outbound Route was set to select the correct trunk (a different one in each of the routes), and both Outbound Routes were
placed higher in priority than the "general" Outbound Route that would normally handle calls to 5552368. Then, all that was left to do was to send each DID to the correct
Misc. Destination (using a Time Condition) at night.

Configuring IMAP voicemail for FreePBX

A couple of notes first:

1. IMAP support is only present in Asterisk 1.4, not 1.2.


2. I can only attest to use of the Cyrus IMAP daemon. The other commonly used IMAP daemon, dovecot, may or may not require changes to the instructions here. If you
find out that is the case, let me know, and I will update this HOWTO.
3. That said, on to the meat:
4. Download and build the UW imap client. Do NOT install it; asterisk will bind the compiled client into itself. Look at the file doc/ imapstorage.txt in the asterisk 1.4
source tree for specific instructions.
5. Configure asterisk for IMAP voicemail support. This is also explained in the same imapstorage.txt file.
6. Install asterisk by 'make install'.
7. Go to /etc/asterisk, and edit the file vm_email.inc. The voicemail text message in /etc/asterisk/vm_email.inc will not work if sent to an IMAP server. The text is
required to end each line with \r\n, not \n. Dovecot may not care (dunno), but Cyrus (which clarkconnect runs) bitches about 'bare newlines'. I fixed it (for now) by
manually adding the \r characters where needed. Unfortunately, this may be overwritten by updates, so make a copy to restore (this is ugly and needs to be fixed
somehow.)
8. Edit voicemail.conf and add the 4 lines following (beware that this also can/may be overwritten):
imapserver=localhost
imapflags=notls
imapfolder=INBOX/Voicemail
expungeonhangup=yes
authpassword=YOURIMAPPASSWORD
9. Now, start up asterisk, and browse to your config. For the extensions, put 'imapuser=YOURIMAPUSERNAME' in the VM Options field. For Cyrus, it seems you need
one username&password for all extensions. If not, let me know how to change this.
10. For any extra extensions, change the mailbox field in Device Options to have default@NNN, where NNN is the primary extension. This is so MWI will work. NOTE:
you will still be prompted for your mailbox, even if you call "My Voicemail" speed-dial, since asterisk can't tell who you really are.
11. In your email client, create a mailbox called "Voicemail".

This *should* all work (at least it did/does for me.) Issues/glitches, let me know, and I'll update this.

Hints and Tips


* Asterisk Tutorials Free video tutorials on Asterisk, TrixBox, and FreePBX
* Custom feature codes to read back the feature status of extensions - Allows users to find out how features such as Call Waiting, Do Not Disturb, and the variations of Call
Forwarding are presently set, simply by dialing a feature code
* Feature Codes - Numbers you dial for various things (Call Forwarding, Divert, etc)
* Follow-Me Function implemented using Queues tutorial at VOIPSpeak.net
* Hints on Route Dial Patterns and Trunk Dial Rules - Helps to clear up confusion for new FreePBX users
* How to change incoming CallerID - Does your provider chop off or add digits to CallerID, so call return doesn't work? Here's a way to fix it (until we get a way to do it in

2 of 89 5/22/2009 11:12 PM
the trunk definition)
* How to get the DID of a SIP trunk when the provider doesn't send it (and why some incoming SIP calls fail) - Can't get an inbound route for a particular SIP trunk to work?
Calls from one particular SIP provider won't come in at all, or only come in on your default route? Or, maybe you have two or more SIP trunks from the same provider, and
Asterisk thinks all your incoming calls are from only one of the trunks? The answers might be here
* How to make multiple extensions use a common voicemail box
* How to make voicemail accessible from an outside line - You can allow your users to access their voicemail from anywhere there's a phone
* How to upgrade Asterisk - This is not necessarily something you should do, but if you feel you must, here's how
* I upgraded, but I can't do a restore
* MythTvOsd - Displaying caller ID info on MythTV's on-screen-display
* New FreePBX users guide to diagnosing problems - Read this BEFORE you go into the #freepbx IRC channel
* Resolving Audio Problems - No audio? One-way audio? Here are some common fixes for audio issues - also read this page if you are trying to set up FreePBX behind a
NAT firewall
* Resolving FreePBX and Sipura/Linksys Supplementary Service and Feature Code Conflicts
* Setting up a trunk and route for free Directory Assistance in the USA - Don't pay the phone company for looking up a number!
* Setup a Linksys/Sipura SPA-3000 with FreePBX - Also applicable to SPA-3102
* Tested and working SIP provider configurations
* Trunk Hints - Configuration hints for various VSP's

Hints on Route Dial Patterns and Trunk Dial Rules


Hints on Route Dial Patterns and Trunk Dial Rules

New users of FreePBX are often confused by the fact that there is a place to enter "Dial Rules" when creating a new Trunk, and "Dial Patterns" when creating a new
Outbound Route. Since the construction of these seems similar, users try to do something in the wrong place and it doesn't work. This is a brief attempt to explain the
difference.

Trunk Dial Rules

First let's deal with trunks, because they are perhaps the easiest to understand. The thing to remember about Trunk Dial Rules is that they are ONLY used for adding numbers
to, or subtracting numbers from the number being sent to the trunk. Trunk Dial Rules are NEVER used to allow or restrict numbers that may be dialed. Therefore, it follows
that any entry not containing a | character (to strip off number at the start of the entry) or a + character (to add numbers at the start of an entry) in totally useless - it will
simply waste processor time while the system looks at those entries.

To give an example, here's a common newbie mistake. Let's say that you have a couple different trunks that allow outgoing toll-free numbers in the USA, and one of them is
Free World Dialup, which requires a star (*) key in front of the actual number. For the moment, let's assume that you want to restrict these trunks to toll-free numbers only.
So in the first trunk, you might be tempted to put some lines like this:

1800NXXXXXX
1822NXXXXXX
1833NXXXXXX
1844NXXXXXX
1855NXXXXXX
1866NXXXXXX
1877NXXXXXX
1888NXXXXXX

And then in the Free World Dialup trunk, you congratulate yourself as you cleverly add the * to each toll-free definition:

*+1800NXXXXXX
*+1822NXXXXXX
*+1833NXXXXXX
*+1844NXXXXXX
*+1855NXXXXXX
*+1866NXXXXXX
*+1877NXXXXXX
*+1888NXXXXXX

Congratulations, you've managed to waste a bunch of processor time! In the first example, NONE of the entires are accomplishing a thing because none of them contain a | or
+ character. You could (and should) remove every one of them. Call filtering by number dialed is done by ROUTES, not by TRUNKS.

Note: There is, however, one exception to the general "definitions without a | or + are useless in a trunk" rule. A definition without a + or |, if matched, will stop the
processing of definitions beyond that point. Consider the following example:

555XXXX
1321+NXXXXXX

This will add 1321 to any 7 digit number, EXCEPT those starting with 555. So, a definition can also be used as a "stopper" to prevent that pattern from being matched by
another definition that is lower in the list (thanks to groogs in the #freepbx IRC channel for this clarification).

And in the second example (the Free World Dialup trunk), you could accomplish the same thing by ONE line, like this:

*+18XXNXXXXXX

or

*+1NXXNXXXXXX

or, because you know that "real" Free World Dialup numbers are five or six digits long, you could even use

*XXXXXX.

3 of 89 5/22/2009 11:12 PM
(Note the period as the last character) - Which would prepend the * to any number 7 digits long or longer (although you may not want to do this if you use Free World Dialup
as a route to other networks, but that's a more advanced discussion).

Again, this bears emphasizing: You CANNOT use Trunk Dial Rules to allow or restrict certain numbers from going out on a trunk. You can only add or strip digits.

Route Dial Patterns

Route Dial Patterns are used to specify what numbers are allowed to go out via that route. When a call is placed, the actual number dialed by the user is compared with the
Dial Patterns in each route (from highest to lowest priority) until a match is found. If no match is found in any route, the call fails (there is "no route" for that call).

If the number dialed matches a pattern in more than one route, only the rules in the route with the highest priority are used. In other words, if a call tries to use that route and
fails, it does not keep trying additional routes to see if it matches another. This is actually desirable behavior because it allows you to force certain calls to go out via lower
cost routes.

Route Dial Patterns cannot be used to add digits to the number dialed by the user. However, you can strip off leading digits before passing them to a trunk. This is most useful
if you use a specific dialing code to access a particular route (for example, "9" to access an outside line).

Note that each route can be set to access one or more trunks. Each trunk may require different translations (changing what was actually dialed to something else before
sending it on is called a translation in telephone-speak) so you don't want to strip digits at the route level if only some of your trunks will require it and some don't.

Route Dial Patterns only allow calls, they cannot block calls. The only way to block certain patterns is to make sure they are not included in any route. Or, you can include
the blocked pattern in a higher priority route, then make sure that route doesn't send calls to any trunks that cost money. The easiest way to do this is to create an ENUM
trunk.

For example, let's say you want to allow all calls within Country Code 1 EXCEPT calls to 1-900 numbers and to local 976 numbers (in a real situation you'd probably have
additional restrictions, but this is just to illustrate the technique). In a lower-numbered route (which has a higher priority) you could include these lines in the Route Dial
Pattern:

1900XXXXXXX
1NXX976XXXX

Then make sure that the only trunk that route accesses is the ENUM trunk (create one if you don't have one). Because ENUM is always free, chances are the call will never
complete, but if it does it will not cost anything. Now make a higher numbered route (lower priority) and either include a general pattern such as:

1NXXNXXXXXX

Or if you want additional security, you could instead use a list of specific area codes that you wish to allow (omitting those that do not exist or that you don't want to allow
calls to be placed to):

1202NXXXXXX
1203NXXXXXX
etc.

Yes, it may be a fairly long list, but it will work. You may still want to use ENUM as your first trunk choice (if you want to check for a "free" route to the called number,
before going to your usual provider), but then you will be sure to include a trunk that permits outgoing calls to these numbers.

How do I....?

How do I allow seven digit dialing for local calls in North America?

In the route that handles calls to your local area code, include this in your Route Dial Patterns:

NXXXXXX

In the trunk(s) accessed by that route, include this in the Trunk Dial Rules:

1aaa+NXXXXXX

Replace aaa with your local Area Code.

How do I block certain International destinations while allowing others?

Again, make sure you've set up an ENUM trunk which can be used as a destination for calls you don't want to pay for. Then think about your dial patterns and how you want
to allow or block them. Remember that less specific rules must always be placed in a lower priority than more specific rules. For example, let's say we want to allow calls to
landlines in country code 64, but not to mobiles or high-cost numbers. In a higher priority (lower-numbered) route, include the patterns you want to block, e.g.:

011642.
011648.
01164900.

Associate this route with the ENUM trunk only. Then in a lower priority (higher-numbered) route, place the more general pattern:

01164.

Then associate this route with the ENUM trunk (if you want to check for a "free" route first), followed by the trunk(s) of the provider(s) you wish to use for calls to country
code 64. Don't forget to strip the "011" or "00" international prefix (or whatever the prefix is in your part of the world) in the ENUM trunk Dial Rules.

How to access additional advanced extension options


How to access additional advanced extension options
Sometimes FreePBX users want to access additional options for extensions. The key to this is to use the Follow Me module. Once it is installed, it can be used for more than
just setting up a Follow Me for an extension. Quoting from the Follow Me documentation:

4 of 89 5/22/2009 11:12 PM
"There are other 'creative' uses of the Follow-Me function. At the simplest, you can simply put in the extension of the Follow Me number with a choice to go to its voicemail
if not answered and you will be accomplishing exactly the same thing as if the extension was being dialed. However, you can now diverge with such simple things as changing
your ring time to override the default, adding an announcement, going to an alternative voicemail or other destination if not reached, and of course adding multiple numbers
and ring strategies when someone tries to call that number."

So what you do is select Follow Me in the left-hand menu that appears on most FreePBX pages. From there, you can select an extension and then configure a Follow Me
and/or any of the additional options. Mouse over the option name on the Follow Me page for a more complete description:

Follow-Me List: If you don't really want a Follow Me and are only using this page to set some advanced extension options, then make sure that only that extension's number
appears in this list (for example, for extension 234 only 234 should appear in the list!). Conversely, you may want to use a follow-me to set up a form of intelligent call
forwarding, with the ability to take the call back and forward it someplace else if the first number you try is busy or doesn't answer - in that case you might put the extensions
or numbers you wish to forward to in the list, but not the original extension's number.

Ring Time (max 60 sec): Use this to change the default amount of time an extension rings before going to voicemail, or another no-answer destination (see below).

Announcement: This is used to specify an announcement to be played to the caller prior to ringing the extension (this is where you can play one of those "This call may be
recorded or monitored" type announcements, for example). Note that this announcement will play BEFORE the extension commences ringing, and therefore cannot be
interrupted by the called party picking up.

Play Music On Hold?: This allows you to select a Music-on-Hold category so that you can play music (and/or pre-recorded announcements) while the extension is ringing.
This IS interruptable, by the extension picking up or the Ring Time expiring.

Alert Info: Allows you to set up distinctive ringing with certain types of SIP extensions. What you place in this text field will be determined by what the SIP endpoint expects
to see (often a string that beings with "Bellcore") - see your SIP endpoint's documentation. The biggest use of this for a single extension is to help distinguish which extension
is ringing when there is more than one in a room.

Destination if no answer: Where the call goes when the Ring Time has expired. Normally you'd set this to the extension's voicemail, but you could also send the call back to
the IVR, or to another extension, or whatever - it's up to you.

Note that all the above options (and the others that I did not mention) may have additional uses if you are actually setting up a Follow Me (that is, you have more than one
destination in the Follow Me List). To discover these, mouse over each option - you should see a small text box that gives you additional usage details about each option.

There is one other question that frequently arises, and that is how to restrict one extension or a group of extensions from making outgoing calls via certain trunks, while
allowing unrestricted access to other extensions. One way to do this is to set a route password (or PIN set) on the individual routes to which you wish to restrict access - this
has the advantage that "approved" users can make calls from any phone on the system, while the night cleaning crew cannot make outgoing calls just because they have
physical access to a "approved" phone (unless someone knows the password). However, people hate dialing passwords or PINs, and the higher they are in the organization
the more they seem to think it is a waste of their time and effort to put up with this type of security feature.

Another option is to use the UNSUPPORTED Custom Contexts module - this will let you set access restrictions for individual extensions, but because the module is
unsupported there is no guarantee that it will continue to work with future versions of FreePBX (if you do use this module, make sure you have the most recent version
installed whenever you upgrade FreePBX!). It's also a bit difficult to maintain, particularly if you frequently add or remove routes, because of the necessity of setting
priorities for each route (and making sure they are set correctly when a route is added, removed, or moved).

A third option is to use the method devised by Moshe Brevda and documented in this blog post: Restricting outbound calls in FreePBX (whitelist). This method allows call
restriction on a per-extension basis, with exceptions placed in a "whitelist" of numbers that can be called despite the block.

Finally, there is the method I have described in this FreePBX forum post: A different approach to placing outgoing calling restrictions on certain extensions. This differs from
Moshe's approach in that although it also allows call restriction on a per-extension basis, my method restricts access to specific outbound routes - an outbound route can be
restricted or non-restricted. If an extension is restricted and tries to access an outbound route that is restricted, the call will be blocked. If either the extension or the outbound
route are not restricted, the call will go through.

How to automatically reject calls from telemarketers and other "junk" callers
How to automatically reject calls from telemarketers and other "junk" callers
Note 1: This is a preliminary version of this page; it may be updated with additional information or to correct errors!

Note 2: The third-party Caller ID Superfecta module also provides a method for rejecting "junk" calls, that might be easier to implement than the method shown here.

This technique uses the service EveryCall.us to look up the numbers of incoming calls that are coming in via selected trunks. If you get a lot of calls from telemarketers and
other "junk" callers, this may help you avoid having to deal with them. It's not foolproof, of course, but it will hopefully catch a good percentage of your "junk" calls.

We are using EveryCall.us for two reasons - first, you don't have to register just to do a phone number lookup, second, they have set up a special way to query their service
that is very fast and that sends only a minimal amount of information (a "score" associated with a number, or -1 if it's not in their database at all). So we just look at the score
and if it's over 10 (you can change that) we send it to the junk call treatment. Here's how to set it up.

Step 1: Make sure curl is installed on your system. From a Linux command prompt, type curl --help
If you get a list of curl options, you are good to go. If not, install curl in the usual manner (e.g. yum -y install curl may work on a CentOS system).

Step 2: Still at the Linux command prompt, enter touch /var/lib/asterisk/agi-bin/check-everycall-us.agi

Step 3: Use a text editor (nano, Midnight Commander's editor, or whatever you like) to edit the /var/lib/asterisk/agi-bin/check-everycall-us.agi file. Copy and paste the
following code into it:
#!/bin/bash

BADCALLSCORE="0"
RETRIEVEDSCORE=`/usr/bin/curl -s -m 2 -A Mozilla/4.0 http://www.everycall.us/query\?${1}`
BADCALLSCORE=`echo ${RETRIEVEDSCORE} | grep score | sed -e 's/.*score=//' -e 's/ <br\/>//'`

if [ -z $BADCALLSCORE ]

5 of 89 5/22/2009 11:12 PM
then
BADCALLSCORE=0
fi

echo "SET VARIABLE badcallscore ${BADCALLSCORE}"

BE SURE NOT TO LOSE ANY BACKTICKS during the copy and paste operation! Be sure to save your changes.

Step 4: Change the permissions and ownership of /var/lib/asterisk/agi-bin/check-everycall-us.agi to be the same as the other .agi files in the /var/lib/asterisk/agi-bin directory.
I always use Midnight Commander's "Advanced chown" (under the File menu) to view and change permissions, not being a Linux geek at heart. The main thing is to make
sure that the owner and group are set to asterisk, and the owner has read/write/execute permissions.

Step 5. Now use your text editor again - this time you want to open /etc/asterisk/extensions_custom.conf and add the following to the existing file:
[custom-check-everycall-us]
exten => _X!,1,NoOp(Checking Everycall.us for bad caller)
exten => _X!,n,AGI(check-everycall-us.agi|${CALLERID(number)})
exten => _X!,n,NoOp(Everycall.us returned score of ${badcallscore})
exten => _X!,n,GotoIf($[0${badcallscore} < 10]?notbadcaller)
exten => _X!,n,NoOp(Bad caller score above threshold - changing DID to 9999999999)
exten => _X!,n,Goto(from-trunk,9999999999,1)
exten => _X!,n(notbadcaller),NoOp(Bad caller score below threshold - continuing)
exten => _X!,n,Goto(from-trunk,${EXTEN},1)
exten => h,1,Macro(hangupcall,)

Save your changes. Note that the number 10 on the 4th line is the score that determines a "bad" call - if a lot of bad calls are slipping through you can try making this lower.
On the other hand, if good calls are getting caught, you may want to make it higher.

Step 6: In the FreePBX "Inbound Routes", create a new Inbound Route that will be used to dispose of the "bad" calls. Make the Description something like Blocked per
Everycall.us, and set the DID Number to 9999999999 (leave the Caller ID Number blank). Then select whatever destination you like - I personally like the option
"Terminate call: Play Ringtones to the caller until they hangup", but you can do whatever you like, including creating a special IVR just for those folks, if that's your bent. By
using an inbound route in this manner, you have additional flexibility for disposing of the call, and you are terminating the call inside the FreePBX dialplan, which may have
some implications for call detail recording, etc.

Step 7: In every trunk you want to monitor, you'll need to go into the trunk setup and change the statement context=from-trunk to context=custom-check-everycall-us -
the good thing about this method is you can choose to check incoming calls on some trunks but not others. The bad part is you have to change the context= statement in
every trunk that you want to check. NOTE: If the context statement is going to someplace other than from-trunk already, you'll need to find the custom dialplan
referenced by that statement, and modify that to go to custom-check-everycall-us after it has done its work (instead of going to from-trunk). If that custom dialplan changes
the DID of the call then make sure that the EXTEN variable contains the new DID before passing the call to custom-check-everycall-us.

Don't forget to apply your configuration changes when you are all finished!

Please note: The above information should be considered preliminary. The code shown above should still be considered experimental code. Use it at your own risk, and
please let us know how it works for you, particularly if you actually receive any calls that score high enough to get "the treatment." Also please watch for any "false
positives" - keep in mind that I am NOT a programmer, so don't rely on any of the above code without testing it for yourself!

How to bypass Grand Central's requirement to press 1 to accept the call


How to bypass Grand Central's requirement to press 1 to accept the call

Google's GrandCentral service offers incoming DID's in a number of places that may not be immediately available from other providers, and their service is free. There are,
however, two downsides to using GrandCentral:

At the time of this writing, you need an invitation from another GrandCentral user. This is solely a requirement imposed by Google (prior to Google's purchase of
GrandCentral, anyone could sign up for a GrandCentral account, without the necessity of an invite). Anyway, I'll spare you my rant about Google, suffice it to say I
think they have forgotten their corporate motto.
GrandCentral lets you route the call to more than one destination, so when the call is answered they ask you to press 1, presumably to confirm that you want to accept
the call at that number, and that you're not an answering machine or voicemail box. While this is a great feature in some scenarios, it's not so great if we want the call to
come into FreePBX and go to an IVR, or if perhaps we want the call to go to a FreePBX voicemail box.

Fortunately, there is a workaround suggested by user "cbrain" in this thread on BroadbandReports.com. This works best if you can dedicate one DID (even if it's a local
PSTN line) to calls received from GrandCentral. Or, because GrandCentral lets you make a Gizmo Project number a destination, you can get a free Gizmo Project account
and then use your Gizmo Project DID as your incoming route for GrandCentral calls (the following instructions from "cbrain" assume the latter):

I just gave it a try and it works.

First go to "config edit" and add the following to -extensions_custom.conf-

[custom-gc-did]
exten => 1,1,answer
exten => 1,n,wait(2)
exten => 1,n,SendDTMF(1)
exten => 1,n,Goto(ext-group,2,1) ;use a setup ring group or extension

Then go to FreePBX - setup - Inbound Routes - and set up or edit your Gizmo Project DID. In the - set destination - section set - Custom App: - to - custom-gc-did,1,1 -.
[NOTE: In a comment below, Cliff said: In recent FreePBX versions you can no longer directly enter a custom app into Inbound Routes. After you set up
"extensions_custom.conf" go to the "Tools" tab - "Custom Destinations" and add "custom-gc-did,1,1" to "Custom Destination" - give it a name FreePBX will use, save,
reload, and you can then choose it from "Inbound Routes."]

Then setup your ring group or extension.

If you need to have access to incoming from GrandCentral from your cell or other, change your inbound route from FreePBX directly to the same ring group or extension and
toggle between press 1 and direct ring.

6 of 89 5/22/2009 11:12 PM
(End of quote from posted message)

In case it's not obvious, the key to the above instructions is that you have Asterisk answer the line, wait two seconds, and then send a DTMF "1". Then you send the call to
wherever you really want it to go, whether that is a specific IVR menu, a particular extension or ring group, a voicemail box, or wherever. But, you only want to do this for
calls coming from GrandCentral (e.g. over your Gizmo Project DID), so that your regular callers don't get blasted with a DTMF "1" every time they call you.

Note that once you have sent the "1", the call will have been considered as answered by the caller's telephone company. If you transfer to an extension that gives a ringing
tone, and the caller abandons the call, they may wonder why they have been charged for an "uncompleted" call (from their perspective). So, you may want to play a short
announcement so that the caller knows that the call has been answered and is being transferred. Obviously, this is not a concern if you send the call directly to an IVR menu,
or a voicemail box.

Thanks to "cbrain" for the instructions. By the way, I can't comment on how well the above instructions work, because nobody's ever sent me a GrandCentral invite!

How to change incoming CallerID


How to change incoming CallerID
(New material added March, 2009:) I should point out at the beginning that there is now an unsupported third-party module for FreePBX called Set CallerID, which "adds
the ability to change the CallerID within a call flow." So, for example, you could create a Caller ID instance using this module, then make the destination of an Inbound
Route that Caller ID instance. This basically accomplishes the same thing that is described below, but keeps you from having to mess around with adding contexts to
extension_custom.conf.

Almost all of the examples below could be used with the Set CallerID module by doing the following: Set the CallerID Name to ${CALLERID(name)} so it will remain
unchanged. Then set the CallerID Number to the target of the Set statement (the part after the = sign, but not including the close parenthesis). So, where in the first example
below you see the line:

exten => _X!,1,Set(CALLERID(num)=0${CALLERID(num)})

If using the Set CallerID module you would take just the part in bold - 0${CALLERID(num)} - and use that as the CallerID Number.

If for some reason you don't wish to install the module, or it doesn't meet your requirements, the method described below still works.

(Original page starts here:) The following is an example of how to add a digit to incoming CallerID on a particular trunk - some people seem to want this because their
phones will not do a proper callback if the leading digit(s) are missing.

Step 1: Go into the trunk for that provider (if not a Zap trunk-see below for Zap) and under Incoming Settings | USER details you will see a "context=" line - usually this will
be "context=from-trunk". Note what is there now (if it is something other than "from-trunk") and change it to "from-trunk-custom", or add "-custom" to the end of whatever
is there now

Step 2: Edit etc/asterisk/extensions_custom.conf (you can use nano, Midnight Commander's built-in editor, or other plain-text editor of your choice) and add the following at
the bottom of the file:
[from-trunk-custom]
exten => _X!,1,Set(CALLERID(num)=0${CALLERID(num)})
exten => _X!,n,Goto(from-trunk,${EXTEN},1)

Again, change the "from-trunk" in the first and third lines if you originally had something else in your trunk context. In the SECOND line, the 0 (following the =) is the digit
to be added - if you want to add something other than 0, you'll have to change that.

Step 3: Reload or restart Asterisk

From CLI: reload (OR, if you want to restart Asterisk for some reason, you can use restart now, or restart when convenient if you don't want to drop calls. You could also
do amportal restart from the Linux command line).

If you need to make this change for your Zap trunk, the procedure is slightly different:

Step 1: Edit etc/asterisk/zapata.conf (you can use nano, Midnight Commander's built-in editor, or other plain-text editor of your choice). You will see a "context=" line -
usually this will be "context=from-zaptel". Note what is there now (if it is something other than "from-zaptel") and change it to "from-zaptel-custom", or add "-custom" to the
end of whatever is there now.

Now continue with Steps 2 and 3 above, substituting "from-zaptel" (or whatever you found in the "context=" line in zapata.conf) in place of "from-trunk" in lines 1 and 3 of
Step 2 (i.e., just replace "trunk" with "zaptel" in those lines).

Note that the variable ${CALLERID(num)} is only available in Asterisk 1.2 and later. If you need to manipulate it in other ways, see the section on String Handling
Functions on the Asterisk variables page - for example, to always strip the first digit or character off of incoming Caller ID, you could probably use ${CALLERID(num):1}
(adding the :1 to return all characters AFTER the character in the first position - this could also be used to strip a leading "+" if a provider adds that).

Here's another example, in which digits are both removed and added - in the FreePBX forum, colinjack wrote, "My SIP provider CallerID comes in the format
+44123456789 but my database uses 0123456789 - so I needed to remove the '+44' and add a '0' to the callerid to allow it to query the user database." And he added this to
extensions_custom.conf to accomplish this:
[from-trunk-custom]
exten => _X!,1,Set(CALLERID(num)=0${CALLERID(num):3:12})
exten => _X!,n,Goto(from-trunk,${EXTEN},1)

Then he changed his sip trunk context statement to context=from-trunk-custom

One final example. In this case the provider was sending the CallerID number prefixed with a "+" (plus sign), but there was no assurance that this would always be true. In
order to facilitate using the callback feature on certain phones, it was desired to strip the "+", but only for calls that appeared to be coming from points in the "North
American Numbering Plan Area" (country code 1). So this code tests for "+1" at the start of the CallerID and if it is present, it strips only the first character (the "+"):
[from-trunk-custom]

7 of 89 5/22/2009 11:12 PM
exten => _X!,1,GotoIf($["${CALLERID(num):0:2}" != "+1"]?noplusatstart)
exten => _X!,n,NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):1})
exten => _X!,n,Set(CALLERID(num)=${CALLERID(num):1})
exten => _X!,n(noplusatstart),Goto(from-trunk,${EXTEN},1)

Once again the sip trunk context statement should be changed to context=from-trunk-custom

Just in case anyone wonders, you can use the same custom context (in extensions_custom.conf) for multiple trunks, as long as they originally had the same "context="
destination. Or, if you need to make different changes to the Caller ID from different trunks, then just make multiple custom contexts in extensions-custom.conf, and change
the names slightly (e.g. you could call one from-trunk-add-0-custom and another from-trunk-strip-2-custom, or whatever - just make sure to use the same context name in the
trunk "context=" line and in the header of your custom context).

Finally, for those using naftali5's Dialplan Injection module (which may not install or work correctly with the most recent versions of FreePBX), you can place these code
fragments in a Dialplan Injection instead of extensions_custom.conf. Simply enter the lines beginning with the "Set" or "Goto" command, like this:
Set(CALLERID(num)=0${CALLERID(num)})
Goto(from-trunk,${EXTEN},1)

Then note the number of the dialplan injection (it will be printed in angle brackets next to the injection name in the list of injections), and in your trunk use
context=injection-number where number is the number of the injection. For example, let's say you named the injection as "Change Caller ID", and after you created it you
saw this in the right hand column: Change Caller ID <15> - in your trunk, you'd then use context=injection-15

Added comment by original author: There was a note that briefly appeared on this page that was mostly incorrect (because the person who wrote the note apparently
missed the fact that the added from-trunk-custom context must be created by the user in etc/asterisk/extensions_custom.conf, which is NOT overwritten by FreePBX
updates). The only part of that note that might have been valid was the idea that the line exten => _X!,n,Goto(from-trunk,${EXTEN},1) could perhaps be replaced by
include => from-trunk. I make no comment on the validity of that because I have not tested it; however I did test the method I posted above and it did work. Also, I cannot
offer an explanation for why some users seem to be having problems using this method with Trixbox; since Trixbox has been forked from FreePBX I suppose it may be
possible that they are doing something different that causes the above not to work.

How to create a system-wide speed dial number


The correct way to create a system-wide speed dial number in FreePBX is now a two-step process:

First, create a Misc Destination, then put the number you want to call (with # suffix if it's an outside number) in the dial: text field, e.g. 18005551212#

Then create a Misc Application, put the extension or speed dial number you want to use in the Feature Code: text field, and make the Destination the Misc Destination that
you just created.

So you call the number you specified in the Misc. Application and it routes to the destination you specified in the Misc. Destination. This keeps everything within the
FreePBX interface. Also, you can specify the Misc. Destination from anywhere in FreePBX that you can select a destination, such as from an IVR menu (if that is ALL you
want then you don't even need to create the Misc. Application).

Here's another approach that probably adds more overhead to the call process, but may be more desirable in certain circumstances: Create a Ring Group with only one
number in the group, that being the number you want to call (with # suffix if it's an outside number); then the Ring Group number becomes your speed dial number. While
that method probably uses slightly more processing time on each call, it does give you the ability to use the options associated with Ring Groups (such as specifying the
amount of time to allow the call to ring, or playing Music on Hold instead of a ringing signal to the caller). Perhaps more significantly, if you set the Ring Time to a shorter
time than the called number's voicemail timeout, you can have unanswered calls go to your FreePBX voicemail (or to another FreePBX extension or some other destination
of your choice) rather than the called phone's voicemail, if that's what you'd prefer.

How to execute a custom dial plan fragment before sending a call to a trunk (for
playing an announcement, etc.)
How to execute a custom dial plan fragment before sending a call to a trunk (for playing an announcement, etc.)

In a FreePBX forum post, Alex Edwards wanted to accomplish the following:

"I'd like to warn my FreePBX users when they're dialling an expensive international fixed-line, or worse, international mobile. (This is from the UK).

"I've put a long list of international codes as a route, with a route password - which is a great start.

"However, ideally I'd like to play an explanatory message too - possibly a Misc Destination / Application / Announcement? ....."

In other words, what he wanted to do was execute a bit of custom code (a dial plan fragment) prior to sending the call to a trunk. One way to do this is to use a CUSTOM
trunk. Here's how Alex did it (slightly revised for clarity):

First, you need to add your custom dial plan fragment to extensions_custom.conf (if you have the Dialplan Injection module installed, you could also put this code fragment
there, but for the moment we'll assume you're using extensions_custom.conf). Alex added the following to the top of that file (slightly modified for clarity):
[mobile-warn-custom]

exten => _X.,1,Answer


exten => _X.,n,Wait(1)
exten => _X.,n(begin),Noop(Playing announcement Expensive-Call-Warning)
exten => _X.,n,Playback(custom/International-Mobile-Warning,noanswer)
exten => _X.,n,Wait(1)
exten => _X.,n,Dial(mISDN/g:out/${EXTEN},300)

8 of 89 5/22/2009 11:12 PM
Note that the final line gives the actual destination of the call, and will have to be tweaked for your own particular situation. Also, the Wait statements are probably optional,
or could be made longer than one second if desired. The recording specified in the fourth line (International-Mobile-Warning) is a custom recording that tells the caller that
the call will cost around £1 a minute, so look for a cheaper alternative! You will need to create the recording you want to use, if none of the standard Asterisk recordings will
work in your situation.

Second, create a new CUSTOM trunk. For the Custom Dial String, use the following:
Local/$OUTNUM$@mobile-warn-custom

If you used something other than "mobile-warn-custom" to identify your custom dial plan then be sure to use that here as well. While you are creating your CUSTOM trunk,
mouse over the words "Custom Dial String" and it will show you some suggested formats that might give you an idea of how the "Dial" argument in the final line of your
custom dial plan should read (in case you are having trouble figuring that out).

Finally, create your route, and make sure it has higher priority than all the other routes that might otherwise handle calls to the same numbers. Don't forget to click the orange
bar when finished.

An alternate method was suggested by user stonet. In /etc/asterisk/extensions.conf there is a context called macro-dialout-trunk-predial-hook which, according to comments
in extensions.conf, is "intentially left blank so it may be safely overwritten for any custom requirements that an installation may have" and that any such "customizations to
this dialplan should be made in extensions_custom.conf." What that means is you can create a [macro-dialout-trunk-predial-hook] context in /etc/asterisk
/extensions_custom.conf and it will override the (intentionally blank) context in extensions.conf. The macro is called whenever a call goes out over any trunk, therefore if
you can determine which trunk has been called you can execute your custome dial plan fragment.

That's the approach that stonet took. He wanted to play the message when calls went out on any of three trunks, so rather than giving the trunks names he gave them
numbers. The SIP trunks on which he wanted to play the message he named 7000, 7001, 7002 and 7003, and then he used this code, which should be placed in /etc/asterisk
/extensions_custom.conf:
[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Trunk ${OUT_${DIAL_TRUNK}} selected)
exten => s,n,Gotoif($["${OUT_${DIAL_TRUNK}:0:7}" != "SIP/700"]?skip)
exten => s,n,NoOp(Playing Progress Announcement)
exten => s,n,Playback(pls-hold-while-try,noanswer)
exten => s,n(skip),MacroExit()

Note that the full trunk name is printed on the CLI by the first line, so you can see what needs to be matched in the Gotoif statement. It usually consists of the technology
type, a forward slash, and the trunk name, although that can vary (especially in the case of a Custom trunk). When this method is used, you don't need to create any custom
trunks, and you have more flexibility in the variables you can use for conditional jumps, but you are responsible for making sure that you correctly construct your conditional
Gotos so they do what you need to do. This also assumes that the [macro-dialout-trunk-predial-hook] context will not be used by any other part of FreePBX. If you use this
method, make sure that the last statement in the macro is MacroExit(), and it would probably be a good idea to read some documentation on Asterisk macros before you
begin.

Keep in mind that the Gotoif statement can contain multiple conditions. For example, let's say that the two SIP trunks that we wanted to play an announcement on were
named "voipcompany" and "foobar" - the Gotoif line could then look like this:
exten => s,n,GotoIf($[$["${OUT_${DIAL_TRUNK}" != "SIP/voipcompany"] & $["${OUT_${DIAL_TRUNK}}" != "SIP/foobar"]]?skip)

You can the use & (and), | (or), or ! (logical unary complement) characters. The first two are placed between expressions, while the ! is placed in front of an expression (with
NO space between the ! and the expression) to give the opposite result of the expression (an expression that evaluates to true becomes false, and vise-versa). Usually it's
clearer to just use != in an expression, however. See the page on Asterisk Expressions for more information.

You may want to check the forum thread to see if any additional comments have been posted that may clarify these procedures. The thing we want to illustrate here is that
when you need to add a custom dial plan fragment prior to sending a call to an actual trunk, one way to do it is to use a CUSTOM trunk, send that to your custom dial plan,
and then make the last line of your custom dial plan send the call to an actual trunk or other destination. The other way to do it is to use the [macro-dialout-trunk-
predial-hook] macro call that's already built into FreePBX.

For those who may be trying to duplicate what Alex did, here is the list of numbers that Alex put into the route definition (to play a warning for high cost mobile calls). Note
that this may or may not include all caller-pays mobile prefixes, and that the '9|xxxx.' variants at the bottom of the list are only required if you use 9 for an outside line:
00124235.
00124245.
00124255.
0012687.
00147341.
0017672.
00201.
002126.
002162.
002169.
0021891.
002207.
002209.
002215.
002216.
002226.
002233.
002234.
002235.
002236.
002239.
002246.
002250.
002256.
002267.
002289.
002299.
002307.
002308.
002309.
0023223.
0023230.
0023233.
002327.
0023328.
0023480.
0023490.

9 of 89 5/22/2009 11:12 PM
002389.
0023990.
002402.
002424.
002425.
002426.
0024322.
0024378.
0024381.
0024384.
0024385.
0024386.
0024388.
0024389.
0024390.
0024394.
0024395.
0024396.
0024397.
0024398.
0024399.
002456.
002457.
002485.
002487.
002499.
0025008.
0025191.
002538.
002547.
0025574.
002567.
002577.
002588.
002609.
002613.
0026311.
0026323.
0026391.
002658.
002659.
0026658.
002666.
002677.
0026860.
002693.
00277.
00278.
002917.
0030693.
0030694.
0030697.
0030699.
00316.
003247.
003248.
003249.
00336.
00346.
0035058.
003519.
00352621.
00352628.
00352661.
00352668.
00352691.
00352698.
003538.
003546.
003548.
003556.
0035679.
0035699.
0035796.
0035797.
0035799.
003584.
0035850.
0035948.
0035987.
0035988.
0035989.
003620.
003630.
003670.
003706.
003725.
0037365.
0037368.
0037369.
0037376.
0037378.
0037379.
003749.
0037525.
0037529.
0037533.
0037544.
003774.
003776.
0037866.
0038039.
0038050.
0038063.

10 of 89 5/22/2009 11:12 PM
0038066.
0038067.
0038068.
0038097.
00381377.
003816.
003826.
003859.
0038761.
0038762.
0038763.
0038765.
0038970.
0038971.
0038975.
0038976.
0038977.
0038978.
0039328.
0039329.
0039333.
0039338.
0039339.
0039340.
0039347.
0039348.
0039349.
0039393.
00407.
004174.
004176.
004177.
004178.
004179.
0042060.
0042072.
0042073.
0042077.
004219.
004237.
0043650.
0043660.
0043664.
0043676.
0043680.
0043681.
0043688.
0043699.
004475.
004477.
004478.
004479.
004530.
004540.
00467.
00474.
00479.
004850.
004851.
004860.
004866.
004869.
004872.
004878.
004879.
004888.
004915.
004916.
004917.
0049700.
005016.
005024.
005025.
005037.
005043.
005048.
005049.
005058.
005063.
005074.
005075.
005076.
005077.
00519.
00521.
00535.
005415.
00557.
00558.
00559.
005698.
005699.
005731.
00584.
005917.
005926.
005938.
005939.
005959.
005978.
0059894.
0059896.
0059898.
0059899.

11 of 89 5/22/2009 11:12 PM
00601.
00614.
00628.
00639.
006420.
006421.
006424.
006425.
006427.
006428.
006429.
00658.
00659.
00661.
00669.
006707.
006738.
00674555.
0067568.
0067569.
006784.
006785.
006799.
0068577.
007300.
007333.
00770.
007777.
0079.
008170.
008180.
008190.
008210.
008211.
008216.
008217.
008218.
008219.
00849.
008523.
008526.
008528.
008529.
008536.
008559.
0085620.
008613.
008615.
0088016.
0088017.
00880181.
0088019.
008869.
00905.
009192.
009193.
009194.
009197.
009198.
009199.
009230.
009231.
009232.
009233.
009234.
009235.
009236.
009375.
00947.
00959.
009607.
009609.
009613.
0096170.
0096171.
009627.
009639.
009656.
009657.
009659.
0096650.
0096654.
0096655.
0096656.
009677.
00968968.
0097059.
0097150.
0097155.
009725.
009733.
009745.
009746.
0097517.
009769.
0097798.
00989.
009929.
009945.
009957.
009959.
009965.
009989.
9|00124235.

12 of 89 5/22/2009 11:12 PM
9|00124245.
9|00124255.
9|0012687.
9|00147341.
9|0017672.
9|00201.
9|002126.
9|002162.
9|002169.
9|0021891.
9|002207.
9|002209.
9|002215.
9|002216.
9|002226.
9|002233.
9|002234.
9|002235.
9|002236.
9|002239.
9|002246.
9|002250.
9|002256.
9|002267.
9|002289.
9|002299.
9|002307.
9|002308.
9|002309.
9|0023223.
9|0023230.
9|0023233.
9|002327.
9|0023328.
9|0023480.
9|0023490.
9|002389.
9|0023990.
9|002402.
9|002424.
9|002425.
9|002426.
9|0024322.
9|0024378.
9|0024381.
9|0024384.
9|0024385.
9|0024386.
9|0024388.
9|0024389.
9|0024390.
9|0024394.
9|0024395.
9|0024396.
9|0024397.
9|0024398.
9|0024399.
9|002456.
9|002457.
9|002485.
9|002487.
9|002499.
9|0025008.
9|0025191.
9|002538.
9|002547.
9|0025574.
9|002567.
9|002577.
9|002588.
9|002609.
9|002613.
9|0026311.
9|0026323.
9|0026391.
9|002658.
9|002659.
9|0026658.
9|002666.
9|002677.
9|0026860.
9|002693.
9|00277.
9|00278.
9|002917.
9|0030693.
9|0030694.
9|0030697.
9|0030699.
9|00316.
9|003247.
9|003248.
9|003249.
9|00336.
9|00346.
9|0035058.
9|003519.
9|00352621.
9|00352628.
9|00352661.
9|00352668.
9|00352691.
9|00352698.
9|003538.

13 of 89 5/22/2009 11:12 PM
9|003546.
9|003548.
9|003556.
9|0035679.
9|0035699.
9|0035796.
9|0035797.
9|0035799.
9|003584.
9|0035850.
9|0035948.
9|0035987.
9|0035988.
9|0035989.
9|003620.
9|003630.
9|003670.
9|003706.
9|003725.
9|0037365.
9|0037368.
9|0037369.
9|0037376.
9|0037378.
9|0037379.
9|003749.
9|0037525.
9|0037529.
9|0037533.
9|0037544.
9|003774.
9|003776.
9|0037866.
9|0038039.
9|0038050.
9|0038063.
9|0038066.
9|0038067.
9|0038068.
9|0038097.
9|00381377.
9|003816.
9|003826.
9|003859.
9|0038761.
9|0038762.
9|0038763.
9|0038765.
9|0038970.
9|0038971.
9|0038975.
9|0038976.
9|0038977.
9|0038978.
9|0039328.
9|0039329.
9|0039333.
9|0039338.
9|0039339.
9|0039340.
9|0039347.
9|0039348.
9|0039349.
9|0039393.
9|00407.
9|004174.
9|004176.
9|004177.
9|004178.
9|004179.
9|0042060.
9|0042072.
9|0042073.
9|0042077.
9|004219.
9|004237.
9|0043650.
9|0043660.
9|0043664.
9|0043676.
9|0043680.
9|0043681.
9|0043688.
9|0043699.
9|004475.
9|004477.
9|004478.
9|004479.
9|004530.
9|004540.
9|00467.
9|00474.
9|00479.
9|004850.
9|004851.
9|004860.
9|004866.
9|004869.
9|004872.
9|004878.
9|004879.
9|004888.
9|004915.
9|004916.

14 of 89 5/22/2009 11:12 PM
9|004917.
9|0049700.
9|005016.
9|005024.
9|005025.
9|005037.
9|005043.
9|005048.
9|005049.
9|005058.
9|005063.
9|005074.
9|005075.
9|005076.
9|005077.
9|00519.
9|00521.
9|00535.
9|005415.
9|00557.
9|00558.
9|00559.
9|005698.
9|005699.
9|005731.
9|00584.
9|005917.
9|005926.
9|005938.
9|005939.
9|005959.
9|005978.
9|0059894.
9|0059896.
9|0059898.
9|0059899.
9|00601.
9|00614.
9|00628.
9|00639.
9|006420.
9|006421.
9|006424.
9|006425.
9|006427.
9|006428.
9|006429.
9|00658.
9|00659.
9|00661.
9|00669.
9|006707.
9|006738.
9|00674555.
9|0067568.
9|0067569.
9|006784.
9|006785.
9|006799.
9|0068577.
9|007300.
9|007333.
9|00770.
9|007777.
9|0079.
9|008170.
9|008180.
9|008190.
9|008210.
9|008211.
9|008216.
9|008217.
9|008218.
9|008219.
9|00849.
9|008523.
9|008526.
9|008528.
9|008529.
9|008536.
9|008559.
9|0085620.
9|008613.
9|008615.
9|0088016.
9|0088017.
9|00880181.
9|0088019.
9|008869.
9|00905.
9|009192.
9|009193.
9|009194.
9|009197.
9|009198.
9|009199.
9|009230.
9|009231.
9|009232.
9|009233.
9|009234.
9|009235.
9|009236.
9|009375.

15 of 89 5/22/2009 11:12 PM
9|00947.
9|00959.
9|009607.
9|009609.
9|009613.
9|0096170.
9|0096171.
9|009627.
9|009639.
9|009656.
9|009657.
9|009659.
9|0096650.
9|0096654.
9|0096655.
9|0096656.
9|009677.
9|00968968.
9|0097059.
9|0097150.
9|0097155.
9|009725.
9|009733.
9|009745.
9|009746.
9|0097517.
9|009769.
9|0097798.
9|00989.
9|009929.
9|009945.
9|009957.
9|009959.
9|009965.
9|009989.

How to get the DID of a SIP trunk


Duplicated Page
This was an inadvertently duplicated page, left in place in case you got here from a search engine or followed a menu link on this site. Please follow this link to reach the page
you want.

How to get the DID of a SIP trunk when the provider doesn't send it (and why
some incoming SIP calls fail)
How to get the DID of a SIP trunk when the provider doesn't send it (and why
some incoming SIP calls fail)
The symptom: On a SIP trunk, you can't get an inbound route to work - it just doesn't seem to recognize the number. You might be able to get the call to come in on your any
DID/any CID route, or maybe the call doesn't get answered at all. When you type sip debug from the CLI, you can see (when you scroll back to the point where the call
came in) that a sip INVITE packet arrived, and perhaps it contained the DID number in the sip To: header (in the form To: <sip:NUMBER@IP ADDRESS>), but you also
see that the FROM_DID was set to s. In other words, you see a line that looks like this:
-- Executing Set("SIP/9995552368-09876543", "FROM_DID=s") in new stack

Before you attempt anything else, you may want to try this suggestion by Dan Swartz: Check the registration string (in the trunk settings for the provider), and if it's not
already there, try putting the DID at the end of the registration string, prefixed by a '/'. It may (or may not) require a leading '1' too. e.g. '/18005551212' (or your country code
if you are not in the U.S./Canada, etc.). So, your registration string would take this format:
accountid:password@your.provider/yourDIDnumber

Remember to try your DID both with and without the country code prefix. If this doesn't work, it's time to try a workaround (however, you may want to read the
addendum at the bottom of this article first!). Perhaps you can see the DID number in the sip INVITE packet's To: header, but the CLI reveals that Asterisk isn't picking it
up, and therefore it goes to your default inbound route.

(Oh, and for anyone who's still trying to figure out how to turn off sip debugging, the CLI command is sip no debug)

Fortunately this isn't a hard thing to work around, as long as the DID number really is in the sip To: header.

NOTE: In the following examples, we now use the s extension rather than _. - this is considered better practice (and safer) but the disadvantage is that the context will fail if
the provider is sending any type of DID, even if it's incorrect or incomplete. If the code doesn't seem to work, try replacing the s extension with _X! (the extension is to the
right of the => and space characters).

First, create a context in extensions_custom.conf that looks like this:


[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${SIP_HEADER(To)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,@,1)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,:,2)})
exten => s,n,Goto(from-trunk,${pseudodid},1)

16 of 89 5/22/2009 11:12 PM
Or, thanks to naftali5, you can cut the above down to one line of code that does the same thing, but is a bit less obvious to the casual reader:
[custom-get-did-from-sip]
exten => s,1,Goto(from-trunk,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

(And speaking of naftali5, if you are using his Dialplan Injection module - which may not work with the most recent versions of FreePBX, so don't run out and get it if you
aren't already using it unless you are sure it has been updated to work with the version of FreePBX that you are using - and want to put the above line in the Destination
section, then you will need to use a slightly different syntax, changing the commas to bar characters, so it looks like this:
* Custom App: from-trunk,${CUT(CUT(SIP_HEADER(To)|@|1)|:|2)},1

The part after Custom App: is what you paste into the text box. This ONLY applies to Dialplan Injection users)

Then, in the trunk associated with the provider, change the trunk context statement (which should read context=from-trunk) to:
context=custom-get-did-from-sip

(Or for Dialplan Injection users, just use


context=injection-n

but replace n with the actual injection number, which will appear next to the injection name in the right-hand column menu of injections.)

And note that with such providers, you may have to move that context statement from the USER details to the PEER details section. This is why calls from some SIP
providers sometimes fail to come in at all - they effectively never "see" the User context and details, therefore they don't see the context statement there and have nowhere to
go. It's also why you sometimes see instructions for sip providers that leave the User context and User details sections totally blank, but include a context statement in the
peer details - in most such cases it's because the provider is treating the customer as an end user (like someone using a softphone or a VoiP adapter) rather than as a peer, and
they aren't sending DID information.

The above instructions may also solve the problem where you have two (or more) trunks from the same provider, but Asterisk always treats it as if all calls are coming in on
one of the two trunks, therefore again not allowing you to set up separate inbound routes for each trunk. As long as the provider sends the number in the sip To header, the
above code should set the DID properly.

If the first part of the To: statement is something other than a DID number (a user name, for example), then you may have to add a line just before the final Goto statement.
For example, let's say the provider is sending To: <sip:Fred@IP ADDRESS> and your DID number (or at least, the number you want to use to denote your inbound route)
is really 5551212. You'd then use code similar to this:
[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(To),@,1),:,2)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="Fred"]?5551212:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, as long as you only have ONE trunk from that provider, you could always just cheat a little and hardcode the desired DID in a separate custom context, like this:
[custom-stupid-provider]
exten => s,1,Noop(Fixing DID to 5551212)
exten => s,n,Goto(from-trunk,5551212,1)

And use the name of this context in the trunk settings. I hear you asking, why not just do it this way on all trunks with this issue? Well, because if you add a second trunk
from the same provider, this won't work correctly for both trunks, and if you ever change your number and then forget what you've done and just try to set your inbound
route to the new number, it won't work. And besides all that, if you have more than one SIP provider that doesn't send proper DID, you'd have to create a separate custom
context for each of them, instead of having one custom context that works for all of them.

One final note for Free World Dialup users, you may find that sip calls will still not come in until you put the following statement in sip.conf:
insecure=invite

I have no idea why that works, but it seems to make a difference.

What if the provider doesn't send the number in the sip To: header?
There is at least one provider that actually sends a s character instead of a number in the sip To: header. What can you do with a provider like that? Well, all may not be lost.
If you only have a single trunk from that provider, you can just use the "cheat" shown above, since it doesn't rely on the contents of the sip headers. If, however, you have
TWO or more trunks from the same provider, you can do a sip debug from the CLI and watch as calls come in on each trunk and note whether there are any consistent
differences.

For example, if you have two lines on the same account, the provider will often assume that you are using a VoIP adapter (such as a Sipura or Linksys) and will use port 5060
for line 1, and port 5061 for line 2. That difference might show up in the headers of the sip INVITE packet, for example:
Via: SIP/2.0/UDP 111.222.333.444:5060;branch=z9hQ4bK67sc0a8e;rport

In this case, you see that there is a colon (:) before the port number and a semicolon following, and that there are actually TWO colons on the line before the port number, so
maybe this would work:
[custom-really-stupid-provider]
exten => s,1,Noop(Fixing DID using port from SIP VIA header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(Via),;,1),:,3)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:${pseudodid})})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5061"]?5552222:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, if you only have two trunks from this provider, you probably could just condense the two test lines into one, by testing for one port number and assuming the other if the
conditional test fails, like this:
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:5552222)})

Note that the code in this section is untested, it's just to give you some ideas about how to possibly handle the really oddball situation were you have two (or more) lines from
the same provider, and cannot find any other way to differentiate them. And, don't automatically assume you have a bigger problem than you actually have - for example, it

17 of 89 5/22/2009 11:12 PM
may well be that having different port numbers on the different trunks would allow Asterisk to distinguish them enough that the simple "cheat" method would work (you'd
have to make one for each trunk, of course).

Again, if a particular piece of code doesn't seem to work at all, try replacing
exten => s, . . . . .
with
exten => _X!, . . . . .
in all lines of the context (just in case the provider is sending some unknown number). But if that works, you should consider using whatever the provider is actually sending
as the DID for your Inbound Route, which would eliminate the need for this extra code altogether.

Addendum
There are a few other reasons that incoming calls may fail that have nothing to do with the main topic of this How-To, but are common enough that they should be mentioned
anyway. The first is that in every trunk configuration, there must be a statement that reads:
context=from-trunk
Some providers will tell you to set the context statement to something else - don't do it (unless you have a valid reason, such as following the instructions above). Providers
are generally more familiar with Asterisk than FreePBX, and often don't realize that you can't just use any context name you like in FreePBX unless you also create that
context somewhere (usually extensions_custom.conf).

Also the placement of that context= statement can be important. If a provider is treating you as an extension (which would likely be the case if most of their customers use
VoIP adapters and/or you are a "Bring Your Own Device" customer) then in most cases you will not need to have a USER context or USER details at all in your trunk, but
you still need to have a context=from-trunk statement (or another context= statement if you are following instructions elsewhere on this page) and in this case it will need
to be in your PEER details, not your user details. So, if incoming calls aren't working, try putting context=from-trunk in your trunk PEER details, and if that works, then
totally remove the USER context and USER settings from your trunk configuration, since they aren't doing any good anyway.

To further complicate matters, I have noted that with a couple of providers, nothing seems to work until you do the following. The symptom typically is that you have no
problem connecting with other providers, and (if you have tried this) you have no problem connecting with the provider in question if you are using an external hardware
device (such as an ATA), but no matter what you do you can't receive calls from the provider. I hate recommending this because I don't know exactly why it works, but it's a
trick I've used for a couple years now to resolve issues with a couple of specific providers. Don't try this until you've first tried adding the DID at the end of the registration
string, prefixed by a '/', as shown near the top of this page.

Open the file /etc/asterisk/sip_general_custom.conf in any text editor and check to see if the following lines are in there:
bindport = 5060 ; Port to bind to (SIP is 5060)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
insecure=invite
tos=0x68
srvlookup=no

If any of the above lines are missing, add them to the file. In my experience these lines will not cause problems with other providers but they do magically get things working
with a select few providers that are more used to serving customers using an ATA than through a trunk into an Asterisk box. If this gets things working you can try removing
lines one at a time to find out which are actually doing the trick, or you can just leave them all in place - as I say, in my experience they don't seem to cause problems with
other providers, although obviously your experience might be different.

Yet another issue that you may encounter, especially if you are upgrading from an earlier version of FreePBX, is that if you have disallow= and allow= statements in your
trunk configuration (to specify the use of particular codecs), starting with Asterisk 1.4 the disallow= statement(s) (particularly if it's disallow=all) must be placed above the
allow= statements. This is one of many cases where Asterisk upgrades have broken existing functionality for no good reason whatsoever, other than that the Asterisk
developers could not be bothered to ensure backward compatibility.

One other note: There is an obscure bug in Asterisk that can cause incoming calls to fail. If Asterisk ever receives a Caller ID NAME that contains only one quotation mark
(usually a name with a quotation mark at the start of the string but not at the end) it will not handle the call properly, and may ignore the incoming call completely.

Additional Reference:
Asterisk SIP channels

How to give a particular extension different or restricted trunk access for


outgoing calls
How to give a particular extension different or restricted trunk access for
outgoing calls
NOTE: Unlike some of the how-tos in this section, this one is written for those who have some experience with adding contexts to /etc/asterisk
/extensions_custom.conf or some familiarity with Asterisk dial plans. It is not as much a "cookbook" type of document as suggestions on how to reach the goal of
giving a particular extension different or restricted trunk access for certain types of outgoing calls. I am not saying that the ways I show here are the only ways, or
even necessarily the best ways to accomplish this goal. If you can improve on what I have written, please leave a comment - I may incorporate it into the main text
(with credit to you, of course).

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

18 of 89 5/22/2009 11:12 PM
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. 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.

Restricting Outgoing Calls


Let's deal with restricting outgoing calls first. Before going any further, I will mention for the benefit of expert users that Rob Thomas has developed an Outbound Route
Permissions module for FreePBX, that allows you to block access to certain routes from specified extensions. You can do bulk changes on the Route Extensions
configuration page, and you can individually change access to routes on the extension's page. At this point (May, 2009) this is still an unsupported module in the first stages
of development.

Having said that, there was an article in Moshe's blog entitled Restricting outbound calls in FreePBX (blacklist). That approach allows one to blacklist calls system-wide, but
it does not allow calls to be passed or blocked selectively depending on the calling extension. But shortly thereafter, Moshe came out with a second blog post, Restricting
outbound calls in FreePBX (whitelist), which not only does allow calls to be passed or blocked selectively depending on the calling extension, but also allows you to
"whitelist" certain numbers (in case you want the "restricted" extensions to be able to dial certain number despite the restrictions). Moshe takes a slightly different approach
than what I do below - Moshe allows you to restrict on a per-extension basis, but the restriction is for ALL routes with the only exceptions being the specific "whitelisted"
numbers. My approach (as well as that of the aforementioned Outbound Route Permissions module) assumes you may only want to restrict access to some routes. It also
allows you to restrict on a per-extension basis, but the restriction is then only applied to specific routes that you wish to restrict (calls to numbers in non-restricted routes can
still go through).

Before we begin, it would be good if you had a solid mastery of the difference between routes and trunks, and how they interact. If you have not already done so, I suggest
you read Hints on Route Dial Patterns and Trunk Dial Rules.

Here's one way to set up a restriction: Use a text editor (nano, Midnight Commander's editor, etc.) to add the following two dialplan fragments to /etc/asterisk
/extensions_custom.conf (note, if your extensions can pass the # character to Asterisk then change all instances of _[*0-9]! to _[*#0-9]! - adding the # character - this applies
to all examples on this page):
[custom-restricted-ext1]
exten => 911,1,Noop(Allowing unrestricted 911 call)
exten => 911,n,Goto(from-internal,${EXTEN},1)
exten => _[*0-9]!,1,Noop(Using Call Restriction 1)
exten => _[*0-9]!,n,Set(_RestrictedExt1=TRUE)
exten => _[*0-9]!,n,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[custom-restricted-trunk1]
exten => _[*0-9]!,1,Noop(Testing for Call Restriction 1 ${RestrictedExt1})
exten => _[*0-9]!,n,GotoIf($["${RestrictedExt1}" = "TRUE"]?restrict1:norestrict1)
exten => _[*0-9]!,n(restrict1),Noop(Call blocked due to call restriction: 1)
exten => _[*0-9]!,n,Playback(feature-not-avail-line,noanswer)
exten => _[*0-9]!,n,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,n(norestrict1),Noop(No call restriction: 1)
exten => h,1,Hangup()

In the code above, change both instances of 911 to your local emergency number if it is something other than 911, or remove those two lines completely if you do not wish to
permit the restricted extensions to make emergency calls (doing that is NOT recommended except in very special circumstances).

After adding this additional code to extensions-custom.conf, create a new custom trunk with the Custom Dial string Local/$OUTNUM$@custom-restricted-trunk1 , then
go into any Outbound Route to which you wish to restrict access, and move that new custom trunk to the top of the trunk list (or second from the top if you have an ENUM
trunk at the top, assuming that you don't care if a free ENUM call actually goes through).

The go into any extension that you wish to restrict and change the context from from-internal to custom-restricted-ext1. After saving all the configuration changes, you
should be able to place a test call that would use the restricted route. You should hear the "That feature is not available on this line" recording (the most appropriate one I
could find among the standard recordings supplied with FreePBX).

If you wanted to have different restrictions for different extensions, you could just make additional contexts. Here's an example for use with a second group of restricted
extensions:
[custom-restricted-ext2]
exten => 911,1,Noop(Allowing unrestricted 911 call)
exten => 911,n,Goto(from-internal,${EXTEN},1)
exten => _[*0-9]!,1,Noop(Using Call Restriction 2)
exten => _[*0-9]!,n,Set(_RestrictedExt2=TRUE)
exten => _[*0-9]!,n,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[custom-restricted-trunk2]
exten => _[*0-9]!,1,Noop(Testing for Call Restriction 2 ${RestrictedExt2})
exten => _[*0-9]!,n,GotoIf($["${RestrictedExt2}" = "TRUE"]?restrict2:norestrict2)
exten => _[*0-9]!,n(restrict2),Noop(Call blocked due to call restriction: 2)
exten => _[*0-9]!,n,Playback(feature-not-avail-line,noanswer)
exten => _[*0-9]!,n,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,n(norestrict2),Noop(No call restriction: 2)
exten => h,1,Hangup()

For this second group you'd then create another custom trunk with the Custom Dial string Local/$OUTNUM$@custom-restricted-trunk2. Then, at the top of the trunk list
for any route, you could add either or both of your custom trunks, depending on which groups of extensions you wanted to restrict from using that particular trunk.

This approach does not incorporate a specific "whitelist" feature, however if you wanted to whitelist certain numbers (so they could be called even by "restricted" extensions)
and those numbers happen to match one of your "restricted" routes, simply create a new outbound route similar to the restricted one, but that contains only the "whitelisted"
numbers listed in the Dial Patterns text box, and that duplicates the trunk list of the restricted route - except, of course, you do not include your custom trunk that enforces
the restriction! Make that route higher in priority than the restricted route. Since you are only matching the "whitelisted" numbers in that route, it will allow calls to those
specific numbers go through without restriction. Of course, you could use patterns rather than specific numbers if you wanted to do something like un-restrict an entire area
code, or entire telephone exchange prefix.

A possible alternative approach to restricting outgoing calls (for advanced users only)

Although I have not attempted to use this method, I just wanted to point out that there is an alternative approach that could possibly be used that would potentially eliminate
the need to change the context in extensions or to use custom trunks. In the file /etc/asterisk/extensions.conf there is a context called macro-dialout-trunk-predial-hook

19 of 89 5/22/2009 11:12 PM
which, according to comments within that file, is "intentially left blank so it may be safely overwritten for any custom requirements that an installation may have" and that
any such "customizations to this dialplan should be made in extensions_custom.conf." What that means is you can create a [macro-dialout-trunk-predial-hook] context in
/etc/asterisk/extensions_custom.conf and it will override the (intentionally blank) context in extensions.conf. The macro is called whenever a call goes out over any trunk,
therefore if you can determine which trunk is being used and which extension is placing the call, you can determine whether the call should be blocked.

Unfortunately, by the time that a call reaches the trunk, the original calling extension number is apparently not preserved except as part of the CHANNEL variable (the
CALLERID(number) variable may be an acceptable substitute in certain situations). And if a call is forwarded, the number of the extension that's actually doing the
forwarding may or may not be found in the DIALEDPEERNUMBER variable. You can test to see what variables are available by adding the following code to /etc/asterisk
/extensions_custom.conf
[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Trunk ${OUT_${DIAL_TRUNK}} selected)
exten => s,n,Macro(dumpvars)
exten => s,n,MacroExit()

Place a test call that uses a trunk and watch the CLI and you will see some of the available and the current contents of those variables. Note that the full trunk name is
printed on the CLI by the first line. By editing [macro-dialout-trunk-predial-hook] you can set up conditional statements, such that if a call from a particular extension
(extracted from the CHANNEL variable) is being sent to a particular trunk, you can restrict it.

If you use this method, make sure that the last statement in the macro is MacroExit(), and it would probably be a good idea to read some documentation on Asterisk macros
before you begin. Also, keep in mind that the Gotoif statement can contain multiple conditions. For example, the Gotoif line could look something like this like this:
exten => s,n,GotoIf($[$["${OUT_${DIAL_TRUNK}" != "SIP/restrictedtrunk"] & $["${CHANNEL:0:7}" != "SIP/234"]]?skip)

...which would jump to the label "skip" unless the trunk name was "restrictedtrunk" and the call originated on channel "SIP/234..." (presumably extension 234).

The page on Asterisk Expressions gives more information on connecting expressions with logical operators such as & (and) and | (or).

Different Routes for Different Extensions


The above code will only restrict calls. It will NOT handle the case where (for example) you have two companies using the same FreePBX system, and you want one
company's calls to go out on one route while the other company's calls use a different route. The problem is that FreePBX will only attempt to use one route for outgoing calls
that match a specific dial pattern - once a dial pattern has been matched with a route, it will not try additional routes. So, you can restrict certain extensions from using a
particular route, but it's a lot harder to make FreePBX try a different route that would match the same dial pattern. You CAN do things like this using the unsupported
Custom Contexts module (if it still works with the version of FreePBX you are using). You can also do it using the aforementioned Outbound Route Permissions module for
FreePBX - as noted above, at this point (May, 2009) this is still an unsupported module in the first stages of development.

Both the Outbound Route Permissions module and the method I am about to describe use route prefixes to select the desired route. To help you understand this technique,
you may wish to read the document Basic usage of route prefixes to reroute calls from specific extensions.

Here's an approach (to making some extensions use one route and some another) that I've used in the past, before the Outbound Route Permissions module was available
(even if you don't plan to use this method, you may wish to read on because the basic technique is very similar). First, I made a duplicate of a particular outbound route (using
a different route name, of course). In the duplicated route, I changed the trunk selections. I kept the dial patterns the same, except that in front of every line in the dial
patterns I added a few more digits followed by a bar character (example, if the original route contained a pattern such as 1NXXNXXXXXX, the duplicated route contained
0000999|1NXXNXXXXXX - I like to use patterns with a few zeroes in front because no real number begins with several zeroes. Note I had to add the 0000999| to the start
of EVERY line in the dial patterns of the duplicated route).

So now I had two routes, the general one with the truck selections used by most extensions (and with the "normal" dial plan), and the duplicated one which contained the
trunk selections I wanted to use with a particular extension, and with the modified dial plan.

In addition, I also made a separate route for 911 calls from that one extension (I'm using 911 here, substitute your local emergency number if it is different) - in that route I
added the dial pattern 0000999|911 and set up the trunk selection for 911 calls from that extension. If you want all your 911 calls to go out the same trunk(s) regardless of
which extension they came from, then you could just add the 0000999|911 pattern to your existing 911 route. Just remember that your emergency routes should be the
highest priority (at the top of the routes list).

Next I added this to /etc/asterisk/extensions_custom.conf:


[custom-trunk-selector-1]
exten => _[*0-9]!,1,Set(restprefix=0000999)
exten => _[*0-9]!,n,Set(sysextlen=3)
exten => _[*0-9]!,n,Goto(custom-trunk-selector,${EXTEN},1)
exten => h,1,Hangup()

[custom-trunk-selector]
exten => 911,1,Goto(from-internal,${restprefix}${EXTEN},1)
exten => _1NXXNXXXXXX,1,Goto(from-internal,${restprefix}${EXTEN},1)
exten => _NXXNXXXXXX,1,Goto(from-internal,${restprefix}${EXTEN},1)
exten => _NXXXXXX,1,Goto(from-internal,${restprefix}${EXTEN},1)
exten => _*72!,1,Goto(custom-app-cf-on-rest,${EXTEN},1)
exten => _*90!,1,Goto(custom-app-cf-busy-on-rest,${EXTEN},1)
exten => _*52!,1,Goto(custom-app-cf-unavailable-on-rest,${EXTEN},1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[custom-app-cf-on-rest]
exten => *72,1,Answer
exten => *72,n,Wait(1)
exten => *72,n,Macro(user-callerid,)
exten => *72,n,Playback(call-fwd-unconditional)
exten => *72,n(startread),Playback(ent-target-attendant)
exten => *72,n,Read(toext,then-press-pound,,,,)
exten => *72,n,GotoIf($["foo${toext}"="foo"]?startread)
exten => *72,n,Wait(1)
exten => *72,n,Set(saytoext=${toext})
exten => *72,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefix)
exten => *72,n,Set(toext=${restprefix}${toext})
exten => *72,n(noprefix),Set(DB(CF/${AMPUSER})=${toext})
exten => *72,n,Playback(call-fwd-unconditional&for&extension)
exten => *72,n,SayDigits(${AMPUSER})
exten => *72,n,Playback(is-set-to)
exten => *72,n,SayDigits(${saytoext})

20 of 89 5/22/2009 11:12 PM
exten => *72,n,Macro(hangupcall,)
exten => _*72.,1,Answer
exten => _*72.,n,Wait(1)
exten => _*72.,n,Macro(user-callerid,)
exten => _*72.,n,Set(toext=${EXTEN:3})
exten => _*72.,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefx)
exten => _*72.,n,Set(toext=${restprefix}${toext})
exten => _*72.,n(noprefx),Set(DB(CF/${AMPUSER})=${toext})
exten => _*72.,n,Playback(call-fwd-unconditional&for&extension)
exten => _*72.,n,SayDigits(${AMPUSER})
exten => _*72.,n,Playback(is-set-to)
exten => _*72.,n,SayDigits(${EXTEN:3})
exten => _*72.,n,Macro(hangupcall,)
exten => h,1,Hangup()

[custom-app-cf-busy-on-rest]
exten => *90,1,Answer
exten => *90,n,Wait(1)
exten => *90,n,Macro(user-callerid,)
exten => *90,n,Playback(call-fwd-on-busy)
exten => *90,n(startread),Playback(ent-target-attendant)
exten => *90,n,Read(toext,then-press-pound,,,,)
exten => *90,n,GotoIf($["foo${toext}"="foo"]?startread)
exten => *90,n,Wait(1)
exten => *90,n,Set(saytoext=${toext})
exten => *90,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefix)
exten => *90,n,Set(toext=${restprefix}${toext})
exten => *90,n(noprefix),Set(DB(CFB/${AMPUSER})=${toext})
exten => *90,n,Playback(call-fwd-on-busy&for&extension)
exten => *90,n,SayDigits(${AMPUSER})
exten => *90,n,Playback(is-set-to)
exten => *90,n,SayDigits(${saytoext})
exten => *90,n,Macro(hangupcall,)
exten => _*90.,1,Answer
exten => _*90.,n,Wait(1)
exten => _*90.,n,Macro(user-callerid,)
exten => _*90.,n,Set(toext=${EXTEN:3})
exten => _*90.,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefx)
exten => _*90.,n,Set(toext=${restprefix}${toext})
exten => _*90.,n(noprefx),Set(DB(CFB/${AMPUSER})=${toext})
exten => _*90.,n,Playback(call-fwd-on-busy&for&extension)
exten => _*90.,n,SayDigits(${AMPUSER})
exten => _*90.,n,Playback(is-set-to)
exten => _*90.,n,SayDigits(${EXTEN:3})
exten => _*90.,n,Macro(hangupcall,)
exten => h,1,Hangup()

[custom-app-cf-unavailable-on-rest]
exten => *52,1,Answer
exten => *52,n,Wait(1)
exten => *52,n,Macro(user-callerid,)
exten => *52,n,Playback(call-fwd-no-ans)
exten => *52,n(startread),Playback(ent-target-attendant)
exten => *52,n,Read(toext,then-press-pound,,,,)
exten => *52,n,GotoIf($["foo${toext}"="foo"]?startread)
exten => *52,n,Wait(1)
exten => *52,n,Set(saytoext=${toext})
exten => *52,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefix)
exten => *52,n,Set(toext=${restprefix}${toext})
exten => *52,n(noprefix),Set(DB(CFU/${AMPUSER})=${toext})
exten => *52,n,Playback(call-fwd-no-ans&for&extension)
exten => *52,n,SayDigits(${AMPUSER})
exten => *52,n,Playback(is-set-to)
exten => *52,n,SayDigits(${saytoext})
exten => *52,n,Macro(hangupcall,)
exten => _*52.,1,Answer
exten => _*52.,n,Wait(1)
exten => _*52.,n,Macro(user-callerid,)
exten => _*52.,n,Set(toext=${EXTEN:3})
exten => _*52.,n,GotoIf($[${LEN(${toext})} <= ${sysextlen}]?noprefx)
exten => _*52.,n,Set(toext=${restprefix}${toext})
exten => _*52.,n(noprefx),Set(DB(CFU/${AMPUSER})=${toext})
exten => _*52.,n,Playback(call-fwd-no-ans&for&extension)
exten => _*52.,n,SayDigits(${AMPUSER})
exten => _*52.,n,Playback(is-set-to)
exten => _*52.,n,SayDigits(${EXTEN:3})
exten => _*52.,n,Macro(hangupcall,)
exten => h,1,Hangup()

Then in the extension setup for that particular extension, I changed the context from from-internal to custom-trunk-selector-1.

In custom-trunk-selector-1, I define the restriction prefix and the length of extensions on the system (the length is only used for call forwarding - set it to the maximum
length of a local extension number on your system). Note that for additional restrictions you could make more of these short contexts with different restriction prefixes.

In the main custom-trunk-selector context I send 911 (emergency) calls, and 11, 10, and 7 digit calls to from-internal, but with the restriction prefix prepended. I will point
out that the 911 line is not necessary if you don't need special routing for 911 calls from any restricted extension, but if you use it make sure that there is a valid 911 route
for every restricted extension! In this case I did want to force 911 calls from the restricted extension to use the specific trunk assigned to that extension.

So, when the user of the restricted extension places a call, it first goes to the customized context to see if it appears to be a 911 call or an 11, 10, or 7 digit number in North
America (the first four lines of the context) - if so it prepends our unique code (0000999 in this case) to the front of the number before sending it on to from-internal. If it is a
call forwarding activation code (*72, *90, or *52) it goes to a modified version of the dialplan that handles call forwarding setup (see further discussion below). If it matches
any other pattern (the last line of the context), the number goes to from-internal unchanged.

When a call that has matched a NANP pattern gets to the routing tables, it will skip the "normal" route and go to the route to which I prepended the 0000999| to the front of
each entry in the dial patterns. The | (vertical bar) character tells the route to strip off the 0000999 before sending the call on to the trunk.

Note the above is rather simplistic and may require more tweaking to get the results you want. If there is a particular route that you want used by ALL extensions (for
example, your outbound route for toll-free calls), but the entries in that route's dial plan are a partial match for the patterns in the customized context, you can simply
duplicate the dial plan entries and prepend the unique code in front of the duplicates (so in your toll-free route you might have both 1800NXXXXXX and

21 of 89 5/22/2009 11:12 PM
0000999|1800NXXXXXX, etc.) - no need to create a separate route in that case (where all extensions use the same trunk selections).

One other point - if you want forwarded or follow-me calls to use the restricted route, then you must include the special prefix when setting up the forward or follow-me!
If an extension user sets up call forwarding by dialing one of the codes *72, *90, or *52, then the above custom dialplan will take care of storing the forwarded number in the
database with the prepended restriction code, so that forwarded calls will use the route associated with the called extension (if, for some reason, that's NOT what you want,
omit the three lines that handle *72, *90, and *52 in custom-trunk-selector, and then omit the three contexts that start with custom-app-cf-). Only numbers exceeding the
length of a local extension (as defined in custom-trunk-selector-1) will have the restriction prefix prepended.

Note that the modified call forwarding code does not prompt the user to enter an extension. I'm not sure why that's allowed in any case, especially without any verification
requirement such as entry of a PIN code, but in this situation you really don't want to be able to set call forwarding for one extension by calling in from a different one, unless
you want the system using the wrong route for forwarded calls. I'm not saying the dialplans could not be modified to permit this, but I'm not going to be the one to attempt it.
I'm trying to keep things reasonably simple here.

The call forwarding contexts were copied from extensions_additional.conf and then modified. The problem with this approach is that future versions of FreePBX may change
something in the original [app-cf-on], [app-cf-busy-on], and [app-cf-unavailable-on] contexts, necessitating revisions of the custom code above. But there's really no other
way to handle user-entered call forwarding where a restriction prefix may be added, other than trusting the user to include the prefix when setting call forwarding (probably
not a good idea).

Again, please note that if you set up call forwarding using any other method (such as the Extension Settings) tool, YOU are responsible for prepending the restriction prefix.

And just to add a little extra complication, the above discussion and code assumes that you want FreePBX to handle forwarded calls locally, but that might not always be the
case. If a particular user happens to have their own provider trunk and their own DID, and if the provider offers call forwarding, then you might want to pass call forwarding
requests upstream to that provider (so that each forwarded call doesn't occupy two channels between your FreePBX switch and the provider). In other words, where possible
you may want to offload the task of call forwarding to the upstream provider, but if you do that keep in mind that local (extension-to-extension) calls won't be forwarded
unless you can figure out some way to also set the forwarding in FreePBX. The exact method for doing this will vary between providers, but hopefully the hints in this section
will have given you some ideas on how to handle that situation. If you wanted to get really fancy, you could write an AGI script to log onto the provider's web portal and
change the call forwarding there, but that's definitely beyond the scope of this document!

I hope this helps someone, and keep in mind there's a good possibility that I may add more to this page later on, particularly if I discover better ways to do this. You might
also get some ideas from this post.

What about restricting calls between extensions on the same FreePBX server?
While this is a bit outside the original topic of this How-To, the question came up about how to make a particular extension or group of extensions unreachable from certain
other extensions. While I have no idea why anyone would want to do this, it can be done using similar techniques to those used for restricting calls to certain trunks, but it
potentially might involve a fair bit of effort. Let's say you wanted to restrict calls to extension 299 and all extensions in the 440-449 range (this is just an example) - you might
add something like this to /etc/asterisk/extensions_custom.conf:
[custom-restricted-internal]
exten => 299,1,Goto(app-blackhole,congestion,1)
exten => _44X,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

The first line of the context would send all calls specifically made to extension 299 to congestion - you can use as many lines as you need if you need to restrict calls to more
than one extension. The second line is an example of a pattern match, restricting all calls to extensions matching the 44X pattern - note the underscore at the start of the
pattern; this indicates to Asterisk that you are matching a pattern and not an individual extension named "44X". The third line catches any other number containing the digits
0-9 and/or the * character in any position, and passes it on to the from-internal context.

After setting up the context as you need it in extensions_custom.conf, you'd then go to the configuration page for each of the extensions you want to restrict (yes, every
single one of them, one by one) and change the context from from-internal to custom-restricted-internal, or whatever you called your context.

Note: Some of the material in this How-To was excerpted from the post, A different approach to placing outgoing calling restrictions on certain extensions, which goes into
more detail on the restriction method described above.

How to increase the execution time and/or memory allowed for "orange bar"
reloads
How to increase the execution time and/or memory allowed for "orange bar"
reloads
If you have a very large dialplan, such that the file /etc/asterisk/extensions_additional.conf starts growing to be more than a few hundred K in size, you may find that not
enough time and/or memory is being allocated to permit an "orange bar" reload to proceed. If that's the case, you may need to edit /etc/php.ini. Look for the section headed:
;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

Directly underneath you will see the values for max_execution_time and memory_limit - try doubling these from their current values (within reason, of course - you can't
allocate more memory than you have available!). If that's not enough, increase them a bit more. Now you should be able to process those monster dialplans!

How to increase the time allowed between characters on in-call functions (such as
## to transfer, *1 to record, etc.)

22 of 89 5/22/2009 11:12 PM
There are certain Asterisk features that can be activated while a call is in progress by quickly entering two specific characters from the touch-tone pad. These include ##
(In-Call Asterisk Blind Transfer), *1 (In-Call Asterisk Toggle Call Recording), *2 (In-Call Asterisk Attended Transfer) and probably a couple others. Unfortunately, by
default you must enter both characters within 500 ms (one-half second) and many people can't find and punch in both characters within that period of time. Here's how to
increase the inter-character timeout:

Open the file /etc/asterisk/features_general_custom.conf in any text editor. The file should already exist in FreePBX, but it may currently be empty. If, for some reason,
you need to create it, make sure the ownership and permissions are correct (matching those of the other features*.conf files).

Add this single line:

featuredigittimeout = 2000

Then save the changed file.

That increases the timeout to 2 seconds (2000 ms). If you want an even longer timeout, increase the value (in ms), although it's probably best to keep it as short as your users
can tolerate so that normal actions like moving through an IVR during an outgoing call don't inadvertently trigger an Asterisk feature. Most people can hit *1 or *2 within 2
seconds, perhaps with a bit of forethought.

How to install BIND, so that SIP extensions continue to work when Internet
connectivity is lost
How to install BIND, so that SIP extensions continue to work when Internet connectivity is lost
In some versions of Asterisk, if there are one or more SIP trunks configured and Internet connectivity is lost, it becomes impossible to place any SIP call, including calls
between SIP extensions that are on the same local network as the Asterisk server (and which therefore should be unaffected by the Internet outage - sadly, that is not the
case)! Note that calls using protocols other than SIP (such as IAX2) are unaffected. At least one distribution that includes FreePBX has claimed to resolve this issue with the
installation of BIND, a local DNS server, so why not try that on any FreePBX-based distribution?

The following information was extracted from posts in the Elastix Forum created on April 9 and 10, 2009. Credit in particular goes to users mbit and Bob for coming up with
this procedure. This assumes that your operating system is CentOS (if not, the yum install commands won't work, but the principle is the same).

Note: There are actually two similar but slightly different methods of doing this - one involves the use of Webmin to configure BIND, and the other does not. Don't mix the
two methods, or things may not work as expected. The following instructions do NOT involve Webmin and if you use these, don't attempt to use Webmin to administer BIND
(if you DO want to use Webmin, scroll down a bit).

The first step is to install BIND to act as a local DNS cache. From a command prompt in a terminal window, run the following commands:

yum -y install bind


yum -y install bind-utils
yum -y install caching-nameserver

Bob explains that "The last yum actually installs the configs for it to act as a Cache-Name Server. I found no configuration necessary to it to act as a DNS Cache. I confirmed
this by checking the Cache Entries to confirm it was indeed caching the entries."

After you do the above, make a backup copy of the file /etc/named.caching-nameserver.conf and then load into a text editor on your Asterisk server. For some reason,
attempts to run the BIND server seem to fail if this file has been edited on a different system (probably has to do with differences in line endings and/or the use of tabs or
something). Midnight Commander's editor seems to work okay, and I would guess that something like nano does as well. You should see a section that looks like this:
// DO NOT EDIT THIS FILE - use system-config-bind or an editor
// to create named.conf - edits to this file will be lost on
// caching-nameserver package upgrade.
//
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";

I know it says not to edit this file, but until someone comes up with a better way to do this (that doesn't add an additional layer of complexity) you may wish to do it do it
anyway. Right after the final line in the above section (the memstatistics-file definition line), add a line that looks like this:
forwarders { 208.67.222.222; 208.67.220.220; };

Note that the semicolons immediately following the each IP address including the final one on the line must be present, in addition to the one at the end of the line! Instead
of the IP addresses shown in the above line (which point to OpenDNS), you could enter the IP addresses of one or more reliable DNS servers, such as your ISP's primary and
secondary DNS servers, or any other DNS server you find fast and/or reliable. As Bob explains,

Quote:

The only change I have made to the config files which is a correct change is to add a forwarder. A forwarder is the IP addresses of your ISP DNS servers. What
this does is that your DNS Cache Server will check for DNS using your ISP instead of the Internet Root Servers. If your ISP does not have the DNS entry, it will
go back up the DNS tree, and retrieve it. This is fair better than having a million PC's trying to hit the root servers. Likewise you are likely to get a faster response
from your ISP DNS Servers than you would via the root servers.

Just remember that any time BIND is updated - as could happen if you do you do a general yum update - you might have to go in and re-add the forwarders line (until you do,
it will still work, but the lookups may be significantly slower). If you have a better solution to this, please leave a comment!

Next you must start BIND and add it to start on boot, so run the following from the command prompt:

service named start

23 of 89 5/22/2009 11:12 PM
chkconfig named on

The final step is to get the Asterisk server to go to the local DNS cache rather than directly to an outside DNS. If you are using a distribution such as Elastix that has a page
that allows you to manage your network connection, go to that page (in Elastix it's under System | Network | Network Parameters) and change the Primary DNS server to
127.0.0.1 (the local loopback address), and leave the Secondary DNS blank. In a distribution that does not have such a page, you may have to use a text editor to edit the
/etc/resolv.conf file, and change the following line to point to 127.0.0.1:

nameserver = 127.0.0.1

To test if it is working, ping a couple of unique sites (ones that have nothing to do with FreePBX or any of your service providers). Then run the following from the command
prompt:

rndc dumpdb
less /var/named/data/cache_dump.db

As Bob explains, "rndc creates a text file from the DNS Cache that is held in RAM. When you view the file with less, you should see the DNS entries located in this file that
you just pinged."

If things don't seem to be working at this point, try rebooting the system, but don't do that during an Internet outage, for the reason explained below.

If things seem really hosed, try the following:

From the command prompt do service named stop, then yum remove all three of the packages you installed above, in the reverse order that you installed them. Then check
to see if the directory /var/named exists, and if it does, remove it (delete the entire named subdirectory including all contents - if the thought of doing that makes you
squeamish, temporarily rename it to something else and you can delete it later). Also look in the /etc directory for any files starting with bind, and if you find any either
rename them or move them to another directory (such as /tmp) until you complete the next step (then you can safely delete them). Now go back to the top of this page and
follow the installation instructions from the beginning. The point of this is to clear out any previous BIND installations and/or configurations and start fresh.

One caveat: Although this will keep you from losing SIP connectivity during an Internet outage, it will only work as long as the system is not rebooted. So if a tree limb falls
and takes out both your electricity AND your Internet connection, and the power comes back on first, this won't help - that's because BIND apparently flushes its cache at
every startup. In that situation, the only thing you can do is manually disable all outside SIP trunks and restart Asterisk - that SHOULD at least give you local connectivity
until your Internet connection is restored.

If you need additional information, or a better explanation of how and why this works, see the original message thread referenced in the second paragraph of this article.

What if I really want to use Webmin?

If you really want to use Webmin to administer BIND, follow the above installation instructions, except do NOT do the yum -y install caching-nameserver, and don't make
any edits to the file /etc/named.caching-nameserver.conf. Then do this:

Log in to Webmin and click on Servers, and then click on BIND DNS Server (if you don't find this under Servers, it may be under Un-used Modules - in that case you
probably need to "Refresh Modules" in Webmin).

The first time you enter the BIND DNS Server module, it should present you with some options on how to run the DNS server. Accept the default (you want it to be your
primary DNS server on the box) and continue.

The main BIND DNS Server page in Webmin will have many options, but the only one you need to worry about is Other DNS Servers. Click on that and on the next page
enter just the IP addresses of one or more reliable DNS servers. Don't change any of the other settings. You could use your ISP's primary and secondary DNS servers, or you
could go to any other server you find reliable. If you're unsure of what to use, try OpenDNS at addresses 208.67.222.222 and 208.67.220.220. It might be a good idea to point
at DNS services from multiple sources (such as your ISP AND OpenDNS) so that if one goes down (and you still have Internet connectivity) you will still be able to do DNS
lookups from the other.

Note that using Webmin to administer BIND and installing caching-nameserver are probably incompatible - they are both trying to do the same thing in different ways, so
don't do that.

How to make multiple extensions use a common voicemail box


How to make multiple extensions use a common voicemail box
This is NOT officially supported in FreePBX, but you can link two or more voicemail boxes together so that all extensions share the same voicemail box.

First create the extensions and enable voicemail for all of them. Do not change the mailbox string from the default when created. Decide which will be the primary extension
hosting the "real" voicemail box. For this example let's say you create three extensions numbered 201, 202, and 203. 201 will contain the "real" voicemail box and the other
two will be symlinked to that box.

Now go to the /var/spool/asterisk/voicemail directory. You will see two subdirectories - default and device. Go into default, you will see directories for each extension. If
you do not see one for 201, go leave a voicemail for 201 and it should be created (assuming you have set voicemail up correctly in the extension). If you see directories for
the other two extensions (202 or 203), delete them (if these are pre-existing extensions, you may want to check first to make sure there are no pending voicemails in those
directories).

While still in /var/spool/asterisk/voicemail/default create a symlink for each of the two extensions:

ln -s 201 202

ln -s 201 203

Make sure that permissions and ownership for the symlinks are the same as for the original directory (in particular, make sure that owner and group are asterisk).

Now back up one directory level and go into the device directory (you want to be in /var/spool/asterisk/voicemail/device). Chances are that the symlinks for 202 and 203
will already have been created automatically, and if they haven't they probably will be when necessary. But if you want to insure they are there, just do this:

24 of 89 5/22/2009 11:12 PM
ln -s /var/spool/asterisk/voicemail/default/202/ 202

ln -s /var/spool/asterisk/voicemail/default/203/ 203

While this is a symlink to a symlink, it means that things won't break if you ever decide to separate the directories (restore them to the original condition) in the original
default directory. "default" seems to be the more important of the two directories - once you create the symlinks there, everything seems to work as expected, so I wouldn't
mess with the device directory at all unless you are having problems.

What if I want individual greetings but a common voicemail box?


(Thanks to philippel for suggesting this in the #freepbx IRC channel.)

Let's say you have three tech support people, and when people call one of them you want that person's voice to give a personalized voicemail greeting, but you still want the
actual voicemails to go to a common voicemail box shared by all three (so in case one of them is away, another can look at the issue).

In that case, the symlink trick still works but you have to do it one level lower in the directory structure, and you will need to symlink the INBOX, Old, and (possibly) tmp
directories individually.

So instead of creating the symlinks in /var/spool/asterisk/voicemail/default, you'd go one level lower, into (for example) /var/spool/asterisk/voicemail/default/201 and
from there create the needed symlinks for each of the two other two extensions:

ln -s INBOX ../202/INBOX

ln -s INBOX ../203/INBOX

ln -s Old ../202/Old

ln -s Old ../203/Old

ln -s tmp ../202/tmp

ln -s tmp ../203/tmp

Again, I would assume that any symlinks from the /var/spool/asterisk/voicemail/device branch will be created as needed so I'm not going to bother with those here. You can
create them manually if you really want to, but I don't think it's necessary.

One thing you need to be aware of, when only the individual subdirectories are symlinked, if a user takes an action that creates a new subdirectory (a.k.a. a "folder" in
voicemail jargon), such as using advanced options to save a message in a specific folder, that folder and its contents will be accessible only by the user that created the folder,
and not everyone in the group. This may or may not be desirable behavior. For example, if a user happens to receive a personal message and moves it to the "Family" folder
(which was not previously created or symlinked), it will thereafter only be accessible to the user that moved the message, regardless of whether or not that was the user that
the message was intended for. If you want the additional folders (e.g. Work, Family, Friends) to be accessible to everyone in the group, then you must make sure those
folders are created for the primary extension (this can be accomplished simply by going into "advanced options" from the primary extension's voicemail menu and then
changing folders to each available folder in turn - the act of simply accessing the folder seems to create it if it doesn't already exist), then symlinking each of the folder
subdirectories to the other extensions, in the same manner as is shown above for the INBOX, Old, and tmp subdirectories.

When you do it this way, the user of each extension should go into voicemail and record their individual unavailable message, busy message, and name. But you may want to
instruct them to say something like, "Hi this is Jan, I can't take your call at the moment, but if you will leave a voicemail message, either I or someone else on our technical
support staff will get back to you as quickly as possible." This lets callers know that they they are leaving a message that may be heard by someone other than the person they
called (so that, for example, someone in the user's family doesn't leave a very personal message in the common voicemail box).

Remember, nothing on this page is officially supported by the developers of FreePBX. These are simply hacks that work. But if you have, for example, three or four
extensions that come into the same phone (or group of phones), you can save yourself the hassle of checking multiple voicemail boxes this way.

How to make voicemail accessible from an outside line


How to make voicemail accessible from an outside line

Here's how to allow your users to call in on your main outside line and access their voicemail boxes.

Install the Misc Destinations module if you have not


already done so: Go to Tools, Module Admin, Check for updates online.
After the page has reloaded, click on Misc Destinations, Install, and
click the Process button.

Create a new Misc. Destination pointing to Dial Voicemail:


Go to Setup, Misc Destinations, Add Misc Destination, give it a
description (such as Voicemail Access), select Dial Voicemail (*98) in the dropdown, click Submit Changes.

Now go to your IVR menu: Setup, IVR. Select you main IVR
menu from the list of IVR's. Click on Increase Options, and when the
page reloads, scroll to the bottom and give the new selection an option
number (what the user dials when in the IVR to get to the Voicemail
menu - note that for added security, you may want to make this a
multi-digit number that cannot easily be guessed by those outside your
organization - just don't let the initial digits be the same as for any
other option). In the Misc Destinations dropdown, select the Misc
Destination you created in the previous step. Click Save, and then the
red bar to commit all your changes.

That's it - when a user dials into your IVR and enters the option

25 of 89 5/22/2009 11:12 PM
number, they should be prompted to enter their mailbox number (usually
the same as their extension number) and password.

Alternately, if you want to have a DID dedicated to voicemail


access, then (after creating the Misc Destination as shown above)
create an incoming route for that DID: Setup, Incoming Routes, Add
incoming route. Put the DID number in the appropriate field, and under
Set destination, use the Misc Destinations dropdown and select the Misc
Destination you created earlier, then click Submit and then the red
bar. After that, a caller dialing into that DID should be prompted to
enter their mailbox number and password. I don't necessarily recommend
doing this, because if a hacker stumbles across your DID they may try a
"brute force" approach toward finding mailbox number/password
combinations that work, but you can set it up if you and your users are
willing to accept the associated risk.

How to send calls to different trunks at different times of day


How to send calls to different trunks at different times of day
Some users have a situation where a particular trunk may offer least-cost calling during the daytime hours, while another trunk may offer better rates at night. Here's a
method to select trunks based on time of day. Note that you cannot use a Time Condition for this because Time Conditions are currently designed for use with incoming calls
only.

Step 1: Create a new context in extensions_custom.conf - it should look something like this:
[custom-timeselect]
exten => _[*0-9]!,1,GotoIfTime(08:00-05:00|*|*|*?dayselect)
exten => _[*0-9]!,n,Dial(SIP/nighttrunk/${EXTEN})
exten => _[*0-9]!,n,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,n(dayselect),Dial(SIP/daytrunk/${EXTEN})
exten => _[*0-9]!,n,Goto(app-blackhole,congestion,1)
exten => h,1,Hangup()

See this page at voip-info.org for an explanation of how to set the time in the GotoIfTime statement (and note that if you are using Asterisk 1.6 or later, you must replace
the | separators with commas) - or if you get stuck, you can always create a dummy Time Condition in FreePBX (so you can use the GUI to specify your time condition
settings), save it and save changes, and then open extensions_additional.conf with a text viewer or editor and search for the [timeconditions] context header - you will see
how FreePBX would construct the GotoIfTime statement according to the parameters you've entered, and you can copy that into your custom-timeselect context (then you
can delete the dummy Time Condition).

Replace daytrunk and nighttrunk with the actual names of trunks you want to use for day and night calls, as shown in your trunks list. Replace SIP with whatever technology
is actually used by the trunk (such as IAX2, etc.), if it's not SIP.

Step 2: Create a CUSTOM trunk. In the Dial text box, enter this:
Local/$OUTNUM$@custom-timeselect

Step 3: Set up your Outbound Route to use the custom trunk rather than calling either of the two trunks directly.

That's all there is to it. Maybe someday, someone will create an "Time Condition Trunk" module, which would create a pseudo-trunk that appears in the Outbound Route list
of selectable trunks, that would let you set a time condition and based on that condition would go to either (actual) Trunk A or (actual) Trunk B. But until then, just use the
above method to accomplish the same thing.

How to set up a Linksys PAP2 or Sipura SPA-2000 for use with FreePBX
How to set up a Linksys PAP2 or Sipura SPA-2000 for use with FreePBX
Please note that the following assumes that you have a fully functional SPA-2000 or PAP2 that is not locked to any provider.

Step 1: Make sure your adapter is plugged in, connected to the Internet, and that you know the IP address of the adapter on your local network. If you don't know the IP
address, you can connect a phone to the Line 1 port, pick it up and dial * * * * (star key four times - try again if it doesn't work the first time) and wait to hear "(Sipura)
Configuration Menu", then dial 110# and it will tell you its IP address. Ignore any busy signals or other tones you may hear during this process.

Step 2 (optional but recommended for the PAP2 only - may also work with a SPA-2000 but probably will NOT work correctly with any other model Linksys or Sipura
adapter): Go to the page at the "ILovePAP2" site entitled How to perform PSEUDO Factory Reset and follow the instructions there (the instructions are also mirrored in this
post). One reason to use this method is that if you happen to have an adapter that was formerly locked to a particular provider, this procedure should not cause it to revert to
its previous locked status. N.B. For the more technically astute, note that you could use this XML file as a starting point for building your own custom XML configuration
file, but that is beyond the scope of this article. Also, if you are configuring a different model adapter you can look at this file (or load it into an XML file editor) to at least
see what the defaults are supposed to be.

Step 3: Make sure you have Javascript enabled in your browser. Go to the adapter's web interface, go to the admin login (which should not require a password at this point),
and then switch to advanced view. We will now visit each of the significant tabs in order.

Step 4: Click on the System tab - the defaults are probably okay but you may want to change the time servers to something more appropriate to your part of the world. Go to
Public NTP Pool Time Servers and you can find addresses of time servers that are closer to you. As an example, in the United States you might use us.pool.ntp.org as the
primary and north-america.pool.ntp.org as your secondary. Of course, if there is a reliable time server on the same local network as the adapter, you could point the

26 of 89 5/22/2009 11:12 PM
adapter to that server.

Step 5: Click on the SIP tab. Here all the defaults should be okay with ONE exception. The default of 0.030 for the RTP Packet Size is WRONG for use with the G711
(ulaw or alaw in Asterisk) codecs. Change it to 0.020 at a maximum. If you plan to try and send any kind of data over the adapter (FAX, satellite receiver or TiVO phoning
home, etc.) then you may even want to try 0.010 for this setting (note, however, that using the lower value will increase bandwidth usage). If you don't change this and you
use the G711 codec, you may hear unnecessary clicks or other noise during calls. This setting applies to all codecs, and lowering the value will increase bandwidth usage but
will also yield better sound quality. Keep in mind that bandwidth is probably not an issue if your adapter is on the same local network as your FreePBX server. If you would
like to read a discussion of this issue, see this thread at DSLReports.com.

Step 6: Assuming you did step 2, you should not need to change anything under the Provisioning tab. However you may want to check and make sure that Provision Enable
is set to No.

Step 7: Click on the Regional tab: There is quite a bit here that you may wish to change, in order to provide service that better emulates regular wireline telephone service,
but several of these are NOT essential settings, and none of them in any way affect call quality. Most of these suggestions were lifted (with slight modification) from the page
How to Distribute VoIP Throughout a Home:

• In the U.S. and Canada, under Ring and Call Waiting Tone Spec, the Ring Waveform should be set to Sinusoid, the Ring Voltage should be set to 90 and (this is most
important) the Ring Frequency to 20 — this not only allows older phones with mechanical bells to work, but it just might help in a few odd cases where Caller ID doesn't
seem to work properly on a particular phone. In fact, if you have any weird problems with equipment that worked fine with traditional phone service not working with VoIP,
and that equipment is activated by a ring signal, this may be the problem. Linksys and Sipura adapters default to a ring frequency of 25 Hz, which is NOT the frequency
usually used in the United States and Canada.

• Under the Control Timer Values (sec) section, we suggest setting the Interdigit Long Timer to 20, especially if you also lengthen the dial tone as explained below (it would
probably be a good idea for the Interdigit Long Timer and the Dial Tone to be the same length). We also suggest setting the CPC Delay to 10 and CPC duration to 1, because
if you have one or more phones with a "hold" button and you ever put a call on hold and then no one picks it up, this will release the hold (freeing the phone line) when the
caller hangs up. Note this will not help if you accidentally leave an outgoing call on hold — at present the Linksys/Sipura doesn't have any good way to release outgoing calls
accidentally left on hold automatically (perhaps Linksys might consider adding this in a future firmware release — it would great if they would add an "Off Hook Warning
Disconnect" signal, which would be like a CPC disconnect, except that it would activate just before the Off Hook Warning Tone plays).

• Lengthen the dial tone to 20 seconds (some people find the default 10 seconds too short): Change Call Progress Tones | Dial Tone to 350@-19,440@-19;20(*/0/1+2) — if
this results in a dial tone that is too low in volume, change the two instances of @-19 to @-16

• Lengthen Second Dial Tone, Outside Dial Tone, Prompt Tone, Busy Tone, Reorder Tone, MWI Dial Tone, and Cfwd Dial Tone to 20 seconds: These settings, like the basic
dial tone mentioned above, are under Call Progress Tones - in all the existing strings find ;10( and change it to ;20(

• Slightly increase the volume of the Call Progress Tones (such as Dial Tone, Second Dial Tone, Outside Dial Tone, Prompt Tone, Busy Tone, Reorder Tone, MWI Dial Tone,
and Cfwd Dial Tone): Once again, look under Call Progress Tones - in all the existing strings in that section, find all instances of @-19 (or @-nn where -nn is any negative
number less than -16) — note that there will often be more than one instance per line — and change it to @-16 — if that is too loud, try a lower value such as @-17 or @-18
etc., if it is too soft, try a higher value such as @-15 or @-14 etc.

• Left a phone off hook accidentally? Found that the adapter's off hook warning tone borders on pathetic? Here's a much better one. This gives you 30 seconds of warning
warble tone followed by 30 seconds of the genuine off hook warning tone used by most phone companies: Change Call Progress Tones | Off Hook Warning Tone to
480@-10,620@-16,1400@0,2060@0,2450@0,2600@0;30(.2/0/1,.2/0/2);30(.1/.1/3+4+5+6)

Note that if you want the off-hook warning to continue indefinitely until the phone is placed back on the hook, rather than shutting off after 30 seconds of the loud tone, use
this instead: 480@-10,620@-16,1400@0,2060@0,2450@0,2600@0;30(.2/0/1,.2/0/2);*(.1/.1/3+4+5+6)

• If you want a phone to ring for more than one minute (the default before a Sipura adapter returns a 480 "Temporarily not available" code to the switch) then look under
Distinctive Ring Patterns at the Ringx Cadence settings (e.g. Ring1 Cadence, Ring2 Cadence ... Ring8 Cadence) and change the number of total seconds, which is the number
prior to the left parenthesis. For example, by default, the Ring1 Cadence is set to 60(2/4) which means "60 seconds of ringing, 2 seconds on followed by 4 seconds off." If
you change the 60 to a higher value, such as 180, then the line would ring for a longer time (in this case three minutes) before failing the call. Note, however, that this setting
will have no effect on any other process that might intercept the call (such as a transfer to voicemail before the timeout ends).

• If the people you are talking to sometimes complain that they hear their own voices echoed back to them, try changing the FXS Port Output Gain to a slightly lower value.
For example, if it is currently set to -3, try changing it to -6 or -9. This will lower the volume that you hear in your telephone's receiver so if you set this too low, you'll have
difficulty hearing people, which is why we suggest making only small changes. Note that if you have a telephone with a receiver volume control and you have this set on
"high", try turning it down to the "normal" setting and see if that fixes the problem first, before you change this value on the adapter.

• If you sometimes hear your own voice echoed back to you, try changing the FXS Port Input Gain to a slightly lower value. For example, if it is currently set to -3, try
changing it to -6 or -9. This will lower the volume of your speech going out, so if you set this too low, those you call will have difficulty hearing you, and/or touch tones you
enter on your phone's keypad will not be recognized. Unless you are having severe problems with your voice echoing back to you, we don't suggest setting this below about
-6.

• If you have an answering machine or similar device that accepts touch tones for control functions, and you find that when you call in and try to use tones to activate the
unit it does not respond properly, check under the Miscellaneous section to see what the DTMF Playback Level and the DTMF Playback Length are set to. The default
DTMF Playback Level is -10.0 which is often too low, while the default DTMF Playback Length is .1 which is very often too short.

• In addition to the above, when using an adapter with FreePBX I suggest clearing out the existing Vertical Service Activation Codes (removing the existing *nn codes) for
the following settings (because you want FreePBX to handle these functions, not the adapter):

CW Act Code
CW Per Call Act Code
Block CID Act Code
CID Act Code
CWCID Act Code
Dist Ring Act Code
Attn-Xfer Act Code
CW Deact Code
CID Deact Code
CWCID Deact Code
Dist Ring Deact Code
Conference Act Code

• Finally, if you are in the United States (and probably Canada) and your location observes Daylight Savings Time, the Daylight Saving Time Rule should be:

27 of 89 5/22/2009 11:12 PM
start=3/8/7/2:00;end=11/1/7/2:00;save=1

Google is your friend for finding the correct rules for other parts of the world. That also applies to things such as Dial and Busy tone frequencies, etc.

Step 8: The Line 1 and Line 2 tabs are pretty much set up the same way (assuming both will go to your Asterisk box). The defaults here are fine except for the following:

• Under Network Settings, you may want to stick with the default settings during initial setup, but there is one setting in particular that you may be able to tweak for better
performance. According to DSLReports.com user DracoFelis, writing in this thread,

Quote:

..... no matter what you set [the Network Jitter Level] to you will be using the same amount of bandwidth. So the trade-off here, is better sound quality (and less
"latency"/echo in the call) if you have a "low jitter" ISP connection, vs being more "conservative" with jitter (at the expense of possible "sound breakup") .....
While it is true that a setting of "low" results in the lowest possible latency/echo (which is "a good thing"), I started having problems with "stuttering sounds"
(fraction of a second drop-outs of sound) when I used the "low" setting. So I boosted my setting to "medium" which helped (but didn't eliminate the effect), and
eventually put it back to the default of "high" (which works reasonably well with my ISP). Granted, I lost the lower latency/echo that I gained by setting it to
"low", but using a setting of "high" also caused me to lose the constant "stuttering" on my VoIP line! So lowering the "Network Jitter Level:" setting is clearly a
YMMV setting. It's worthwhile trying, because it will lower latency/echo, but be prepared to set it back up if/when you start getting "stuttering" on the line...

Note that getting the Network Jitter Level right could easily make the difference in whether a data device (FAX machine, satellite receiver or TiVO phoning home, etc.) is
able to communicate successfully most of the time. If you find such devices are having problems communicating try a higher jitter level setting - data devices can usually
tolerate small delays (latency) much better than actual gaps in the signal.

• Under SIP Settings, for Line 2 only change the SIP Port from the default 5060 to 5061 (make sure you also change this on the FreePBX extension configuration page
associated with that line). Although multiple devices on the same local network can use the same port with no conflict, you can't use the same port for both lines of the same
device if they are connecting to the same server.

• Under Proxy and Registration, set the Proxy to the address of your Asterisk server. This should be the dotted IP address if the server is on the same local network,
otherwise use the hostname associated with your server. Also, I personally like to set Register Expires to something less than the default 3600 seconds (one hour) because if
you have to take your server down, that's potentially how long it might be before the device re-registers. On a local network there's nothing wrong with having it re-register
every 300 seconds, but for an external device you may want to set it to something a bit longer, like 900 or 1800.

• Under Subscriber Information, set the Display Name to whatever you like (FreePBX won't use this), and the User ID to the FreePBX extension number. The password must
match the "secret" on the FreePBX extension configuration page.

• Under Supplementary Service Subscription, I suggest that you set the dropdowns for the following services to No (because you want FreePBX to handle these functions):

Block ANC Serv


Cfwd All Serv
Cfwd No Ans Serv
Cfwd Last Serv
Accept Last Serv
Call Return Serv
Speed Dial Serv
Service Announcement Serv
Block CID Serv
Cfwd Busy Serv
Cfwd Sel Serv
Block Last Serv
DND Serv
Call Back Serv
Secure Call Serv

Note the above are just suggestions for a basic setup - if you know what you are doing and have a good reason to leave one or more of these enabled (or to disable something
I didn't mention), by all means do so.

• Under Audio Configuration, the defaults are fine except that you may have to tweak the DTMF Tx Method. I have found that INFO seems to work the best. If you have
problems accessing services that require touch tone input, I would suggest trying INFO first, then Auto, then InBand (on a SPA-2000 you may also have the option to use
InBand+INFO, which seems to work well in some situations, but that setting seems to have disappeared from the PAP2). Keep in mind that InBand probably won't work
very well, if at all, with a highly compressed codec, so if you have to resort to using InBand I suggest using only G711u (the default) or G711a as your Preferred Codec - also
note that when you use InBand you must change the dtmfmode setting on the associated extension configuration page from rfc2833 to inband, or you will lose the ability to
control internal FreePBX functions (such as voicemail) that rely on touch tone input. Note that your FreePBX trunk settings can also affect the passing of touch tones, so if
INFO doesn't produce the desired result I'd first check to see if you need to set the dtmf and dtmfmode options in your trunk settings (for example, with one provider I have
to add dtmf=inband and dtmfmode=inband to the trunk PEER details before I can reliably access services that rely on touch-tone input). A good tactic to resolve where the
problem lies might be to first set up a SIP softphone and configure your trunk so that it will reliably pass tones sent from the softphone, then if necessary try different settings
for the DTMF Tx Method in your adapter. I've even seen a situation where setting a trunk to use a different switch from the same provider made tones passed using INFO
somewhat more reliable, although ultimately we had to fall back to InBand to get tones to pass reliably via that provider. Sorry, there's just not a single DTMF Tx Method
that works reliably in all situations.

• Under Dial Plan, I suggest that you set Enable IP Dialing to No. There is some controversy over the Emergency Number field, which only appears in later firmware
revisions. Some have suggested that if you place your emergency services number (such as "911") in this field, then when you dial that number it will not allow you to hang
up the line until the other end disconnects. If this is true (and I have not tested it), it would be an attempt to emulate how 911 service works in the United States on a PSTN
line. But since no one can seem to find documentation on this from Linksys, I can only speculate how it works.

As for the Dial Plan - you will probably want to change it, but to what? This depends on your needs and on how you have FreePBX configured. On our system we do not
require a dial prefix for ANY call, and allow the user to just dial the number for calls to any extension. We also allow calls to Free World Dialup numbers (five or six digits in
length). This is the plan we've been using:

(911S2|[2-9]xxxxxxS0|1[2-9]xx[2-9]xxxxxxS0|*67S0|[*x][*x].S4)

This first makes an exception for 911, delaying only two seconds after it is dialed (the reason for any delay at all is in case one is dialing a FWD number that happens to begin
with 911). Then seven digit or eleven digit numbers that conform to the U.S./Canada numbering plan go through with no delay. Then comes an exception for *67, which goes
through immediately - you probably do NOT want that one unless you have implemented the procedure described in How to set up per-use Caller ID blocking (*67). After
that is a generic catch-all for every other pattern of two digits or more, which provides for a four-second delay after dialing each digit to see if you are going to dial any more

28 of 89 5/22/2009 11:12 PM
digits (which can be bypassed by hitting the # key after dialing the complete number).

I do NOT suggest you copy the above dial plan verbatim - it's just an example to show you how the various parts of the plan, separated by the | character, are used to define
the patterns you want to recognize. When learning how to construct dial plans, Google is again your friend (just be careful that the information was written by someone who
knows what they are talking about). You could try a Google search for Linksys "Phone Adapter Administration Guide" (include the quotes where shown), you may find a
PDF file that describes all the nuances of setting up a dial plan.

• Under FXS Port Polarity Configuration, you don't need to change anything here but some people may wish to set Caller Conn Polarity to Reverse. All this will do for most
people is give you an audible "click" when a call you place is connected, and again when the called party hangs up. What it actually happening is that the polarity of the line
is reversed when the outgoing call is connected. Some advanced phone systems may be able to use this information to avoid the "line left on hold" problem, but most "hold"
buttons on telephones will NOT release just because line polarity reverses (if you are handy with electronics, you may be able to build a circuit that responds to polarity
reversals and generates a CPC disconnect signal after a polarity reversal). Also, if you want the line polarity to reverse when you are the called party (so you hear a click
when the caller hangs up, perhaps), then you will want to set the Callee Conn Polarity to Reverse.

Step 9: The User 1 and User 2 tabs are set up the same way (assuming both will go to your Asterisk box). The defaults here are fine except that under Ring Settings, you may
want to set the VMWI Ring Splash Len to .5 (that is, one-half second). But if you don't want your phone to give you one-half second rings when you have voicemail waiting,
then leave this blank or set it to 0.

Step 10 (optional): For added security, you may wish to return to the System tab and set an "Admin Passwd" and "User Password". I have mixed feelings about this for a
couple reasons. First, no effort is made to verify the typed passwords, so if you mistype your password in these fields, you could lock yourself out of your device. Second, in
most cases you are not going to expose the device's web interface outside your local network. On the other hand, setting passwords here could keep others (employees,
family members, a hacker that happens to get into your local network, etc.) from messing around with the device - however, in the event your local network is broken into, I
suspect you'll have larger problems than messed-up settings on a VoIP adapter!

Hopefully this information will get you going. If you think I have a wrong value anywhere, or have left out anything that should be included, please leave a comment. I would
especially be interested in any comments by those who have found through experience that certain changes improve performance over Internet connections with high latency
and/or jitter.

How to set up a Skype gateway


How to set up a Skype gateway
This how-to is a bit unusual in that it incorporates, by reference, a document on the Nerd Vittles site: Why Wait? Build Your Own Skype Gateway to Asterisk. These
instructions were developed for and by users of the PBX in a Flash distribution, and while it appears they attempted to make the instructions generic enough to be used by all
FreePBX users, I found that there were additional instructions that needed to be followed. My intent here is to document the differences between the Nerd Vittles
(hereinafter: NV) instructions and what I had to do to actually make this work. I suggest you actually read the NV instructions first to get an overview of the process, but then
follow along here to save yourself some grief. Note that at some point the NV folks may modify their instructions and hopefully incorporate some of the changes mentioned
here.

These instructions assume you are using CentOS as your operating system. If not you will have to adjust these instructions accordingly (using apt-get or whatever you use in
place of yum to install packages, for example). It also assumes your server has hardware audio capability - if it has microphone or line in and speaker/headphone jacks you
should be fine, otherwise this may not (or may) work for you. And it assumes that you are running the Skype and SipToSis software as root - I know some people will choose
not to do that, but I just followed the NV instructions originally and that's how they did it. If you can figure out how to run this as some other user, then you'll have to
mentally compensate for any references to the /root directory in this document (and if you want to post a comment and tell us what you had to do, I think many users would
appreciate it).

NOTE: If you have already downloaded configuration files from the NV site prior to March 1, 2009 please go back and download them again - they now contain
important changes that are no longer mentioned in this document.

When you are ready to begin, read and follow the NV instructions down to where it says "Basic Installation. Now we're ready to get started. Log into your Asterisk server as
root and issue the following commands" but ignore the sentence that says, "For inbound Skype calling to work with other implementations including generic PBX in a Flash
systems, you'll need to create a SIP URI for your Asterisk server: mothership@127.0.0.1. We've previously explained how to set one up in this article. The Atomic Flash
installer, VPN in a Flash build, and the Orgasmatron II and III builds include this SIP URI functionality out of the box." That's the wrong way to do things, in my opinion, so
in the rest of this article I'm going to assume you did not do that part. However, you do need to follow the instructions about installing Java, if you don't already have it.

Before you begin the next section, know that there are additional packages you may need to install to satisfy dependencies on your system. For example, prior to doing "rpm
-ivh skype*" you may need to do the following:

yum install libXv.so.1

Another issue that will affect many users is that for the gateway to operate properly, you must have the X Window System installed on your server. Many distributions don't
include the X Window System, but fortunately it is easy to install:

yum groupinstall "X Window System"

Before you go any further, I suggest you open the file /etc/inittab see if there is a line that reads

id:3:initdefault:

if there is, change it to

id:5:initdefault:

This will start the X server at bootup. Be careful to just change the 3 to a 5 - if you get this wrong you can make your system unbootable! Save the file and continue on.....

If you do not have a full desktop on your system - and you probably shouldn't on a server - then the Skype client will be running in twm, which you can think of as a very
lightweight windows manager of last resort. It is perfectly adequate for our purposes, but you need to make one change to twm's configuration for the Skype client to run
properly. Open the file /etc/X11/twm/system.twmrc and add this line...

RandomPlacement

29 of 89 5/22/2009 11:12 PM
after top comment section. Save the change and then copy the entire file to /root/.twmrc (note the period before the filename). This will stop everything from coming to a
screeching halt when Skype tries to open a window.

Note that, at least for initial testing and configuration, you will need a VNC server installed on your system (unless you intend to do all the initial configuration from your
server's console). Many distributions already come with one installed but if yours doesn't, you can probably do

yum install vncserver

to remedy that situation (I already had it on my system, so am unable to test that). You may also want to look in the file /etc/sysconfig/vncservers and see if it has lines
uncommented to start the VNC server with good security. In my file I have these two lines uncommented (and as shown):

VNCSERVERS="3:root"
VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"

With the above configuration, when you start your VNC client you will need to set it to connect to port 5903 rather than 5900. You are, of course, welcome to modify the
VNC server configuration but that is beyond the scope of this document - I'm just showing what works for me.

Now follow the NV instructions from where it says "Basic Installation. Now we're ready to get started. Log into your Asterisk server as root and issue the following
commands." and continue up to where it says "FreePBX Design. The FreePBX setup that we recommend goes something like this. ....." While you are welcome continue
beyond that point and do things the way they suggest, I really don't recommend it, because they are going outside if the normal FreePBX interface when it's not necessary
(which can come back to bite you if you ever upgrade FreePBX). So until you get the gateway set up, I suggest skipping this section and dropping down to where it says,
"Activating Your Skype Gateway. Now we're ready to place your Skype gateway in production. ....."

But before you continue, one change I strongly suggest making is going into the file /siptosis/SkypeToSipAuth.props and change this line:

*,sip:mothership@127.0.0.1:5060

to

*,sip:75973@127.0.0.1:5060

75973 was chosen arbitrarily because that's what the letters S-K-Y-P-E spell out on a touch tone pad - the reason for changing this to a number is so that you can bring the
call into FreePBX using an Inbound Route (the right way) rather than trying to modify part of a configuration file (the wrong way!). You can use any number you like, but
these instructions will assume you've used 75973.

Okay, now you should be starting at the section where it says, "Activating Your Skype Gateway. Now we're ready to place your Skype gateway in production. ....." Do only
steps 1 through 7 and stop there. You can do this part from within a VNC client window if necessary, or if you just don't want to be seated at the server console.

Some extra notes on these steps: During step 2, make sure to go into Skype's options, under Video Devices, and make sure that "Enable Skype Video" is UNCHECKED - if
you don't do this you may have problems making or receiving calls. During Step 3, if you set up a new Skype account on the first run of the program, log in one more time the
regular way because you'll be prompted for the password - check the box so that it won't prompt again on future startups. Then shut down Skype again before going on to
Step 4. In step 6, it says to run ./SipToSis_Linux but in our installation it was actually ./SipToSis_linux (note the lowercase l). After completing Step 7, stop and skip down to
the paragraph that begins: "Security Warning. One final note of caution. Do NOT expose UDP port 5070 to the Internet..." and heed that advice.

Now go into FreePBX, and create a new Inbound Route for DID 75973 (No CID). You may want to send it to an extension rather than an IVR for initial testing, so you can
be sure that the audio is working properly. Try making a call from a Skype client into your system and see if it comes in and is properly routed. If not, you can either try going
to the General Settings and setting Allow Anonymous Inbound SIP Calls? to Yes, or you can proceed with creating a trunk and then try the inbound test again.

To create a trunk, first edit the file /siptosis/siptosis.cfg - look for the (uncommented) line that says passwd=unimportantpassword, then change the password to something
better:

passwd=somegoodpassword

Also check to see if the following (uncommented) line exists - it will probably be the line immediately following the passwd= line mentioned above, or at least very close to it:
from_url="SkypeCaller" <sip:Skype_Caller@127.0.0.1:5060>

Make sure this line is exactly as shown, including the underscore in the sip:Skype_Caller portion.

Stop SipToSis if it is running, wait one minute (important so you don't get multiple instances of Java running) and restart it. Now in the FreePBX interface, create a new SIP
trunk and use the following settings:

Maximum Channels: 1

Trunk Name: Skype

PEER details:

disallow=all
allow=ulaw&alaw&ilbc&speex
canreinvite=no
context=from-trunk
dtmfmode=rfc2833
host=127.0.0.1
incominglimit=1
nat=never
port=5070
qualify=yes
secret=somegoodpassword
type=peer
username=Skype_Caller
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255

Remove anything in the USER section, save and apply. If you have problems try temporarily removing the deny and permit lines - they are just there for added security.

30 of 89 5/22/2009 11:12 PM
Now you should be able to receive incoming calls with no problem. The next step is to try an outgoing call. Since you can't directly dial Skype addresses from most phones,
you'll need to create a CUSTOM extension for each of the Skype users you want to call. So for now, create a new CUSTOM extension that connects to one of your Skype
clients (not the one running on your FreePBX box!) - give the extension a number and a Display Name and then and use this format in the "dial" text box:

sip/Skype/skypeusername

Note this assumes you named the trunk "Skype."

Try an outgoing test call to the custom extension. If it doesn't work, there are two things to check:

First, edit /siptosis/SipToSkypeAuth.props and note that the last line is: *,*,127.0.0.1,calleeid - if you change that to *,*,*,calleeid it should work, although if you do that you
want to make absolutely certain that port 5070 is not open in your router or firewall for incoming traffic from the world wide Internet. Note that I and many other
people were originally led to believe that you had to open ports 5060 through 5084 (or even a wider range) for incoming SIP traffic, but it turns out that's not true - for SIP
you only need to open port 5060 and any other ports that your off-site devices or other SIP connections may use (in most cases that will be 5060 and 5061, unless perhaps
you have an 8-port device sitting out there somewhere that uses ports 5060-5067). Note I'm only referring to the SIP ports in the 50xx region here, but the point is, don't
leave port 5070 open in your router or firewall!!! The same goes for your VNC server port(s) - use ssh tunneling if you simply must access VNC from outside your local
network. YOU HAVE BEEN WARNED!!!

If outgoing calls still don't work, try going into the Skype client itself, into Options|Sound Devices and change the Sound Out setting to an actual hardware device instead of
Default Device (I just picked the first one on the list). That was the final key to making outbound calls work on my system.

I'm not suggesting you make an outbound route unless you plan to use the SkypeOut service for completing calls - otherwise there's really no good reason to. The only way
you can dial Skype numbers directly is by using a softphone and if you are going to use a softphone anyway, you might as well fire up a real Skype client and get a wider
bandwidth connection. If you really want to do it (or plan on using the SkypeOut service) that's fine, but be aware that neither Outbound Routes nor Trunks are designed to
use alpha characters in their dialing patterns/rules, and that certain characters (such as N and X) have a meaning in a route dial pattern or trunk dial rule, so you probably
won't get the expected results if you try to put Skype user names in these fields. From what I see on the NV site, it appears that SkypeOut wants to see numbers in ten digit
format (NXXNXXXXXX) so bear that in mind if you do decide to send calls to SkypeOut. By the way, I will never understand why the NV folks insist on including useless
patterns that don't do anything in their trunk configurations - apparently they've never read the document HOWTO: Route Dial Patterns and Trunk Dial Rules.

Now, once you have this all working you'd probably like it to start whenever you boot the system. There are two ways of doing that. One is to start the VNC server at bootup
(I used Webmin's System|Bootup and Shutdown to start vncserver at bootup - just check the box next to vncserver and click “Start on Boot”), and then start Skype and
SipToSis from the vncserver startup script. If you want to do that, add these lines to /root/.vnc/xstartup after the line twm &:

skype &
sleep 5
cd /siptosis
./SipToSis_linux >> /var/log/siptosis

(The "sleep 5" is optional, but I think it's a good idea in order to give the Skype client time to fully initialize.)

After a reboot connect to the VNC server (remember that your client must connect to port 5903 if you used my configuration settings) and confirm that you can see the
Skype client, also check /var/log/siptosis to make sure that siptosis is running. Once again, make sure the VNC server port is not exposed to the wide open Internet (that
would be VERY bad since it's running as root and access is not restricted in any way)!

In normal operation, you do not need to have a VNC client connected for this to work - just the VNC server running seems to be sufficient. The advantage of this method is
that you can take a look at what the Skype client is doing at any time by using a VNC client - the disadvantage is that it can be a very bad security risk if you don't know how
to secure it properly. You might want to do it this way for the first week or so, then when you know everything is working as it should be, switch to method explained below
(and disable the automatic running of the VNC server at startup).

The other method was suggested by bbhenry in this thread on the PiaF site (specifically this post, also see another variation in this post). Use his method if you'd rather not
leave a VNC server running full-time.

To keep the logs from growing too large, if you have Webmin installed on your system you can use Webmin's System|Log File Rotation|Add a new log file to rotate to
make sure the SipToSis log doesn't get too large. Suggested settings:

Log file paths: /var/log/siptosis


Ignore log file if missing? Yes
Re-create log file after rotation? Yes, with mode 0644 and owned by user root and group root

Leave everything else at the defaults. Then make another rule, but this time use /siptosis/log/*.log as the Log file path. You only need use the second rule if you are not
starting everything with the VNC server and therefore not creating the /var/log/siptosis file.

One note on operation - if you ever need to shut down the SipToSis program (for example, to get it to reread its configuration file), wait about a minute or so between shutting
it down and restarting it. The reason is that it apparently starts a Java process that takes a few seconds to realize that the program has been shut down, and then shut itself
down. If you restart SipToSis too soon, you will have two (or more) instances of Java running and competing for the same connection to Asterisk, and one of them will get it
and the other will post multiple lines of complaint to the log file at an astronomical rate! Pretty soon you will be out of hard drive space and when you look for the offending
file, it will be SipToSis.log. So always give SipToSis (and its Java process) plenty of time to shut down before restarting it!

Finally, here are some links to posts and message threads that may be useful if you have problems:

SipToSis Skype Gateway Bridge Forum


Nerd Vittles: Why Wait? Build Your Own Skype Gateway to Asterisk
Elastix Forum: Siptosis Skype gateway
PBX in a Flash Forum: SipToSis-Skype Gateway Tips

How to set up notification (Caller ID popup) on Mac OS X, Linux and other


systems
How to set up notification (Caller ID popup) on Mac OS X, Linux and other systems

31 of 89 5/22/2009 11:12 PM
If you have a Macintosh computer, you may have wondered if there is any way to have a pop-up notification of who is calling whenever your extension rings. It turns out
that there is, but it's not exactly straightforward. This method may also work for certain systems running under Windows or Linux, although the client you use will be
different. I will explain how I set it up on a Mac. There is one caveat, if your computer does not have a fixed IP address on your local network, then you'll have to make a file
edit in the FreePBX configuration every time it changes. There may be a way around that, but I haven't found it yet. Note: If you have Growl notifications installed on
your Macintosh or Windows system(s) (that will receive and display the popup notifications), AND you know how to install a Perl module on your
FreePBX/Asterisk box, you will probably want to scroll down a bit and look at the "Alternate Method" first.

I do not consider the following an elegant solution, indeed there are parts of it I consider a hack. But it works (although I now prefer the "Alternate Method" shown below).
To begin with, look over the page at http://mezzo.net/asterisk/app_notify.html - we are going to install the "Notify application module for the Asterisk PBX" at the top of
the page, and then the appropriate client for your computer (lower on the page). Of course, the Notify application module must be installed on the system running Asterisk
and FreePBX. So start there at the command prompt and do this:

cd /usr/src

Asterisk 1.2.x: wget http://mezzo.net/asterisk/app_notify-1.0.tgz


or
Asterisk 1.4.x: wget http://mezzo.net/asterisk/app_notify-2.0rc1.tgz
(These are just examples, you should probably use whichever download is the most recent for your version of Asterisk)

tar -xzf app_notify-1.0.tgz (replace filename with whatever you actually downloaded)

cd app_notify-1.0 (ditto, omitting the .tgz extension)

make install

Restart Asterisk or load the application module with:


load app_notify.so
(I went to the Asterisk CLI and did a restart when convenient just to make sure I wouldn't interrupt any calls)

That's all you have to do to install the module. While at the Linux command prompt, bring up your text editor of choice (nano, Midnight Commander's editor, or whatever
you like) and edit etc/asterisk/extensions_custom.conf and, somewhere under the [from-internal-custom] context insert these two lines for each extension for which you
wish to generate notification messages (this example assumes you want to monitor extension 525 and send the notifications to the computer at local IP address
192.168.0.123):

exten => ****525,1,Notify(${CALLERID(num)}|${CALLERID(name)}|525/192.168.0.123)


exten => ****525,n,Busy

Change the boldfaced items to the proper extension number and/or IP address of the computer to receive the notifications.

If you want notifications for more than one extension, repeat the above two lines for each extension you want to monitor. If you want the notifications to go to more than one
computer, just duplicate the topmost line as many times as you need to, changing the 1,Notify to n,Notify in subsequent lines, and other than that changing only the target IP
address (so it will send the notification to one computer, then the next, and so on). Note that you're actually creating a custom extension consisting of "****" + the extension
number - you can change this to something else but it must be unique in your system. My goal was to make it something that no one would actually dial, since it's only used
internally. When you're through with your edits, don't forget to save the changes!

Now it's time to use your web browser and browse to the FreePBX configuration. What you need to do is create a Follow-Me for the extensions you want to monitor. So
make sure that FreePBX's Follow-me module is installed, then go there and select the follow-me for the extension you wish to monitor (again we're using 525 in this
example). Add the Follow-Me, make the ring strategy firstnotonphone, set the ring time to whatever you want, and make the Destination if no answer whatever you want
(probably the extensions's voicemail). In the Follow-Me List put two entries. At the top put the custom extension number with the four asterisks in front of the number, and
(this is very important) a pound sign (hash mark for you Brits) on the end. On the next line, just put the extension number itself. So for extension 525, you'd have these two
entries:

****525#
525

Save this. Note that if you already have a Follow-me for the extension, it might complicate things a little bit, or maybe not. The basic idea is to attempt a call to the custom
extension (which will always fail busy) just before you attempt the real extension. If you already have a certain configuration of Follow-me set up, it might be necessary to
move some or all of the Follow-me settings to a Ring Group to make this work, and use the Ring Group as the destination of the Follow-me, but that's beyond the scope of
this article (I only mention that because using a Ring Group as the destination of the Follow-me may help resolve some logical conflicts, and you can even chain ring groups if
necessary. Most users won't have this issue, but I mention the possibility for those who do).

The one flaw in this is that you'll receive the popup notification even if you are currently on the phone, and the call ultimately goes to a different extension or to voicemail.
For some situations that would be desirable behavior, whereas in others it would not. Personally I want the notifications of calls I missed, but maybe you don't. I did say this
was a hack, right?!

Once you have this set up, and reload the configuration in FreePBX, the notifications will be sent out (if you have done everything correctly) One note, on the module
download page, it shows specifying the target computer by name, not IP address. That trick only works if the computer name actually resolves to something, which means
you'd have to have a line in /etc/hosts linking the computer name and IP address, or you'd have to have a local DNS server that resolves local machine names. Most home and
small business users won't have either. So the best plan is, give the computer a fixed IP address (most routers provide a way to do this), then just specify that IP address in
extensions_custom.conf.

Installing the client

Go back to http://mezzo.net/asterisk/app_notify.html and pick up the appropriate client for the target computer (that receives the notifications). I have only installed this on
a Mac (OS X Leopard) so here are a few hints for that client:

I was not able to make the dialer function work - don't know why and don't really care because that wasn't my goal in the first place. So that will not be covered here (if you
get it to work, please leave a comment and I may revise this).

To receive notifications you install the client (standard software install method), then go to System Preferences | Other | Asterisk (yes, the client is called "Asterisk" in the
preference panel). Under "Notifier" I suggest you turn on Growl notifications if you have Growl installed, and turn off "Speak announcement" - although that would be a cool
feature if it worked reliably, it appears that it only works once or twice and then you don't get ANY notifications at all until you turn "Speak announcement" back off (and
usually you have to stop and restart the client as well).

32 of 89 5/22/2009 11:12 PM
There also currently a bug where you enter the server address. Unless you have Bonjour installed on your Asterisk server (something also offered at this site, but good luck in
getting it set up and working if you're not a true Linux geek - and if you are and you make it work, please leave a comment and give us step by step instructions!), you will
have to enter the IP address manually. But the keyboard input routine is buggy! So go to another application (text editor, e-mail program, whatever) and type in your Asterisk
server address, then highlight and copy it (Option-C) so it's in your clipboard. Go back to the preferences panel, click the plus (+) to add a server, then click in the location
where the server address should be, and then a text box should appear which SHOULD allow you to enter the address. Click in it and paste the server address (Option-V)
from the clipboard. If you still get extraneous characters, highlight all the characters other than the correct ones using the mouse, then right-click and select "cut", and you
should be left with the correct server address. Yes, I know that's a screwy way to do it, but whatever works...

Once the client is configured you may need to instruct the computer's firewall to allow it to receive the incoming notifications. The listen port defaults to 40000 (I don't advise
trying to change that unless there's a serious conflict). As soon as I configured the client, I got a popup asking if I wanted to allow incoming communications to that program,
to which I answered in the affirmative, and that's all there was to it.

I do wish there were a better way to insert some custom code into the FreePBX generated dial plan, that would fire off a custom dialplan fragment just prior to ringing an
extension. That would not only be useful for this application, but probably for several others where you might want to do something special just before an extension rings. I'm
aware that you can modify the dialplan if you create a module; p_lindheimer (one of the developers) said, "...you can splice a line in to the dialplan. Take a look at pinset
module, you will see how it splices a call to it's own macro in the outbound route macros, or I think cidlookup does the same into ext-did. It would require writing a simple
module to do what you want but that is not really all that hard." Well, it might not be hard for some people, but it would be impossible for me (I have only a VERY limited
knowledge of Perl, none at all of PHP, and don't have a clue how a module is constructed - I know you can view module code easily but unless I'm told exactly what I'm
looking at, it usually makes no sense at all to me). My point is, if you have the knowledge that I lack, there are much better ways to accomplish this, but until someone creates
a module (or ANYTHING better than what I've described), the above is the only way I know how to do it, particularly with the client on a Mac computer.

Alternate Method

The main problem with the above method is that you must install a module in Asterisk (that may or may not be updated to keep up with future versions of Asterisk) and,
depending on the target platform, a possibly buggy client that may be difficult to configure. In contrast, the following method relies on a simple Perl AGI script on the
FreePBX system, and the presence of the Growl notification system on the target computers. Growl is a fairly standard notification system for Macintosh computers, and now
there is a Growl for Windows as well. This method uses Growl's ability to receive a message over the network. The only real "catch" is that you will most likely need to install
a Perl module on your FreePBX/Asterisk box. If you have Webmin installed, look under the "Others" heading in the left-hand menu and see if you have an entry for "Perl
Modules" (if not, you may want to add the "Perl Modules" module to Webmin), or perhaps you already know how to install a Perl module.

The Perl module you need is called Net::Growl and it must be installed on your FreePBX/Asterisk box, not the computer receiving the notification. You must then create a
Perl script with the filename /var/lib/asterisk/agi-bin/growlsend.agi which should contain this code:
#!/usr/bin/perl
use strict;
use warnings;
use Net::Growl;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();
my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
if ( $ARGV[2] ne "" ) {
$ext = $ARGV[2];
}

# Define months and weekdays in English

my @months = (
"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November", "December"
);
my @weekdays = (
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
);

# Construct date/time string

my (
$sec, $min, $hour, $mday, $mon,
$year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour eq 12 ) { $ampm = "PM"; }
if ( $hour eq 0 ) { $hour = "12"; }
if ( $hour > 12 ) {
$ampm = "PM";
$hour = ( $hour - 12 );
}

if ( $min < 10 ) { $min = "0" . $min; }


$year += 1900;

my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";

# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(\d{2})([2-9])(\d{2})(\d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(\d{2})([2-9])(\d{2})(\d{4})$/$1-$2$3-$4$5-$6/;

register(host => "$ARGV[0]",


application=>"Incoming Call",
password=>"$ARGV[1]", );
notify(host => "$ARGV[0]",
application=>"Incoming Call",
title=>"$name",
description=>"$num\nfor $ext\n$fulldate",
priority=>1,
sticky=>'True',
password=>"$ARGV[1]",
);

After you have created that file, check the ownership and permissions to make sure that it is the same as the other agi files in that directory (owner and group are asterisk,

33 of 89 5/22/2009 11:12 PM
and the file should be executable). I use Midnight Commander's "Advanced Chown" to do that sort of thing, but some people prefer to do it from the Linux command prompt
- whatever works for you is fine.

After that, use your text editor of choice to edit etc/asterisk/extensions_custom.conf and, somewhere under the [from-internal-custom] context insert these two lines for
each extension for which you wish to generate notification messages (this example assumes you want to monitor extension 525 and send the notifications to the computer at
local IP address 192.168.0.123):

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)


exten => ****525,n,Busy

Change the boldfaced items to the proper extension number, IP address of the computer to receive the notifications, and network password for Growl on that computer. Note
the three arguments following growlsend.agi are as follows: The first is the IP address of the system to receive the notifications, the second is the server password for Growl
on that remote system (more on that below), and the third is the actual extension number that is being called. The first two arguments are required, while the third is optional,
however if you don't use the third it defaults to the extension called to reach the agi script (****525 in this case) rather than the extension that's actually being called (525),
so in most cases in FreePBX you're going to want to include the third argument.

If you want notifications for more than one extension, repeat the above two lines for each extension you want to monitor. If you want the notifications to go to more than one
computer, just duplicate the topmost line as many times as you need to, changing the 1,AGI to n,AGI in subsequent lines, and other than that, changing only the target IP
address and password (so it will send the notification to one computer, then the next, and so on). Note that you're actually creating a custom extension consisting of "****" +
the extension number - you can change this to something else but it must be unique in your system. My goal was to make it something that no one would actually dial, since
it's only used internally. When you're through with your edits, don't forget to save the changes!

On your client computers, bring up the Growl preference panel and go to the Network tab. Make sure that "Listen for incoming notifications" and "Allow remote application
registration" are checked. Set the Server Password to the same password you used in place of "GrowlPassWord" (you DID change the password to something more secure,
right?!) in the line in extensions_custom.conf that corresponds to that machine. Users of Growl for Windows may find that some display styles do not permit all of the text to
be displayed (for example, the time and date may be missing) - if that is the case, we suggest using the Standard style for Incoming Call popups (and if you can't get the
Standard style to work, try running the following from a Windows command prompt:
regsvr32 "C:\Program Files\Vortex Software\Growl For Windows\Displays\WebDisplay\WebKitDependencies\WebKit.dll"
(That is all one line). This is per a suggestion in Comment 2 of this thread).

Now it's time to use your web browser and browse to the FreePBX configuration. What you need to do is create a Follow-Me for the extensions you want to monitor. So
make sure that FreePBX's Follow-me module is installed, then go there and select the follow-me for the extension you wish to monitor (again we're using 525 in this
example). Add the Follow-Me, make the ring strategy firstnotonphone, set the ring time to whatever you want, and make the Destination if no answer whatever you want
(probably the extension's voicemail). In the Follow-Me List put two entries. At the top put the custom extension number with the four asterisks in front of the number, and
(this is very important) a pound sign (hash mark for you Brits) on the end. On the next line, just put the extension number itself. So for extension 525, you'd have these two
entries:

****525#
525

Save this. Note that if you already have a Follow-me for the extension, it might complicate things a little bit, or maybe not. The basic idea is to attempt a call to the custom
extension (which will always fail busy) just before you attempt the real extension. If you already have a certain configuration of Follow-me set up, it might be necessary to
move some or all of the Follow-me settings to a Ring Group to make this work, and use the Ring Group as the destination of the Follow-me, but that's beyond the scope of
this article (I only mention that because using a Ring Group as the destination of the Follow-me may help resolve some logical conflicts, and you can even chain ring groups if
necessary. Most users won't have this issue, but I mention the possibility for those who do).

Once Growl has successfully received the first notification, you can go back into Growl's preference pane and go to the Applications tab. Click on "incoming Call" and then
"Configure" (or in Growl for Windows, click on "incoming Call", then look in the bottom panel). I suggest setting Stay on Screen to Always (so the notification will stay there
until you dismiss it), Priority to High, and (in the Mac version of Growl) Play Sound to whatever you like (I like the Pop sound, but it's entirely up to you).

What if the IP address changes?

One limitation of both of the above methods is that you need to know the IP address of the computer you are sending the notification to, and in some cases this can change
from time to time. However, if the remote extension is always at the same IP address as the computer receiving the notifications (note this will often NOT be the case on a
local network, since the phone and computer will be at different IP addresses), then you may be able to use either of Asterisk's SIPPEER or IAXPEER functions (depending
on the type of endpoint) to get the address. So, for example, instead of the following line in the second method:

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

You MIGHT be able to use this (assuming it's a SIP endpoint):

exten => ****525,1,AGI(growlsend.agi,${SIPPEER(525:ip)},GrowlPassWord,525)

Of course, the problem with the above is that if the endpoint is inaccessible then the SIPPEER function would not return any address, and I'm not sure if the call to the agi
file would fail gracefully in such a case. If not, you may want to add some code to the perl script to bail out if the IP address is invalid or missing (if anyone really needs this,
leave a comment and I may modify the script to add such a test, although I suspect it may fail gracefully in any case).

Note that at the distant end (assuming you are sending to a public IP address, and not one on your local network), a firewall rule may need to be implemented to direct the
notifications to the proper computer. It appears that the Growl UDP port is 9887, so that would be the incoming port that needs to be sent to the proper machine in the
firewall rules (once again, that is UDP port 9887, NOT TCP).

Why Perl?

Because Perl and BASIC are the only high level languages I know at all (and I'm definitely not an expert in either). However, if you would like to convert the script into PHP
or Python or some other language, feel free to have a go at it. You nay find it helpful to view the page on netgrowl.php and/or netgrowl.py if you intend to do this. If you do
rewrite the script in either of those languages (or if you are able to improve upon the perl script, which probably wouldn't be too difficult) please post your results in a
comment!

How to set up per-use Caller ID blocking (*67)


How to set up per-use Caller ID blocking (*67)

34 of 89 5/22/2009 11:12 PM
Note: The following is experimental - it worked for me but may or may not work for you. Also, as shown here it may NOT correctly handle the case where some idiot dials
*67 then 911 - depending on the call path and the provider, such a call may get "dropped on the floor", so to speak (to decrease the chances of that, you may want to insert
something like *67|911 into the Dial Patterns for your emergency route, just in case someone does dial *67 and then 911).

It must be noted that due to technical limitations, dialing *67 from ANY phone will not block your Caller ID 100% of the time - if an end user has the right equipment and/or
the right relationship with their provider, they can receive your Caller ID regardless of your attempt to block it. This is because your Caller ID is always sent, but with a
"privacy flag" set when you choose to block it. If the telephone company at the distant end chooses to ignore the privacy flag setting - or, if the called party is in effect acting
as their own telephone company - then the person you call may see your Caller ID anyway. "It depends" on several factors, some of which may be beyond your control.

This document assumes that you have one or more SIP or IAX providers that will accept a number in the format *671NXXNXXXXXX and treat it as a private call, and will
block Caller ID to the called party. I do not go into passing a private call through to a ZAP channel, as I am not sure if the same principles would work. On a ZAP channel
only, in some cases you might need to insert a w (wait) character between the *67 and the rest of the number, but that would not be the case on a SIP or IAX trunk (One
exception: A SIP trunk associated with an SPA-3000/SPA-3102 device - I will cover the changes needed for that below).

Step 1: Create one or more new outbound routes:


In our case we wanted to send all private (Caller ID blocked) calls to area codes in the United States and Canada through a single provider. So we set up a new outbound
route, specifying all the possible 11 digit patterns that include area codes in the U.S. and Canada.

Route Name: Star_67_Privacy (or whatever you want)

Dial Patterns: Here we individually specified each possible U.S. (and Canadian, if your provider handles calls to Canada) area code, like this:

*671201NXXXXXX
*671202NXXXXXX
[..... more patterns .....]
*671985NXXXXXX
*671989NXXXXXX
*67NXXXXXX

(The last example line shown above allows *67 + 7 digit local calls - if you have 10 digit dialing of local calls in your area you could use *67NXXNXXXXXX instead).

Yes, I know that some of you will try to get by with more generic patterns here, but when someone tries to use *67 to bypass your high cost destination blocks you'll thank
yourself for being explicit here. If you need a list of valid area codes, you can find one at the NANPA NPA Reports page. Don't forget the pattern for seven digit calls if your
provider accepts them.

Trunk Sequence: Here you select only the provider(s) that will accept and honor the *67 prefix. Note that if a particular trunk does not accept *67+7 digit calls but you
want to dial calls using *67+seven digits, you may have to add a trunk dial rule of the form
*67|*671AAA+NXXXXXX
(replace AAA with your area code). Or, if you dial local calls using ten digits but your provider wants to see eleven, then the trunk dial rule would be
*67|*671+NXXNXXXXXX

In addition, we created a separate route for toll-free numbers, after discovering that the provider selected in our first route did not honor *67 on calls to toll free numbers:

Route Name: Star_67_TollFree

Dial Patterns: Note on these we are using the bar character to strip off the *67 prefix before sending it on:

*67|1800NXXXXXX
*67|1822NXXXXXX
*67|1833NXXXXXX
*67|1844NXXXXXX
*67|1855NXXXXXX
*67|1866NXXXXXX
*67|1877NXXXXXX
*67|1888NXXXXXX

Trunk Sequence: ENUM

If you have not created an ENUM trunk, go do that first, then select it as the destination for toll-free numbers. As far as I know (but I may be wrong, so test with a toll-free
number that reads back your Caller ID) the carriers that pass toll-free calls via ENUM use a "dummy" number, not any number you pass to them.

After doing the above, you should be able to dial any 11 digit number (or either a 7 or a 10 digit number) with the *67 prefix and the call should go out, and hopefully the
outgoing Caller ID should be blocked (assuming your provider actually honors the *67 prefix). But, your users will not get the second dial tone after dialing *67. If you're
happy with that, you can stop here. If all your endpoints are Linksys/Sipura adapters or phones (or use similar dial plan strings) you may wish to read step 5 before doing
steps 2, 3, and 4. The rest of the steps are primarily designed to provide the second dial tone after *67 is dialed, and also provide some extra assurance that you are not
sending a valid Caller ID.

Step 2: Add a new context to etc/asterisk/extensions_custom.conf:


[custom-set-privacy]
exten => _1NXXNXXXXXX,1,Noop(Adding *67 prefix - 11 digit call)
exten => _1NXXNXXXXXX,n,Goto(from-internal,*67${EXTEN},1)
exten => _NXXNXXXXXX,1,Noop(Adding *67 prefix - 10 digit call)
exten => _NXXNXXXXXX,n,Goto(from-internal,*671${EXTEN},1)
exten => _NXXXXXX,1,Noop(Adding *67 prefix - 7 digit call)
exten => _NXXXXXX,n,Goto(from-internal,*671###${EXTEN},1)
exten => 911,1,Noop(Some idiot dialed *67 + 911 - attempt to handle it)
exten => 911,n,Goto(from-internal,${EXTEN},1)
exten => _[*0-9]!,n,Goto(app-blackhole,busy,1)
exten => h,1,Hangup()

REPLACE ### IN LINE 6 WITH YOUR AREA CODE! (Yes, we know we already took care of 7-digit calling above, but as you read on you may understand that there are
probably good reasons to do it in both places). You can, of course, omit any lines that match dial patterns that you don't use on your system. It may not be a good idea to
leave in the lines for both 7 and 10 digit dialing, for example - pick one or the other.

35 of 89 5/22/2009 11:12 PM
Step 3: Add a new DISA:
Note that the DISA module must be installed!

DISA name: Privacy


Caller ID: <>
Context: custom-set-privacy

Leave everything else at the defaults (you can change the timeouts later if you like, once you get this working). You are not going to expose this to outside callers, so unless
your system is seriously misconfigured you should not need, and for this application do not want a PIN. Be sure to set the Caller ID to <> - this is the extra assurance that you
aren't sending out a valid Caller ID!

Step 4: Add a Misc Application:


Description: *67 Privacy
Feature Code: *67
Destination: DISA [Privacy]

Step 5: Configure the dial plan at your endpoints:

Originally, our idea was that endpoints should send *67 calls to Asterisk as soon as *67 is dialed, and let the DISA handle it (which is the reason for steps 2 through 4 above).
However, we have discovered that there's a more reliable method that works with Linksys/Sipura devices, and that may work with other types of phones or endpoint devices
as well (depending on how configurable the phone or device is). Let's consider how we might set up a Linksys PAP-2 or equivalent Sipura adapter.

A Linksys/Sipura device typically wants to handle *67 itself, but not in the way we want it to. The reason we don't just use the *67 feature built into the adapter is because
that only blocks the adapter itself from sending Caller Id information, and FreePBX pretty much ignores that anyway, instead using the Caller ID data you have entered on
the FreePBX extension configuration page(s) associated with the extensions handled by the adapter. So the *67 feature built into the adapter just gets in the way, and
therefore must be disabled. So look in the "Supplementary Service Subscription" section (you need to be in advanced view to see this) and make sure that "Block CID Serv"
is set to NO. Then go to the "Regional" tab, scroll down to the "Vertical Service Activation Codes" section, and make sure that *67 doesn't appear anywhere (particularly in
the "Block CID Act Code" setting) - if it does, erase it and save the settings.

There are a couple of ways that a Linksys/Sipura adapter can handle *67 calls. If you completed steps 2 through 4 above, you could go into each of the Line tabs and change
the Dial Plan for each line going to your Asterisk box, to add *67S0 (and be sure there are the required bar characters separating this from other parts of the dial plan, e.g.
|*67S0|). The "0" is a zero, not a letter "O." This tells the adapter that once it has seen *67 dialed, it should complete the call (to the DISA) right away, so that the caller gets
the second dial tone almost immediately. We originally tried this method, and discovered that while it generally works, sometimes digits dialed after the second dial tone
aren't received reliably by Asterisk, causing misdials and calls to not go through. However, with some adapters that may be the only method that works at all (though,
obviously, what you need to add to the Dial Plan may vary with different equipment manufacturers).

Every endpoint is different but the principle is the same: You want the endpoint to pass the *67 (or *67 + the digits dialed thereafter) to Asterisk, not try to handle it itself.
And if it is to connect to the DISA after dialing *67, you want that to happen immediately, not after a few seconds delay. But obviously, the best way to handle this, if the
adapter supports it, is to have the adapter generate the second dial tone after the *67, collect the additional digits, and send all of the dialed digits (including the *67 prefix) to
your Asterisk server (so there is no inband dialing of touch tones, and less chance of misdialed numbers).

At first I did not think this was possible with a Linksys/Sipura adapter, but after digging into some documentation on Dial Plan construction I realized that it is possible - but,
it might turn a relatively simple dial plan into a somewhat more complicated one. Don't worry, a Linksys/Sipura device lets you use a Dial Plan that contains up to 2047 bytes,
and you probably won't be anywhere near that limit (however, other manufacturers may not be as generous).

So, if you want the Linksys/Sipura device to collect all the digits and then send them to Asterisk, here's how to do it - but don't say I didn't warn you that it was a bit
convoluted. Note that if you do this, you still need to follow ALL of the instructions above, except that if ALL of your endpoints are Linksys/Sipura devices and you plan to
modify the dial plan in this way on all of them, then you can skip steps 2, 3, and 4 (the custom context and the DISA - it doesn't hurt to leave them in if you've already
created them, however, and they can still be used with other types of endpoints).

For reference, here's a sample original Linksys/Sipura dial plan (which includes our original trick of using *67S0 to reaching the DISA):

(911S2|[2-9]xxxxxxS0|1[2-9]xx[2-9]xxxxxxS0|*67S0|[*x][*x].S4)

This Dial Plan may seem strange to some, but it allows us to dial anything - local extensions, regular PSTN numbers, Free World Dialup Numbers, and even Sipbroker codes
and numbers without ever having to dial an access code. For anything other than a 7 or 11 digit PSTN number there is a four second timeout (except for 911 where the
timeout is reduced to two seconds, and that short timeout exists only because there could be a Free World Dialup number starting with 911 - if you don't have any FWD
trunks you really should change the timeout to zero, using 911S0 instead of 911S2). Anyway, to get the adapter to generate the second dial tone it gets a lot more complicated
- here is how that same dial plan looks after changing it to allow *67 + 7 digit and *67 + 11 digit calls:

(911S2|[2-9]xxxxxxS0|1[2-9]xx[2-9]xxxxxxS0|*67,[2-9]xxxxxxS0|*67,1[2-9]xx[2-9]xxxxxxS0|x[*x].S4|*[*0-57-9][*x].S4|*6[*0-68-9].S4|*6[*0-68-9][*x].S4)

The main reason it got so much longer (besides the obvious addition of the two patterns that start with *67,) is that apparently the Linksys/Sipura will NOT generate the
second dial tone if there is any ambiguity with another part of the dial plan, even if you put the *67, parts first (note the comma after the *67 - that's what generates the
second dial tone). So where we had [*x][*x].S4 (which basically meant, pass anything dialed with a digit or a * in any position as long as it's at least two characters long, but
only after a four second delay to see if more digits are coming), we now had to use these four Dial Plan elements instead, to get roughly the same functionality...

x[*x].S4|*[*0-57-9][*x].S4|*6[*0-68-9].S4|*6[*0-68-9][*x].S4

...which gives pretty much the same effect except that it specifically excludes *67 from a possible timeout (also it will reject some two character long patterns that the other
element would have accepted, but we have nothing like that on our system anyway). The new Dial Plan is still nowhere near the 2047 byte limit; it's just harder to decipher
what's going on unless you understand Linksys/Sipura dial plan construction.

If you don't get the second dial tone after modifying your dial plan as shown (or in some similar manner) the most probable reason is because there's a conflict with some
other part of the dial plan, or because there is a *67 somewhere in the "Vertical Service Activation Codes" section (under the "Regional" tab). If you get a fast busy
immediately after dialing *67 plus a seven digit number, it likely means you didn't set up a route in FreePBX to accept the *67NXXXXXX dial pattern.

One final note: The dial tone you hear after dialing *67 in this configuration is the "Outside Dial Tone" under the Regional tab. If you want it to sound like a normal dial tone,
just copy the pattern from the "Dial Tone" text box, and paste it into the "Outside Dial Tone" text box, then save the settings. While in the Regional settings, you may want to
go to the "Control Timer Values (sec)" section and change the value of the Interdigit Long Timer to 20, so that if someone dials *67 and then pauses a few seconds to look up
the number, they will have 20 seconds before the (second) dial tone times out.

36 of 89 5/22/2009 11:12 PM
Additional Instructions if you are using a SPA-3000/SPA-3102 device (or other channel/device that requires a
wait after *67 is dialed) for your trunk
(NOTE: I had a major brain fart when creating this page and originally had a process here that was totally unnecessary. Sorry about that).

You may find that the channel you are dialing out on requires a short delay after the *67 is dialed - this usually occurs when you are calling out to the PSTN. The following
additional instructions have been tested using a Sipura SPA-3000 device but MAY be equally applicable if you are using a ZAP channel. Make some test calls without
inserting a delay first - they may work.

But, if it does turn out that the delay is necessary, then what you need to do is go to the page for each trunk that connects to such a channel or device, and add TRUNK Dial
Rules to match the patterns you might be dialing through that trunk, that will insert the w (wait) character after the *67. Here are some sample TRUNK dial rules. Note these
would REPLACE any TRUNK Dial Rule patterns you may have added in Step 1 above (do NOT get confused and change any ROUTE Dial Patterns - see Hints on Route
Dial Patterns and Trunk Dial Rules if you are not quite sure of the difference).

If you want to dial *67 + 11 digit calls (U.S./Canada numbering format) and you need a short wait after *67 is dialed on a particular trunk, add this trunk Dial Rule:

*67|*67w+1NXXNXXXXXX

Alternately, if your provider accepts *67 + 7, 10, or 11 digit calls you could just use this pattern as a catch-all to insert the wait after *67 and then pass on whatever other
digits were received (don't use this pattern if you are going to use any of the other patterns on this page with the same trunk):

*67|*67w+X.

If you want to be able to dial local calls using 7 or 10 digits, but you need or want to send your provider *67 plus a full 11 digits, here's how to do that. First, if you want to
dial *67 + 7 digits (for calls within your own area code) and you want to send the number to the provider as *67 + 11 digits, you could add this TRUNK Dial Rule (replace
AAA with your area code):

*67|*67w1AAA+NXXXXXX

Alternately, if you dial local calls using ten digits rather than seven in your area you'd use this:

*67|*67w1+NXXNXXXXXX

ONLY make these changes on trunks that require a short delay after the *67 is dialed. A single w gives you a one half second delay, which is almost always long enough for
the second dial tone to come up - but if it's not you can stack w's for more time (e.g. wwww would give a two second delay). Just make sure all the w's are together, and on
the left side of the + character.

How to strip or replace the + character at the beginning of a called number


How to strip or replace the + character at the beginning of a called number
Every now and then you run into a situation where a particular phone will try to call numbers with a + (plus sign) character at the start of the phone number. This can occur if
you have such numbers in the phone's "phonebook", or if you receive a call that had a + at the start of the Caller ID number, and you then use the phone's callback feature.
This plays havoc with FreePBX - you can't match the + in a Dial Rule because the plus sign has a special meaning there. So, how do you get rid of the + and (optionally)
replace it with something more meaningful, like your international dialing code? Here's one way to do it:

Step 1: Add a context to /etc/asterisk/extensions_custom.conf


[custom-strip-plus]
exten => _+X!,1,Noop(Stripping + from start of number)
exten => _+X!,n,Goto(from-internal,${EXTEN:1},1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

The line with the Noop is just a comment, so you can change the text between the parenthesis to anything meaningful to you - it's there so if you are watching call progress in
the CLI, you can see when the + is being stripped. The next line after the Noop is where the action is - as shown, it simply strips the +. If you want it to replace the + with
any digits (such as "011" or "00"), simply insert those digits immediately before ${EXTEN:1} (between the comma and the $). So if your international dialing code is "00",
you might do this:
exten => _+X!,n,Goto(from-internal,00${EXTEN:1},1)

Step 2: Go the FreePBX page of all affected extensions and change the context from from-internal to custom-strip-plus - I know it's a pain to have to change the context
manually if you have several extensions, but until some other solution is devised, it's the only way I know to make this work.

Step 3 (optional): In your outgoing trunk(s), strip any added international dialing code on calls within your own country - if you added an international dialing code in step 1,
you probably don't want it sent on calls within your own country. The solution to that is to add a line in your trunk dial rules that looks for the international dialing code you
added followed by your country code, and replaces that with your in-country dialing code (if any). For example, if your country code is 385, and for in-country calls you dial
0+ the number, you might do this (changes 00385 to just 0):
0+00385|.

Or in the U.S. and Canada, if you used 011 for the international dialing code, you might do this to replace the 0111 with just 1:
1+0111|.

Credit: The above was developed in response to a question on the Elastix Forum. Thanks to "protenus" for asking the initial question and then providing meaningful
feedback!

37 of 89 5/22/2009 11:12 PM
How to upgrade Asterisk
How to upgrade Asterisk

Note: Doing this improperly may break your system, so I don't recommend doing this unless you have a complete backup and know how to fix what you break.

Note 2: Do NOT just upgrade to the very latest version of Asterisk unless you are CERTAIN that version works with FreePBX. If you are using an older version of FreePBX
(2.2.x or earlier) you should not even consider upgrading to the 1.4 branch of Asterisk. Instead, use the latest Asterisk version in the 1.2 branch. On the other hand, if you are
using a current FreePBX version (2.3.x or later), you may be able to use a version of Asterisk in the 1.4 branch. The instructions below assume that you are sticking with the
1.2 branch of Asterisk for the time being.

Note 3: Users of "all in one" distributions (such as AsteriskNOW, Elastix, PBX in a Flash, etc.) should be aware that that the preferred method for upgrading your
distribution may be to use an upgrade script, or some other method specific to your distribution. You may want to peruse the forums specific to your distribution before
proceeding. Note that upgrading using the method shown here could cause some distribution-specific features to stop working - if that happens, it's your responsibility to
figure out what to do to get those features working again. Also, it's possible that the kernal source code may not have been included the distribution you are using, and it is
needed to successfully compile Asterisk, so if you need the kernal source you may to do yum -y install kernel-devel kernel from the command prompt prior to continuing
with these instructions. If you do choose to use the procedure shown here rather than the one specific to your distribution, and then at some later date you run a distribution-
specific upgrade script, you may in fact revert some of the software to an older version.

That said, here is the best information I have found on upgrading Asterisk. Before you do this, you may want to use your web browser to navigate to the following directories
to see if there are later versions in the same branch as the version shown below - if so, you may want to try the newer version:

http://downloads.asterisk.org/pub/asterisk/releases/

http://downloads.asterisk.org/pub/zaptel/releases/ (if using dahdi rather than zaptel: http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/)

http://downloads.asterisk.org/pub/libpri/releases/

(libpri is really only necessary if you have a T1, but it may already be installed on your system and if so, you probably want to update it.)

From the command prompt, execute each of the following commands, in turn, from the command line (substituting the latest version in the same branch if you wish, and
substituting dahdi for zaptel if your installation uses dahdi - the author of this document has no experience with dahdi, so cannot advise you beyond that):
cd /usr/src

wget http://downloads.asterisk.org/pub/asterisk/releases/asterisk-1.2.32.tar.gz
tar -xzvf ./asterisk-1.2.32.tar.gz

wget http://downloads.asterisk.org/pub/zaptel/releases/zaptel-1.2.27.tar.gz
tar -xzvf ./zaptel-1.2.27.tar.gz

wget http://downloads.asterisk.org/pub/libpri/releases/libpri-1.2.8.tar.gz
tar -xzvf ./libpri-1.2.8.tar.gz

wget http://downloads.asterisk.org/pub/asterisk/releases/asterisk-addons-1.2.9.tar.gz
tar -xzvf ./asterisk-addons-1.2.9.tar.gz

wget http://downloads.asterisk.org/pub/asterisk/releases/asterisk-sounds-1.2.1.tar.gz
tar -xzvf asterisk-sounds-1.2.1.tar.gz

Prior to compiling you need to remove the old modules, but rather than just blowing the directory away, I'd suggest renaming it to a backup - there might be some added
modules in there that you will want to restore later, e.g. codecs you may have added. Note that making some of these modules unavailable may be the cause of certain
third-party applications "breaking", which I why I don't advise just deleting everything.
cd /usr/lib/asterisk/
mv modules ./old-modules-backup

If you have never done it previously (and particularly if you are not installing a fairly recent distribution), you may need to grab an updated version of the spinlock.h file from
the Nerd Vittles site. If you are simply upgrading from a earlier version of Asterisk you probably don't need to do this, but I'll mention it anyway (definitely take a look if you
are having problems with Zaptel). See the Nerd Vittles article at either http://nerdvittles.com/index.php?p=137 or http://nerdvittles.com/index.php?p=174 (search the page for
"spinlock.h").

Now compile and install (note the directory names will be different if you installed different versions):

Note: If you are running a Rhino Zaptel PCI Card like the R4FXO, please see the comment by WAudette at the bottom of this page before proceeding with the next step.

Note: If you are using the Open Source Line Echo Canceller (OSLEC) then you will want to patch Zaptel before running make. See this page and look for the section
heading "HowTo - Run OSLEC with Asterisk/Zaptel."
cd /usr/src/zaptel-1.2.27
make clean
make
make install

Note: If the Zaptel compile fails during "make", run the following from the command line:
sed -i s/rw_lock/rwlock/ /usr/src/kernels/*/include/linux/spinlock.h

Then rerun "make" and "make install". One person said the above line didn't work for him, but this one did:
sed -i s/rw_lock/rwlock/ /usr/include/linux/spinlock.h

Anyway, once you get the Zaptel upgrade installed, you can continue...
cd ../libpri-1.2.8

38 of 89 5/22/2009 11:12 PM
make clean
make
make install

cd ../asterisk-1.2.32
make clean
make
make install

cd ../asterisk-addons-1.2.9
make clean
make
make install

cd ../asterisk-sounds-1.2.1
make install

Note: "make clean" and "make" are not required for the sounds module.

(The "make clean" instructions above may not always be necessary, strictly speaking, but they don't hurt anything and in a few cases may help avoid problems.)

After doing the above, you may want to compare the contents of /usr/lib/asterisk/modules and /usr/lib/asterisk/old-modules-backup, and copy over any files that are in the
backup directory but not the new modules directory. Some modules I found that had not been reinstalled included:

app_flite.so
app_managerredirect.so
app_mwanalyze.so
app_nv_backgrounddetect.so
app_nv_faxdetect.so
app_rxfax.so
app_txfax.so
cdr_odbc.so
cdr_pgsqI.so
chan_h323.so
format_ogg_vorbis.so
res_config_odbc.so
res_odbc.so

Your list may be different. Note that simply copying these modules back does not automatically guarantee that everything will start working again, but it probably improves
your odds considerably. Be careful NOT to overwrite anything in the new modules directory!

Note that on rare occasions, Asterisk may fail to restart after you upgrade (this was a particular issue starting with version 1.2.16 and continuing for perhaps a couple of
versions thereafter, but has not been frequently noted in the most recent versions). If that happens, don't panic! Instead, enter the following at the command prompt:
tail /var/log/asterisk/full

This will show you the last few lines of the log file, and will (hopefully) reveal what Asterisk was attempting to load when it failed. How you handle it depends on the exact
nature of the problem, but the typical problem seems to be that Asterisk fails to load a module, such as a codec - for example, I had a problem where Asterisk refused to load
the codec_speex.so module. Since I don't use the speex codec anyway, I simply moved the module out of the usual location (the /usr/lib/asterisk/modules directory) into
another location, and restarted Asterisk. When Asterisk couldn't find the offending codec, it moved on and restarted normally. The creator of the Nerd Vittles site had a
problem with the app_speech_utils.so module; you can read about his experience and solution here (look for the section headed "Fixing a Source Code Wrinkle").

After removing the incompatible module, you may get a message such as "Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)" when you attempt
to restart Asterisk. Simply deleting the asterisk.ctl file does not seem to help. Probably the easiest way to resolve this problem is to simply reboot the system (use shutdown -r
now), after which Asterisk will (hopefully) come back up and operate normally (if anyone knows a better way, please feel free to edit this paragraph - I know that in theory
one should hardly ever need to reboot Linux, but in this case Asterisk is already non-functional and rebooting seems to get it to restart properly, and IMHO a reboot after a
upgrade is an easy way to end any running processes that might benefit from being restarted anyway).

The Nerd Vittles site suggests that you may need to rebuild Zaptel after doing the above upgrade. I'm not convinced this is always necessary (and would welcome comments
one way or the other), but if you find you are having problems with Zaptel, try entering these commands from the command prompt:
amportal stop
rebuild_zaptel

(You may need to reboot at this point:)


shutdown -r now

(After the reboot:)


modprobe wcfxo — Do this only if you have Zaptel devices installed in your system!!!

amportal stop
genzaptelconf

(The Nerd Vittles site suggests rebooting again. Personally I think they overdo it with the reboots, but maybe better safe than sorry. Again I'd appreciate clarification from
more knowledgeable folks:)
shutdown -r now

If anyone finds that the above instructions need tweaking, please share your comments either by editing this page, or adding a comment below. Until there are a few
comments noting success, I'd advise folks that are not that familiar with Linux to hold off on the upgrade, so that you don't take the chance of breaking something you can't
fix.

Comment by WAudette on Rhino R4FXO

39 of 89 5/22/2009 11:12 PM
Added Monday 15 of January, 2007 03:20:00 UTC

If you are running a Rhino Zaptel PCI Card like the R4FXO these Lines need to be added before building Zaptel.[b]
cd /usr/src/zaptel-1.2.27
wget ftp://ftp.rhinoequipment.com/R4FXO/Drivers/latest/r4fxo.c
wget ftp://ftp.rhinoequipment.com/R4FXO/Drivers/latest/r4fxo.h

Next edit the Makefile in this directory.


nano Makefile

Search for the place to add instructions to build the Rhino in by hitting

<CTRL-W> Then type tor2 <enter> Then add R4FXO in front of tor2.

Exit the program by hitting


<CTRL-X>
Save, answer Yes and <enter> to keep the same name. Yes to overwrite as well if it asks you.

Then continue w/ make

How to use callgroups and pickgroups


The question sometimes arises about how to pick up a call on an extension that is ringing in another part of the home or office, when you are closer to a different extension.

If you know the number of the extension that is ringing, you can simply pick up the nearest extension and dial ** + the extension number of the ringing extension. But what
if you're in an office or a large home, you hear a phone ringing in the distance but have no idea which extension it is? That's when callgroups and pickupgroups come in
handy. When implemented, if your pickupgroup list includes the ringing phone's callgroup, you can simply pick up your phone and press *8# and you'll get the call.

To get your feet wet, here's how to set up your first callgroup and pickupgroup. Decide on a group of extensions that should be able to pickup each other's calls (keep it small
for test purposes - you can always expand it later). Go to the FreePBX configuration page for each of those extensions, and put the number 1 in both the callgroup and
pickupgroup text boxes. Click "Submit" after adding those values, and go to the next extension in the group and do it again. When you've done enough to test it, click the bar
to save the configuration changes.

Now place a call from any phone to one of the phones in the group. From any other phone in the group, pick up and dial *8#. The other phone should stop ringing and you
should get the call. If it doesn't work, there are a couple possibilities - either you didn't enter the same number in both text areas on each extension configuration page, or your
phone has a dial plan that doesn't recognize *8 as a valid number. On a Linksys/Sipura phone or VoIP adapter, you could add something like *8S4 to the dial plan (remember
to separate it from other dial plan sections using the | character), which if you hit *8 without the # would wait four seconds to see if you might really be dialing a *8x format
code. With other brands of phones or devices you just might need to do something similar if the phone refuses to pass *8 to your Asterisk server. Alternately, you could just
change the *8 code to something else that your phones will allow you to dial, by going to the Feature Codes page and changing the code associated with "Asterisk General
Call Pickup" (under the "Core" section).

Once you have this working, you can set up other callgroups and pickupgroups. Callgroups must have a number between 0 and 63. Any extension can only belong to one
callgroup, but you can allow any extension to pick up calls from one or more callgroups by specifying multiple callgroup numbers for that extension's pickupgroup (separate
callgroup numbers by commas). So, for example, if you had a few bosses and several employees, you could put all the employee extensions in callgroup 1 and the boss
extensions in callgroup 2. Then you could specify 1 as the pickupgroup option for employee extensions, and 1,2 as the pickupgroup option for the boss extensions. That way,
an employee could answer any other employee's phone, but not a boss phone, while a boss could pickup a call from an employee extension or a boss extension.

Note that an extension does not need to be part of a callgroup to be able to pickup calls (if there's only one boss, you don't need to put him in a callgroup so he can pickup
employee extensions) and conversely, an extension can be part of a callgroup but not a pickupgroup (maybe you don't want employees picking up each other's calls, but you
want the boss to be able to do so).

There are a couple caveats: First, callgroups and pickupgroups are an Asterisk feature, not a feature implemented in FreePBX (that is to say, the FreePBX developers
probably can't do much about any bugs in the implementation). One thing I recall about this feature from a couple of years ago is that it would not let you pick up calls across
technologies (that is, if a SIP extension was ringing it could not be picked up from an IAX2 extension). I have no idea if that's been fixed, but since most people only use SIP
endpoints these days, that probably won't be an issue in most places where this feature might be useful.

Also, I've seen a report that someone with zap extensions is having a problem making this work. I don't have any zap extensions so am unable to test that, but curiously, I did
find this section in the /etc/asterisk/zapata.conf that ships with FreePBX:
; Ring groups (a.k.a. call groups) and pickup groups. If a phone is ringing
; and it is a member of a group which is one of your pickup groups, then
; you can answer it by picking up and dialling *8#. For simple offices, just
; make these both the same. Groups range from 0 to 63.
;
callgroup=1
pickupgroup=1

Note that the two lines are uncommented by default, but since this file is not associated with any particular zap extension I have no idea whether it applies to all zap
extensions generally. Anyone with more information on how to implement this with zap extensions is invited to leave a comment.

HOW TO: Using FreePBX Back End for trixbox CE Authentication


Using FreePBX Back End for trixbox CE Authentication

Introduction

One of the cool features of FreePBX that seems to get lost when it goes in to trixbox is the ability to have multiple users. The following article explains how to make teixbox
CE 2.4/2.6 use the "administrators" module of FreePBX rather than the standard .htaccess (maint/passw0rd) This obviously is not supported by Rhino, trixbox, or FreePBX
and is for informational purposes only that said if you do this make backups of everything. You can not back up the trixbox.conf into the same directory or apache will look

40 of 89 5/22/2009 11:12 PM
at both files. Before doing this go in to FreePBX and make sure you know the username and password, default is admin/admin.

Information

1. Install apache's MySQL auth module:


yum install mod_auth_mysql

2. set authtype=webserver in your amportal.conf


nano -w /etc/amportal.conf

3. Replace the contents of /etc/trixbox/httpdconf/trixbox.conf


nano -w /etc/trixbox/httpdconf/trixbox.conf

Your file should look like this:


<directory>
AllowOverride AuthConfig
Options Indexes FollowSymLinks
order allow,deny
allow from all
AuthType Basic
AuthGroupFile /dev/null
AuthName "Restricted Area"
AuthMySQLEnable On
AuthMySQLHost localhost
AuthMySQLDB asterisk
AuthMySQLUserTable ampusers
AuthMySQLUser asteriskuser
AuthMySQLPassword amp109
AuthMySQLNameField username
AuthMySQLPasswordField password
AuthMySQLAuthoritative On
AuthMySQLPwEncryption none
Require valid-user
</directory>

<directory>
AllowOverride AuthConfig
Options Indexes FollowSymLinks
order allow,deny
allow from all
AuthType Basic
AuthGroupFile /dev/null
AuthName "Restricted Area"
AuthMySQLEnable On
AuthMySQLHost localhost
AuthMySQLDB asterisk
AuthMySQLUserTable ampusers
AuthMySQLUser asteriskuser
AuthMySQLPassword amp109
AuthMySQLNameField username
AuthMySQLPasswordField password
AuthMySQLAuthoritative On
AuthMySQLPwEncryption none
Require valid-user
</directory>

These use default mysql passwords. If you have changed these you will want to update amp109 above

4. Restart apache and FreePBX


/etc/init.d/httpd restart
amportal restart
Applies To
FreePBX
trixbox CE 2.4
trixbox CE 2.6
Keywords
trixbox CE, FreePBX, Authentication

Author James Finstrom

Original posting at https://support.rhinoequipment.com

How-Tos and Tutorials on Other Sites


How-Tos and Tutorials on Other Sites
There are many other sites that offer Tutorials and How-Tos that could be of interest to FreePBX users. Some of these were written with a particular distribution in mind, but
may be usable (or at least get you started in the right direction) if you use a different distribution. We have NOT tested most of these, and simply offer links to these sites as a
convenience - in other words, if something doesn't work as expected, take it up with the author of the article (although if things really go badly, you may wish to post a
comment to that effect on this page). Also note that many of these articles may have at least some outdated information.

If you should discover a dead link, please keep in mind that you may still be able to view the page by right-clicking on the link, copying the link (the URL) to your clipboard,
then going to the Wayback Machine and pasting the link in there, then clicking the "Take Me Back" button. Or, if you copy and paste the link title into Google, you may find
that Google has a cached copy of the page.

From the Best of Nerd Vittles site:

41 of 89 5/22/2009 11:12 PM
AsteriDex™ 4.0 - Web-Based RoboDialer
Asterisk Weather Station - By Airport Code, By Zip Code, or Worldwide Forecasts
Asterisk Wi-Fi HotSpot Finder - WiFi Hot Spot Locator for any ZIP Code in the United States
CallerID Trifecta Superfecta for FreePBX - AsteriDex, Google Phonebook, AnyWho, and WhitePages Name Lookups for Asterisk
Faxing with Asterisk - The Good, The Bad, and The Ugly with VoIP Faxing
FONmail for Asterisk - Email Delivery of Messages Dictated Using Any Asterisk Phone
MailCall for Asterisk - Get Your Email by Telephone
NewsClips for Asterisk - Get News Updates by Telephone
Phone Genie for Asterisk 2.0 - Web-Based Controller for Asterisk Manager API and CLI
PodCast Studio for Asterisk - Create and Listen to PodCasts by Telephone
TeleYapper 3.0 - Message Broadcasting System for Asterisk 1.2
TeleYapper 4.0 - Message Broadcasting System aka Phone Blasting Software for Asterisk 1.4
Telephone Reminders 3.0 - Flexible Reminder System for Asterisk 1.2, Now Supporting Daily, Weekly, Monthly and Annual Recurring Reminders
Telephone Reminders 4.0 - Reminder System for Asterisk 1.4, Now Supporting Recurring Reminders and Web Scheduling
xTide for Asterisk - The latest Tides, Solar and Lunar Happenings By Phone for Any Port City

From the Elastix Forum:

800 numbers using an Enum trunk - use an ENUM trunk to place toll-free calls (800, 888, 877, 866 etc.) at no cost whatsoever
Easily install Hamachi
Howto Upgrade IAXmodem,Hylafax, & Install Avantfax
openvpn - instructions based on OpenVPN setup on Centos 5.2
Restrict outbound calls using A2billing - only extensions with a positive credit are allowed to place calls on designated routes. See also this post for the rationale behind
this.
Tutorial: How to install the DEVSTATE-mod

From the ElastixConnection site:


DNS Cache for Elastix - How to setup a DNS Cache on your Elastix system. Helps resolve SIP Hang issue when Internet connection fails
Installing Asternic Call Centre Stats - Great looking Graphs and information relating to your Call Centre Queues
Installing ISymphony - How to setup ISymphony, a receptionist console, alllowing you to drag and drop calls with your mouse, including recording calls, barging calls
etc.
Installing OpenFire with MYSQL - How to setup Openfire to use MYSQL as the database and implement Asterisk-IM
Streaming Music On Hold (Revised) - How to install setup your Elastix system to use Internet Music Streams (Internet Radio) for on hold music

From the Michigan Telephone, VoIP and Broadband blog:


A quick way for FreePBX/Elastix/Trixbox users to auto-update Dyndns, maybe
BETA Perl script for Caller ID popups when using Linksys/Sipura devices
Echo problems with Asterisk? Try OSLEC
Linksys and Sipura adapter users - check your RTP Packet Size and Network Jitter Level - also applicable to some Linksys phones
Review of Ring Voltage Booster II™ from Mike Sandman Enterprises - this is how to connect more ringers (phones) to a VoIP adapter that has a low REN rating
Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server
Voip Phreak - » FreePBX Ubuntu Howto
Using Asterisk and FreePBX as a podcast player - part 1 of 3
Using Asterisk and FreePBX as a podcast player - part 2 of 3
Using Asterisk and FreePBX as a podcast player - part 3 of 3

From Moshe's Blog:


BLF and FreePBX feature codes
Howto: list Asterisk contexts and includes
Miscellaneous/Custom application/extensions: How to extend FreePBX with custom dialplan (part 1 of 2)
Miscellaneous/Custom application/extensions: How to extend FreePBX with custom dialplan (part 2 of 2)
Queue weights vs. Queue priorities
Restricting call transfers with FreePBX
Restricting outbound calls in FreePBX (blacklist)
Restricting outbound calls in FreePBX (whitelist)
Time Groups & Time Conditions

From the Nerd Vittles site:


Adding Post-Dial Processing to Asterisk and FreePBX Dialplans
Allison’s Text-to-Speech Trifecta: Cepstral, Asterisk 1.4 or 1.6, and FreePBX 2.4
Asterisk Hell: A Minefield Navigation Guide for Newbies
Avoiding the $100,000 Phone Bill: A Primer on Asterisk Security
Cloud Computing 101: Using Amazon’s S3 (Simple Storage Service) for Off-Site Asterisk Backups
Free Asterisk Calls to Zillions of Phones with ENUM and Gizmo5’s Backdoor Dialing
Good Morning: Hotel-Style Wake Up Calls Return to Asterisk
Introducing Noojee Click for Asterisk: The Free Click-to-Dial Solution for Firefox Using AJAM
The Lean, Mean Asterisk Machine: And Now It’s a Fax Machine - the part about faxing begins part way down the page
Why Wait? Build Your Own Skype Gateway to Asterisk - see also How to set up a Skype gateway on this site.

From the voip-info.org site:

NOTE: This site has a tremendous amount of information about Asterisk and VoIP in general. The following links just scratch the surface...

Asterisk
Asterisk AGI - The Asterisk Gateway Interface is an interface for adding functionality to Asterisk with many different programming languages. Perl, PHP, C, Pascal,
Bourne Shell - it's your choice, really.

42 of 89 5/22/2009 11:12 PM
Asterisk auto-dial out - The Asterisk dial plan extensions.conf responds to someone calling an extension on a channel. If you want to initiate a call from an external
application, there are several ways to do this.
Asterisk call notification - Possible instant messaging (and other) tools you could employ...
Asterisk - documentation of application commands - Here is a list of all the commands that you can use in your Dialplan (in FreePBX you would use these in
extensions_custom.conf). You can obtain your Asterisk's list of available applications at the CLI by typing "show applications" and "show application ".
Asterisk echo cancellation
Asterisk Functions - Asterisk functions are used in Asterisk's dialplan. Unlike dialplan applications, they cannot be used directly. Instead they return a value that could
be used by the dialplan logic.
Asterisk IAX channels
Asterisk sound files
Asterisk T.38 (used to send and receive faxes, especially in Asterisk 1.6)
Asterisk Telemarketer Torture
Asterisk tips and tricks - This page includes references to various tidbits of information that may assist you in your configuration of the Asterisk Open Source PBX. The
documents are often contributions of Asterisk users, documentation of solutions they've created in their implementation.
Asterisk tips MythTV integration - The open source PVR application suite named MythTV supports on-screen caller ID notifications. The original source of the caller
ID information was from an attached modem, but the application structure allows any source to broadcast the caller ID parameters. This example uses a System() call
to invoke mythtv's on screen display (OSD) with caller ID information.
Asterisk tips simple wake-up call - Yet another wake-up call implementation.
Asterisk Variables - Asterisk can make use of global, shared and channel-specific variables for arguments to commands
Fail2Ban (with iptables) And Asterisk - Fail2Ban is a limited intrusion detection/prevention system. It works by scanning log files and then taking action based on the
entries in those logs. We are implementing Fail2Ban with a configuration to be able to prevent SIP brute force attacks against our Asterisk PBX's.
How to install Asterisk 1.4 and FreePBX 2.3.1 in Ubuntu Linux
Modified Weather.agi to Work with Cepstral - be sure to scroll down to "Alternative Change" heading.
Packet8 DTA310 and Asterisk
Setting up paging with a sound card
Settings Mediatrix APAs with FreePBX
The Dummies Guide to Direct Sound Card Overhead Paging with Optional Ring Tone Generation - Don't Try This at Home

From various sites not listed above:


A Simple Asterisk Based Toll Fraud Prevention Script
Answering machine detection
Asterisk Call Notification over XMPP
Asterisk Tutorials - from asteriskguru.com
AstRecipes - a place to store and share real world "recipes" that can help in configuring and running your Asterisk system.
Controlling Applications With Asterisk - this example uses DTMF tones to issue commands to control a VideoLAN VLC Media Player (additional comments here).
Creating a FreePBX module
Elastix Without Tears (link to .pdf file) - if you installed Elastix to get FreePBX and Asterisk then you should download and read this free e-book
Email notifications for missed calls in Asterisk
How To Add a Cellular Trunk to Your VoIP System
How To Add a Cellular Trunk to Your VoIP System - Part 2
How to connect your Free PBX server to Gizmo5
How to Distribute VoIP Throughout a Home - how to safely reuse inside telephone wiring for VoIP
How to use ENUM with FreePBX and Asterisk VOIP
How to use Talkshoe.com with Asterisk
Important thing to look at if you get one way audio problem with Asterisk 1.4.10 and FreePBX 2.3.0
Recover MySQL root password - you can recover MySQL database server password with these five easy steps.
PiaF without Tears (link to .pdf file) - if you installed PBX in a Flash to get FreePBX and Asterisk then you should download and read this free e-book
Setup MySQL CallerID Lookup Source on FreePBX
The wonders of echo cancellation troubleshooting
Ultimate CNAM script - This perl script looks up a phone number using a number of different sources and tries to match the number to a name and also figure out if the
number has been reported as one sometimes found in phone spam calls. The resulting text string is then sent to your phone as the caller id name string. (Instructions are
in the README file)
Using ENUM with FreePBX
Using monit Tool to Monitor Asterisk
Using wideband codec in Asterisk 1.4 - How to install g722 as an available codec in Asterisk 1.4.x.

If you have found an especially informative how-to or tutorial page on another site, please leave a comment. I reserve the right to delete any comments that appear to be
thinly-disguised spam.

HOWTO Install HylaFax with iaxmodem on a running CentOS 4.3 + Asterisk


1.2.7.1 system with FreePBX 2.1
This is a different setup from the default fax installation in FreePBX
which uses rxfax and txfax. By using HylaFax instead you will get a
fully featured enterprise class fax server.

- Download the Redhat Enterprise Binary RPM of HylaFax 4.3.0 (hylafax-4.3.0-1rhel4.i386.rpm)

- Install it

- Run /usr/sbin/faxsetup which may complain about missing components (note: mgetty-voice is not required)

- ln -s /usr/share/fonts/ghostscript /usr/share/ghostscript/fonts

(to solve missing fonts problem)

For documentation on HylaFax I prefer the docs at

43 of 89 5/22/2009 11:12 PM
http://hylafax.sourceforge.net/howto/index.php instead of the docs at
hylafax.org (sf.net is a fork)

Questions in FaxSetup:

Should an entry be added for the FaxMaster to /etc/aliases )yes(? yes

Users to receive fax-related mail )root(? root

HylaFAX configuration parameters are:

1 Init script starts faxq: yes

2 Init script starts hfaxd yes

3 Start old protocol: no

4 Start paging protocol: no

Are these ok yes? yes

Setup scheduler options according to local requirements. Left most of it default except for the area codes and dialling rules.

- Download IAXmodem from http://iaxmodem.sourceforge.net/

- Check the README of IAXmodem for installation. If you already


have a version of spandsp or libiax installed (which you want to keep)
you to build statically, otherwise just build normally (just
./configure && make for libiax2 and spandsp, then ./build for
iaxmodem). After that move the iaxmodem binary you just built to
/usr/local/sbin

This is my example /etc/iaxmodem/ttyIAX0 :

device /dev/ttyIAX0 #each line should have it's own device node!

owner uucp:uucp

mode 660

port 4570 #each line should have it's own port number!

refresh 300

server 127.0.0.1

peername 201 #this is the local extension number in FreePBX (create it!)

secret 12345 #password for the extension

cidname Fax1

cidnumber 0015554731543

codec alaw

Now that iaxmodem is configured we must make sure that HylaFax will
find it as modems. In the tarball of iaxmodem you will find a file
config.ttyIAX Edit this file (if you are in Europe use
etc/dialrule.europe for example instead of default). You only need to
change the first 6 lines. When done copy the file to
/var/spool/hylafax/etc/ similar to the other files, one for each modem,
i.e. onfig.ttyIAX0 onfig.ttyIAX1 etc.

Don't forget you also need to setup basic HylaFax stuff but the HF docs will help you there.

After starting iaxmodem, you then need to run faxgetty on the


ttyIAX device. Then hylafax will start to answer calls. To try it from
the commandline first start "/usr/local/sbin/iaxmodem ttyIAX0" and in
another screen "faxgetty /dev/ttyIAX0"

If it works, put something like this in /etc/inittab :

iax1:2345:respawn:/usr/local/sbin/iaxmodem ttyIAX0

iax2:2345:respawn:/usr/local/sbin/iaxmodem ttyIAX1

mo1:2345:respawn:/usr/sbin/faxgetty ttyIAX0

mo2:2345:respawn:/usr/sbin/faxgetty ttyIAX1

The first two lines start two iaxmodem sessions, the last two enabe fax receive on the 2 modems.

Then run : "/sbin/init q" to reload the inittab settings

This works for me, now I need to get fax routing working based on

44 of 89 5/22/2009 11:12 PM
DID. As far as I can see now, it will not be possible to do this with a
standard IAX extension from FreePBX, I guess we need to create a custom
one. From the HylaFAX mailinglist :

When you dial the iaxmodem, you need to append the DID that is coming in on the line:

exten => 900,1,Dial(IAX2/iaxmodem0/${EXTEN},10,r)

The ${EXTEN} variable gets set as $CALLID4 in Hylafax, where you can then route in FaxDispatch:

case "$CALLID4" in

8001112222)

SENDTO="joeschmoe@somewhere.com"

;;

8005551111)

SENDTO="foo@bar.com"

;;

*)

SENDTO="baz@failover.com"

;;

esac

I still need to figure out how to create the proper extension


configs in FreePBX. I tried adding the ${EXTEN} to the dial string of
an IAX extension but FreePBX doesn't like that. And if you would try to
use a trunk (which you can customize) then you cannot forward inbound
routes to it.

HOWTO Setup A Remote SIP Extension


This HOWTO assumes that your FreePBX system is sitting behind a NATed firewall with no direct connection to the outside world and it is NOT in the DMZ zone. If you
have your system facing outside, or have used Mapped IP addresses or other techniques, then it is assumed that you have adequate knowledge to interpret these instructions
and also assure that you have properly secured your installation.

The three key considerations in setting up remote extensions are:

Asterisk Knows what network is external vs. internal


All Signaling and Media ports are forwarded to Asterisk
The Extension/Device is setup to be NATed

In order to accomplish the above we need to apply some configuration information into FreePBX, some Asterisk configuration files and on your firewall/router.

Internal/External Network Information

You must edit or create the file sip_nat.conf typically found in your /etc/asterisk directory and make sure it is owned by asterisk. We will assume that you have an internal
network of 192.168.1.0/255.255.255.0 and that you have a static IP address of 24.72.182.16. If you have a dynamic IP, see the notes that follow. In this situation, you need
to create or edit the following entries in your sip_nat.conf file:
externip=24.72.182.16
localnet=192.168.1.0/255.255.255.0

This tells Asterisk what IP address range is internal vs. external so that it can rewrite the SIP headers appropriately. If you have a dynamic address instead of a static address
then you need to modify the above. You will need to have a domain name for the host, let's assume you are using dyndns.com's free service and have chosen the name
mydomain.dyndns.org. Then your sip_nat.conf file would look like the following:
externhost=mydomain.dyndns.org
externrefresh=120
localnet=192.168.1.0/255.255.255.0

Where externrefresh tells Asterisk to recheck the IP address every 120 seconds in this case. You should adjust this higher or lower based on the frequency that this changes.

Firewall/Router Configuration

The default installation of FreePBX is configured to use UDP port 5060 as the SIP signaling port and UDP ports 10001-20000 as the RTP Media ports. All these ports must
be forwarded to your FreePBX System. How to do this varies widely depending on the firewall or equipment that you are using. It is commonly referred to as Port
Forwarding or maybe Destination NAT (DNAT). However it is referred, if we assume in this example that your FreePBX system has an internal IP address of 192.168.1.100
then you will want:

UDP/5060 -> Forward to 192.168.1.100


UDP/10001-20000 -> Forward to 192.168.1.100

Extension Information

45 of 89 5/22/2009 11:12 PM
We will assume you are using FreePBX in Extension mode but if you are using Devices/Users the same applies on the Devices page. You need to configure the extension
with NAT enabled so that Asterisk knows this device is NATed and can apply the SIP rewriting rules that you previously configured in the sip_nat.conf file. Navigate to the
desired extension and scroll down to the Device Options Section, it should look like:

Device Options - NAT

The configuration option nat must be set to yes, and you may want to set qualify to yes as well although not necessary.

With these steps, when properly configured, your external device should be able to communicate with your FreePBX server unless you have issues on the remote end where
the device is located because of badly behaved Firewalls. The remote device should be configured to use your external IP address or domain name as configured above in the
sip_nat.conf file.

HOWTO: Create custom feature codes to read back the feature status of
extensions
Custom feature codes to read back the feature status of extensions

This code can be dropped into extensions_custom.conf and will read


back to the caller the status of various features on the caller's
extension (if *108 is dialed) or on any specified extension (if
*109+extension is dialed - if you only dial *109 you are prompted to
enter the extension). See the comments in the code for additional
details. This code was originally created by philippel (a.k.a.
p_lindheimer), and modified slightly to add Call Forward On Unavailable
/ No Answer. Also, the invocation feature codes were changed to *108
and *109 - if you want to change them to *+ a 2 digit code, be sure to
change the {EXTEN:4} back to {EXTEN:3} in the two places it appears (in
the *109 section below).

Addendum: This code calls a file:


/var/lib/asterisk/sounds/custom/quarter-second-silence.wav which is
simply one-quarter second of silence in a .wav format file (8000 Hz, 16
bit, mono format). If you don't have this file and don't wish to create
it, search and replace all instances of custom/quarter-second-silence with silence/1

Also, the code has been modified since the original posting to
combine consecutive multiple Playback statements into single
statements.

;-------------------------------------------------------------------------------------------
; REPORT BACK ON EXTENSION STATUS
;
; Settings Currently Supported:

46 of 89 5/22/2009 11:12 PM
; CW: Call Waiting
; DND: Do Not Disturb
; CFB: Call Forward On Busy
; CFU: Call Forward On Unavailable / No Answer
; CF: Call Forward Unconditional
;
; get status of a specific extentsion by dialing *109xxx where xxx is the extension
; status is desired for. (Can be any number of supported extension digits)
exten => _*109.,1,Set(uext=${EXTEN:4})
exten => _*109.,n,Noop(STATUS ON EXTENSION: ${EXTEN:4})
exten => _*109.,n,Answer
exten => _*109.,n,Wait(1)
exten => _*109.,n,Goto(custom-check-status,s,1)
; get status from specific extension, prompted after dialing
exten => *109,1,Answer
exten => *109,n,Wait(1)
exten => *109,n,BackGround(please-enter-the)
exten => *109,n,Playback(extension)
exten => *109,n,Read(uext,then-press-pound)
exten => *109,n,Wait(1)
exten => *109,n,Goto(custom-check-status,s,1)
; playback extension settings for current or prompted phone
exten => *108,1,Answer
exten => *108,n,Set(uext=${CALLERIDNUM})
exten => *108,n,Goto(custom-check-status,s,1)
; this function is passed an extension number and will read back the
; status on the target extension
;
; TARGET EXTENSION ${uext}
;
; Settings Currently Supported:
; CW: Call Waiting
; DND: Do Not Disturb
; CFB: Call Forward On Busy
; CFU: Call Forward On Unavailable / No Answer
; CF: Call Forward Unconditional
[custom-check-status]
; Announce Extension Being Reported on
exten => s,1,Noop(REPORTING STATUS ON EXT: ${uext})
exten => s,n,Playback(status&for&extension)
exten => s,n,SayDigits(${uext})
exten => s,n,Playback(is)
; CW: Call Waiting Status
exten => s,n,Noop(CW RESULTS: ${DB_EXISTS(CW/${uext})} : ${DB_RESULT})
exten => s,n,Playback(custom/quarter-second-silence&call-waiting)
exten => s,n,GotoIf($[${DB_EXISTS(CW/${uext})}]?cwenabled:cwdisabled)
exten => s,n(cwenabled),Playback(activated)
exten => s,n,Goto(dndcheck)
exten => s,n(cwdisabled),Playback(de-activated)
; DND: Do Not Disturb Status
exten => s,n(dndcheck),Noop(DND RESULTS: ${DB_EXISTS(DND/${uext})} : ${DB_RESULT})
exten => s,n,Playback(custom/quarter-second-silence&do-not-disturb)
exten => s,n,GotoIf($[${DB_EXISTS(DND/${uext})}]?dndenabled:dnddisabled)
exten => s,n(dndenabled),Playback(activated)
exten => s,n,Goto(cfbcheck)
exten => s,n(dnddisabled),Playback(de-activated)
; CFB: Call Forward on Busy Status
exten => s,n(cfbcheck),Noop(CFB RESULTS: ${DB_EXISTS(CFB/${uext})} : ${DB_RESULT})
exten => s,n,Playback(custom/quarter-second-silence&call-fwd-on-busy)
exten => s,n,GotoIf($[${DB_EXISTS(CFB/${uext})}]?cfbenabled:cfbdisabled)
exten => s,n(cfbenabled),Playback(activated&and&is-set-to)
exten => s,n,SayDigits(${DB_RESULT})
exten => s,n,Goto(cfucheck)
exten => s,n(cfbdisabled),Playback(de-activated)
; CFU: Call Forward on Unavailable Status
exten => s,n(cfucheck),Noop(CFU RESULTS: ${DB_EXISTS(CFU/${uext})} : ${DB_RESULT})
exten => s,n,Playback(custom/quarter-second-silence&call-fwd-no-ans)
exten => s,n,GotoIf($[${DB_EXISTS(CFU/${uext})}]?cfuenabled:cfudisabled)
exten => s,n(cfuenabled),Playback(activated&and&is-set-to)
exten => s,n,SayDigits(${DB_RESULT})
exten => s,n,Goto(cfcheck)
exten => s,n(cfudisabled),Playback(de-activated)
; CF: Call Forward Unconditional Status
exten => s,n(cfcheck),Noop(CF RESULTS: ${DB_EXISTS(CF/${uext})} : ${DB_RESULT})
exten => s,n,Playback(custom/quarter-second-silence&call-fwd-unconditional)
exten => s,n,GotoIf($[${DB_EXISTS(CF/${uext})}]?cfenabled:cfdisabled)
exten => s,n(cfenabled),Playback(activated&and&is-set-to)
exten => s,n,SayDigits(${DB_RESULT})
exten => s,n,Goto(endcheck)
exten => s,n(cfdisabled),Playback(de-activated)
; CALL STATUS END - GOODBYE!

47 of 89 5/22/2009 11:12 PM
exten => s,n,Playback(custom/quarter-second-silence&goodbye)
exten => s,n,Hangup
;------

HOWTO: Free Directory Assistance in the USA


Setting up a trunk and route for free Directory Assistance in the USA
NOTE: In the following document it is suggested to use the 1-800-FREE411 service. However, before doing that you may wish to read this message (including the reply
comments) to avoid getting hit with unwanted text messages on your cell phone. This is particularly true if you permit calls into your FreePBX system from outside lines that
could then be redirected to one of the free directory assistance services.

This makes use of the free 1-800-FREE411™ and/or 1-800-411-SAVE services, so that all Directory Assistance calls are free (I note that Google has now started up a
service at 1-800-GOOG-411 but it is only for U.S. business listings). Here are three easy ways to set this up in FreePBX - just pick the one you prefer (I'd recommend the
third method for the greatest flexibility, but it's up to you). Note that all of these methods assume you already have a route and trunk that will complete toll-free calls in the
USA - if you don't (or if your provider charges you for them), just set up an ENUM trunk (if you haven't already done so), and then create an Outbound Route that catches
calls matching the toll-free number patterns (e.g. 1800NXXXXXX, 1888NXXXXXX, 1877NXXXXXX, 1866NXXXXXX, etc.) and specify the ENUM trunk as the top
choice (or only choice) for completing those calls. Then make that "toll free" route higher in priority than the route that handles your regular USA traffic.

Method #1 (the newer way):


This will only let you use ONE of the above services. If you want to be able to fall through to the other service when your primary choice is unreachable, then use Method #2
below, or if you want to be able to pick which service you use on each call, then use Method #3. This method simply creates the equivalent of one or more speed-dials to the
service of your choice

Create a Misc Destination.


Give it a description, such as "Directory Assistance".
Put the number of the service you wish to use (such as 18003733411) in the dial: text field.
Don't forget to click "Submit Changes".

Create a Misc Application.


Give it a description, such as "Directory Assistance".
Put the number you want to use in the Feature Code: text field. Typical choices are:
411
5551212
_1NXX5551212 (Note the initial underscore)
_NXX5551212 (Note the initial underscore)
Make the Destination the Misc Destination that you created in the first step.
Don't forget to click "Submit Changes".
If you wish to match all of the above-mentioned patterns, you can create as many additional Misc Applications as you need, however you should also consider
using Method #2.

Method #2 (the old way, but possibly better than the first method):
Not only will this allow you to possibly fall through to another service if your first choice is unreachable, but it's also a bit easier if you're matching many patterns. Also you
can place it in the correct priority order among your routes, which is not possible with Method #1 (see the notes below). The only downside is that the method used here is a
bit less obvious in its workings.

Create the Trunk(s)


Create a new CUSTOM Trunk. Previously we had said that the ONLY thing you need to fill in for this trunk is the Custom Dial String, which will be in the form:

Local/number-to-call@outbound-allroutes

Where the number-to-call will be 18003733411 or 18004117283, so the Custom Dial String would simply look like one of these (better yet, you could create two custom
trunks so you have have access to both, in case one is down):

Local/18003733411@outbound-allroutes

Local/18004117283@outbound-allroutes

Bear in mind that you must have an outbound route that will pass 1-800 number calls, otherwise this won't work.

We now also suggest that you may want to add the following, if you wish to avoid sending Caller ID information from an external source to any of these services (see the
note at the top of this page for a reason you might want to do that, and note this does NOT inhibit the sending of Caller ID from an internal extension):

Outbound Caller ID: hidden

Note that the word "hidden" above is a "magic string" that is used to hide the CallerID sent out over Digital lines ONLY (E1/T1/J1/BRI/SIP/IAX). You could also use any
landline or VoIP DID number that you own, as long as it doesn't have text messaging service associated with it, isn't a FAX line, etc. The main idea here is to avoid the
possibility of passing a cell phone number to these services. You need only do this with services you don't trust to not send you unwanted text messages. Note again that this
does NOT override the CallerID on calls from internal extensions!!!

Create The Route


1) Name the route whatever you like, for example, "411" or "DirectoryAssistance"

48 of 89 5/22/2009 11:12 PM
2) In the Dial Patterns put the following lines:

411

5551212

1NXX5551212

NXX5551212

If there are any other local variations that normally work for calling Directory Assistance (such as 1411), you may wish to include those also.

3) Select the trunk(s) you just created. It/they will show as the name whatever you put in the Custom Dial String, for example:

Local/18003733411@outbound-allroutes

Local/18004117283@outbound-allroutes

4) Save the new route and then, when it appears in the list of routes, use the arrows to move it to a position higher than the routes you normally use for outgoing PSTN calls.
This route must have a higher priority than any other route where the pattern could match. For example, if someone dials 1-212-555-1212, you want the call to hit this route
before any other routes to the 212 area code.

Notes:
First, be aware that if this route is higher in priority than routes that handle calls to toll-free numbers, it will intercept calls to 1-800-555-1212. If that's not desirable behavior,
make sure your route that handles North American toll-free calls is higher in priority than this route.

Second, please be aware that ANY calls to 1NXX5551212 will be picked off by this route, which means it will also intercept calls intended for Directory Assistance in
Canada and/or the Caribbean (those portions that use the country code "1"). If that's not desirable, you may need to specify each valid USA area code individually, e.g.
12125551212, 12135551212, etc.

Method #3 (the most versatile method):


This method is slightly more complicated to initially set up, but it gives your users the option of going to the free directory assistance service of their choice, while still
blocking them from going to the expen$ive telephone company service. It was inspired in part by a thread in the Elastix "Tips and Tricks" forum (Adding mulitple Free dir
asst. in your dialplan).

Create the Destinations


Go to Misc Destinations and add the following three destinations:

Description: 800-411-SAVE
Dial: 18004117283

Description: 1800FREE411
Dial: 18003733411

Description: GOOG-411
Dial: 18004664411

Create a Recording
Use the System Recordings module to create or upload a recording. Here is a suggested script for the recording:

"Free Directory Assistance! To use 800 411 SAVE, press 1. To use 1 800 FREE 411, press 2. If you want a business listing and wish to use Google's 411 service, press 3. Or
stay on the line to be connected to 800 411 SAVE"

(We suggest using 800-411-SAVE as the default because they use live operators. If you're having trouble getting touch tones through, that's the one you want.)

Create an IVR
Go to the IVR module and Add IVR. Here are the suggested settings:

Change name to Directory Assistance

Change timeout to 3 (optional)

Uncheck "Enable Directory"

Uncheck "Enable Direct Dial"

Check "Loop Before t-dest"

Check "Loop Before i-dest"

Change Repeat Loops to 1

For the Announcement, pick the System Recording you created in the previous step.

For the first three options, pick the three Misc Destinations you created, in the same order they are mentioned in the announcement. Be sure to type the number coresponding
to the menu option in the text box. Do NOT check "Return to IVR" for any of these. Then click on "Increase Options"

For the final option, type t in the text box and select the default Misc Destination (800-411-SAVE if you used the script above). Once again do NOT check "Return to IVR"

49 of 89 5/22/2009 11:12 PM
Click on SAVE. Check to make sure that all four options are there and entered correctly after the page reloads, then click the "Apply Configuration changes" bar (this is
necessary for the next step).

Determine the new IVR context name - OR - create a Misc Application


At this point you can do either of two things. If you want to get a bit down and dirty with the system, then use a text viewer or editor to look at etc/asterisk
/extensions_additional.conf. You need to find the context name for the IVR you just created. It will be in the form [ivr-x] where x is a number, such as [ivr-5]. So search for
"[ivr-" (without the quotes) and for each one that comes up, look to see if it appears to be the correct one. It will probably be the highest numbered one (since you just
created it) and also it will contain a line that looks like this...
exten => s,n,Background(custom/sound_file)
...where "sound_file" is the name of the file you created or uploaded when you made the System Recording. Make a note of the context name (just the part within the square
brackets). You can close the text editor or viewer now (do not make any changes to the file!).

Alternately, you can create a new Misc Application. If you do that, set it up as follows:

Description: Directory Assistance

Feature Code: 411

Feature Status: Enabled

Destination: (The IVR you created in the previous step:) Directory Assistance

Create a Custom Trunk


Create a new CUSTOM Trunk. Fill in the following:

Outbound Caller ID: hidden (optional, see discussion under Method #2 above)

Custom Dial String:


If you did NOT create a Misc. Application in the previous step: Local/s@ivr-x (Replace the x with the correct number from your IVR context as determined in the previous
step).
If you DID create the Misc. Application in the previous step: Local/411@from-internal

Click on Submit Changes.

Create an Outbound Route


Go up to Method #2 above and find the section headed "Create The Route" and follow the instructions for that step - for the trunk, pick the Custom Trunk you created in the
step above. Don't forget to "Apply Configuration changes" when you are all through. Be sure to read the notes after that section also, they are equally applicable to this
method.

HOWTO: Linksys SPA-3102/Sipura SPA-3000 + FreePBX


How to setup a Linksys SPA-3102 or Sipura SPA-3000 with FreePBX
Here is how you can setup Linksys/Sipura SPA-3000 series devices to work with FreePBX. These instructions were originally written for the Sipura SPA-3000, but are also
applicable to the Linksys SPA-3102.

It took a lot of work to get the SPA-3000 working, but what finally got it working was very simple setup.

The FXS port (where you plug in your phone) is set up in the normal manner, just as on the Linksys PAP2 or a Sipura unit. So when you want to set up that port (labeled
"Line 1" in the web interface), just look for instructions for setting up a Line port on a PAP2 or SPA-2000 (such as How to set up a Linksys PAP2 or Sipura SPA-2000 for
use with FreePBX) - the setup of the FXS port is pretty much identical to those devices. What were are concerned with here is the FXO port, that is, the port that connects to
the PSTN telephone line (appropriately labeled "PSTN Line" in the web interface).

Before you begin you may want to make sure you have the latest firmware, which at this writing may be available at the Linksys site. Note that the old Sipura site (which is
now redirected to the Linksys site) implied that if you had 2.0 hardware you had to use 2.0 series firmware. However, at least two people have successfully upgraded a 2.0.x
series SPA-3000 to firmware revision 3.1.10(GWd). No guarantees, but if you are feeling lucky (and can locate the firmware) you may want to try it. Of course if you have
the 3.0.x series hardware you can definitely upgrade your firmware. The upgrade will give you some additional settings but will wipe any current configuration, so you will
want to do that first if you intend to do it. You may want to hold off on the upgrade unless you experience problems - that is up to you.

FreePBX Trunk setup:


For the PSTN setup here is what I did to finally get it working.

1) Create a new SIP trunk in FreePBX.

2) For Caller ID I put my inbound DID there since it's from my BellSouth POTS line.

3) Max channels: I put 1 since it's only one line. This is important because if you don't do this, and this trunk is busy, calls may not fall through properly to the next trunk, due
to a combination of bugs in certain versions of Linksys/Sipura firmware, and a bug in chan_sip in some versions of Asterisk. Even with this set, this bug can still bite you if
you have an Asterisk version earlier than 1.2.16, the device is in use for an incoming call and the system attempts to use it for an outgoing call (the max channels logic only
counts outgoing channels, not incoming ones).

4) Dialing rules, Dialing Wizard and prefix I left blank. (Remembering to keep it simple at the beginning will go a long way). If you want to add or strip a prefix you can
change the dialing rules later. (Note: If you plan to send out calls with the *67 privacy code prefix, after you get the rest of this working you can go to the page How to set up
per-use Caller ID blocking (*67), and particularly take note of the section at the bottom of the page, "Additional Instructions if you are using a SPA-3000/SPA-3102
device...")

50 of 89 5/22/2009 11:12 PM
5) Trunk name: Call this 1-pstn (again, simple). The reason for starting this trunk name with the digit "1" is an attempt to make it the first sip trunk listed in
/etc/sip_additional.conf, which can help you avoid a strange bug in Asterisk (more on this in the "Additional information" section below). IMPORTANT - Note that the
Trunk Name must match the User ID in the "Sipura 3000/3102 Device Settings" section below, otherwise you may have registration problems.

6) Outgoing settings - Peer settings (don't enter the comments - the text following the semicolons):

disallow=all ;Starting with FreePBX 2.4 this must be the first statement in the peer settings
allow=ulaw
canreinvite=no
context=from-trunk ; this is needed here - very important.
dtmfmode=rfc2833 ; you can try inband if you have problems accessing your IVR menus
host=dynamic ; or you may use host= followed by a static IP address, SEE NOTE BELOW
incominglimit=1
nat=never ; if Sipura is not on your local network you may need nat=yes
port=5061 ; we use port 5061 rather than 5060
qualify=yes
secret=XXXXXX ; pick a good password
type=friend
username=1-pstn ; must match the trunk name or registration may fail.

NOTE: The original author of this page had written that the host setting should be host=dynamic and added the comment "IMPORTANT - use this even if you set the Sipura
to use a static IP." However I (wiseoldowl) found that when the Sipura has a static IP address on the same local network, you can set the host= to that address (example:
host=192.168.0.250) and it works fine EXCEPT that you will get complaints in your Asterisk log in the form "Peer '1-pstn' is trying to register, but not configured as
host=dynamic". If you use the recommended host=dynamic (to avoid the log entries, or because the adapter really is on a dynamically assigned IP address), then you
probably should use a fairly short registration interval in the SPA-3000/3102 configuration - see the section below on Sipura 3000/3102 PSTN settings.

7) Incoming settings - User settings

From wiseoldowl: It turns out that these are not needed at all as long as you set the type=friend in the Peer Settings. The original author of this page had placed some settings
in this section but I do not believe they were actually being used and in fact may have been causing problems. Other Sipura 3000/3102 configuration pages on the net don't
include a User context or User settings so I strongly advise leaving these blank.

8) No Register String is used. Click Submit Changes and remember to click the orange bar to update your system.

FreePBX Outbound Route setup:


You now are ready to setup your outbound routing.

1) Name the route whatever you like. I called my route spa3000; again this is to keep it simple.

2) No password for the route; keep it simple

3) I only want calls to my area code and 911 via this route so under dial pattern I have:

911
305NXXXXXX
786NXXXXXX

The point here is to use dial patterns that will allow only those calls that you wish to go out via the Sipura - don't just copy the above verbatim!

4) Trunk sequence: I have it going to the trunk associated with the Sipura (SIP/1-pstn) first. Then, to my Voipjet settings.

5) Submit Changes and remember to click the orange bar for the update.

FreePBX Inbound Route setup:

This is easy to set up, but necessary if you want to receive incoming calls!

1) Give the Inbound Route any name you like, such as 1-pstn or spa3000 - it's totally up to you.

2) For DID number, keep it simple and use the phone number associated with the line connected to the Sipura. The most important thing to remember is that this must
EXACTLY match the number you put in "Dial Plan 2" while configuring the Sipura, as shown in the instructions below.

3) Skip down to the bottom of the page and set a destination for incoming calls - this can be a particular extension, your IVR, or any destination you like.

4) Submit Changes and remember to click the orange bar for the update.

Skip the other Inbound Route options for now - once you get it working you can come back and make changes if you like.

Sipura 3000/3102 Device Settings:

Next you need to setup your actual Sipura 3000/3102 PSTN settings.

The person who originally started this page said, "Ok here is where I was playing for 3 days to get this part working. It's strange that when I just removed everything and kept
it very simple and logical it started to work just fine." So if possible, start with a Sipura 3000 or Linksys 3102 set to the factory default configuration and go from there,
because other than the changes specifically mentioned below you'll probably want the default settings.

To begin the setup, login to the device, click on admin (if prompted, enter "admin" as the username and the password, if you have set one up), and then click on advanced.
Some of the following settings may not be visible if you are only logged in as a user, or have not clicked on the advanced link.

Check the RTP Packet Size!!!


VERY IMPORTANT: Before you do anything else, go to the SIP tab. Look under RTP Parameters and check the RTP Packet Size. Linksys has set this to 0.030 by default,
which is not correct for use on ulaw (G711u codec) connections. Change it to 0.020 instead (or 0.02 on older Sipura devices). If you don't do this, you may experience
strange problems with "choppiness" or random clicks on some calls but not others, and you may also experience problems when playing Asterisk sound files. By the way, this

51 of 89 5/22/2009 11:12 PM
applies to all Linksys/Sipura adapters, not just the SPA-3000/3102.

Next go to the PSTN Line tab - I am only putting what needs to change.

1) Sip settings: Just make sure the SIP Port is set to port 5061 (I did not need to change mine).

2) Proxy and Registration:

Proxy: The numeric IP address of your Asterisk box if both the Sipura and the Asterisk box are on the same local network, or the address of your Asterisk server if it is
elsewhere on the Internet.
Make Call Without Reg: Yes
Ans Call Without Reg: Yes
Register Expires: 300 (if Asterisk box is on same local network and you used host=dynamic in the FreePBX Trunk settings), or see discussion in note below

Notes on Proxy and Registration section: Some people have reported that they had to set Make Call Without Reg and Ans Call Without Reg to Yes before things would work
- it apparently doesn't hurt anything to change those two settings, and it may save you some grief. Also, if you used host=dynamic in the FreePBX Trunk settings (as
discussed above), then you will probably want to make the Register Expires: setting something fairly low, especially if the SPA-3000/3102 is on the same local network as the
Asterisk box - for example, Register Expires: 300 would make the unit re-register at five minute intervals, while a setting of 900 would probably be a good choice if the
device and the Asterisk Server are not on the same local network. The reason for the shortened timeout is that when you use host=dynamic in the FreePBX Trunk settings, if
registration is lost for any reason (such as a server reboot) then the SPA-3000/3102 will be inaccessible until the next time it re-registers. This has led some people to
conclude that host=dynamic doesn't work, when in fact it does but is just waiting for the adapter to re-register.

3) Subscriber Information:

Display name: Put something here that will identify this line - this is only displayed on your phones if you get a call with no Caller ID information (or you don't subscribe to
Caller ID). Keep it at 15 characters or shorter. You could use something like LOCAL PSTN CALL.
User ID: 1-pstn ; very important - this must exactly match the FreePBX Trunk name and username in the trunk configuration!
Password: XXXXXX (same as you used in FreePBX Trunk settings).

4) Audio Configuration (if you don't see all these settings, you forgot to click on "advanced"):

DTMF Process INFO: Yes


DTMF Process AVT: Yes
DTMF Tx Method: Auto

Note: The DTMF Tx Method is the one you especially need to check if your IVR is not receiving DTMF from your callers reliably. Also, in this section you may want to
check to make sure that the Preferred Codec is set to the default G711u (assuming you placed "allow=ulaw" in the FreePBX Trunk configuration as shown above).

5) Dial Plans:

Under Dial Plans it's important not to change the default (xx.) on any except Dial Plan 2. I put it very simple to go to my inbound so FreePBX takes care of my calls:

(S0<:1234567890>)

Replace 1234567890 with the telephone number of the PSTN line coming into the device. Note that this must exactly match the DID number in your FreePBX Inbound
Route setting for this device. If the number here and in the Inbound Route don't match exactly, you won't receive incoming calls.

6) VoIP-To-PSTN Gateway Setup:

This is another important settings section.

VoIP-To-PSTN Gateway Enable: yes


VoIP Caller Auth Method: None ; use "None" to start, you can change later for added security (see below).
VoIP PIN Max Retry: 3 ; I did not change this.
One Stage Dialing: Yes ; very important
Line 1 VoIP Caller DP: none
VoIP Caller Default DP: none
Line 1 Fallback DP: none

7) VoIP Users and Passwords (HTTP Authentication):

During the initial setup, leave all of these blank (the drop-downs can be left set to 1). After you get everything working you can revisit this section to add security, as will be
discussued later.

8) PSTN-To-VoIP Gateway Setup:

Here is another section that made me pull my hair out.

PSTN-To-VoIP Gateway Enable: Yes


PSTN Caller Auth Method: none
PSTN Ring Thru Line 1: no ; I use Asterisk for my routing.
PSTN Pin Max Retry: 3
PSTN CID for VoIP CID: Yes if you subscribe to CallerID service on your PSTN line, otherwise No
PSTN CID Number Prefix: (Leave Blank)
PSTN Caller Default DP: 2 ; important - here is where it sends the calls to.
Off Hook While Calling VoIP: No
Line 1 Signal Hook Flash To PSTN: Disabled
PSTN CID Name Prefix: (Leave Blank)

Leave everything else in this section blank. We are almost finished now.

9) FXO Timer Values (sec):

Just change 2 items here.

52 of 89 5/22/2009 11:12 PM
Voip Answer Delay: 0 (The original recommendation was 1, but this can cause a spurious half ring on outgoing calls, before actual ringing from the called line commences, so
0 is now the recommended value).

PSTN Answer Delay: If you do not subscribe to CallerID service on your PSTN line, this can be set to 0. Most users will want to set it to at least 3 so that the incoming
CallerID data is captured. In rare situations you may need a slightly longer delay (5 should be more than enough).

10) PSTN Disconnect Detection:

Skip the PSTN Disconnect Detection section unless you know what type of PSTN disconnect signal(s) are used on your PSTN line and wish to change the settings so that
those signals (and only those signals) are detected. Generally you should only tweak this section if the Sipura isn't properly detecting disconnected calls on the PSTN side.
The "Disconnect Tone" is by default set to detect the "fast busy" signal usually sent after a call has ended in North America - you may wish to tweak this setting if the switch
serving your PSTN line sends a different tone after disconnect.

11) International Control

Check the settings here - each country uses different values for PSTN lines. If you live in Australia, Canada, the United States or most other countries with modern telephone
systems you probably won't have to change anything except perhaps the gain levels, so we'll only deal with them for now. The default values for both the SPA To PSTN Gain
and the PSTN To SPA Gain are 0 (zero), and that's where you should leave them when you're first setting up the SPA-3000/3102. But just so you know, here's some
information on those settings:

If the SPA to PSTN gain is set too low, the parties on the PSTN side of the connection will probably complain about your volume being too low, or will ask you to speak up
or talk closer to the phone. If it is set too high, however, you are more likely to hear echo, and outgoing calls may fail because the level of DTMF tones sent by the
SPA-3000/3102 will be too "hot" to register properly at the PSTN switching equipment.

If the PSTN To SPA Gain is set too low, you'll hear low volume levels on PSTN calls. If it's set too high, the people on the PSTN side of the connection will be more likely to
hear echo (they may hear their own voices echoed back from your end). Also, any echo that has been reflected back to you will be heard at a higher volume level, and will
therefore be more objectionable.

While the default levels are usually adequate, we found that boosting both values up to 3 produced a more "natural" sounding volume level in both directions. However, this
is very much dependent on the characteristics of the PSTN line - if you're on a very short loop, values of 0 may be adequate for both settings, if on a very long loop you may
need to go even higher than 3. The valid range is -15 dB to 12 dB in 1 dB increments (but just enter a numeric value, do not enter "dB" in the text field). If you have actual
test equipment available you can fine-tune the volume settings for best results.

We'll talk a bit more about settings in this section under "Troubleshooting", below. For now, that's it. Submit and it should register and you should be able to use the PSTN
port on the Sipura. Note that if you used host=dynamic in the FreePBX Trunk setting, the adapter may take some time to register, and it will not be accessible until it does (as
discussed above). If you're in a hurry, you can power-cycle the adapter to force it to re-register (but make sure that you have first submitted your changes, and that the
adapter's web page has refreshed!).

Troubleshooting
If you are connecting VoIP adapters back-to-back (SPA-3000 PSTN port to a line port on another device, perhaps because you are wanting to access a line from a
commercial VoIP provider that insists you use a VoIP device that they provide) and if their device ever sends caller ID names with a single quotation mark, those calls will
either simply ring and never answer, or will be answered but then disconnected after a few seconds, due to a bug in the SPA-3000 firmware. This problem usually presents
itself if the other device is a Cisco ATA-186. You can either have your provider send you a newer device (they may charge you for this) OR you can disable CallerID
passthru (which will throw away the incoming Caller ID). To do the latter, set PSTN CID for VoIP CID to NO, and you may as well set PSTN Answer Delay to 0 since there
will be no need to wait for CallerID. A third option involves patching Asterisk itself but that is beyond the scope of this article (however, see the added comment at the
bottom of this article).

If you have problems getting the SPA-3000 to register with your Asterisk box, try setting the Sipura up on a static IP address instead of letting your router assign it one via
DHCP. Go to the System tab, and the Internet Connection Type settings:

DHCP: No
Static IP: (pick an address on your local network that will not conflict with your router's DHCP assignments, such as 192.168.0.250)
NetMask: (usually 255.255.255.0 unless you have a large network)
Gateway: (usually either 192.168.0.1 or 192.168.1.1, unless your local net is numbered differently - for home users, this is generally the same address you use to get to your
router's configuration page)

Skip down to Primary DNS: (you will probably want to put the same address as you used in Gateway here - usually both functions are handled by your router. Or, you can
use a third-party DNS service such as OpenDNS).

While you are here you may want to set a Primary NTP Server so that your Sipura will know the time. Usually you can point this to any NTP server on your local network
(such as your Asterisk box) and it will be close enough, but you could also use a public "pool" NTP server. But if you do this you will also want to set a time zone, and that
setting is found under the "Regional" tab at the bottom of the page (if you have the latest firmware you can also include a Daylight Savings Time rule). It is NOT necessary to
set up a time server to get this unit to operate as a PSTN gateway; I only mention this so that people who do want to set the time will know where the settings are.

There are two other settings under the PSTN tab, in the International Control section that you should be aware of if you are having problems. If you can't seem to get calls to
go out (and in particular, if Asterisk reports that there are no circuits available), try setting the Line-In-Use Voltage to a lower value, such as 15. Some telephone companies
use "pair gain" or "subscriber carrier" equipment to put multiple subscribers on the same loop. If you have the great misfortune to receive telephone service through such
equipment, your on-hook line voltage may be less than 30 volts, and if that is true the Sipura will think the line is always in use unless the Line-In-Use Voltage setting is
lowered. In the U.S.A. and Canada, nominal on-hook voltage is about 45 to 48 volts, and in that situation the 30 volt setting is correct. But if you are "served" using pair gain
or subscriber carrier equipment (or are unsure of the telephone line voltages used in your locality), you may want to use a voltmeter to measure both PSTN on-hook voltage
and off-hook voltage (the latter being the voltage on the line when a phone is taken off-hook), and set the Line-In-Use Voltage setting to a value about halfway between
those two measured voltages. That's also a report that a particular fixed cellular terminal designed for making calls over GSM only produces 14 volts on-hook voltage - one
user had to set the SPA-3102 Line-In-Use Voltage to 10 to get it to work properly with that device.

Also, the FXO Port Impedance default setting is 600 ohms is correct for many places in the world. Some places use 900 ohms. You really should try to find out the standard
impedance setting for the PSTN line you are connected to, since an improper setting can cause some frequencies to be higher or lower in volume than others. Mismatched
impedance can also be a source of echo and DTMF recognition problems. However, determining the best/most correct setting can be something of a black art, as this Cisco
document illustrates. That said, if you don't know the correct impedance, the 600 ohm setting will generally work well, especially on loops of about one mile/1.5 km or less. If
you have noticeable echo, try also the 900 ohm setting to see if that reduces or eliminates the echo.

Adding security

53 of 89 5/22/2009 11:12 PM
Once you have it working satisfactorily using the above instructions (test it with both incoming and outgoing calls), you can try adding additional security - most users
seem to have had success doing this, but occasionally someone has problems, however it's easy to reverse the procedure if you do have any issues. Go to the adapter's PSTN
Line tab and make the following changes:

In the VoIP-To-PSTN Gateway Setup section, change VoIP Caller Auth Method to HTTP Digest.

In the VoIP Users and Passwords (HTTP Authentication) section, change the following:

VoIP User 1 Auth ID: 1-pstn


VoIP User 1 DP: none
VoIP User 1 Password: XXXXXX (same as you used in trunk settings).

After making the above changes test to make sure that both incoming and outgoing calls still work as expected. That's all the security changes under the PSTN tab.

However, the Sipura's web pages are still wide open (unless you have already set up passwords) and if anyone on your local network goes there (or someone manages to hack
their way in) they can go to the Sipura's web pages, and see and change all your settings. So you will probably want to password protect the settings pages. Note that there are
separate user and admin passwords - you can set these in the System Configuration section of the page accessed through the System tab. BE CAREFUL - take your time and
think about what you are doing here, because if (for example) you make a typo in a password and don't catch it, you could lock yourself out of your Sipura!

Additional information
If your adapter is at a remote location, or for some other reason you would like incoming calls on the PSTN line to ring through directly to "line 1" (the phone port)
WITHOUT first passing through Asterisk (but still having the ability to send the call to voicemail if no one answers), set PSTN Ring Thru Line 1 to Yes, set PSTN Answer
delay to whatever number of seconds delay you wish before the call goes to voicemail, and then set PSTN Caller Default DP to 1 and set Dial Plan 1 as
(<:*extensionnumber@asterisk_ip:port>) - the * in front of the extension number tells FreePBX to send the call directly to that extension's voicemail without building a
inbound route. So, incoming calls from the PSTN should ring directly into any telephones connected to the phone port, but if not answered in the specified time they will still
get transferred to the extensions voicemail (thanks to "cyberglobe" for suggesting this in the IRC channel).

The reason we used a trunk name starting with the digit "1" is an attempt to make it the first sip trunk listed in /etc/sip_additional.conf (which seems to have trunk names
sorted alphanumerically). This can help some users avoid a strange bug in Asterisk. In some versions of Asterisk, if there are one or more SIP trunks configured and Internet
connectivity is lost, it becomes impossible to place any SIP call, including calls between SIP extensions that are on the same local network as the Asterisk server (and which
therefore should be unaffected by the Internet outage - sadly, that is not the case)! Note that calls using protocols other than SIP are unaffected. There have been some
reports that if the first SIP trunk (listed in /etc/sip_additional.conf) is accessible, Asterisk will be happy and continute to complete calls on the local network. Therefore, we
suggested using 1-pstn so that the adapter would be the first SIP trunk and (assuming it's on the same local network as the Asterisk server) always accessible, even during an
Internet service outage, thereby (hopefully) avoiding the issues when the Internet connection goes down. If you have more than one adapter, or don't need this attempted
protection against Internet service outages, then you can change ALL instances of 1-pstn to some other string, but just make sure that ALL instances mentioned above are
changed to the EXACT SAME string (otherwise the adapter will not be able to register with Asterisk).

Other pages with Sipura 3000/3102 setup instructions


Different people have different ways of setting up any particular piece of hardware. Here are some alternative approaches to setting up a SPA-3000/3102:

Asterisk@Home Handbook Wiki

SPA3102 and FreePBX HOWTO

Voipspeak - Guide to the SPA-3102

Added comment about Caller ID name problem


As mentioned above, if the SPA-3000 receives a CallerID name from the PSTN line that contains only one quotation mark, the call will fail. This issue, or a very similar one,
has been raised in Digium Issue Tracker report 0007333: Malformed callerid string causes SIP clients to silently drop packets. The report contains a patch to an older version
of callerid.c that MAY or MAY NOT have solved this problem. It is extremely doubtful whether this patch would work with any recent version of callerid.c, but if you are a
very proficient coder you may be able to figure out how to do the same thing in a more recent version. We do NOT recommend that anyone attempt to apply this patch as
shown, it is included here only to illustrate the problem, and one attempt at a solution:
656c659

< /* Just trim off any trailing spaces */

---

> /* Just trim off any leading spaces or quotes */

658,661c661,664

< while(!ast_strlen_zero(instr) && (instr[strlen(instr) - 1] < 33))

< instr[strlen(instr) - 1] = '\0';

< /* And leading spaces */

< *name = ast_skip_blanks(*name);

---

> while(*(*name) && ((*(*name) < 33) || (*(*name) == '\"'))) (*name)++;

> /* And trailing spaces or quotes */

> ne = *name + strlen(*name) - 1;

> while((ne > *name) && ((*ne < 33) || (*ne == '\"'))) { *ne = '\0'; ne--; }

54 of 89 5/22/2009 11:12 PM
Howto: Linksys/Sipura SPA-3000 + FreePBX
This page has been moved here:
HOWTO: Linksys SPA-3102/Sipura SPA-3000 + FreePBX

HowTo: Linux Tips and Tricks


This section is to provide some good linux tips and tricks to all the PBX'ers.

How to add Hamachi Moderated VPN for remote administration/softphone


access

Basically, what this howto is intended to do is to teach you how to get hamachi to run as a service.

Why would you want to run Hamachi? Once installed on your CentOS 4.5/5.X system and installed on a workstation (perhaps a laptop) you can access your server remotely
via VPN for http or ssh administrative tasks. You can also use the private network to connect softphones and even set up DUNDi trunking over this VPN.

For client installation see this link.

Installing hamachi as a linux system service is quite simple. You first follow the regular steps of installation of hamachi.

Download the file from http://files.hamachi.cc/linux/hamach...-20-lnx.tar.gz and then execute the following command (see http://files.hamachi.cc/linux/ for other
options):

Code:
# tar -zxvf hamachi-0.9.9.9-20-lnx.tar.gz

(Note: You do not have to do these next 3 commands, it's just a good idea to keep your hard drive organized)

Code:
# mkdir /usr/src/hamachi
# mv hamachi-0.9.9.9-20-lnx /usr/src/hamachi
# cd /usr/src/hamachi/hamachi-0.9.9.9-20-lnx

Once done with this, you need to do your standard hamachi installation command:

Code:
# make install

Once installed, you need to first run the program "tuncfg". (Note: tuncfg is a program which makes the hamachi network adapter and must always be running while
hamachi is running in order for hamachi to work)

Code:
# tuncfg

Now to get hamachi running as a system service and make your setup scripts:

First and foremost, you need to put your hamachi


configurations in a global directory as opposed to your home directory.
hamachi-init creates scripts in your home directory in a folder called
.hamachi by default, but we are going to specify the configuration
directory of /etc/hamachi. (note also that hamachi itself can be run under a non-privileged user. tuncfg, however, needs to be run as root).

Code:
# hamachi-init -f -c /etc/hamachi
# hamachi -c /etc/hamachi start
# hamachi -c /etc/hamachi login
# hamachi -c /etc/hamachi create network password

NOTE: Start thinking about how telephony might use a VPN when naming.

Next:

# hamachi -c /etc/hamachi set-nick nickname


# hamachi -c /etc/hamachi go-online network

Once done with this, we will need to make a hamachi runtime script.

Use your favorite text editor to make a file called hamachi-start.

Code:
# nano /usr/bin/hamachi-start

55 of 89 5/22/2009 11:12 PM
This file will be a shell script. For those who aren't well versed in
linux, just copy exactly what I tell you to and it should work
perfectly fine. If you feel like modifying it any, feel free -- it will
still work. The most important thing is, start tuncfg, then start hamachi.

Here is the contents of hamachi-start:

Code:

#!/bin/sh

hamachi_start() {
echo "Starting hamachi..."
/sbin/tuncfg
/usr/bin/hamachi -c /etc/hamachi start
}

hamachi_stop() {
echo "Stopping hamachi..."
killall tuncfg
/usr/bin/hamachi -c /etc/hamachi stop
}

hamachi_restart() {
hamachi_stop
sleep 1
hamachi_start
}

case "$1" in
'start')
hamachi_start
;;
'stop')
hamachi_stop
;;
'restart')
hamachi_restart
;;
*)
hamachi_start
esac

Not done yet, now you need to chmod it to give it executable permissions:

Code:
# chmod a+x /usr/bin/hamachi-start

To add Hamachi as a startup item you manually edit /etc/rc.local -- be sure to back this up before poking around in there though.

Code:
# cp /etc/rc.local ~/rc.local.bak

Then edit it (Again, use your favorite text editor instead of nano. If nano doesn't work, you can always try pico)

Code:
# nano /etc/rc.local

At the very bottom of this file, add the following lines:

Code:

if [ -x /usr/bin/hamachi-start ]; then
. /usr/bin/hamachi-start
fi

Crtl-x and Crtl-y then press enter and viola! You have Hamachi as a service when you restart.

SOME ADDITIONAL NOTES:

I found the easiest way to manage a Hamachi


network is to use the free Windows version (Better still to purchase a
full version) and create all networks from that workstation.

We want to use a global configuration file... So, you need to always


specify the file's location. Therefore, instead of "hamachi join
network password" and so on, the commands will look like this:

Code:
# hamachi -c /etc/hamachi set-nick nickname
# hamachi -c /etc/hamachi login
# hamachi -c /etc/hamachi create network password
# hamachi -c /etc/hamachi join network password
# hamachi -c /etc/hamachi go-online network

56 of 89 5/22/2009 11:12 PM
# hamachi -c /etc/hamachi list
# hamachi -c /etc/hamachi go-offline my-net

57 of 89 5/22/2009 11:12 PM
Prevent unauthorized access to Webmin (or FreePBX or any other service)
I have my PBX configured, so I can only access my FreePBX web interface and my webmin from within my network, or from ON the machine itself… however, I
occasionally need to access it when I am not in my office, and here is a GREAT way to do it:

((The following example is assuming you are using a windows desktop, and using Putty to connect to your server via SSH, and that you currently have iptables configured for
firewall blocking (why wouldn’t you), and you are know what ports your services are running on. If you have a linux desktop, try: ssh -L 80:localhost:80
user@remotemachine))

IF YOU ARE NOT SURE WHAT YOU ARE DOING WITH YOUR FIREWALL - READ THE MANUAL OR YOU MAY LOCK YOURSELF OUT OF THE SERVER!!!

On your server, connect via SSH and nano /etc/sysconfig/iptables Modify your iptables firewall as follows:
-A INPUT -p tcp -m tcp --dport 80 -j DROP
#(If this same line exists with an ACCEPT, put a # in front of the line) - Web Interface Port

-A INPUT -p tcp -m tcp --dport 9001 -j DROP


#(If this same line exists with an ACCEPT, put a # in front of the line) - Webmin Port

(change the port numbers as appropriate)

You should also make sure you have a line similar to one of the following
-A INPUT ! -i eth0 -j ACCEPT
or
-A INPUT -i lo -j ACCEPT

Then do a service iptables restart

Now, if you try to connect to webmin or your web interface, your browser will just timeout or disconnect.

Now, open your putty configuration, and set it up as follows:

LinuxPuttyTunnelConfiguration: Picture to show how to configure Putty for SSH Tunneling

This will map the ports on your machine (80 and 9001) to the same port on "localhost" on the remote machine when you make an ssh connection.

Now, here's the cool part:


Just connect and login to your remote server via SSH.

Then open a browser on your local machine and browse to http://localhost:9001 and your webmin interface on the remote machine will answer and allow you to login.
Because we setup "Putty Tunneling", your local machine port 9001 is passed down the SSH connection to your remote server on port 9001, allowing you to do exactly what
you need to do, only do it without the threat of having a hacker keep trying to login to your webmin and gaining control of your server by leaving your webmin open in the
firewall.
In addition, you can just browse to http://localhost and connect to your FreePBX configuration.

Obviously, this can be used for any service/port on your server, but webmin is a good example to show you how to set this up.

Editor Note: Additional security related items you **should** configure in your iptables is to block EVERY port not necessary. Then setup SSH on an alternative
port by editing /etc/ssh/sshd_config and restarting sshd (configure the firewall to accept this alternate port first), as well as ensuring you are using STRONG
passwords. THIS IS NOT EVERYTHING YOU SHOULD DO TO SECURE YOUR LINUX SYSTEM, BUT HOPEFULLY THIS WILL HELP GET YOU
STARTED!

-Richard Teachout
RHCE, MCSA, MCTS:Hosting

Notes: This assumes you have AllowTcpForwarding yes (or have #AllowTcpForwarding commented out which is default) in your /etc/ssh/sshd_config, or tcp forwarding
won't work.

Setting Network Card Duplex Settings

58 of 89 5/22/2009 11:12 PM
Note: This should be read completely before you try this, as it could cause you to lose connectivity to the server if your network doesn't support it!

Many of the asterisk servers you may install/deploy are going to be setup in someone else's network, who likely doesn't have a linux engineer, and you may not be one, so this
is for you. Even experienced linux engineers often miss the little things, and this is one of them!

On any network switch, you have settings for "Full Duplex"/"Half Duplex" 10Mb/100Mb/100Mb etc.. Most of the networks that are around today, are 100Mb networks.
Many of us know how to set this up on a windows PC, but have you ever wondered how you do this in linux? Or have you just hoped that using "Auto-Detect" always
works... (ps.. not recommended)
Have you ever had "wierd" sip timeouts, or network disconnects to a sip provider that you just can't trace?? THIS MAY BE THE REASON! (the network card is flapping
between 10Mb and 100MB or Full and Half duplex, causing packet loss). By forcing the NIC's to be the same as the switch, you eliminate this issue. It may not solve your
problem, but it definitely can't hurt, and is recommended.

In order to ensure your linux server and the switch are always talking at the same speeds, I recommend that you have the onsite network engineer setup the switch port that
you are plugging into to be forced to 100MB FULL DUPLEX, and the use the following tool to set this up on your network interface(s) on the server. Note: I use the
following tool on Redhat/Centos (so pbxinaflash and trixbox should both be able to do this for **most** network cards. If you have an abnormal linux driver for your
network card, you should know what you are doing anyway).

The tool I recommend using (because it is soo easy) is ethtool, and is likely already installed on your PBX as it is used by the ifup utilities. (If not, try "yum install ethtool" or
visit http://sourceforge.net/projects/gkernel/ - just know what you are doing..)

I take and run the following on any new machine I setup:


ethtool eth0 | grep -e eth -e Speed -e Duplex
which would show you:
Settings for eth0:
Speed: 100Mb/s
Duplex: Half
(You should run "ethtool eth0" once to see the full output!)
As you can see, the duplex reported as Half.. So I then run:
ethtool -s eth0 speed 100 duplex full autoneg off
This sets the duplex settings on the NIC.

Note If you are doing this on a remote server, it may timeout your SSH session for a moment, or if your switch port doesn't support Full-Duplex, you may not be able
to re-connect, so do your homework, or have someone locally who can restart the network services or restart the machine!!!. Just doing this will only keep the setting
for the current session.

Assuming it worked, you should then be able rerun the first command and you would see:
Settings for eth0:
Speed: 100Mb/s
Duplex: Full

Now. Assuming this was true, you need to make sure this gets setup after a server reboot as well.
Here's how:
Add the following at the end of /etc/rc.d/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
OR
Add the following to your /etc/sysconfig/network-settings/ifcfg-eth0
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

I hope this helps some of you properly setup a linux server on a corporate network, and for those lucky ones, I hope this helps you resolve odd connectivity issues with your
sip provider (as it did for me on the first asterisk server I installed way back when, where I forgot to set this - we lost an occasional sip trunk for about 10 seconds, randomly -
I found errors on the switch port, and remembered I forgot to set the duplex settings.. now no more switch port errors, and the sip trunk stopped randomly dropping).

-Richard Teachout
RHCE, MCSA, MCTS:Hosting

Using Screen for Session Mgmt (Never have your upgrade/installation die because
you lost your connection!)
Ever had a remote SSH connection where you were doing an upgrade (say to asterisk or pbxinaflash, etc) and you lost your internet connection, which killed your ssh session,
and stopped your compile, leaving your system in a horribly unusable state? NEVER AGAIN! That is what I use screen for!

This will quickly become your FAVORITE AND REGULARLY USED LINUX UTILITY!!!

What is Screen?
As the man page states, "Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells)." This can be a
life saver when working with remote servers. Screen has a several great features for helping you administer your linux box more productively and most importanly, safely.

I am going to discuss the four features (multiple windows, sessions, logging, sharing) that I use the most.
(Check out the man screen for more info)

Installing Screen
If you are using a RedHat/CentOS distribution, you probably already have this installed (pbxinaflash/trixbox/and more!) You will find it in /usr/bin/screen. To see if it is, type
which screen
If you do not have it already installed, it is easily installed by doing "yum install screen" or installing the appropriate RPM for your distribution (most distributions have this
great application, and it's been around for YEARS). You can visit the screen website at http://www.gnu.org/software/screen/

Using Screen
Screen is started from the command line, just like any other application
[root@pbx ~]# screen

59 of 89 5/22/2009 11:12 PM
You may or may not get a text message about screen. If you do not, then you probably think nothing has happened, but it has. You are now inside of a window within screen.
This functions just like a normal shell except for a few special characters. Screen uses the command "Ctrl-A" as a signal to send commands to screen instead of the shell. To
get help, just use "Ctrl-A" then "?". You should now have the screen help page.
Screen key bindings, page 1 of 2.

Command key: ^A Literal ^A: a

break ^B b info i other ^A suspend ^Z z


clear C kill K pow_break B time ^T t
colon : lastmsg ^M m pow_detach D title A
copy ^[ [ license , prev ^P p ^? vbell ^G
detach ^D d lockscreen X readbuf < version v
digraph ^V log H redisplay ^L l width W
displays * login L removebuf = windows ^W w
fit F meta a reset Z wrap ^R r
flow ^F f monitor M screen ^C c writebuf >
focus ^I next ^@ ^N sp n select ' xoff ^S s
help ? number N silence _ xon ^Q q
history { } only Q split S
[Press Space for next page; Return to end.]

Key bindings are the commands the screen accepts after you hit "Ctrl-A". You can reconfigure these keys to your liking using a .screenrc file, but I just use the defaults.

Multiple Windows
Screen, like many windows managers, can support multiple windows. This is very useful for doing many things at the same time without opening new sessions. As a RHCE, I
often have four or five SSH sessions going at the same time. In each of the shell, I may be running two or three applications. Without screen, that would require 15 SSH
sessions, logins, windows, etc. With screen, each system gets its own single session and I use screen to manage different tasks on that system.

To open a new window, you just use "Ctrl-A" "c". This will create a new window for you with your default prompt. For example, I can be running top and then open a new
window to do other things. Top stays running! It is still there. To try this for yourself, start up screen and then run top.
start "top"
Now open a new window with "Ctrl-A" "c"
To get back to top, use "Ctrl-A "n"

You can create several windows and toggle through them with "Ctrl-A" "n" for the next window or "Ctrl-A" "p" for the previous window. Each process will keep running
while your work elsewhere.

Leaving Screen
There are two ways to get out of screen. The first is just like logging out of a shell. You kill the window with "Ctrl-A" "K" or "exit" will work on some systems. This will kill
the current windows. If you have other windows, you will drop into one of those. If this is the last window, then you will exit screen.

The second way to leave screen is to detach from a windows. This method leaves the process running and simple closes the window. If you have really long processes, you
need to close your SSH program, you can detach from the window using "Ctrl-A" "d". This will drop you into your shell. All screen windows are still there and you can
re-attach to them later.

Re-attaching to existing sessions


This is the best part!!

So you are using screen now and compiling a program. It is taking forever and suddenly your connection drops. Don't worry screen will keep the compilation going. Login to
your system and use the screen listing tool to see what sessions are running:
[root@pbx ~]# screen -ls
There are screens on:
31620.pts-0.pbx (Detached)
31625.pts-0.pbx (Detached)
2 Sockets in /var/run/screen/S-root.

Here you see I have two different screen sessions. To re-attach to a session, use the re-attach command:
[root@pbx ~]#screen -r 31620.pts-0.pbx
Just use screen with the -r flag and the session name. You are now re-attached to the screen. A nice thing about this, is you can re-attach from anywhere. If you are at work
or a clients office, you can use screen to start a job and then logout. When you get back to your office or home, you can login and get back to work. If you only have one
screen running, screen -r will automatically connect to that session.

Screen Logging
I find it important to keep track of what I do to someone else's server. Fortunately, screen makes this easy. Using "Ctrl-A" "H", creates a running log of the session. Screen
will keep appending data to the file through multiple sessions. Using the log function is very useful for capturing what you have done, especially if you are making a lot of
changes. If something goes awry, you can look back through your logs.

Sharing a Screen Session


If you have two users connected to the same server (say as root) and one user types screen another user can type screen -x and now BOTH of you are able to type and
view in the same window!!! GREAT FOR REMOTE TRAINING OR GETTING ASSISTANCE FROM SOMEONE ELSE, especially if you want to know how they fixed
your server!!

Screen Tips
I also wanted to mention to other beneficial tricks you can do with screen. Screen can monitor a window for activity or lack thereof. This is great if you are downloading large
files, compiling, or watching for output. If you are downloading something or compiling, you can watch for silence. To start the monitor, go to the screen you want to monitor
and use "Ctrl-A" "M" to look for activity or "Ctrl-A" "_" to monitor for silence. Then open or switch to a new window. When the monitor detects activity or silence, you will
get an alert at the bottom with the window number. To quickly go to that window, use "Ctrl-A" " (thats a quote mark, ctrl-a then a "). After you do this, just type in the
number of the window and enter. To stop monitoring, go to that window and undo the monitor with the same command. For example, to stop monitoring for activity you
would use "Ctrl-A" "M" again.

Hopefully this will help.. well lets face it, ALL OF US... in working with remote servers and help to ensure we don't brick the server while we work remotely!

Richard Teachout
RHCE, MCSA, MCTS:Hosting

60 of 89 5/22/2009 11:12 PM
HOWTO: MythTV CallerID OSD
MythTV CallerID OSD

The basic idea is to have callerID information pop up on the TV


when someone calls. It's suitable for a home setup where you have a
mythtv-based media center and are using asterisk for your phones.

This was tested on FreePBX 2.1 and Mythtv 0.19.

You need the mythtvosd executable on your system. In 0.19, this has some templates built-in, and that's what we'll be using.

If your asterisk and mythtv systems are different, you'll probably


also need to use mythudprelay. See the README included with
mythudprelay for more information (in the mythplugins
contrib/mythnotify/ directory).

You'll need to use a ring group to dial this. You can probably also do it with follow-me, but I didn't test that.

First, create a context in extensions_custom.conf:

[from-internal-custom]

exten => 99999,1,System(/usr/local/bin/mythtvosd --template=cid


--caller_name="${CALLERID(name)}" --caller_number="${CALLERID(number)}"
--caller_date="${DATETIE:0:2}/${DATETIME:2:2}/${DATETIME:4:4}"
--caller_time="${DATETIME:9}" )

(that should be two lines)

Note you can use anything you want for the "99999" part, just be sure it doesn't conflict with anything.

Now, in the ring group that you want to have display callerid, add:

99999#

That's it.

This works by adding the 99999 to the from-internal context (where


all internal calls are originated from). The # instructs the
dialparties script to dial the call externally, so it actually calls
"Local/99999@from-internal" (like it would if it was calling an
external number) to let the asterisk dialplan logic take care of
matching it (normally performing outbound routing).

Note: it's actually possible to use a word (like "ciddisplay")


in place of the 99999, EXCEPT that the freepbx web interface won't
allow that in the ring group extension list.

q. Why not?

HOWTO: New FreePBX users guide to diagnosing problems


New FreePBX users guide to diagnosing problems

[editor's note: reading documentation (yay for you!) and forums is recommended first before hitting the IRC. The only time you should need IRC is if you are trying to make
FreePBX do something not-yet-supported.- jms]

I'm creating this document in order to bring new users up to speed


on some basics of troubleshooting. Read this BEFORE you go onto the
#freepbx IRC channel or post in the FreePBX forum. Some of this should probably be in a FAQ document of some kind but as far as I know, we don't have one of those yet.

Before we begin, please understand that there is a distinction between Asterisk, FreePBX, and Trixbox. Briefly,

Trixbox is a complete distribution that includes the


CentOS operating system (a Linux distro), the Asterisk PBX software,
FreePBX, and a few other programs and scripts. At the moment, it's the
easiest way for new and inexperienced users to get Asterisk and FreePBX
up and running, though that may change in the near future.

Asterisk is the underlying PBX software. It is normally configured using text-based configuration files.

FreePBX is a web-based GUI interface and configuration


file generator for Asterisk. Basically it allows to users to set up
their configuration using point-and-click, and filling in some
information in text boxes (usually with "flyover" help boxes that
assist the user). FreePBX makes it far easier to make Asterisk work the
way you want it to, and gives you access to features not available in
Asterisk (unless you were to write the configuration scripts yourself).

61 of 89 5/22/2009 11:12 PM
A primary source of help for new users is this wiki
and the #freepbx channel on IRC (use the server irc.freenode.net). But
the thing to remember is that the #freepbx channel is primarily for
help with problems related to FreePBX. If it's a problem that ONLY
affects Trixbox users, or it affects ALL Asterisk users (including
those not running FreePBX), there's less of a chance you'll be able to
get help there, though you are welcome to try.

If you're not familiar with IRC (Internet Relay Chat), not to


worry, there in an IRC client preconfigured and built into FreePBX. Go
to the Tools menu, then Online Support - read the text on that page,
and then (if you agree to the terms of use on that page) click "Start
IRC" and you should be taken into the #freepbx channel automatically.
If you don't agree with the terms of use on that page, you can use a
different IRC client (Wikipedia has a List of IRC clients).

We'll talk more about IRC usage a bit further down the page.

As a new user, you need to know is how to access your FreePBX


system from another box on your network. Ideally you should be able to
run your FreePBX system without even having a keyboard or monitor
connected (that's the ideal, but the fact remains that if
everything comes crashing down you will need to directly access the
system. But 99% of the time you should be able to work from another
box).

I'm going to skew these instructions just a bit toward people who
have more experience with Windows than Linux, simply because that's the
situation I'm in, and because I think the Linux folks will have no
problem picking up on the differences.

The first thing that a Windows user should do is install PuTTY on


their desktop system (NOT on the Asterisk box). PuTTY is a free
implementation of Telnet and SSH for Win32 and Unix platforms, along
with an xterm terminal emulator. It is useful for securely accessing
the Asterisk CLI and the Linux command line. Use these links for more information and to download the program.

Use PuTTY (or ssh if you're a Linux user) to access your Asterisk
box. After logging in, you will initially be at the Linux command
prompt. As this point you need to note the difference between the Linux
command prompt and the Asterisk Command Line Interface (CLI). These are
NOT interchangeable; if someone tells you to type something at the CLI
and you do it at the Linux command prompt it won't work!

You enter the Asterisk CLI by typing:

asterisk -vvvvvvvvvvr

Followed by the ENTER key. The number of v's control the


"verbosity" of output and more is generally better when you're trying
to fix a problem. Should you need to return to the Linux command
prompt, just type exit then ENTER.

Now, let's say that you're having a problem receiving incoming


calls. While you are sitting at the CLI prompt (NOT the Linux prompt),
place a call to your system. You should see a bunch of output scroll
by. If you are lucky, you may see a line that indicates an obvious
problem. If you don't, copy and paste the entire output into a
pastebin, remove any identifying information you don't want to reveal
(such as personal phone numbers - replace with a dummy number such as
all zeros or xxxxx or something). Normally the CLI won't print any
passwords, but for future reference, never put a password in a
pastebin!

What's a pastebin, you ask? It's a place on the web to paste your
issues. You paste in your CLI output or configuration files or
whatever, and it will return a page with a URL. You can then point
people in the #freepbx IRC channel to that URL if you need help in
resolving your problem. They can see what you've seen and comment on
it. The best pastebin site to use (because it is faster and more
responsive than some others) is http://pastebin.ca

I will say again, don't put any information you don't want others to see in a pastebin!!! That particularly includes passwords and perhaps phone numbers,
if you wish to keep them private. Some people may also wish to remove
information such as Internet addresses - that is up to you.

Now, let's say you have a really thorny problem that's not revealed
in the CLI output. Someone may ask you to look at the Asterisk log.
Generally, that means you'll want to view this file:

/var/log/asterisk/full

This can be a VERY large file on some systems. So before you begin

62 of 89 5/22/2009 11:12 PM
your diagnostics, FIRST go to the Asterisk CLI and enter the command:

logger rotate

Followed by the ENTER key. (By the way, did I mention you can get a
list of all valid commands at the Asterisk CLI prompt by typing help and ENTER?)

Now you want to get some debugging information into the log. So,
assuming that you are dealing with a problem that affects a sip trunk
or sip device, enter these two lines at the CLI:

debug level 4

sip debug

Now when you try to place a test call, you should see much
additional output, both on your screen and in the log. By the way, if
the issue is with an IAX channel instead of a SIP channel, use iax2 debug instead of sip debug. And when you are ready to turn off debugging, put the word no in front of
debug, e.g. sip no debug.

When you place your test call, note the exact time (including
seconds) that it should be going through - this will help you find it
in the log.

To view the log file, you can use any file viewer. Some people may wish to use nano from the Linux Command Prompt:

nano /var/log/asterisk/full

Others may wish to use the Linux "tail" command, or the file viewer
in Midnight Commander. You can bring up Midnight Commander from the Linux Command Prompt:

mc -a

Then navigate to the log file and press F3 to view it.

Often, what you will be looking for is the sip invite packet and
Asterisk's response. You may see a line that tells you exactly what the
problem is. But if you do not, again you can paste this into a
pastebin, observing the earlier caveats about not revealing passwords
or personal information. Someone more experienced may be able to show
you what the problem is.

If you learn the above basics, others will be much more willing and
able to help you. People on the #freepbx channel get a little tired of
explaining these same basics over and over, and sometimes new users are
ignored for that reason. It's not that we don't want to help you, it's
just that after you've had to walk someone through the above procedures
for the 999th time, you really don't want to do it again.

A few other tips:

When using the #freepbx IRC channel:

Don't post messages saying "Hello?" or "Can anyone help


me?" and then wait for a response. Just post your problem and what
steps you've taken to diagnose it in your first messages. As the saying
goes, "Don't ask to ask, just ask. Those who ask to ask risk being
axed!"

If no one responds immediately, don't keep reposting the same message every couple of minutes. It just annoys people.

Remember that most of us can only help one person at a


time, or maybe two at most. If traffic is really heavy, go ahead and
ask your question, but realize that no one may be able to get to you
for a few minutes.

If you post and no one responds, it most likely means that


no one is on the channel AT THAT MOMENT that can help you. A BIG
mistake that newbies make is to come on the channel, ask a question,
wait a couple of minutes, and then make some snide remark and leave.
Not only does that make people NOT want to help you, but had that
person stuck around for a bit their question might have been answered.
I have seen people leave the channel as I was in the process of typing
an answer to their question! There are times of day when a lot of
"experts" are online, and other times when there will be no one on the
channel but newbies like yourself. Also, keep in mind that even when
someone is online they may get interrupted by a phone call, or employer
or family demands, or whatever. Patience is a virtue (and will often be
rewarded eventually) on IRC.

Try to use complete English sentences, and think about


whether your question actually makes sense before you press the ENTER
key. #freepbx users are more likely to ignore questions they can't
understand. We realize that English is a second language for some, and

63 of 89 5/22/2009 11:12 PM
we'll try to work with you up to a point, but if we can't understand
you at all, then you probably won't get helped.

When someone who is trying to help you asks you a question, answer that question!
Nothing is more infuriating to the experienced folks than to ask a
question in an attempt to try and diagnose a problem, and then have the
person who is having the problem either not respond, or respond with
something totally unrelated to the question. Usually when an
experienced person asks you a question they're trying to determine
which of several possible issues you may have, or eliminate possible
problems from consideration. Remember they cannot read your mind, nor
see what is on your screen, so answer the question and you are far more likely to get to the bottom of your problem.

Consider leaving the channel open for some time (several


hours at least) after you post, whether or not you get an answer. First
of all, people come onto the channel from all parts of the world and
it's not that uncommon to see a question get answered HOURS after the
person originally posted it. It's also not that uncommon to see someone
get questionable advice in the first few minutes (remember, there are
other newbies like yourself on the channel) and much better advice a
bit later on. So, don't be so quick to leave the channel. Besides,
maybe YOU can help someone else!

If you can't get an answer on IRC (or have a complicated question), consider using the FreePBX Forum.
This is a new one that should be easier for people to access and use,
since a lot of folks seemed to have a problem accessing the old one.

Don't ignore the FreePBX wiki pages, they are a wealth of information for new and existing users alike. For example, there is a page on Resolving Audio Problems that will
be very useful to those setting up FreePBX and Asterisk for the first time.

NEVER, EVER manually edit a configuration file that does not have
the word "custom" in the file name. There are a few minor exceptions -
you can modify sip.conf and iax.conf to allow additional codecs, you
can modify sip_nat.conf to resolve one-way audio problems,
etc. but the thing to keep in mind is that any file with the word
"additional" in it will be rewritten by the system every time you click
the red bar in FreePBX, and most other configuration files (except for
the ones with "custom" in their name) will be overwritten every time
FreePBX itself is upgraded. Many VoIP providers will tell you to
directly modify extensions.conf - DON'T DO IT,
because any changes you make there will not be preserved! You should
create a new trunk and put the settings they give you into the trunk
settings. Remember, you are using FreePBX so that you don't have to
deal with Asterisk configuration files directly. If you want
to write your own Asterisk configuration files, then you shouldn't be
using FreePBX. You can't have it both ways, you either use FreePBX or
you don't. But for those really special circumstances where you
absolutely need to do it manually, you can modify the "custom" files
and FreePBX will not change them.

HOWTO: Patching Asterisk for incoming fax functionality


This page assumes that you've already downloaded and compiled Asterisk
and Zaptel. If you've been linked to this page from a walkthrough
installation page, you already have! Here we're downloading and
installing the spandsp rxfax and txfax applications, along with the Newman Telecom's 'nvfaxdetect' applcation.

Download the required files:


Note: Due to long URL's on this page, be careful when copying and pasting - everything in bold is one command.

root@dhcp1 ~# cd /usr/src

root@dhcp1 src# wget http://www.soft-switch.org/downloads/spandsp/old/spandsp-0.0.2pre26.tar.gz

root@dhcp1 src# tar zxf spandsp-0.0.2pre26.tar.gz

root@dhcp1 src# cd spandsp-0.0.2

root@dhcp1 spandsp-0.0.2# ./configure --prefix=/usr && make && make install

That installs 'spandsp', a very powerful DSP package that can, as


one of it's many things, emulate a Fax machine. If you're interested in
what else spandsp can you, you can read the technical documentation here.

Download and install the txfax and rxfax applications

root@dhcp1 src# cd /usr/src/asterisk/apps

root@dhcp1 apps# wget http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.2pre26/asterisk-1.2.x/app_rxfax.c

64 of 89 5/22/2009 11:12 PM
root@dhcp1 apps# wget http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.2pre26/asterisk-1.2.x/app_txfax.c

root@dhcp1 apps# wget http://www.newmantelecom.com/download/asterisk/faxdetect/1.0.6/app_nv_faxdetect.c

root@dhcp1 apps# wget http://aussievoip.com/makefile.patch

root@dhcp1 apps# patch < apps_makefile.patch

root@dhcp1 apps# cd ..

root@dhcp1 asterisk# make upgrade

That will build and install the three new modules, app_rxfax,
app_txfax and app_nv_faxdetect. You will need to restart asterisk to
load these modules:

root@dhcp1 apps# asterisk -rx 'restart when convenient'

HOWTO: Resolve FreePBX and Sipura/Linksys Feature Code Conflicts


Resolving FreePBX and Sipura/Linksys Supplementary Service and Feature
Code Conflicts
Note: There is a separate page on How to set up a Linksys PAP2 or Sipura SPA-2000 for use with FreePBX.

One problem faced by users of FreePBX that have Sipura or Linksys endpoints (VoIP adapters, etc.) is deciding how to set the Supplementary Services and Feature Codes on
the endpoint so that there is no conflict between FreePBX features and Sipura/Linksys features. The presumption here is that we want FreePBX to handle as much as
possible, and only allow the endpoints to perform functions that they must provide - for example, if the endpoint provides dial tone, then only the endpoint can provide stutter
dial tone as a message waiting indication. So we can't just disable all the endpoint features and feature codes and expect everything to work.

Some may feel that it would be more efficient to allow the endpoint to handle certain functions, and while that may be true in the short term, it has the potential to "break"
something when new features are added to FreePBX, or when there are unintended feature interactions that FreePBX could resolve if it had control of the feature. Also,
sometimes the default Sipura/Linksys feature codes do not have the same meaning as the equivalent FreePBX feature codes, and the presumption is that in order to keep
things uniform throughout the system, we want all extensions to use the same feature codes.

So, here are the suggested settings for the Sipura/Linksys endpoints (note that this document covers VoIP lines only, and has nothing to do with PSTN lines on the
Sipura/Linksys 3xxx series).

Supplementary Services
Each of these services can be set to "Yes" or "No". First the parameter name, then the description, then the suggested setting, and underneath any notes, conflicts, etc.

Call Waiting Serv - Enable Call Waiting Service - yes


If this isn't activated, the device won't be able to accept call waiting calls.
This normally uses *56 to Enable Call Waiting on all calls, and *57 to Disable Call Waiting on all calls.
It also uses *71 to Enable Call Waiting for the next call, and *70 to Disable Call Waiting for the next call.
These codes may need to be changed or deactivated to avoid a conflict with FreePBX feature codes.
The FreePBX standard is to use *70 for Call Waiting - Activate and *71 for Call Waiting - Deactivate.
However, the PSTN standard in much of North America is to use *70 to Disable Call Waiting for the next call.
At present FreePBX does not use the *56 or *57 codes for anything by default.

Block CID Serv - Enable Block Caller ID Service - no


In most cases, the FreePBX extension page, or the trunk definition specifies the outgoing CallerID, therefore this generally has no effect.
This normally uses *67 to Block CID on all outbound calls, and *68 to Unblock CID on all outbound calls.
It also uses *81 to Block CID on the next outbound call, and *82 to Unblock CID on the next outbound call.
FreePBX does not appear to provide this feature at the present time (although it is able to pass a "Block CID on the next outbound call" code through to an outbound
trunk, assuming that code is honored by a provider - see How to set up per-use Caller ID blocking (*67) for details).
The PSTN standard in much of North America is to use *67 to Block CID on the next outbound call.
At present FreePBX does not use the *67 code for anything by default.

Block ANC Serv - Enable Block Anonymous Calls Service - no


This normally uses *77 to Block all anonymous calls, and *87 to Unblock all anonymous calls.
FreePBX provides this function (although it cannot be enabled or disabled using a feature code), and can give the caller the option to enter their number.
FreePBX by default uses *77 to save a recording.

Dist Ring Serv - Enable Distinctive Ringing Service - yes


FreePBX can send distinctive ringing requests but the device will ignore them unless this is set to yes.
This normally uses *26 to Enable Distinctive Ringing, and *46 to Disable Distinctive Ringing (some Linksys docs say *61 and *81 respectively, but I believe those may
be wrong, judging from what I've seen on actual adapters).
These codes may need to be changed or deactivated to avoid a conflict with FreePBX feature codes.
At present FreePBX does not use the *26 or *46, or for that matter, *61 or *81 codes for anything by default. However, Trixbox uses *61 to provide a weather service.

Cfwd All Serv - Enable Call Forward All Service - no

65 of 89 5/22/2009 11:12 PM
This normally uses *72 to Forward all calls to the target specified after the activation code, and *73 to Cancel call forward all.
FreePBX provides the same functions using the same feature codes by default, and in addition uses *74 for Call Forward All Prompting Deactivate.

Cfwd Busy Serv - Enable Call Forward Busy Service - no


This normally uses *90 to Forward busy calls to the target specified after the activation code, and *91 to Cancel call forward busy.
FreePBX provides the same functions using the same feature codes by default, and in addition uses *92 for Call Forward Busy Prompting Deactivate.

Cfwd No Ans Serv - Enable Call Forward No Answer Service - no


This normally uses *92 to Forward no-answer calls to the target specified after the activation code, and *93 to Cancel call forward no-answer.
FreePBX provides the same functions using *52 for Call Forward No Answer/Unavailable Activate, and *53 for Call Forward No Answer/Unavailable Deactivate.
FreePBX by default uses *92 for Call Forward Busy Prompting Deactivate.

Cfwd Sel Serv - Enable Call Forward Selective Service - no


FreePBX doesn't provide this YET so you could enable it if you really need it, but most users don't.
Configured in the user tab of the device's web interface, does not use any feature codes.

Cfwd Last Serv - Enable Forward Last Call Service - no


This normally uses *63 to Forward the last inbound or outbound calls to the target specified after the activation code, and *83 to Cancel call forward last.
At present FreePBX does not use the *63 or *83 codes for anything by default.

Block Last Serv - Enable Block Last Call Service - no


This normally uses *60 to Block the last inbound call, and *80 to Cancel blocking of the last inbound call.
FreePBX has the ability to maintain a blacklist, though not yet on a per-extension basis.
FreePBX by default uses *60 for the Speaking Clock, and *80 as the Intercom prefix.

Accept Last Serv - Enable Accept Last Call Service - no


This normally uses *64 to Accept the last outbound call. Let it ring through when DND or Call Forward All is in effect. It also uses *84 Cancel Accept Last.
FreePBX does not appear to provide this feature at the preset time, although there is a code to remove a number from the blacklist.
At present FreePBX does not use the *64 or *84 codes for anything by default.

DND Serv - Enable Do Not Disturb Service - no


This normally uses *78 to Enable Do Not Disturb, and *79 to Disable Do Not Disturb.
FreePBX provides the same functions using the same feature codes by default.

CID Serv - Enable Caller ID Service - yes


If this isn't activated, the device won't send Caller ID information to the telephone.
This normally uses *65 to Enable Caller-ID Generation and *85 to Disable Call-ID Generation.
These codes may need to be changed or deactivated to avoid a conflict with FreePBX feature codes.
At present FreePBX uses *65 for Speak Your Exten Number. FreePBX does not use *85 at present.

CWCID Serv - Enable Call Waiting Caller ID Service - yes


If this isn't activated, the device won't send Caller ID on Call Waiting information to the telephone.
This normally uses *25 to Enable Call Waiting Caller-ID generation, and *45 to Disable Call Waiting Caller-ID generation.
These codes may need to be changed or deactivated to avoid a conflict with FreePBX feature codes.
At present FreePBX does not use the *25 or *45 codes for anything by default.

Call Return Serv - Enable Call Return Service - no


This normally uses *69 to Call the last caller.
FreePBX uses *69 for Call Trace, which provides the same feature but with additional functionality.

Call Back Serv - Enable Call Back Service - no


This normally uses *66 to Callback when the last outbound call is not busy, and *86 to Cancel callback.
FreePBX does not appear to provide this feature at the preset time.
At present FreePBX does not use the *66 or *86 codes for anything by default.

Three Way Call Serv - Enable Three Way Calling Service - yes
Three Way Calling is required for Three Way Conference and Attended Transfer

Three Way Conf Serv - Enable Three Way Conference Service - yes
Three Way Conference is required for Attended Transfer.

Attn Transfer Serv - Enable Attended Call Transfer Service - yes


This is when you flash, call a third party, speak to them privately, then hang up and the original call transfers.
Does not use any feature codes.

Unattn Transfer Serv - Enable Unattended (Blind) Call Transfer Service - yes
This normally uses *98 to Blind transfer current call to the target.
FreePBX uses *98 for Voicemail access by default, however there is usually no conflict because the code is used in different contexts.
Blind transfer only works if the caller is engaged in a call, flashes to a second dial tone, dials *98, then waits for an additional dial tone and dials the number the call is

66 of 89 5/22/2009 11:12 PM
to be transferred to, therefore *98 works normally for retrieving voicemail if the user does not have an existing call on hold.
This feature can be disabled (or the feature code changed) if there is a desire to be able to flash away from a call and retrieve voicemail.

MWI Serv - Enable MWI Service - yes


MWI is available only if a Voice Mail Service is set-up in the deployment

VMWI Serv - Enable VMWI Service (FSK) - yes


This is the service that activates the message waiting light on most phones

Speed Dial Serv - Enable Speed Dial Service - no


This normally uses *74 to Assign a speed dial number.
FreePBX uses *74 for Call Forward All Prompting Deactivate.
FreePBX provides user speed dial functions (using the *75 code by default).

Secure Call Serv - Enable Secure Call Service - no


As far as I know, Asterisk doesn't yet support this.
This normally uses *16 to make all outbound calls secure and *17 to make all outbound calls not secure.
It also uses *18 make the next outbound call secure, and *19 to make the next outbound call not secure.
At present FreePBX does not use the *16, *17, *18, or *19 codes for anything by default.

Referral Serv - Enable Referral Service - yes


This has no effect unless you add some referral service codes, in which case you probably know what you're doing.

Feature Dial Serv - Enable Feature Dial Service - yes


This has no effect unless you add some feature dial service codes, in which case you probably know what you're doing.

Service Announcement Serv - Undocumented (does anyone know what this is?) - no

When you are all finished your Supplementary Service Subscription settings should look something like this (note that this may be slightly different from your unit, depending
on the actual model you have):

(If the above graphic doesn't show, try clicking here)

If your device is a multi-line unit, don't forget to make these changes in the Line tab associated with each line of the device that is used with FreePBX!

Vertical Service Activation Codes (Feature Codes)


If you have used the suggested settings EXACTLY as shown above, then you don't have to change or blank out many of the Vertical Service Activation Codes (found under
Admin login, select Advanced view, Regional tab). The following are the changes that I do suggest. The yellow highlighted text shows the existing code assignments in a
PAP2 - where followed by NA that means the feature is deactivated (again, only IF you followed the suggested settings above EXACTLY) so you don't have to worry about
that code. Where a feature needs to stay activated but there's a potential code conflict, I suggest how to deal with it. In this, I make certain assumptions - for example, that
you don't want to be able to accidentally deactivate a feature such as call waiting, caller ID, or distinctive ringing.

Note that after you make these changes you MUST go to the device's User tab(s) and set the dropdowns in the Supplementary Service Settings section to known values,
otherwise the device may not work as expected. More on that in a moment.

This list is obviously subject to change if FreePBX adds or changes feature codes! It is current as of December 20, 2006:

First column (PAP2):

Call Return Code: *69 NA

Call Back Act Code: *66 NA

67 of 89 5/22/2009 11:12 PM
Cfwd All Act Code: *72 NA

Cfwd Busy Act Code: *90 NA

Cfwd No Ans Act Code: *92 NA

Cfwd Last Act Code: *63 NA

Block Last Act Code: *60 NA

Accept Last Act Code: *64 NA

CW Act Code: *56 (Delete this entry)

CW Per Call Act Code: *71 (Delete this entry)

Block CID Act Code: *67 (Delete this entry)

Block CID Per Call Act Code: *81 NA

Block ANC Act Code: *77 NA

DND Act Code: *78 NA

CID Act Code: *65 (Delete this entry)

CWCID Act Code: *25 (Delete this entry)

Dist Ring Act Code: *26 (Delete this entry)

Speed Dial Act Code: *74 NA

Secure No Call Act Code: *17 NA

Secure One Call Deact Code: *19 NA

Attn-Xfer Act Code: (Blank by default)

Second column (PAP2):

Blind Transfer Code: *98 (Same as FreePBX voicemail but used in different contexts, suggest leaving as is but change if desired)

Call Back Deact Code: *86 NA

Cfwd All Deact Code: *73 NA

Cfwd Busy Deact Code: *91 NA

Cfwd No Ans Deact Code: *93 NA

Cfwd Last Deact Code: *83 NA

Block Last Deact Code: *80 NA

Accept Last Deact Code: *84 NA

CW Deact Code: *57 (Delete this entry)

CW Per Call Deact Code: *70 (Suggest leaving as is wherever *70 is PSTN standard for per call call waiting deactivation)

Block CID Deact Code: *68 NA

Block CID Per Call Deact Code: *82 NA

Block ANC Deact Code: *87 NA

DND Deact Code: *79 NA

CID Deact Code: *85 (Delete this entry)

CWCID Deact Code: *45 (Delete this entry)

Dist Ring Deact Code: *46 (Delete this entry)

Secure All Call Act Code: *16 NA

Secure One Call Act Code: *18 NA

Conference Act Code: (Blank by default)

Modem Line Toggle Code: *99 (Not in all adapters, conflicts with FreePBX "Check Recording", suggest you delete UNLESS you have a device that attempts to send data
through the adapter, in which case it might be better to change the "Check Recording" code in FreePBX to some unused code like *76)

68 of 89 5/22/2009 11:12 PM
AFTER you make the above changes and save them (by clicking on "Save Settings"), go to the device's User tab(s) (User 1 and User 2 in a PAP2, SPA-2000, etc.),
Supplementary Service Settings section, and make sure that the options there are set like this:

(If the above graphic doesn't show, try clicking here)

If you need to change any of these, be sure to once again click "Save Settings" at the bottom of the page, and don't forget to do this in each User tab if there is more than one.

List of default feature codes


Here is a list of default feature codes used by Linksys/Sipura, FreePBX, and Trixbox. Code conflicts are shown in red (for conflicts of dissimilar functions) or orange (for
conflicts of similar functions):

** FreePBX: Call Pickup (Can be used with GXP-2000)

*0 FreePBX: Speeddial prefix

*11 FreePBX: User Logon

*12 FreePBX: User Logoff

*16 Linksys/Sipura: Make all outbound calls secure

*17 Linksys/Sipura: Make all outbound calls not secure

*18 Linksys/Sipura: Make the next outbound call secure. This operation is redundant if all outbound calls are secure by default.

*19 Linksys/Sipura: Make the next


outbound call not secure. This operation is redundant if all outbound
calls are not secure by default.

*21 FreePBX: Findme Follow Toggle

*25 Linksys/Sipura: Enable Call Waiting Caller-ID generation

*26 Linksys/Sipura: Enable Distinctive Ringing

*30 FreePBX: Blacklist a number

*31 FreePBX: Remove a number from the blacklist

*32 FreePBX: Blacklist the last caller

*34 FreePBX: Perform dictation

69 of 89 5/22/2009 11:12 PM
*35 FreePBX: Email completed dictation

*43 FreePBX: Echo Test

*45 Linksys/Sipura: Disable Call Waiting Caller-ID generation

*46 Linksys/Sipura: Disable Distinctive Ringing

*52 FreePBX: Call Forward No Answer/Unavailable Activate

*53 FreePBX: Call Forward No Answer/Unavailable Deactivate

*54 FreePBX: User lntercom Allow

*55 FreePBX: User lntercom Disallow

*57 Linksys/Sipura: Disable Call Waiting on all calls

*60 FreePBX: Speaking Clock

*60 Linksys/Sipura: Block the last inbound call

*61 Trixbox: Weather

*62 Trixbox: Wakeup

*63 Linksys/Sipura: Forward the last inbound or outbound calls to the target specified after the activation code

*64 Linksys/Sipura: Accept the last outbound call. Let it ring through when DND or Call Forward All is in effect

*65 FreePBX: Speak Your Exten Number

*65 Linksys/Sipura: Enable Caller-ID Generation

*66 Linksys/Sipura: Callback when the last outbound call is not busy

*67 Linksys/Sipura: Block CID on all outbound calls

*68 Linksys/Sipura: Unblock CID on all outbound calls

*69 FreePBX: Call Trace

*69 Linksys/Sipura: Call the last caller.

70 of 89 5/22/2009 11:12 PM
*70 FreePBX: Call Waiting - Activate

*70 Linksys/Sipura: Disable Call Waiting for the next call

*71 FreePBX: Call Waiting - Deactivate

*71 Linksys/Sipura: Enable Call Waiting for the next call

*72 FreePBX: Call Forward All Activate

*72 Linksys/Sipura: Forward all calls to the target specified after the activation code

*73 FreePBX: Call Forward All Deactivate

*73 Linksys/Sipura: Cancel call forward all

*74 FreePBX: Call Forward All Prompting Deactivate

*74 Linksys/Sipura: Assign a speed dial number

*75 FreePBX: Set user speed dial

*76 FreePBX: DND Toggle

*77 FreePBX: Save Recording

*77 Linksys/Sipura: Block all anonymous calls

*78 FreePBX: DND Activate

*78 Linksys/Sipura: Enable Do Not Disturb

*79 FreePBX: DND Deactivate

*79 Linksys/Sipura: Disable Do Not Disturb

*80 FreePBX: Intercom prefix

*80 Linksys/Sipura: Cancel blocking of the last inbound call

*81 Linksys/Sipura: Block CID on the next outbound call

*82 Linksys/Sipura: Unblock CID on the next inbound call

*83 Linksys/Sipura: Cancel call forward last

*84 Linksys/Sipura: Cancel Accept Last

*85 Linksys/Sipura: Disable Call-ID Generation

71 of 89 5/22/2009 11:12 PM
*86 Linksys/Sipura: Cancel callback

*87 Linksys/Sipura: Unblock all anonymous calls

*90 FreePBX: Call Forward Busy Activate

*90 Linksys/Sipura: Forward busy calls to the target specified after the activation code

*91 FreePBX: Call Forward Busy Deactivate

*91 Linksys/Sipura: Cancel call forward busy

*92 FreePBX: Call Forward Busy Prompting Deactivate

*92 Linksys/Sipura: Forward no-answer calls to the target specified after the activation code

*93 Linksys/Sipura: Cancel call forward no-answer

*97 FreePBX: My Voicemail

*98 FreePBX: Dial Voicemail

*98 Linksys/Sipura: Blind transfer current call to the target specified after the activation code

*99 FreePBX: Check Recording

*99 Linksys/Sipura: Modem Line Toggle Code

HOWTO: Resolving Audio Problems


Resolving Audio Problems
One of the most common issues to plague new users is the lack of audio. Calls appear to complete, and show up in the call detail, etc. but nothing is heard by one or both of
the parties on the conversation. This section of the wiki will be devoted to such problems and their solutions, and I encourage others to add to it as you encounter problems
and then discover the solution, particularly if it's not posted here already.

NAT issues
Perhaps the most common problem encountered is one-way audio and 99% of the time this is caused by a NAT firewall. So here are the steps you must take to configure
FreePBX to work behind a NAT firewall.

Make sure you have a resolvable address on the Internet.

If you don't want to pay a few bucks to get a static IP address, and are served by an ISP that periodically changes your IP address, then get a free account with DynDNS or
some similar service. Your router may already have built-in support for one or more of these services, if so, use one that your router supports and then configure your router
to automatically update your dynamic address when your ISP changes your IP address. Failing that, you can set up an updater program such as inadyn, there are instructions
for doing that at this blog page.

Make use that your system knows its own name.

Once you get a DynDNS or other address that identifies your system on the Internet, put it in your etc/hosts file. For example, if you are assigned foo.dyndns.net, then open
etc/hosts in your favorite text editor (nano, or Midnight Commander's editor will do - use mc -a from the command prompt to access Midnight Commander) and look for this
line:
127.0.0.1 localhost

DO NOT REMOVE OR CHANGE THAT LINE. On a NEW line directly underneath it, place this line:
127.0.0.1 foo.dyndns.net

But substitute YOUR address, of course.

72 of 89 5/22/2009 11:12 PM
Add some information to your /etc/asterisk/sip_nat.conf file

If this file doesn't exist you'll have to create it, but make sure that the ownership and permissions match those of sip.conf and other files in that directory. You can use the
command

touch /etc/asterisk/sip_nat.conf

To create the file. I personally use Midnight Commander's "Advanced CHOWN" feature to check and change permissions; if you are a true Linux geek you probably already
have a preferred method.

Now edit the file and insert AT LEAST these two lines:
externip=your.external.dotted.IPaddess

localnet=192.168.0.0/255.255.255.0

The above localnet line assumes that your local network uses 192.168.0.x addresses, but if it uses something else, make the appropriate substitution.

Personally I use four lines, as follows:


nat=yes

externip=your.external.dotted.IPaddess

fromdomain=foo.dyndns.com

localnet=192.168.0.0/255.255.255.0

The "fromdomain" line would contain your public address, while "externip" contains the numeric IP address your ISP has assigned you (which hopefully doesn't change
often).

If your ISP does change IP addresses on you frequently, and for some reason you can't/won't change ISP's or get a static IP address, and you are running at least Asterisk
1.2.x then there is an alternative way to specify your address to the system (however, note that some users find that this simply does not work as expected):
externhost=foo.dyndns.net

externrefresh=10

These are used IN PLACE OF the "externip" (and "fromdomain", if you have included that) lines. DO NOT use both "externhost" and "externip." Supposedly, "externhost"
will cause Asterisk to perform DNS queries periodically, but they say it is "Not recommended for production environments!" and suggest using "externip" instead.
"externrefresh" tells the system how often to refresh "externhost". If this method does not work for you, see the Addendum at the bottom of this document for another
approach.

Reload SIP

After you have added whichever lines you need in sip_nat.conf, go to the Command Line Interface and type
sip reload

And hit enter. Alternately you could restart Asterisk, but that will interrupt any calls that are in progress.

Open the SIP and RTP ports to your Asterisk server

You must make sure that you open the correct UDP ports in your router's firewall and pointed at your Asterisk server. For SIP protocol, open UDP (NOT TCP) port 5060
(SIP) AND ports 10001-20000 (RTP, which must also be defined in /etc/asterisk/rtp.conf, see below). All these ports are UDP, opening the TCP ports will NOT help
anything and may expose your system needlessly. While you are in your firewall configuration, you may as well also open UDP port 4569 (IAX), since sooner or later you'll
probably want to accept IAX connections.

Check your /etc/asterisk/rtp.conf file

It should contain these two lines:


rtpstart=10001

rtpend=20000

If the port values are any different, change them. N.B. These MUST match what you opened in your firewall, and DO NOT start with port 10000, because it conflicts with
usage in Webmin (and despite what anyone may tell you, Webmin does use UDP port 10000 in addition to TCP port 10000 - it uses the UDP port in an attempt to discover
and communicate with other Webmin servers running on your network. So don't believe anyone who tells you that Webmin only uses TCP port 10000 and therefore there is
no conflict).

Some people feel the need to open fewer than 10,000 ports. I don't recommend this because six months from now when you start having audio problems you may not
remember that you opened fewer than the recommended number of ports, and may spend hours troubleshooting the issue. But if you are simply obsessive about open ports,
remember that each open SIP connection may require as many as FOUR concurrent ports, so don't cut it down to some ridiculously small number. For the non-paranoid, I
suggest sticking with the recommendations above (and remember, if a hacker is looking at ports on your system, he's going to scan ALL of them, so having fewer UDP ports
open really doesn't make you any more secure).

CODEC issues
Whenever a call is placed, both ends of the call must agree on the codecs they want to use. If one end speaks only ulaw and the other end refuses to communicate using
anything other than gsm, no communication is going to take place. This is why I would recommend that beginners always allow ulaw (also known as g.711u) and alaw (also
known as g.711a) unless specifically instructed not to but whomever you are connecting to. There are actually five different places that codecs can be specified:

At an endpoint/device (phone or ATA), typically in the device's configuration.

73 of 89 5/22/2009 11:12 PM
In a FreePBX EXTENSION configuration, however it's best to leave those settings blank in most cases.

In a FreePBX TRUNK configuration, using allow= statements coupled with disallow=all. If these are omitted, then the defaults in sip.conf and iax.conf are used.

In sip.conf, using allow= statements coupled with disallow=all. These are the system defaults for SIP calls but can be overridden by trunk or extension settings.

In iax.conf, using allow= statements coupled with disallow=all. These are the system defaults for IAX calls but can be overridden by trunk or extension settings.

Note that as of Asterisk 1.4, the order of allow and disallow statements is important. If you use a disallow=all statement, it must be placed before any allow statements,
because if it is placed after any allow statements it will negate them. This was not the case in Asterisk 1.2 and earlier versions.

Asterisk will attempt to translate formats if the codecs are available on the system and allowed for that leg of the call. So if you have a trunk that only allows gsm but your
extensions will only communicate in ulaw, that's not a problem as long as you have allowed gsm in the trunk configuration. To see the available codecs and translations, type
core show translation (or just show translation in Asterisk 1.2 and earlier) from the Command Line Interface - if there is a number showing between two codecs in the grid
then translations are possible, if a single line (and it's not to the same codec) then translations are not possible, usually because one of the codecs isn't installed on the system.

Missing files/incorrect paths


If calling into an IVR or voicemail box, and the expected recording isn't played, it's possible that it's missing or not in the expected location. Did you use the System
Recordings module to import the recording? If not, are you sure it's in the correct location?

Permissions/ownership issues
This most commonly occurs when people copy audio files directly onto the system and forget that it's a Linux box and that Linux is finicky about file permissions and
ownership. If permissions or ownership aren't correct, Asterisk will be unable to access the file, and therefore can't play it. One thing you can try to resolve this is to run the
following from the Linux command prompt:
amportal chown

This is supposed to set appropriate permissions on files used by Asterisk

Incorrect audio format


Sometimes people create system audio files using an external sound file editor, such as Audacity, in order to get better sound quality. What they don't realize is that Asterisk
is very picky about the format of audio files it will play back. For example, if the file is .wav file format, Asterisk wants a file recorded at 8000 Hz, 16 bit, monaural (a.k.a.
single channel) format and if you directly upload a file in any other format, the CLI may show that the file is being played, but callers hear nothing. If normal system files
play correctly but the files you've created do not, check the format, especially if you've directly copied it to a particular location on the system instead of importing it with the
System Recordings module.

Hardware issues
Yes, even a hardware problem can cause audio failures. In one case, a T1 card had been installed in the system but not configured, and that stopped all recorded audio from
being played. So if all else fails, look for any unconfigured or misconfigured hardware device, particularly if it's a zaptel card (it appears that having ANY non-configured
zaptel card in a system may cause problems with audio output).

Addendum: A Perl script to rewrite sip_nat.conf when your IP address changes


The following is a Perl script that checks your IP address using whatismyip.com, and rewrites /etc/asterisk/sip_nat.conf if the external IP address has changed. Note that you
may have to install additional Perl modules, and you WILL need to modify one line in the script:
#!/usr/bin/perl

#
# This program gets the current IP address (as assigned by the ISP) from
# whatismyip.org and modifies /etc/asterisk/sip_nat.conf if the external IP
# address has changed. You can Use Webmin to install any missing Perl
# modules, and to invoke the script as cron job that runs every 5 minutes
#
use strict;
use warnings;
use WWW::Mechanize;
use Tie::IxHash;
use Data::Validate::IP qw(is_public_ipv4);
my $s_filepath = "/etc/asterisk/sip_nat.conf";
my $mech = WWW::Mechanize->new( autocheck => 1 );
$mech->get('http://whatismyip.com/automation/n09230945.asp');
$mech->success or die 'Cannot connect to http://whatismyip.com/automation/n09230945.asp';
my ($ip) = ($mech->content() =~ /(\d+\.\d+\.\d+\.\d+)/);
if (is_public_ipv4($ip)) {
tie my %configvars, 'Tie::IxHash';
# The 'fromdomain' (& possibly 'localnet') values in the next line MUST be changed
%configvars = ('nat' => 'yes', 'externip' => '0.0.0.0','fromdomain' => 'foo.dyndns.com','localnet' => '192.168.0.0/255.255.255.0') ;
open IN,"<$s_filepath";
while (my $i = <IN>) {
chop $i;
if ($i =~ /=/) {
$i =~ s/\s//g;
my ($key,$value) = split /=/,$i;
$configvars{$key} = $value;
}
}
close IN;
if ($configvars{'externip'} ne $ip) {
$configvars{'externip'} = $ip;
open OUT,">$s_filepath";
while (my ($key, $value) = each %configvars) {
select OUT;

74 of 89 5/22/2009 11:12 PM
print "$key=$value\n";
};
select STDOUT;
close OUT;
`/usr/sbin/asterisk -rx reload`;
};
};

Please be sure to change foo.dyndns.com to YOUR dynamic IP address, and 192.168.0.0/255.255.255.0 to a value consistent with your local network address range (if you
are not using addresses in the 192.168.0.x range).

It is suggested that you place the above script in your /var/lib/asterisk/agi-bin/ directory, make sure the permissions and ownership are set correctly (make the script
executable!), backup your existing /etc/asterisk/sip_nat.conf file, and then as a test invoke the script from a command prompt, e.g. (assuming you name the script checkip.pl):

cd /var/lib/asterisk/agi-bin
perl checkip.pl

If the script exits without printing any error messages, check /etc/asterisk/sip_nat.conf to make sure that the all of the lines in it contain correct values. If all looks as it
should, you can can then set up a cron job to run the script every five minutes. I did this using Webmin's System|Scheduled Cron Jobs page, but you may prefer to do it
from the command line. If you get any errors about missing Perl modules when you run the script, these will have to be installed (there are Webmin modules that can do this
also - look for one called "Perl Modules" or "CPAN").

One other note - if this script is running and sip_nat.conf gets deleted for any reason, the script will probably recreate it but with the wrong ownership and permissions - so if
you ever accidentally delete that file, and after that Asterisk acts like it isn't there, check the permissions and ownership to make sure it is the same as for the other sip_*.conf
files in /etc/asterisk.

HOWTO: Route Dial Patterns and Trunk Dial Rules


Hints on Route Dial Patterns and Trunk Dial Rules
New users of FreePBX are often confused by the fact that there is a place to enter "Dial Rules" when creating a new Trunk, and "Dial Patterns" when creating a new
Outbound Route. Since the construction of these seems similar, users try to do something in the wrong place and it doesn't work. This is a brief attempt to explain the
difference.

Trunk Dial Rules


First let's deal with trunks, because they are perhaps the easiest to understand. The thing to remember about Trunk Dial Rules is that they are ONLY used for adding numbers
to, or subtracting numbers from the number being sent to the trunk. Trunk Dial Rules are NEVER used to allow or restrict numbers that may be dialed. Therefore, it follows
that (with one exception noted below) any entry not containing a | character (to strip off number at the start of the entry) or a + character (to add numbers at the start of an
entry) is totally useless - it will simply waste processor time while the system looks at those entries.

To give an example, here's a common newbie mistake. Let's say that you have a couple different trunks that allow outgoing toll-free numbers in the USA, and one of them is
Free World Dialup, which requires a star (*) key in front of the actual number. For the moment, let's assume that you want to restrict these trunks to toll-free numbers only.
So in the first trunk, you might be tempted to put some lines like this:
1800NXXXXXX
1822NXXXXXX
1833NXXXXXX
1844NXXXXXX
1855NXXXXXX
1866NXXXXXX
1877NXXXXXX
1888NXXXXXX

And then in the Free World Dialup trunk, you congratulate yourself as you cleverly add the * to each toll-free definition:
*+1800NXXXXXX
*+1822NXXXXXX
*+1833NXXXXXX
*+1844NXXXXXX
*+1855NXXXXXX
*+1866NXXXXXX
*+1877NXXXXXX
*+1888NXXXXXX

Congratulations, you've managed to waste a bunch of processor time! In the first example, NONE of the entires are accomplishing a thing because none of them contain a | or
+ character. You could (and should) remove every one of them. Call filtering by number dialed is done by ROUTES, not by TRUNKS.

Note: There is, however, one exception to the general "definitions without a | or + are useless in a trunk" rule. A definition without a + or |, if matched, will stop the
processing of definitions beyond that point. Consider the following example:
555XXXX
1321+NXXXXXX

This will add 1321 to any 7 digit number, EXCEPT those starting with 555. So, a definition can also be used as a "stopper" to prevent that pattern from being matched by
another definition that is lower in the list (thanks to groogs in the #freepbx IRC channel for this clarification).

And in the second example (the Free World Dialup trunk), you could accomplish the same thing by ONE line, like this:
*+18XXNXXXXXX

or
*+1NXXNXXXXXX

75 of 89 5/22/2009 11:12 PM
or, because you know that "real" Free World Dialup numbers are five or six digits long, you could even use
*XXXXXX.

(Note the period as the last character) - Which would prepend the * to any number 7 digits long or longer (although you may not want to do this if you use Free World Dialup
as a route to other networks, but that's a more advanced discussion).

Again, this bears emphasizing: You CANNOT use Trunk Dial Rules to allow or restrict certain numbers from going out on a trunk. You can only add or strip digits.

Route Dial Patterns


Route Dial Patterns are used to specify what numbers are allowed to go out via that route. When a call is placed, the actual number dialed by the user is compared with the
Dial Patterns in each route (from highest to lowest priority) until a match is found. If no match is found in any route, the call fails (there is "no route" for that call).

If the number dialed matches a pattern in more than one route, only the rules in the route with the highest priority are used. In other words, if a call tries to use that route and
fails, it does not keep trying additional routes to see if it matches another. This is actually desirable behavior because it allows you to force certain calls to go out via lower
cost routes.

Route Dial Patterns cannot be used to add digits to the number dialed by the user. However, you can strip off leading digits before passing them to a trunk. This is most useful
if you use a specific dialing code to access a particular route (for example, "9" to access an outside line).

Note that each route can be set to access one or more trunks. Each trunk may require different translations (changing what was actually dialed to something else before
sending it on is called a translation in telephone-speak) so you don't want to strip digits at the route level if only some of your trunks will require it and some don't.

Route Dial Patterns only allow calls, they cannot block calls. The only way to block certain patterns is to make sure they are not included in any route. Or, you can include
the blocked pattern in a higher priority route, then make sure that route doesn't send calls to any trunks that cost money. The easiest way to do this is to create an ENUM
trunk.

For example, let's say you want to allow all calls within Country Code 1 EXCEPT calls to 1-900 numbers and to local 976 numbers (in a real situation you'd probably have
additional restrictions, but this is just to illustrate the technique). In a lower-numbered route (which has a higher priority) you could include these lines in the Route Dial
Pattern:
1900XXXXXXX
1NXX976XXXX

Then make sure that the only trunk that route accesses is the ENUM trunk (create one if you don't have one). Because ENUM is always free, chances are the call will never
complete, but if it does it will not cost anything. Now make a higher numbered route (lower priority) and either include a general pattern such as:
1NXXNXXXXXX

Or if you want additional security, you could instead use a list of specific area codes that you wish to allow (omitting those that do not exist or that you don't want to allow
calls to be placed to):
1202NXXXXXX
1203NXXXXXX
etc.

Yes, it may be a fairly long list, but it will work. You may still want to use ENUM as your first trunk choice (if you want to check for a "free" route to the called number,
before going to your usual provider), but then you will be sure to include a trunk that permits outgoing calls to these numbers.

How do I....?
How do I allow seven digit dialing for local calls in North America?

In the route that handles calls to your local area code, include this in your Route Dial Patterns:
NXXXXXX

In the trunk(s) accessed by that route, include this in the Trunk Dial Rules:
1aaa+NXXXXXX

Replace aaa with your local Area Code.

How do I block certain International destinations while allowing others?

Again, make sure you've set up an ENUM trunk which can be used as a destination for calls you don't want to pay for. Then think about your dial patterns and how you want
to allow or block them. Remember that less specific rules must always be placed in a lower priority than more specific rules. For example, let's say we want to allow calls to
landlines in country code 64, but not to mobiles or high-cost numbers. In a higher priority (lower-numbered) route, include the patterns you want to block, e.g.:
011642.
011648.
01164900.

Associate this route with the ENUM trunk only. Then in a lower priority (higher-numbered) route, place the more general pattern:
01164.

Then associate this route with the ENUM trunk (if you want to check for a "free" route first), followed by the trunk(s) of the provider(s) you wish to use for calls to country
code 64. Don't forget to strip the "011" international prefix in the ENUM trunk Dial Rules.

Howto: Setting up VOIP Provider Trunks

76 of 89 5/22/2009 11:12 PM
How to set up common VOIP provider trunks with FreePBX

BBPglobal
Peer Details

Trunk Name: bbpglobal

disallow=all
allow=g723&gsm
authuser=<user number>
fromdomain=sip2.bbpglobal.com
fromuser=<user number>
host= sip2.bbpglobal.com
insecure=very
qualify=yes
secret=<password>
type=peer
username=<user number>

User Details

User Context: <user number>

context=from-trunk
fromuser=<user number>
insecure=very
secret=<password>
type=user
username=<user number>

Register String:

<user number>:<password>sip2.bbpglobal.com/<user number>

Broadvoice
After long days and nights of probing the web this is what has worked for me.

Outbound Caller ID:

Maximum Channels: <2>

Dial rules : <1|NXXNXXXXXX>

Trunk Name:

Peer Details:
authname=
canreinvite=no
context=from-pstn
dtmf=inband
dtmfmode=inband
fromdomain=sip.broadvoice.com
fromuser=
host=sip.broadvoice.com
insecure=very
qualify=yes
secret= this is different from your login pw
type=peer
user=phone
username=

INCOMING SETTINGS

User Context:

User Details:
authname=
canreinvite=no
context=from-pstn
dtmf=inband
dtmfmode=inband
fromdomain=sip.broadvoice.com
fromuser=

77 of 89 5/22/2009 11:12 PM
host=sip.broadvoice.com
insecure=very
secret=
type=user
user=phone
username=

Registation String:
@sip.broadvoice.com::@sip.broadvoice.com

Make sure you omit the <> signs and enter your variables. I have copied this directly from my working broadvoice trunk and removed my variables.

Broadvoice (alternative/corrected)
I was helping another user get a Broadvoice trunk working and below is what we finally settled on. The major difference between these and the other Broadvoice settings in
this section is that the incoming (USER) settings are not used (as is the case with most consumer VoIP providers, because they treat you as an extension rather than a peer)
and therefore the context statement is moved to the peer settings. This should work with FreePBX 2.4 and above and Asterisk 1.4 and above.

OUTGOING SETTINGS

Trunk Name: Broadvoice

PEER Details:
disallow=all
allow=ulaw&alaw
context=from-trunk
dtmf=auto
dtmfmode=inband
fromdomain=sip.broadvoice.com
fromuser=xxxxxxxxxx (your 10 digit broadvoice number)
host=sip.broadvoice.com
insecure=port,invite
qualify=yes
secret=xxxxxxxxxx (this is NOT your login password)
type=peer
user=xxxxxxxxxx (your 10 digit broadvoice number)
username=xxxxxxxxxx (your 10 digit broadvoice number)

INCOMING SETTINGS NOT USED

Registration String: YOUR 10 DIGIT NUMBER:YOUR SIP PASSWORD@sip.broadvoice.com/YOUR 10 DIGIT NUMBER

Engin BYO
Peer Details

Trunk Name: engin

allow=ulaw&alaw
disallow=all
auth=md5
canreinvite=yes
dtmfmode=rfc2833
fromdomain=voice.mibroadband.com.au
fromuser=02321XXXX
host=byo.engin.com.au
insecure=very
musiconhold=framed
nat=yes
port=5060
qualify=no
realm=mobileinnovations.com.au
reinvite=yes
secret=<password>
type=friend
username=02321XXXX

Incoming Settings

User Details

User Context: 02321XXXX

context=from-pstn
fromdomain=voice.mibroadband.com.au

78 of 89 5/22/2009 11:12 PM
host=byo.engin.com.au
secret=<password>
type=user
username=02321XXXX

Register String:
02321XXXX:<password>@byo.engin.com.au/02321XXXX

Note:You may need to include the following in your sip_general_custom.conf

Defaultexpirey=600
Maxexpirey=3600

Faktortel (IAX)
Peer Details

Trunk Name: faktortel

disallow=all
allow=g729&gsm&ulaw&alaw&ilbc
host=iax.faktortel.com.au
qualify=3000
secret=<password>
type=friend
username=xxxxxx

User Details

User Context: xxxxxx

context=from-trunk
host=iax.faktortel.com.au
qualify=3000
type=friend
username=xxxxxx

Register String:
xxxxxx:<password>@iax.faktortel.com.au

Faktortel supports the following codecs:

ulaw
alaw
ilbc
gsm
g729

79 of 89 5/22/2009 11:12 PM
FWD aka Pulver
Peer Details

Trunk Name: fwdsip


disallow=all
allow=ulaw&alaw
canredirect=no
host=fwd.pulver.com
insecure=very
secret=<password>
type=peer
username=xxxx

User Details
User Context: 65xxxx

canreinvite=no
context=from-trunk
fromuser=65xxxx
insecure=very
qualify=no
secret=<password>
type=user
username=xxxx

Register String:
username:<password>@fwd.pulver.com

Gizmo5
Peer Details
Trunk Name: Gizmo5
disallow=all
allow=ulaw&alaw&ilbc
canreinvite=no
context=from-trunk
dtmfmode=rfc2833
fromdomain=proxy01.sipphone.com
fromuser=1747xxxxxxx <-- Your Gizmo5 number
host=proxy01.sipphone.com
insecure=very
secret=<password>
type=peer
username=1747xxxxxxx <-- Your Gizmo5 number

User Details
(not used)

Register String:
1747xxxxxxx:<password>@proxy01.sipphone.com

Notes:
If you are using Gizmo5 to get free outgoing calls to U.S. cell phones, etc. via their Backdoor Dialing then you may want to prepend the 0101 code using the dial plan,
depending on how you set this up. For example, if you have set up an outbound route that routes calls to certain specific cell phone numbers in the 212 area code to this
trunk, then in the trunk dial rules you may want to add something like this:

010+1212XXXXXXX
0101+212XXXXXXX

Or, if you are careful about the traffic you send to this trunk (so that all numbers are pre-validated, or Gizmo5 numbers) then you could use something more generic:

1747XXXXXXX
1+747XXXXXXX
010+1XXXXXXXXXX
0101+XXXXXXXXXX

(747 is the pseudo-area code that Gizmo5 uses, so you don't want to preface that with 0101, therefore put it first so it will match and not fall through to the 0101's).

Note that there is a very short recorded message played at the start of each "free" call, and also note that (at the present time) Caller ID info is not passed through, but instead
it will send a Caller ID number in the 262 area code, so you might only want to use this for free calls to friends and family members (in theory this number can be used by the
person you called to return your call, but only if they call back from the number you called!). Another "gotcha" is that if your call out credit balance ever goes to zero or
negative, "Backdoor Dialing" appears to stop working properly (even though those are "free" calls) - it will ring the called party's phone, but the moment they answer it will
disconnect (hopefully this will be fixed someday).

It appears that wherever the 1747xxxxxxx number is given in the above configuration, it is acceptable to substitute the account username (but be consistent, use either the
number or the username, but not both).

80 of 89 5/22/2009 11:12 PM
Some users have reported that when sent from Asterisk, passwords are case sensitive. If you have problems, go to the Gizmo5 login and say you have lost your password an
get them to e-mail it to you, then copy and paste from the e-mail into your configuration. Note that passwords are NOT case-sensitive when used with the softphone, Gizmo5
web site, etc.

If you always get an "all circuits busy" when trying to place an 0101 prefix call, check your fromuser and fromdomain lines to make sure they are present and correctly
formatted.

iinet
The following are the various iinet sip proxies for the different states (at the time of writing).

You may use the sip proxy designation or the dot format IP address when configuring your iinet setting in TrixBox.

State SIP Server IP


act sip.act.iinet.net.au 203.55.231.193
nsw sip.nsw.iinet.net.au 203.55.231.199
nt sip.nt.iinet.net.au 203.55.229.193
qld sip.qld.iinet.net.au 203.55.228.194
sa sip.sa.iinet.net.au 203.55.229.193
tas sip.tas.iinet.net.au 203.55.229.193
vic sip.vic.iinet.net.au 203.55.229.193
wa sip.wa.iinet.net.au 203.59.49.5

Peer Details

Trunk Name: iinetout

disallow=all
allow=alaw&ulaw
canreinvite=no
context=ex-did
fromdomain=iinetphone.iinet.net.au
fromuser=073XXXXXXX
host=203.55.228.193
insecure=very
nat=no
pedantic=no
secret=<password>
type=peer
username=073XXXXXXX

User Details

User Context: iinet-inbound

canreinvite=no
context=from-trunk
fromuser=073XXXXXXX
host=203.55.228.193
insecure=very
qualify=no
secret=<password>
type=friend
username=073XXXXXXX

Register String:

073XXXXXXX@iinetphone.iinet.net.au:Password:073XXXXXXX@iinetout/073XXXXXXX
(Source Ref: Graham Foote)

iTalk (New Zealand)


Peer Details

Trunk Name: italk


disallow=all
allow=ulaw&g729
canreinvite=no
context=from-trunk
dtmfmode=rfc2833

81 of 89 5/22/2009 11:12 PM
fromuser=64997xxxxx
host=akl.italk.co.nz
insecure=very
secret=<your password>
type=friend
username=64997xxxxx

Note: Incoming setting is not required with newer versions of AAH.

You may prefix outgoing calls with 0197 to disable outgoing CID.

Inbound route 64997xxxxx required to be forwarded to a destination ext/menu

Register String:

64997xxxxx:<your password>@akl.italk.co.nz/64997xxxxx

(Source Ref: Steve Biddle)

Koala
Peer Details

Trunk Name: KoalaSip

disallow=all
allow=g729&gsm&alaw&ulaw
fromuser=<User-Sip Id>
host=203.122.248.173
nat=yes
port=5060
qualify=no
secret=<password>
type=friend

User Details

User Context: <User-Sip Id>

context=from-pstn
fromdomain=203.122.248.173
host=203.122.248.173
secret=<password>
type=user
username=<User-Sip Id>

Register String:

<User-Sip Id>:<password>@koalavoip.com.au

(Source Ref: Curtis of Koala) also refer here https://www.koalavoip.com.au/billing/node/75

MyNetFone
Trunk Name: MyFonesip

disallow=all
allow=alaw&ulaw
authname=091xxxxx
canreinvite=no
dtmfmode=rfc2833
fromuser=091xxxxx
host=sip.myfone.com.au
insecure=very
nat=yes
pedantic=no
qualify=yes
secret=<password>
type=friend
username=091xxxxx

User Details

82 of 89 5/22/2009 11:12 PM
User Context: 091XXXXX

canreinvite=no
context=from-trunk
fromuser=091xxxxx
insecure=very
qualify=no
secret=<password>
type=friend
username=091xxxxx

Register String:

091xxxxx@sip.myfone.com.au:<password>:091xxxxx@sip.myfone.com.au/091xxxxx

Nehos (IAX)
Peer Details

Trunk Name: Nehos

disallow=all
allow=g729
host=iax.ifone.com.au
qualify=yes
secret=<password>
type=peer
username=661xxxx

User Details

User Context: 661XXXX

context=from-trunk
host=iax.ifone.com.au
secret=<password>
type=user
username=661xxxx

Register String:

661xxxx:<password>@iax.ifone.com.au

Nodephone
Peer Details

Trunk Name: Nodephone

disallow=all
allow=g729
canreinvite=no
dtmfmode=rfc2833
fromdomain=sip.internode.on.net
fromuser=<usernumber>
host=sip.internode.on.net
insecure=very
secret=<password>
type=peer

User Details

User Context: <usernumber>

context=from-trunk
host= sip.internode.on.net
secret=<password>
type=user
username=<usernumber>

Register String:

<usernumber>:<password>@sip.internode.on.net

83 of 89 5/22/2009 11:12 PM
SipBroker
Peer Details

Trunk Name: sipbroker-out

disallow=all
allow=g729&ulaw&alaw
canreinvite=no
dtmfmode=rfc2833
fromdomain=<your existing sip provider>
fromuser=<your user ID of existing provider>
host=sipbroker.com
insecure=very
nat=yes
port=5060
secret=<password for existing provider>
type=peer

You will not require user details since you will not be receiving
incoming calls from this trunk.You do not need to register either.

If you are using SipBroker, you must ensure that your sip_nat.conf is modified to the following;

nat=yes
externip=<Fix Ip address> ; if you have fix IP or
externhost=<your DNS hostname> ; if you are using Dynamic IP
localnet=192.168.1.0/255.255.255.0

Sipgate (U.K.)
This is copied verbatim from this blog post at sysadminman.net, except that I have changed the context statement to context=from-trunk, as required by FreePBX. The USER
Context and USER Details in the trunk configuration are left blank. Be sure to substitute your user information and password in place of all instances of "1234567" and
"XXXXXXXX".

Sipgatge trunk with Asterisk/FreePBX

9th November 2008, 01:00 pm

I’ve used Sipgate for the past few years with my Asterisk box and have been pretty impressed.

For anyone else looking to use Sipgate with Asterisk/FreePBX here is my trunk setup
Trunk Name: Sipgate

PEER Details:
username=1234567
type=peer
secret=XXXXXXXX
qualify=yes
nat=never
insecure=very
host=sipgate.co.uk
fromuser=1234567
fromdomain=mydomain.com
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=yes
authuser=1234567
allow=ulaw

Register String:
1234567:XXXXXXXX@sipgate.co.uk/1234567

If you are using NAT between your Asterisk box and Sipgate you will need “canreinvite=no” and “nat=yes” or you will probably get one way audio only on your calls.

SipMe
Peer Details
Trunk Name: sipme
authname=1777xxxxxx
dtmfmode=rfc2833
fromuser=1777xxxxxx
host=sip.sipme.com.au
insecure=very
secret=<password>
type=peer
username=1777xxxxxx

84 of 89 5/22/2009 11:12 PM
User Details
User Context: 1777xxxxxx
context=from-trunk
fromuser=1777xxxxxx
secret=<password>type=user

Register String:
1777xxxxxx:<password>@sip.sipme.com.au/1777xxxxxx

SipPhone
Peer Details
Trunk Name: sipphone
fromdomain=proxy01.sipphone.com
host=proxy01.sipphone.com
insecure=very
secret=password
type=peer
username=1747xxxxxxx

User Details
User Context: 1747xxxxxxx
canreinvite=no
context=from-trunk
fromuser=1747xxxxxxx
insecure=very
qualify=no
secret=password
type=user
username=1747xxxxxxx

Register String:
1747xxxxxxx:password@proxy01.sipphone.com/1747xxxxxxx

TelephoneGlobal
Peer Details

Trunk Name: Teleglobal

disallow=all
allow=g729
canreinvite=no
host=210.80.182.142
insecure=very
secret=<password>
type=peer
username=2222xxxxxxxxx

User Details

User Context: 2222xxxxxxxxx

context=from-pstn
fromuser=2222xxxxxxxxx
secret=<password>
type=user

Register String:

2222xxxxxxxxxxx:<password>@210.80.182.142/2222xxxxxxxxxxx

ViaTalk
OUTGOING SETTINGS

Trunk Name: viatalk

PEER Details:
disallow=all
allow=ulaw
authuser=xxxxxxxxxxx (your 11 digit viatalk number)
context=from-trunk

85 of 89 5/22/2009 11:12 PM
dtmf=auto
dtmfmode=inband
fromdomain=chicago-1.vtnoc.net
fromuser=xxxxxxxxxxx (your 11 digit viatalk number)
host=chicago-1.vtnoc.net
insecure=port,invite (or insecure=very only in Asterisk 1.2 & earlier)
qualify=yes
secret=xxxxxxxxxx
type=peer
username=xxxxxxxxxxx (your 11 digit viatalk number)

NOTE: Use your nearest ViaTalk server as selected in the ViaTalk control panel for fromdomain and host settings (Chicago is shown in this example).

NOTE: If you have problems with touch tones not being able to control your IVR on incoming ViaTalk calls, or you find you can't create an inbound route that works, or
ViaTalk is sending Caller ID with a + prefix and you'd like to get rid of that, try this: instead of setting the context= to from-trunk, set it to custom-from-viatalk and then
add the following lines to the end of /etc/asterisk/extensions_custom.conf (do NOT include the parenthetical line numbers at the start of each line, they are there solely for
reference in this documentation):

(1) [custom-from-viatalk]
(2) exten => _X!,1,Noop(Incoming ViaTalk call)
(3) exten => _X!,n,SIPDtmfMode(inband)
(4) exten => _X!,n,GotoIf($["${CALLERID(num):0:2}" != "+1"]?noplusatstart)
(5) exten => _X!,n,NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):1})
(6) exten => _X!,n,Set(CALLERID(num)=${CALLERID(num):1})
(7a) exten => _X!,n(noplusatstart),Goto(from-trunk,${EXTEN},1)
(7b) exten => _X!,n(noplusatstart),Goto(from-trunk,your-viatalk-number,1)

Always include lines (1) and (2). Use line (3) if you find that callers can't use touch tones to control your IVR, or otherwise get around in your system (if in doubt, we
recommend including it). Lines (4) through (6) can be used if ViaTalk is sending the Caller ID number with a + prefix and it is causing problems (with callbacks, etc.) As
shown, the code will only strip the + if the number starts with +1, so the + would (hopefully) still be present on any international calls. If you want to remove the +
unconditionally (even on international calls) then change Line (4) in two places, so that the :0:2 becomes :0:1 and the "+1" becomes "+". Finally, if your inbound route is
working without any issues (as usually seems to be the case now) then use line (7a) rather than line (7b). But if, for some reason, you are still having problems with ViaTalk
calls not coming into your inbound route, then try using line (7b) instead of (7a) and where you see your-viatalk-number, replace that with your 11 digit ViaTalk number
(you might also have to replace all instances of _X! with s in all lines of the context). Note that using line (7b) should no longer be necessary if you construct the registration
string properly (see below), so please try line (7a) first. Whichever variation of line (7) you use, if (and only if) you did not use lines (4) through (6) then remove the
(noplusatstart) label on line (7).

INCOMING SETTINGS NOT USED

Registration String: YOUR 11 DIGIT NUMBER:YOUR SIP PASSWORD@YOUR VT PROXY/YOUR 11 DIGIT NUMBER

Source: http://aussievoip.com.au/wiki/Tested+and+working+SIP+provider+configurat...

Voip Buster
Peer Details

Trunk Name: VoipBuster

disallow=all

allow=alaw&ulaw&gsm

context=from=pstn

dtmfmode=inband

fromdomain=sip1.voipbuster.com

fromuser=<your username or user number>

host=sip1.voipbuster.com

insecure=very

nat=yes

qualify=yes

secret=<your password>

srvlookup=yes

type=friend

username=<your username or user number>

Register String:

<Username or User Number>:<password>@sip1.voipbuster.com/<Username or User Number>

86 of 89 5/22/2009 11:12 PM
Note: Incoming setting is not required with newer versions of TrixBox.

If you have an inbound number, an Inbound route is required to


forwarded your incoming call to a destination extension or IVR menu:

Inbound Route:DID: <User inbound Number>

No Fax

(Source Ref: Florent Chandelier)

HOWTO: SPA-3102 and FreePBX


From a FACTORY RESET or FACTORY NEW box:

SPA-3102 Web Administration:

Regional Tab:

Remove Feature Codes

PSTN Line Tab:

Proxy: YOURASTERISKBOX

User ID: SOMEUSERID

Password: SOMEPASSWORD

Echo Supp Enable: No

Echo Canc Adapt Enable: No

Dial Plan 1: (S0<:DIDNUMBER>)

or IF PASSING CID INFO: Dial Plan 1: (S0<:s>)

Dial Plan 2: (*x.|x.)

Line 1 VoIP Caller DP: 2

VoIP Caller Default DP: 2

PSTN Ring Thru Line 1: No

PSTN CID For VoIP CID: Yes

VoIP Answer Delay: (default 0) 1

PSTN Answer Delay: (default 16) 5

FXO Port Impedence: 220+820||120nf (MAY NEED TO TWEAK FOR ECHO REMOVAL)

SPA To PSTN Gain: (default 0) 5 (MAY NEED TO TWEAK FOR ECHO REMOVAL)

PSTN To SPA Gain: (default 0) 5 (MAY NEED TO TWEAK FOR ECHO REMOVAL)

FreePBX Trunk Setup:

Trunk Name: spapstn

Peer Details:

dtmfmode=rfc2833
secret=SOMEPASSWORD
type=peer
username=SOMEUSERNAME

87 of 89 5/22/2009 11:12 PM
USER Context: from-spapstn

User Details:

context=from-trunk
host=dynamic
dtmfmode=rfc2833
secret=SOMEPASSWORD
type=user
username=SOMEUSERNAME

When an internal extension user dials one of my DID's, how do I keep the call
from using external trunks?
When an internal extension user dials one of my DID's, how do I keep the call
from using external trunks?
In larger installations you often find the problem of employees or guests picking up one of your internal extensions and dialing one of you main DID numbers. The usual
reason for this is that they know how to navigate your IVR menus, but don't necessarily know the direct internal extension number of the person or department they wish to
reach. Human nature being what it is, they take the path of least resistance and dial your external number, which by default will use two external voice channels and possibly
even two trunks, for which you might be charged per-minute usage rates (depending on your provider).

If you have registered all your DID's with an ENUM registry, such as e164.org, then you can simply make your ENUM trunk your first choice for all outgoing calls, and the
calls should come right back to your system (in effect never leaving your FreePBX box). But what if you have never registered your numbers with an ENUM registry, or for
some reason it's not working as you think it should? Well, here's an alternate method that is easily changeable as you add or remove DID's:

First, create a CUSTOM trunk. For the Custom Dial String, use this:
Local/$OUTNUM$@from-trunk

In the Dial Rules, make adjustments for any differences between the way you would dial the number, and the DID your provider sends. To illustrate what I mean, let's
suppose that you are in the United States and allow 7 and 11 digit dialing of local numbers, but your provider sends a 10 digit DID. Let's further assume the DID is
9998675309, so internally people might dial 1-999-867-5309 or just 867-5309. So in your trunk Dial Rules you might have this:
1|9998675309
999+8675309

The idea is to convert whatever people might dial internally to match the DID your provider sends, so that it will be recognized as a valid DID for an inbound route. I do
suggest doing each DID separately rather than using a pattern that fits multiple DID's because someday you might get a DID from a different provider that sends DID's in a
different format (perhaps eleven digits rather than ten) and this would "break" your generic patterns - however if you plan to use only one provider and have many DID's
from that provider, you could use more generic patterns such as (in keeping with the above example):
1|NXXNXXXXXX
999+NXXXXXX

Second, create a new Outbound Route. Name it something like Local-DID-Loopback, check the Intra Company Route box if you want looped calls to show the local
extension number in the Caller ID (you probably do want that), and then in the Dial Patterns simply list all your DIDs as people might dial them from inside your system. So,
again in keeping with the above example DID of 999-867-5309 and your system allowing 7-digit or 11-digit dialing, you'd use the following Dial Patterns:
19998675309
8675309

In case you are wondering, you could strip the leading 1 (in this example) in the route Dial Pattern, for example using 1|9998675309 - it would make no difference whether
this is done at the route or trunk level. As your final step in creating the route, you'd simply select the CUSTOM trunk you created in the first step as the only available trunk
for calls using this route.

Note that after you submit the changes for the route, you need to move it to a higher priority than your normal routes that would otherwise handle these calls, so keep
clicking the up-arrow next to the route name until it is higher in priority than any of your other routes (except for your emergency routes, which should always have the
highest priority). Then click the orange "Apply Configuration Changes" bar to make your new trunk and route active.

This seems like a lot of work - I only have one DID, isn't there an easier way?
The method shown above may be a bit more difficult to set up initially, but it is the easiest to reconfigure as you add or remove DIDs. However, perhaps you prefer a more
direct approach - or maybe you want special routing of such calls (maybe you want to send them to a recording that says "Stop being lazy, and look up the extension
number!", or perhaps something slightly more helpful). What you could do is create one or more new Misc Applications. In that case, you'd make the Feature Code of each
Misc Application the DID number as your users would dial it internally (not necessarily the DID) - so if we again use the above example, we'd have to create two new Misc
Applications, one using 19998675309 as the Feature Code and the other using just 8675309 as the Feature Code. Then you just send each number to the destination you
prefer, whether it be your main IVR, a recording, or some other destination.

There are two problems with this method - it gets a bit unwieldy to maintain if you have more than a handful of DID's, and perhaps more significantly, it doesn't automatically
track changes you make in your Inbound Routes. That's good if you want to give calls to these numbers different treatment than what outside callers would receive, but bad if
you want callers to get whatever an outside caller would get when dialing one of your numbers.

Even if you use another method to handle your DID's that are associated with Inbound Routes, this method can be used to handle numbers for which you don't have a
DID/Inbound Route. For example, if you have a provider that lets you have more than one number associated with a trunk, but regardless of the number dialed always sends
the same DID, you may not have an Inbound Route for the other number(s) associated with that trunk. You could use the Misc Application method to intercept and reroute
those secondary numbers, if dialed from an internal extension.

Using any of the methods mentioned above may help save your bandwidth, and possibly some money that would otherwise be paid in unnecessary per-minute charges!

88 of 89 5/22/2009 11:12 PM
Where to Get Free Classical Music on Hold
Free Classical Music-On-Hold files.

Elena Kuschnerova (pianist) and Lev Guelbard (violinist) placed a series of music file in the public domain in 2004.

They are hosted here:

aussievoip.com

For an even wider selection, visit:

Classic Cat

Other options include:

http://creativecommons.org/audio/

This site is basicly royalty free (the owner requstest that you email him though):

http://ghostnotes.blogspot.com/

89 of 89 5/22/2009 11:12 PM