Asterisk is generally pretty reliable, but termination providers aren't always so good; in a market where anybody can re-sell an upstream provider, or setup a few Asterisk boxes and start routing calls for people, it's generally a good idea to have a "backup" provider (or three) to route your calls through.

You can easily setup an Asterisk system, to fail-over to secondary systems, if your primary provider fails for some reason- and this can all be done right in the dial plan, using a simple MACRO.

Add this MACRO to your dial plan:

[macro-direct-dial]
exten => s,1,Set(CALL_ATTEMPT=1)
exten => s,2,Set(TERM_PROVIDER=${TERM_PROVIDER1})
exten => s,3,Dial(${TERM_PROVIDER}/${ARG1},60)
exten => s,4,GotoIf($["${CALL_ATTEMPT}" >= "${MAX_PROVIDERS}"]?s-CANCEL,1)
exten => s,5,Set(CALL_ATTEMPT=$[${CALL_ATTEMPT} + 1])
exten => s,6,Goto(s-${DIALSTATUS},1)

exten => s-BUSY,1,Noop()
exten => s-NOANSWER,1,Noop()
exten => s-CANCEL,1,Hangup()
exten => s-HANGUP,1,Hangup()

exten => s-CHANUNAVAIL,1,Set(TERM_PROVIDER=${EVAL(${TERM_PROVIDER${CALL_ATTEMPT}})})
exten => s-CHANUNAVAIL,2,Goto(s,3)

exten => s-CONGESTION,1,Set(TERM_PROVIDER=${EVAL(${TERM_PROVIDER${CALL_ATTEMPT}})})
exten => s-CONGESTION,2,Goto(s,3)

Now you'll need to route your calls into this MACRO; this can vary by dial plan, as you may have a special configuration for different area codes, or country codes, or based on some least-cost-routing business decisions, but a simple example would be something like this:

[default]
exten => _1NXXNXXXXXX,1,Answer()
exten => _1NXXNXXXXXX,2,Macro(direct-dial,${EXTEN})
exten => _1NXXNXXXXXX,3,Hangup()

This routes any NANPA numbers through the direct-dial MACRO above, passing in the phone number as the first argument to the MACRO.

Now, before this will work, you'll need to configure some variables; this can be done in many places- in my working configuration, I have these variables dynamically generated via an AGI script, based on the phone number being dialed. This way I can control dial-groups, by phone number, based on a cost/preference/etc.

In this example, we'll simply set these values in the globals section of the extensions.conf file:

[globals]
TERM_PROVIDER1 = SIP/first_provider
TERM_PROVIDER2 = IAX/second_provider
TERM_PROVIDER3 = SIP/last_provider
MAX_PROVIDERS = 3

So I've configured three fictitious termination providers; you can specify as many as you like, as long as the TERM_PROVIDER increments one for each, and you set the MAX_PROVIDERS value to the total number of providers listed.

This is obviously more useful if this list is automatically generated somehow, or changed based on the phone number being dialed, otherwise the retries could simply be hard-coded into the dial plan.

Now when you dial your number, it will start with the first (default) provider; if the dial() function returns a congestion or channel un-available error, the MACRO will cycle to the next provider, until it as gone through all of the providers listed.

We've received a tremendous amount of press coverage in the week since we launched the Fonolo iPhone application, including a quick spot on the ABC News tech bytes segment.

It was also featured on:

lifehacker- Fonolo Skips Automated Customer Service Phone Trees, Now on iPhone

TMCnet.com - Fonolo Launches Free iPhone App

CNet - Fonolo's deep dialer comes to the iPhone

Techvibes - Fonolo lets iPhone users skip corporate phone hell

and many other sites.

We couldn't be happier!

Stay tuned for some upcoming additions.

Fonolo for business lets you embed your companies phone menu (IVR system) right on your website, or in your mobile applications, with just a few simple lines of HTML code.

Fonolo automatically maps out your phone system (and stays up-to-date with any changes you make)- You will get happier customers, fewer misdirected calls, and better feedback from your callers. Best of all, you do not have to change anything in your existing phone system.

Here's a really simple example for our fake "Fonolo Airlines" company:

More details about Fonolo for business can be found here. We're running several live trial runs with a handful of companies- if you're interested in getting access to the Fonolo widget, contact us.

Asterisk, by design, is very "extension" orientated- that is, if you want to dial an end-point, it requires an extension to route the call to. These extensions (defined in the asterisk extensions.conf file), can be extensions registered to phones, DIDs (XXXYYYZZZZ), or simply usernames assigned to users by the network administrator. Extensions are used for both incoming, and outgoing phone calls.

For example, if I place a call through my SIP phone to 1-444-555-1212, then asterisk will look up the "extension" 14445551212 in the extensions.conf file, to determine how to route the call.

Similarly to how e-mail works, an artifact of these extensions is a direct SIP address, which is basically your SIP extension @ your SIP server- so, if my phone was extension 555, and my SIP server had the IP address 192.168.1.1, then my SIP address would be: sip:555@192.168.1.1, and (if it's not implictely blocked), I can be dialed directly using that SIP address.

But, because Asterisk is so extension orientated, it doesn't easily allow for outbound dialing, using remote SIP addresses; If I try to dial the address sip:444@somedomain.com, Asterisk will immediately strip off the host portion (@somedomain.com), and try to route the call based simply on the extension "444"- which, since it's an extension on a remote server (@somedomain.com), it won't be able to route it locally, and will fail.

The solution? Well, it's not ideal, but Asterisk provides the ability to use wild cards in the extensions.conf file (it refers to them as "patterns") when doing extension look ups; this is handy when you have blocks of extension or DID's- you can use the wildcard to map like extensions to the same config, keeping your config file small.

The issue, is that the wild card only compares against the local part of the SIP URI, which can look like almost anything, including other phone numbers.

First, define some general config

[general]
;
; Your termination provider (defined in sip.conf)
;
TERM_PROVIDER = SIP/company_peer

;
; The IP address of this asterisk server
;
ASTERISK_IP = 192.168.1.1

The "ASTERISK_IP" address is important later, as we'll use it to validate outgoing SIP addresses.

Then in your default config, you should have something like this configured already- handling NANPA style dialing, and international dialing

[default]
;
; Dial NANPA style phone numbers directly
;
exten => _1NXXNXXXXXX,n,Dial(${TERM_PROVIDER}/${EXTEN},60)
exten => _1NXXNXXXXXX,n,HangUp()

;
; Dial international numbers directly
;
exten => _011.,n,Dial(${TERM_PROVIDER}/${EXTEN}, 60)
exten => _011.,n,HangUp()

After all the specific matches are done, then add:

;
; very last, assume anything else is a SIP URI
;
exten => _.,n,GotoIf($[${SIPDOMAIN} = ${ASTERISK_IP}]?unhandled)
exten => _.,n,GotoIf($[${SIPDOMAIN} = ${ASTERISK_IP}:5060]?unhandled)
exten => _.,n,Macro(uri-dial,${EXTEN}@${SIPDOMAIN})
exten => _.,n,HangUp()

;
; if the call doesn't match anything
;
[unhandled]
exten => s,n,Congestion()

The reason this has to be last, is because matching the extension "_." will match *anything*- basically it's a catch-all. You're saying that if it doesn't match anything else before this, then assume it must be a SIP URI.

This section also compares the ${SIPDOMAIN} variable to your ASTERISK_IP address; this ensures that only SIP URI's with remote hosts are processed as SIP URI's. If the host matches our ASTERISK_IP address value (ie- it's a local extension), then it should have already matched something above this catch-all config.

Pass any SIP URI dials to the uri-dial MACRO, merging back together the extension and the SIP domain value.

;
; handle dialing SIP uri's directly
;
[macro-uri-dial]
exten => s,n,NoOp(Calling as SIP address: ${ARG1})
exten => s,n,Dial(SIP/${ARG1},60)

This solution works, but isn't ideal, as it will match anything that didn't already match; a better solution would be for it to NOT strip off the SIP domain, and allow for using a regular expression of some kind to check the extension, but there is currently no better way of handling this in Asterisk.

I was playing with the Gizmo5 service today- we've had a few customer now ask if they could have Fonolo call them back at their Gizmo5 address, instead of a regular PSTN number. Their service, which is very Skype-ish, aims as providing cost saving on international phone calls, as well as provides free calls between Gizmo5 users.

One of the first things I noticed (after installing the Gizmo5 client), was that their system allocates each user a "SIP" number, which they made the unfortunate choice of formatting like a standard ten digit phone number (XXX-YYY-ZZZZ)- not only that, but they used the area code 747!

Unfortunately, they don't have any stake in the *real* 747 area code controlled through NANPA- even worst, looking at the NANPA database, the 747 area code is already allocated as an overlay to the 818 area code (in California), and is set to be put in service May 18th, 2009 (~3 months from now).

Now, the Gizmo5 site doesn't seem to make any mention of this, and there are only a few posts out there I can find- but they all simply say that the "SIP number" was never meant to be used as a normal PSTN number- it can only be called from one client to another, or as a full SIP address (by tacking on @proxy01.sipphone.com)- if that's the case, it seems really weird that they opted to use phone numbers, instead of just usernames.

I'm not sure how they plan to handle it when *real* PSTN numbers in the 747 area code start getting allocated to people in California, and then one of their users with a DialOut package tries to call one of them? I'm sure it's not going to take long before phone numbers start being duplicated, and they're going to have to solve this issue.

Not to mention general confusion; I've read post after post about people being confused about why they can't dial their 747 phone number from PSTN number.

As far as Fonolo support, I was hoping to simply trunk any calls to the 747 area code over SIP to the Gizmo5 system, as if they were just regular phone numbers; in testing, it seems to work well, but I'd just run into the same issue they will, come May.

I'll have to just add them into the system as generic SIP addresses- hopefully I'll have this working soon.