Signal Quality

Skype recently created a pretty flimsy excuse for their outage last Thursday, blaming the outage on a statistically unlikely massive reboot of Windows systems after a Windows Update. While several blogs have their own take on the explanation, with some picking apart the explanation, to some coming up with possible, but elaborate ideas for what might have ‘really’ happened, the overall concensus is that no matter what actually happened, Skype really let people down.

The basic problem for this comes down to a desire on the part of Skype to control every aspect of their service from the basics, down to how every end user is allowed to connect. The Skype communications protocol, the basic way that Skype’s network works, is kept a complete secret, allowing them to charge licensing fees to anyone who wants to make hardware or software that runs on the network.  As opposed to an open communications protocol like SIP, however, this means that you rely on the Skype developers when it comes to choices about security, stability, and user-experience.

With SIP, if there were a major bug in the backbone of the system, as there was in Skype, the fact that everyone can see the SIP protocol and how it works lets far more people find solutions to potential problems long before they become an issue for millions of helpless subscribers.

This reliance on obscurity for the sake of security and control is Skype’s biggest achilles heel, and is what makes use of their protocol a danger to anyone relying on them for business or essential communications. While one can hope that they might learn something from this lesson, or that users might realise that perhaps Skype is not all it’s hyped up to be, only time will tell for sure.

Telephone conversations, while these days often taking place on mobile phones in public places, have often been considered to be, by many people, private conversations. Even when one person (or a whole crowded room) can hear half of a conversation, it’s not always readily apparent what the entire discourse is about.

This false sense of security has been the focal point of many a Hollywood film, often with the police, the government, or even the villains listening in and recording phone conversations through various methods. Traditional telephones are, after all, very easy to listen in on, as the technology behind them is exceedingly simple.

When cordless and early mobile phones became popular, this sort of listening in became even easier. Anyone with $30USD and a nearby Radio Shack could buy all the equipment he needed to hear the intimate conversations of his neighbors. A famous incident involving someone listening into phone conversations was one in which Prince Charles was overheard telling his mistress at the time, Camilla Parker Bowles, that he wished to be her tampon. The ease with which the conversation was overheard helped more people become aware of the inherent insecurity in phone conversations.

Since then, many mobile phones have gone digital and implemented several methods to help protect their users’ conversations from anyone trying to listen in. Conversations on mobile networks are interleaved and portions of the conversation are carried out on different, random channels to make it difficult to intercept any whole conversation as it flies through the air. They use this method of encryption to secure their calls.

There is an inherent flaw in these methods work, however: All data is disassembled and reassembled via a ‘trusted’ party (in this case, the mobile phone company). This is for the dual purpose of centralised management and ease of governmental wire-tapping. The phone company, then, is the ‘man in the middle’ who facilitates the security of the conversation. At any time, the phone company could choose to share the secure conversation with another third party, and in cases of police wire tapping, that’s exactly what’s done.

Enter into the equation VoIP (Voice over Internet Protocol). VoIP conversations, by their very nature, are more difficult for the layman to intercept, as they’re sent over the Internet as opposed to floating through the air or winding along wires as raw, unencrypted audio signals. It takes a little more expertise to tap into an Internet conversation and convert the data back into audio, but there is plenty of computer software available that takes the expertise out of the equation, allowing anyone to tap in and record if he can somehow find his way into the data stream. With Wi-Fi networks, this is quite easy, as all the data is just bouncing through the air.

It makes reasonable sense that VoIP, with its modern, technological origin, would have some sort of encryption built in that would make listening in on conversations more difficult, but in truth, encryption is still not always readily available in the VoIP world.

In VoIP, there are several issues to worry about. For one, if you’re using a VoIP phone to talk to a regular old landline or mobile phone, you run into the inherent limitations of both the traditional telephone network or the mobile phone network (as mentioned above). For another, while there are encryption methods available for VoIP calls, not many phones readily support them, and they each have their own flaws as well.

The major method of encrypting a VoIP conversation is called SRTP. The audio part of a VoIP phone call gets passed through the Internet using something called the RTP protocol (Real Time Transport). The S in SRTP stands for ’secure.’ SRTP works a lot like a secure web page works. A centralised authority hands the digital equivalent of a code word out to each phone, allowing the phones to encrypt their conversations back and forth. The centralised authority, often the VoIP provider itself, is considered to be a ‘trusted’ authority. However, there is still concern that such an authority could allow back-door access to a conversation to other people — governments or other authorities. It’s also possible that a particularly unscrupulous trusted authority could faciliate access to anyone it chooses.

This brings us to a different kind of encryption, ZRTP. ZRTP, created by Phil Zimmermann, the man who almost went to jail in the US for writing and openly sharing the high-powered encryption software, PGP, is a method of handling VoIP encryption without relying on a trusted authority in the middle. The phones themselves negotiate a secret code pair and share them with each other in a secure way, creating an encrypted conversation between the two phones. ZRTP uses a method of encryption called Diffie-Hellmann, which uses a public and private key encryption scheme. Each phone has a private code key and a public code key, and the only key ever shared is the public key. One end uses the public key to encrypt the conversation, and the other end uses its private key (unknown to anyone but him) to decrypt the conversation.

Diffie-Hellmann is an incredibly secure method of communication, that suffers only one weakness — a ‘man in the middle’ attack. The idea of a man in the middle attack is that someone COULD be in the middle of a conversation, intercepting all the calls and all the keys. He passes out his own keys to both sides, pretending to be the other person. He is able to decrypt and re-encrypt the conversation in both directions, thereby listening in to the entire conversation.

A man in the middle attack is a difficult thing to accomplish, but it’s possible, so one usually takes precautions such as sharing code words decided in advance, to ensure that the person you’re talking to is REALLY the person you expect to talk to on the other end.

The ZRTP code is freely available for anyone to use in his own software, and Zimmermann has also created ZFone, a program which encrypts the conversations from most popular VoIP softphones.

Unfortunately, VoIP hardware phones and PBX switches have yet to implement any form of ZRTP, so in order to use this newer, more secure communication method, you’re limited to VoIP to VoIP calls (remember, the limitations of traditional and mobile phone networks don’t allow for the same type of encryption yet) between other ZFone users on compatible VoIP networks (IdeaSIP, FWD, Gizmo Project, etc.)

There is simple no such thing as an unbreakable method of securing a phone call. Given enough time and enough resources, any encryption scheme could be broken. Strong encryption, however, is often impractical to break, and it’s usually much easier to rely on people and their misunderstanding of the privacy of their calls as the weak link in any security scheme. While, in this modern age of VoIP, one can still have a reasonably private conversation, secure in the knowledge that his intimate discussions won’t make it to the media, the best way to keep a secret is, and always will be, never to tell it to anyone.

While it still hasn’t reached mass acceptance, VoIP communication is rapidly insinuating itself into every facet of our daily lives. Many long-distance and calling-card providers have used VoIP to reduce costs for years now, and consumers are getting more and more choices for VoIP services every day. VoIP companies are springing up like Spring flowers, offering everything from inexpensive long-distance calling to quality phone features such as caller ID and voicemail.  It’s become quick, easy, and often free for a consumer to sign up to one of the thousands of available VoIP services like Skype, IdeaSIP, or Gizmo Project, and all the consumer needs is a broadband internet connection and the right hardware or software.

It seems only natural that the next big thing will be Wi-Fi VoIP. Wi-Fi phones and Wi-Fi-capable mobile phones  are beginning to crop up on the market from leading manufacturers such as Apple, Nokia, and Linksys. Some, like the Linksys and UTStarCom Wi-Fi phones offer only Wi-Fi-based VoIP, while others such as the Nokia and Apple iPhone offer both traditional mobile phone service, but also have Wi-Fi connectivity to allow connections to most VoIP providers directly without incurring mobile connectivity charges.

With the increasing prevalence of Wi-Fi hotspots, and the soon to appear WiMax zones covering entire cities, connecting to a VoIP company and bypassing usual cell charges whenever possible makes perfect sense; however, this terrifies the mobile companies, who see their revenue streams dropping over the course of the coming years.

In fact, it’s terrified mobile phone companies so much, that the underhanded tricks are beginning to appear in abundance.  Verizon has made the news lately by claiming patent ownership over the mere idea of using Wi-Fi VoIP phones to make phone calls, a fact that is likely to cause any number of providers that currently allow customers to connect via Wi-Fi VoIP phones to worry about repercussions. It seems the next logical step in VoIP, and that such a patents even exists is ludicrous, but it is still cause for real concern, as Vonage was recently found guilty of infringing upon this patent and ordered to pay $58 million USD in damages.

In the UK, Orange and Vodafone have gone so far as to require Nokia to remove VoIP capability from their N95 telephones in an effort to keep users from avoiding cell charges. This has caused somewhat of an uproar from customers, as Nokia clearly advertises the VoIP capability of its N95 handsets, and neither Orange nor Vodafone bother to mention to customers that such capability has been forcibly removed from their own versions of the N95 phones.

In the US, it’s almost impossible to find a mobile phone provider that has VoIP-capable phones available at all. Nokia’s VoIP-capable E61 PDA/phone, exceptionally popular in Europe, has an almost identical counterpart in the US (marketed by Cingular/AT&T) called the E62. It has all the same features, but no Wi-Fi capability at all, leaving the only Internet connectivity to be that which the cell provider allows through its own charged network.

Meanwhile, strictly Wi-Fi phones such as the Linksys WIP330 or the UTStarCom F3000, offer only limited performance, and have connectivity trouble when moving from Wi-Fi hotspot to Wi-Fi hotpot. Their inability to utilise a mobile cell network as a backup makes them of limited overall use for the moment except in offices or homes, where traditional VoIP-connected cordless phones might work just as well.

The technology is ready for Wi-Fi VoIP, and its popularity is guaranteed with price-conscious consumers, but there is still a considerably amount of pressure from mobile providers to keep the technology from reaching the populous.

While the news of Wi-Fi VoIP is bombarding the media, it still has significant hurdles to overcome before it is truly the next big thing.

You can’t escape the news these days about how Verizon is suing Vonage for patent infringement. Every week, there’s a new legal twist. The latest of these was that Verizon got the court to issue an injunction against Vonage, disallowing Vonage to sign up new customers. Vonage almost immediately got a stay on that injunction, so they’re back to where they were before — waiting for an appeal.

There are a lot of problems with this court case, and it’s very dear to my heart, since I run a VoIP company. How can Vonage be infringing on so many patents? Why is Verizon just now choosing to enforce them? What does this mean for the future of other VoIP companies? What are the patents involved, and why wasn’t Vonage given an option to license the technology instead of Verizon doing everything in its power simply to shut them down?

The answer to all of these questions is simple. The US Patent system is horribly, massively broken.

A brief look at how the patent system used to work:

You create an invention of some kind. You want to protect your rights, so you file for a patent. In the filing process, one of the requirements for you to receive a patent is that the information you provide must give step by step instructions and details to the point that anyone with materials and time and a little expertise could rebuild your invention from the patent. You are then granted an exclusive patent to this invention, and you can sell it or sell the idea to companies that are able to build it in mass quantities. If someone comes along and creates something that’s like your patented invention, you sue them for breach of patent, and either require them to pay you royalties, licensing fees, or simply require them to stop manufacturing the item.

Lawsuits are built into the patent process. In order to maintain your rights to your patent, you are required to ‘actively defend’ your patent. This means that, if you DON’T sue a company that’s making a device like yours, you are almost certain to lose your patent. As you can see, the patent offers you protection, but only protection to the point that you can police it. If you can’t afford the lawsuit, or you aren’t watching the marketplace like a hawk, or the company that’s infringing your patent is in a country that doesn’t care about your US patent, then your patent was, essentially, a huge waste of money.

For the most part, however, patents on objects are relatively easy to police. If an item comes out and is being marketed, it’s likely it will be marketed in the same segment as your item. You’ll see it on the shelves next to your device. You’ll see it in catalogs alongside your own. It’s easy enough to spot and track down so you can fight to save your rights.

The problem came, however, when the US Patent Office decided to allow method or process patents. Now, anyone can create a process in his head, using technology he may or may not have invented, and patent that process. For instance, I could try and patent the process of using a mouse to click on back and forward buttons on a web browser. As long as the process doesn’t currently exist, and the patent office clerk doing the filing is unaware of the technology in question, it’s very likely I will get my patent.

Suddenly, anyone who tries to create a web browser with forward and back buttons owes me money.

Now, if I try to sue Microsoft, for example, for using forward and back buttons on their Internet Explorer web browser, I’m liable to run into the problem of something called prior art. Microsoft is an enormous company, and has the legal power to crush my little claim. They will say that the concept of forward and back buttons has existed since the days before web browsers, and that my patent has no merit.

From this, we learn two lessons.  One, don’t make your patent easy to understand, and two, don’t target the rich companies first.

I should therefore create a process patent that is far more obtuse. Don’t mention forward and back buttons. Don’t mention web browsers. Make the patent more vague.  For instance, I should patent a system whereby navigation through a series of user-displayed screens and/or menus is facilitated by the local caching of content, allowing a user to proceed through pages or to previous pages more rapidly.

There. No mention of web browsers. No mention of forward and back buttons. And instantly, my idea is applicable not only to web browsers, but to any menuing system that has a back button. I added the little bit about local caching so that it will help explain the technology to the point that it looks like I’m giving a more concrete example. This sort of method patent is far more likely to make it through the patent system, and it gives me a distinct advantage.

My first lawsuit will be against the smallest mom and pop company I can find. They’re not liable to have enough money to fight me, and they’ll have to settle out of court.

As soon as I get a single company to settle, I win. This creates what’s called a precedent. Patent disputes with a precedent are far easier for judges to decide upon. They don’t need to really understand the technology (and face it, there are not a slew of technologically-savvy judges in the US legal system). They can simply rely on the added weight of the precedent to help them make their decision. Obviously, I won before, so I should win again.

My first five or six targets will be small shops that can’t afford the legal fees. Target anyone who might go out of business if he fought me, and anyone and everyone who used a menuing system in his software.  Once I gain a few decent precedents, I can start going after the larger companies with ease. It’s almost a given that a judge will side on the side of precedent, and with several precedents, it’s a no-brainer. It then becomes increasingly difficult and increasingly more expensive to fight against the patent holder, even if the patent is vague, has prior art, or the patent holder has ever made anything based on his own patent.

Enter the Verizon/Vonage patent lawsuit.

Verizon, one of the US’ only two remaining phone companies (AT&T, Verizon) is having trouble competing with Vonage. Verizon’s VoIP product is riddled with restrictions on usage, and their rates aren’t terribly competitive. To top it off, few people even know Verizon offers VoIP service. Their chosen service name is VoiceWing, which leaves most to wonder what it has to do with VoIP or Verizon. Vonage, on the other hand, is a well-known brand in the US. Their commercials, while horribly inane, certainly leave you knowing who they are.

Verizon simply can’t compete. The rule for competition in the US is, if you can’t compete, legislate your competition out of business.  Verizon tried this. Regulations from the FCC were passed (after heavy lobbying from AT&T and Verizon) that required Vonage to get all of their customers to sign a notice saying that it was understood that Vonage didn’t offer the same level of Emergency 911 services that a traditional land line offered. Regulations were passed to force Vonage to offer E911 service to all their customers, regardless of feasibility.  Vonage was almost shut down because it was given a ridiculously short time table to innovate, install, and verify new technology to allow E911 access for all its customers, but it made it over that hurdle.

It looked like Verizon would have to compete the traditional way after all, but they still had a trick or two up their sleeves. In order to stop Vonage once and for all, Verizon dragged up 7 rather vaguely-worded patents that might, in some way, apply to things Vonage is doing, and decided to sue Vonage for breach of patent. Yet again Vonage is on the brink of being shut down by a court order unless they can modify their technology to no longer fall under the patents.

The patents that Vonage was declared guilty of violating are vague to the point of being worthless, but they’re so convoluted that, having read them over and over, I still couldn’t tell you exactly what they are for. One of them talks about a method by which a telecommunications service can somehow be linked with a name or telephone number. This could refer to standard DNS, or it could be referring to ENUM, which is a way of linking telephone numbers to telephone or non-telephone services, or it could be referring to something that was a standard long before the patent in question existed, mapping a URI using DNS. Since the patent is both verbose and vague, it could very well be applied to all of these things.

Another of the patents allegedly infringed by Vonage was that of a method by which one uses a wireless phone to connect to talk over the internet.  No, I’m not making this up. While it seems pretty obvious that, given a VoIP network, one might want to use a phone without wires to talk over it, this was apparently a patented ‘idea’ granted in 2002.

And therein lies a problem for any number of VoIP companies. Wi-Fi VoIP-only or VoIP-capable phones have become a big thing lately. It really only makes sense that, given the growing availability of Wi-Fi, and the number of VoIP options, using a Wi-Fi phone to make VoIP calls is going to be huge.  Unfortunately, if Verizon gets its way, no one will be able to do that without either paying them money for ‘coming up with the idea.’ That is, if Verizon allows it at all. With its new found patent madness, it may simply disallow companies to use this technology if it doesn’t want them to be able to compete. IdeaSIP has several users that use Wi-Fi phones on our network. Will I be forced to block them because Verizon says they own the rights to the technology?

How about companies like Yahoo and MSN, which allow phone calls via their IM program? Technically, anyone using their IM on a wireless laptop is violating their patent. Where does the madness end? Will companies stop making Wi-Fi VoIP phones because of patent violation worries?

The allowance of process or method patents has become so rampant, that it’s even affecting new technology standards. There are few standards out there that someone hasn’t patented. Usually, the patent-holder is not the person who created the standard.  This was the case recently with Microsoft and its spate of XML-related patents, patenting everything from XML serialisation to XML conversions.  The XML standard was created as an open standard to encourage interoperability, and that a company would choose to patent changes to XML means that XML loses its standardisation and its very reason for being. More and more companies will have to worry about which parts of XML are and are not patented, and some may opt not to use it at all for fear of patent infringement reprisals.

In the VoIP world, this is happening all the time.  ENUM, a proposed standard for allowing easy interoperability between regular phones and Internet-based phone networks has been patented. That patent might fly in the face of Verizon’s earlier patent that vaguely describes a system that could be ENUM. Calling features get patented — like call return and call waiting.  Someone has a patent out there on using SIP to communicate with customer service people.  All of these patents are vague, process-related patents whose only real purpose appears to be patenting new standards so that, someday down the road, someone can come to collect rewards for technology they didn’t even create.

Innovation and standardisation go out the window (why standardise when someone else can patent your creation and force others to pay for it?), and consumers are left with fewer choices and less competition in the market. And this will continue to be the case until someone takes the brave step of completely overhauling and redoing the patent system — a daunting task, likely to bring lawyers and megacorporations screaming from their corners, ready to crush anyone who suggests an alternative to the current broken system.

In my last post, I talked about the disappointing performance of embedded Asterisk on a mini router.

Today, I’m going to discuss Trixbox (formerly Asterisk@home). Trixbox is a handy little open-source software package containing a combination ready-to-go linux install combined with an install of Asterisk with all the bells and whistles. It makes installing an Asterisk PBX as simple as it possibly can be. You take your Trixbox CD, drop it into the CD Rom drive of a machine, boot off the CD, and off goes the install.

After answering a couple of questions about a password and the timezone I’m in, the install adds all the necessary packages, reboots a few times while it does its work, and comes up running Asterisk. At this point, you can either log in via the console or, preferably, open up a web browser and point it at the newly-installed machine.

Coming from a background of installing Asterisk by hand and hand-editing the configuration files to do what I wanted and how I wanted, I’ll admit that the web-based interface was a little confusing. Documentation can be found online (and is extensive) , although there’s a trick to finding it from the interface which I found a little odd. You have to click on ‘Forums’ and it brings up an online page which includes a tab for documentation. That could have been labeled a little better (or had a direct link), but overall, I found the layout to be pretty good.

I would not, however, call the interface transparent. While there are several different interfaces combined into one (system configuration, recording management, etc), they all assume some Asterisk and phone knowledge, as the terms, layout, and configuration options are all Asterisk-specific. One couldn’t, for example, with no prior knowledge, load up Trixbox and have a phone system running in a matter of hours. It’s just not that simple.

With some careful reading, however, and if one uses all the resources of the internet available, it’s very easy to set up a basic running system to the point that you could then easily add or remove additional phones and users, work with voicemail, and configure some important features one would expect from a full phone system: conference calling and conference bridges, call waiting, call forwarding, do not disturb, call transfers, etc.

For those with Asterisk experience already, however, the experience can be frustrating. I’ll admit, I had to avoid the urge to uninstall the whole thing and just go back to my old ways of manually editing the config files. It would have been easier for me, but I was determined to understand the Trixbox solution, so I often forced myself to plod ahead.

As an install for a newer user, however, Trixbox comes wholly recommended. It takes the guesswork out of setting up a PBX either for home or at the office. Supporting large numbers of users would be a breeze with the web-based interface, and managing all the system files and configurations could be done by practically anyone with only a little bit of training.

I installed Trixbox at home, hooked it up to my IdeaSIP account using the instructions on the Asterisk@home wiki, and connected a device with an FXO port so that all my incoming PSTN calls go straight to my Asterisk box. From there, it determines whether or not I’m home or at the office by ringing first my local extensions, and then my remote extensions. If I’m nowhere to be found, and it’s during the day, it will forward off to my cell phone using my IdeasOUT minutes. If it’s night-time (sleep time), it just goes straight into voicemail.

And since I’ve become somewhat of a VoIP aficionado, and have many different VoIP-capable phones around the home, from the Snom phone to the wi-fi SIP phone to the ATA connected to my Uniden phones, I’m able to easily manage them all graphically with the Trixbox suite of interfaces. It’s quite effective.

The only real disappointment from Trixbox isn’t a Trixbox problem at all, really. It’s just that it requires a separate computer to use, and that means power, noise, space, and heat — something I’d been trying to avoid with the embedded asterisk install.

However, I can say that the whole suite works effectively enough that it’s worth investing in a small, shoebox-sized computer with a fanless power supply so at the very least I can keep space and noise down to a minimum.

If you’ve been thrilled with your VoIP account, but had been wondering what the next step might be in its evolution, I urge you to give Trixbox a try — for work or for home.

For those who’ve not yet explored the world of Asterisk, I urge you to do so. Asterisk is open-source PBX software that more and more large companies are using to replace their old, expensive, and often horribly antiquated PBX systems. Why spend $50,000 on a Lucent system when you could buy a nice server for $5000, and get the same or better performance with far more customisation options? You don’t, though, have to be a huge business to take advantage of what Asterisk has to offer. Many run it at home to use it for voicemail, home businesses, or give themselves for free some of the features for which the phone companies charge.
I was playing around a bit this past weekend with embedded Asterisk — Asterisk running on a small, hackable router capable of running one of the third-party firmwares like OpenWRT or DD-WRT. I’d noticed the Buffalo WHR-54GS was on sale, so I picked one up with the intention of building an Asterisk box for the home that would be small, quiet, and use very little power.

Storage space on the little routers is always a concern, and the WHR-54GS has very limited space (4MB Flash, 16MB RAM). Some of the newer models of these little routers have additional built-in memory, but some manufacturers, such as Linksys, actually use less memory on the newer models than the older ones, making it difficult to find just the right router for the job. Another concern, of course, is speed. Little home routers are relatively simple machines, and therefore don’t need much in the way of processing power. Few homes have enough computers to really slow these routers down, so they generally perform quite well for their assigned tasks.

The problem, however, comes when you install a third-party firmware on it and load the router up with additional software packages. Some of the packages available run brilliantly. Some of them do not, as the computing power inside the router simply isn’t enough to handle it.

I’d heard differing stories about running Asterisk on one of these little boxes, with some saying it’s the perfect way to create a miniature PBX server, and some saying that there’s simply no way that Asterisk can run effectively because there’s not enough processing speed.

Undaunted by the naysayers, I set about the task of replacing my router’s firmware (I chose OpenWRT for the task, but there are others available) . This proved to be the most difficult part of the undertaking, as Buffalo makes it difficult to replace the firmware on their routers. One can’t simply use the ‘Firmware Update’ portion of their routers because their firmware update program requires the firmware to be encrypted in a special way that’s either illegal or too difficult to duplicate. Replacing the firmware consisted of sending the new firmware via TFTP at just the right moment of a maintenance boot cycle. Hold the recessed reset button down. Pull out the power cord. Plug the cord back in. Initiate the transfer of the firmware. Release the reset button. The whole process takes more arms than I have, so it required significant juggling.

Once the firmware was updated, however, installing Asterisk was easy. There’s a web server built into the router to manage the features, and one page included an option to add additional software. Asterisk was one of the options, along with modules to handle voicemail, additional sounds, additional features, etc. I ran into a problem briefly in which I ran out of space to install one of the modules I’d wanted to install, but other than that, the rest of it was pretty easy.

Configuring Asterisk is a daunting experience for those who are unfamiliar with its idiosyncrasies, however, there are numerous help files available on the web, and since I was connecting to IdeaSIP, I just started off with the IdeaSIP instructions from the faq and worked from there to customise things.

In minutes, I had a functioning Asterisk server running.

Unfortunately, in testing the server’s ability to handle incoming, outgoing, and internally-transferred calls, I noticed that the performance of the little router simply wasn’t enough to handle the traffic. I could easily forward calls in to the phones and bounce calls out through IdeaSIP, but the signal was choppy, and there were numerous errors from its inability to keep up.

While there are slightly more powerful home routers out there on the market from which I could choose, none of them really seem to meet the minimum specs for Asterisk to be able to actually handle calls effectively.

Coming soon: My experiences wrangling TrixBox (a Linux/Asterisk install with all the gizmos and easy-to-use web-based management tools built-in)

This is something I wrote to the UTStarCom wi-fi phone forum.  You have to sign up for a support account and jump through hoops galore just to get to their forum, so I thought I’d share it openly as a sort of review.

In 10 words or less: Don’t buy it if you don’t have $200 to waste.

It holds promise, but it’s very far from a ‘working’ implementation.

It’s glitzy. It’s glamourous. The physical design of the phone is quite nice. I’m actually okay with the speaker volume (although volume controls for more than just ‘ringtone’ would be handy), but the rest of it, so far, has left me unenthusiastic.Issues so far:

1. WEP doesn’t work. I’ve tried it on numerous different kinds of wireless routers. 64 bit and 128 bit keys. No dice. When WEP is active, the phone simply doesn’t grab an IP and do what it’s supposed to. (while this might not matter to many, I live in a world where my network needs to be WEP to accomodate my WPA-less Sony AIBO that’s connected to my wireless network… that and there are many WEP networks out there that people might want to use).

2. Poor design on keepalive. Right now, the only way for the phone to keep a NAT connection alive is to reregister every X seconds in order to keep data going through the NAT tunnel so it doesn’t time out. This is a bit like thwarting modem timeouts by redialing/connecting/logging on every 60 seconds. SIP’s registration was NOT designed as a NAT keepalive, and to use it for such is a pretty poor hack. There are options requests, NAT pings, and various other methods (subscribe, notify, etc) which actually WERE designed more to keep a network connection alive, and which don’t require a reauthentication handshake every 60 seconds to keep a tunnel open.

3. Overall connection issues. Connecting and reconnecting to a wireless hotspot when going in and out of range is a bit like pulling teeth. UTStarCom advertises the wondrous nature of how their phone can roam from one AP to another without dropping a call, seamlessly and magically. In reality, I have a hard enough time connecting to ONE AP, much less taxing the poor phone’s logic to reconnect.

4. Features disappearing from spec. Downloadable ringtones? Downloadable wallpaper? These things just sort of vanished from the list of possibilities. Will they ever come back? Who can say…

5. Documentation. The documentation is about like looking at an API function reference. It’s a book filled with one or two line descriptions of each function, without examples, without anything detailed enough for the average user to know what logic was in the minds of the developers when they created feature X. While that may be just fine for someone buying a phone from a retailer who’s bundling it with a preconfigured service plan, for anyone else, it’s less than helpful.

6. Did I mention a lack of something as simple as onboard volume controls with granularity? Oh… wait… I did. Perhaps I just felt it needed to be reiterated. The idea that I can’t control the volume of any tones without altering some sort of global ring parameter is just… odd.

7. Logical mystery. I’ve seen the explanation of why the phone can’t be allowed to connect to SIP servers that have their SIP ports at, say, port 80, but as a former TCP developer, I’m somewhat astounded that there aren’t more people who balked at the poor explanation. If I connect to a SIP server at port 80, the connection has to come back to the phone’s port 80 and would hit the webserver? Does this mean I can’t send email from a machine running an email server, as return communications would hit the email server and not the client? Or run a web browser from a machine running a web server? That someone even suggested a user get a new provider because of this ridiculous limitation in the UA is laughably negligent. If I’d seen one of my developers give that line to ANYone, he’d have been fired on the spot. “I’m sorry, but this car only goes forward and reverse. It has no steering wheel. I recommend you only drive on roads that require no turns.”

Seriously…. this seems like it could potentially be a great phone, but either its limitations need to be taken seriously and overcome, or there needs to be more detailed and valid information about its limitations available somewhere so that future buyers can make the informed decision to go with another hardware provider.

I’ll keep mine on the off chance that someday it might actually be worth using (after all, since it was research to see if we wanted to bundle it with our services, it’s tax-deductible), but for now, it sits in the corner with the other hardware that didn’t live up to its promises.

The FCC announced yesterday that it will require all VoIP services that interconnect with the PSTN (traditional phone network) to pay into the Universal Service Fund that phone companies currently pay into. This decision came after considerable lobbying by the telecom industry complaining that the fees, which help to bring phone service and Internet access to rural customers, schools, and libraries, were only being paid by phone companies and not all VoIP providers. In response, the FCC has decided that all phone-like companies will pay into the USF, but at varying rates. The rates are based on rather wild speculations of how much long distance is used by the different kinds of providers. According to the FCC, cell phones are used the least for long distance (an estimation that is far from likely), followed by land lines, and then VoIP providers. VoIP providers are estimated as having double the amount of long distance as land line providers, meaning they would pay double the amount in Universal Service fees for each customer. The FCC has taken a ‘prove us wrong’ approach saying that VoIP providers may gradually lower their contributions if they can provide exhaustive research to show that the FCC’s speculation is incorrect.

The real smoke and mirrors is about who gets the money. The telecom companies have been very slow to roll out broadband access in rural markets, and many government regulations forbid the use of VoIP services in schools. What this means is that, the Universal Service Fund, which goes to schools and rural areas to help fund Internet access and phone access, goes back to the telecom companies, who by current regulations, have to pay the least into the fund. Essentially, this is a system by which the telecom companies’ competitors help boost the telecom companies’ revenues.

With a drastic disparity in USF pay-in, and the low availability of VoIP for the USF’s primary beneficiaries, VoIP companies will have to pay more for little benefit to themselves, and telecom companies will pay less and get a good portion of that money back from the people to whom it is actually given as a subsidy.

It’s a good scam if you’re a telecom company.

Microsoft pushed an automatic update yesterday (they say only to randomly-targetted machines, but in a network of 60 machines, all 60 got the update) that pops up warning messages and places a permanent banner across your machine if you’re running a copy of Windows that hasn’t been validated as genuine by Microsoft. This is their latest attempt at getting pirate users of Windows to upgrade, but tactics like these — installing software that in no way secures the system as a hidden ’security’ update are going to make many people think twice about leaving automatic updates running on their Windows machines. This will result in more Windows machines that go unpatched, leaving far more spam bots and virus passers around on the Internet.

Microsoft’s original claim was that their Genuine Validation program would be to help reduce the number of computers out there that were a security risk (no one believe that claim back then, either). Now, they’re clearly showing a propensity toward increasing the number of vulnerable machines that fall under the control of hackers and spammers.

With Vista around the corner, even those without valid copies of Windows may be hesitant to spend an obscene amount on an operating system that will be phased out in less than a year’s time, so the incentive for people to move to non-pirate copies will descrease. This latest attempt by Microsoft is simply to keep the money rolling in at the expense of what they claim are millions of people who are unwittingly running illegitimate copies of Windows.

Jeff Pulver, founder of Pulver Communications and Free World Dialup, has posted a rather novel Petition to the FCC. It asks for a temporary easing of restrictions covering VoIP in times of emergencies. The background of this goes to the Hurricane Katrina disaster and what happened to communications during and after.  Wireline phones ceased to be a viable method of communication, as many of the homes were underwater, lines were cut, and even cell towers were knocked out of commission by the hundreds.

The saviour for the relief organisations, the government workers, and the refugees was VoIP. Companies came in and created a wireless VoIP network for people to use in order to maintain communications, allowing refugees to maintain contact with their loved ones and even gave them free voicemail to get urgent messages.  The wireline providers, however, did no such thing, and were proven to be a disasterous single point of failure.

The FCC, however, has severley hamstringed VoIP providers with regulations disallowing numerous things such as porting a phone number to an area outside its original geographical location, easily interconnecting with the PSTN (traditional phone network), and has even cited safety concerns as their reason for limiting to whom VoIP can even market. Many of these regulations have been politically mandated, with the big telecom lobbyists pushing hard to get them in place.
The petition asks for these regulations to be relaxed during times of emergency to ensure that we’re no longer left in a situation where politics dictates that we must all be without  communications for the sake of not hurting the business of the telecoms who aren’t actually physically able to provide service.

It’s a good first step, really. It’s hard to deny the role that VoIP played in helping with Katrina, and it’s shameful to think that the FCC would deny an emergency provision to allow an easing of restrictrions when it’s absolutely necessary. And, of course, if they recognise that VoIP is truly essential in times of emergency, it helps negate their argument that VoIP is inherently dangerous for people to use and requires strict regulations to keep people safe.