From November 2009 until last week we were using Gizmo5 plus Google Voice for our home phone service, via a Linksys PAP2T-NA "SIP ATA" device. That last bit is a small piece of hardware that bridges a regular old (POTS) telephone to IP/ethernet.
The Gizmo5 solution worked pretty well, a few technical issues here and there, but it was fairly stable. Inbound calls were free, as they were routed through Google Voice. Outbound calls were $0.01 per minute. Our total phone bill during that 16 months was $8.
Google acquired Gizmo5 about a year ago, and have now decided to kill the service. I was really disappointed to hear this decision, as I expected to see more SIP integration in Google Voice, not less. It seems clear that Google is not interested in SIP, though they are supporting XMPP - as used in Google Talk. And just to close up the history on this, Grand Central was the original company that Google bought and became Google Voice (GV).
The old solution was pretty simple to setup, as Google provided the integration between Gizmo5 and Google Voice via GV settings. Basically, you just added your Gizmo5 number to GV, then configured the ATA to talk to Gizmo5's SIP servers. Then plug in a phone and make some calls. Super easy.
The new solution? Well it's quite a bit more complex.
First, a few telephony acronyms for the uninitiated.
- VOIP - Voice Over Internet Protocol. Sort of a misnomer, as it's not really a protocol, just a classification.
- SIP - Session Initiation Protocol. This is the standard VOIP protocol that devices use to establish phone calls over the internet.
- ATA - Analog Terminal Adapter. The device that an old analog phone plugs into to bridge to a VOIP protocol. An alternative would be using an IP phone.
- POTS - Plain Old Telephone Service. The analog phone system, in use well over 100 years, amazing!
- DID - Direct Inward Dial. The ability for someone to call your VOIP phone from a regular phone.
- CID - CallerID. You know what this is.
- PBX - Private Branch eXchange. Essentially a small, private phone company. All the phones plug into this (either directly or virtually via a network), and it handles all the routing between calls or trunking to an external phone service (for example, calling a regular phone). PBXs provide other features, such as voice mail, caller ID, and management of IP phones - to provide a few examples.
- PSTN - Public Switched Telephone Network. This is the huge network of wires, switches, central offices, and so forth that give us POTS.
- Linksys ATA - The same device used for Gizmo5.
- PBXes - An internet based virtual PBX. The ATA talks to this service.
- ipkall - Provides free DID. This gives me a phone number regular phones can dial.
- CallWithUs - Outbound phone trunk. This is used for outbound calls to the PSTN.
- Google Voice - Yep, that
Here's an overview of how it all fits together (the arrows show direction of call initiation):
The only number people need to know is our Google Voice number. Dialing it rings our home phone. Likewise, outbound calls work just as you would expect from a regular phone. Outbound CallerID is "spoofed" with our Google Voice number. This spoofing of the number makes sense, since it is our valid phone number - we aren't sending some fake number or anything dumb like that.
When the ATA boots up, it establishes a connection to the PBXes SIP switch. They use an Asterisk based system, and for a basic system (like this) it's a free service. Once the ATA is registered with the switch, the phone line is provisioned and that connection stays nailed up. The ATA has some options to help with NAT traversal and keeping the IP sockets connected.
Inbound calls to our Google Voice number get forwarded to our ipkall DID number. This is some random phone number in Washington state. ipkall bridges that via SIP to PBXes, which then forwards that to our ATA. PBXes has all sorts of various options in terms of call display, hunt groups, forwarding, and all that other nifty PBX stuff - but in our case it's really simple, as we have just one registered extension and all calls go directly to it.
Outbound calls go to PBXes where an outbound trunk is selected. Again, it's possible to have all sorts of routing rules with multiple providers, but we are using just one - which is CallWithUs. PBXes sends the call via SIP to CallWithUs, which bridges the call out to the PSTN. This is the only leg that costs anything, with calls to the USA at $0.01 per minute. And we can always use Google Voice to initiate the call with their callback service, making calls free. One thing I like about CallWithUs is that you can purchase time in $5 increments.
There's quite a bit of configuration required to the various services to make sure they all talk to each other.
Out of the box, CallWithUs, like most SIP to PSTN services, requires a full dialing string that includes country code. The solution to this is to setup a dialplan on the ATA allowing standard 7 and 10 digit dialing:
(<:1>xxxxxxxxxx|<:1530>xxxxxxx|<411:18004664411>|*xx|11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)I won't go into all the entries but basically this tells the ATA what to do with various dialed numbers, inserting missing digits or replacing numbers entirely. For example, the first entry automatically prefixes a 10-digit number with the "1" country code for the USA. The second, uses area code "530" for 7-digit dialing. The third entry forwards calls to "411" to the Google directly service. An option to do here is cause a call to be initiated immediately once the dialplan has been fulfilled - which is what the S0 suffix does, but it can be tricky. Without it, the ATA would wait for awhile to see if you have more digits to dial. A good full tutorial on this is here.
The dial string rules could also be done in PBXes, though there would still be a delay for the ATA to wait for all dialing digits. A hybrid approach would be worthwhile - use the ATA configuration for 10 and 7 digit, and the various other, basic dial rules - as well as dial immediately when it can. Use the PBXes configuration for forwarding services.
This would also be the appropriate place for routing 911 calls to some local emergency number - and that brings up one very, very important issue: This solution does not provide traditional 911 service. We have enough cell phones that I'm not worried about it, but it's worth thinking about how you would handle it for your case.
The only existing issue is that some incoming calls do not have the original caller's Caller ID showing up on the phone when people call us, instead showing some Washington number. Not entirely sure why this is occurring. Outbound Caller ID works flawlessly.
Also, I had to use the G711u codec. It works fine, but G729a uses less bandwidth and the voice quality is still excellent.
Here's screenshots and details for configuration:
- CallWithUs - No configuration needed for the service, just an active account and call credit balance. PBXes is a client to this service. You do need connection and account information to provide PBXes, and CallWithUs has decent documentation.
- PBXes - Lots of configuration required here. You need to define an extension (with a username and password for the ATA to authenticate as). You need an outbound trunk configured (CallWithUs in my case). You need a default route that sends all inbound calls to the extension. You need a default route that send all outbound calls to the trunk.
Username will look something like "foo-100", where "foo" is your PBXes account, and 100 is the extension number. The Password you pick, and will be configured into the ATA and ipkall. The Dial field would look like "SIP/foo-100" for this example. Note dtmfmode of "info" - this setting here, and in the ATA, was required for Google Voice to accept DTMF tones to validate my ipkall DID number for GV to forward calls to it. Outbound CID is our GV number.
Username and Password, along with SIP server or proxy, are values provided by CallWithUs. Outbound Caller ID is our Google Voice phone number.
Inbound route configuration:
This is pretty simple. We want to route all incoming calls directly to extension "100".
Outbound route configuration:
Also simple, this routes all outbound calls directly to the CallWithUs trunk.
- ipkall - This just needs to know about routing inbound calls to PBXes. The SIP Phone Number is our PBXes SIP account info - "foo-100" for our example. Password is the corresponding PBXes password.
- Linksys ATA - This is an especially complex device to configure. I configured Line 2 on the device, as I set this up in parallel with the existing Gizmo5 service until I got things all working. User ID and Password are the matching username and password for this extension in PBXes configuration. You'll see DTMF Tx Method set to "INFO" to match PBXes configuration. I had to use the G711u codec, as my preferred G729a didn't work. NAT Mapping Enable and NAT Keep Alive were enabled to help keep the extension registered through our firewall/router/ISP. Comcast works with a SIP Port of 5060, however when we had AT&T DSL, I had to change this. Dial Plan is the entry discussed above.
An acquaintance mentioned the use of CallCentric for a VOIP provider. There are a number of one-stop VOIP providers that don't involve or require this complex of a setup. The advantage of a one-stop solution is simplicity - only one thing to configure, although you can still use a GV number for incoming calls. I looked into CallCentric, but their rate was higher at $0.02/minute. I scouted out a few other ones as well - one wanted $35 in initial calling credits, which was more than I was willing to spend up front (and I was still only going to use them as an outbound trunk, not for a DID number).
For anyone seriously considering a VOIP solution, I would also say that you don't have to do anything complex like the above. There are lots of one-stop VOIP providers that will allow a simple setup - and it's still going to be significantly cheaper and better than, say, Vonage or or Comcast VOIP.
UPDATE 2011-03-28 (And read an even newer update below):
Well, it was a great idea, but due to some issues with inbound calls, I'm giving CallCentric a try instead - even though it will cost more - around $2/month for the inbound number, and outbound rate of $0.02/minute. Inbound calls also are billed at a rate of $0.02, so they aren't free either.
What we have found is that Caller ID is flaky at best (if it works at all, it's usually some number in Tacoma WA - probably belonging to either Google Voice or ipkall), and even worse - by the time inbound calls are forwarded through all the services and our phone rings, Google Voice gives up and forwards the call to voice mail. So our phone rings, and we pick it up, but there's nobody there - because the caller is already leaving a message on GV.
This is a very simple configuration, consisting of our ATA and CallCentric, plus Google Voice. Our GV number will be forwarded to the CallCentric DID (in fact, both numbers are in the same Central Office), and CallCentric will send the GV CallerID on outbound calls - they just needed to verify that the number, indeed, belonged to me.
Now we shall see if CallWithUs gives me back my $4 calling credit... Otherwise there are some LONG outbound phone calls in our future! :-)
You can read my blog posting on attempt #2 right here, where any additional updates or discussion will go on this topic.
After about 20 months with Callcentric I've switched to Flowroute as a result of about 4 weeks of flaky or down service due to DDOS and then superstorm Sandy.
Read the latest update here before considering anything written here.
And another update here on switching to an Obihai OBi100 after my Linksys died.