The final(?) word on the QuickPhones phone.

It has been a while, but a few weeks ago I go another update from the QuickPhones guys about the multiple AP issue that I ran in to. I was extremely disappointed to hear that they were unable to find a fix for the multiple AP issue, and have given up trying.

So, what can I say? I will still tell you that this phone has the best battery life of any of the lower priced wifi phones out there. (I have not had a chance to try the more expensive ones. Feel free to contact me if you want to send me one!) When I didn't have it associated to a network, and just sitting on my desk the battery lasted about a month. When connected to an AP, the battery lasted about a week.

Now, just to be clear, it is possible that this phone would work perfectly on wireless gear that "pretends" to be a single huge AP. The one that comes to mind is Meru networks. I have some Meru gear that I am going to install, and will post a follow-up on this phone once I get it installed.

I have, however, discovered a bit of a workaround to the multi-AP issue. If you happen to have a single AP around that can broadcast another SSID, you can still use the phone in an area with multiple APs on one SSID. To do this, you need to shut down all of the APs that are broadcasting the same SSID so that the phone can pick up the AP that is single.

That didn't make a lot of sense, so let me expand on it. Lets say you have 5 "brand X" APs, all broadcasting an SSID called "CorporateFoo". While those APs are all broadcasting the SSID, the phone will be unable to consistently see any SSIDs around you. So, to get the phone working, you need to run to your local electronics store and purchase an inexpensive "brand Y" AP. Set that AP up and name it something like "IWishQuickPhonesWorkedOnMultiAPNets". (yes, I know that is too long for an SSID.. work with me here.) Now, shut down all of the APs that are broadcasting the "CorporateFoo" SSID, and reboot your QuickPhone. When the phone comes back up, it should be able to see your single AP that is broadcasting the "IWishQuickPhonesWorkedOnMultiAPNets" SSID. Configure the phone to use this SSID, make sure it connects and can talk to your SIP server. Once you verify it is working, you can turn your other APs back on. Now that you have the configuration set in the phone, it should always talk to the single AP. When it is powered on, it might take a while to find the AP, but it should eventually connect to it.

So, in a nutshell, if battery life is king for you, and you either only have a single AP, or don't mind jumping through hoops to get your phone working, the QuickPhone is what you want. If having a phone off the charger and on standby for more than 24 hours isn't important, then I recommend the UniData phone I reviewed a few months ago. It is a solid phone that has been working perfectly in my environment.

Love and Hate with Asterisk

For a year or two I have been running an Asterisk server. It has been wonderful. Recently, I wanted to add the new Skype functionality to Asterisk, so it required that I move from an old Apple X Serve to an x86 based machine. In the process, I figured I would upgrade from Asterisk 1.4, to 1.6. It should be simple, right?


Umm.. Yeah... Something like that. My configuration consists of a Sipura/Linksys/Cisco SPA-3102, the Asterisk server, and a collection of random VoIP phones around the house. By just moving the configurations from the old server to the new one, I was able to get the VoIP phones to talk to each other, along with being able to make outbound PSTN calls. This left me with three major headaches for the migration.

1. Calls from VoIP phones to the analog port on the SPA failed.
2. Inbound calls from PSTN->Asterisk weren't routed to the phones.
3. My custom AEL scripts to stop annoying people were broken.


Fixing #1 was pretty easy. The failure was coming from the fact that I had some events in the extension that couldn't be executed, so Asterisk would stop working through the list. (Or, in a nutshell, #3 was the cause of #1.) By changing the events back to a basic "ring the phone" list, this problem was solved.

#2 was a real pain. The solution was ultimately stupid/annoying. (Isn't it always!?) In the sip.conf file, I had "insecure=very" set in the [spa3k-pstn] configuration. It would seem this doesn't mean the same thing in 1.6 that it did in 1.4. Changing the line to "insecure=invite" resolved that problem, and allowed inbound calls to work once again.

#3 is an adventure I have not yet undertaken. Stay tuned...