NOTE: If you are serious about undertaking this solution,
you probably want to read the updates at the bottom of this
entry, as we have now switched over to Flowroute as a
one-stop-shop (OK, two-stop-shop, with Google
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
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
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
- 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,
- 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.
The new solution consists of the following bits and
- Linksys ATA - The same device used for Gizmo5.
- PBXes - An
internet based virtual PBX. The ATA talks to this
- ipkall - Provides
free DID. This gives me a phone number regular phones can
- CallWithUs -
Outbound phone trunk. This is used for outbound calls to the
- Google Voice -
It could be simpler, but not with the breadth of features
we get and also making it as cheap as possible - in this case
it means nearly free! Inbound calls cost nothing. Outbound
calls are as low as $0.01 with CallWithUs. I can swap in
different outbound trunks trivially via PBXes - I can even have
multiple services with complex routing rules. Very cool hackish
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
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
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:
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
Also, I had to use the G711u codec. It works fine, but G729a
uses less bandwidth and the voice quality is still
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
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
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
- 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
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.
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
And another update here
on switching to an Obihai OBi100 after my Linksys died.