A few days back Om told us about PhoneGnome and commented mostly about the box. Most of the follow up comments were about the novelty (or lack there of) of the box and mostly they have been dismissive. Even I commented on the box and only made passing comments about the service technology. I want to make that point to be the focus of this note just to make sure the emphasis is not lost.
If you recall, PhoneGnome uses the telephone number as the id for the VoIP account as well. Either explicitly or implicitly they are using ENUM technology. Since this can not be proprietary, their claims of patentability must be for the registration procedure. But others can use the scheme put forward by ENUM group, if they are different. I hope that Richard Stastny comments on this when he returns from his vacation. But I am digressing.
An understated assumption behind PhoneGnome is that PSTN service is very much viable for some time to come and certain VoIP providers are better off exploiting it during that time. What is interesting to note is that even incumbents can use this to fight against replacement service providers. Consider the following strategy. The incumbents offer PhoneGnome like service (David will have a fit if he were reading this – the claim is it is a product and not a service. But then I think he has finally granted it is a service.). It can allow multiple interconnect service providers, just like they have dial around service in PSTN and just like PhoneGnome does. The only difference is that now they will not be regulated and they can decide on access charges on their own. SkypeOut and Gizmo Project seem to argue that all you can eat plan is not as invincible as it was originally thought.
I am suggesting that the incumbents can continue to maintain their subscriber base, seem to offer VoIP service, but derive interconnect revenue just as in PSTN. In other words, if the incumbents were indeed dinosaurs, probably VoIP is not the rumored meteorite.
During December 2001, for the umpteenth time I was trying to convince a colleague that we should be focusing our attention on VoIP CPEs rather than softswitches and media gateways. For some reason (known, but not relevant now) the argument clicked and we agreed that I should develop my simple idea. The idea was that a caller will dial the standard phone number on a standard phone, which will be collected by this new device (he called it MaxBox). It will do its own analysis either on its own or by consulting a provider’s database to determine whether the call should be established either as a VoIP call or through the PSTN.
For the scheme to work, the important thing is to build the database that maps the standard telephone number to an URI. As I was devising a way to handle this, I came across the ideas behind ENUM. ENUM is precisely the thing I was looking for and a standard scheme is just good. Further readings on ENUM confirmed a problem that I stumbled upon: how to validate the user’s phone number? Of course it is simple to handle the initial condition. Simply require the user to register using both the interfaces and use the ANI information to confirm the valid telephone number. There are two problems with this approach. If the user is behind a PBX like environment, then we may not be able to get the valid telephone number. Also if the user changes the PSTN number for one reason or another and the old number is subsequently assigned to another user, it is possible that the new user may create a conflict. I concluded that both the cases can be handled only through human intervention and some form of identity confirmation.
There was another noteworthy problem that I had to overcome. To a large extent, the MaxBox is behaving like a PBX. What I mean is that it has two “trunk interfaces” – the PSTN line and the VoIP “line” – and has only one station. So it is natural to offer many of the standard telephony features. But unlike a PBX, the PSTN carrier may offer its own features on the PSTN line, but using only in-band signaling. So I have to be extra careful when I extend these features across both the interface. The example of call waiting will illustrate the feature interaction problem. Human factors considerations require that the user be presented a maximum of only two calls – one in talking state and one in held state. Since the PSTN does not know about the broadband interface, it will deliver a second call on the PSTN interface, irrespective of whether or not a call is taking place on the broadband interface. So it is possible that three calls may be in progress at any given time. I felt that allowing the user to cycle through the three calls will lead to confusion. So I required the Maxbox to intercept the call waiting tone on the PSTN interface if a call is in progress on the broadband interface.
MaxBox and PhoneGnome share many common objectives and features. But it is not clear how they overcome these two issues. (I didn’t plan on including voice mail or call blocking capabilities.)
There was one other feature that was planned for MaxBox that I am not sure whether the current version of PhoneGnome provides. Since the main objective of MaxBox was tariff avoidance, any non-toll call to a PSTN number will always be routed over the PSTN. In this respect, the database has to be more than the standard ENUM database.
If you are interested you can look up documents from that time. The following documents are available:
Additionally I had developed a mockup for the call logic. It can run on a Windows XP platform by downloading the zipped file (5 MB), expanding to a directory location. To run the mock up, open a command window, change the directory to the new location and type: tbsystem\tb85run.exe. In the Open File dialog box, select the file HGMockup under the directory HomeVoiceGateway. Enable the speaker to hear some sound effects. The instructions are under the Help menu.
Alternatively, you can copy the contents of the unzipped files under the Mockup directory to the root directory of a CD. The CD will autoload the program. In either case, no additional files are written to your computer.
After working on it for some 9 months, the partnership broke and I filed away the work. But PhoneGnome made me dust up the old files. If you would like to develop these ideas further I will be interested.
When some Vonage customers were dissatisfied with its service and tried to use Vonage supplied ATAs with alternate service providers, they realized that they could not provision the ATA to use the new service provider’s resources. This is similar to the situation in the cellular world, where the phone issued by one carrier can not be used with another carrier. Both the cases came to be known as “locked” devices, meaning the entity that subsidized the device locked it so that it can not be used with an alternate service provider. A few maverick service providers prided themselves in supplying “unlocked” ATAs.
But recently a new trend is emerging where some have hijacked the term to mean something else altogether. First Gizmo Project claimed that their soft client is “unlocked” because it can be used to reach any other SIP service provider (see the comment by Jeff Bonforte). It looks like PhoneGnome continues the trend by suggesting that it is also unlocked because its users can access any internet-to-phone service provider. But these are not the original definition of the term “unlocked” ATA.
What is in a name? Nothing, except when it is used to derive some positive attribute.
Om talks about a new VoIP adapter called PhoneGnome. Based on a quick look it seems to be an enhanced clone of Call-in-One adapter from SIPPhone. This device connects to PSTN and to broadband. With a standard phone connected to the device, one can make/receive calls from either. Neither TelEvolution (the company that is marketing PhoneGnome) nor Om compares it to Call-in-One.
So far, I have identified two additional capabilities that are not available in CIO – it has a built-in answering machine that can forward voice mail as an email and the other one is that it has a built-in call screener. Also you can select one of many interconnect provider. But it is not clear whether I could select different provider for different countries. For example, the rates to India by two of the providers listed in their web site are more expensive than AT&T PSTN rate I get (the link to the third provider does not load). But it is a step in the right direction.
I also have some questions that can be answered in the near future.
A few days back a new VoIP client, called Gizmo, was released claiming to be a Skype killer. This is closely associated with SIPPhone, which had earlier released another client called GAIM, an integrated IM and VoIP client.
First a summary of what one can do with Gizmo. It gives a nice UI to use the SIPPhone system. The first notable feature is the way it supports the voice mail. The system collects voice mail and then forwards to a specified email. This is in contrast to Skype, which hosts the messages. The second feature of note is the ability to record the conversation. Their website indicates that they have a partnership with Golbal IP Sound. Even though it is not stated on the nature of partnership, the consensus seems to be that Gizmo uses their wideband codec.
Then there are the standard set of features like call-logs and buddy lists. It also offers the ability to make and receive calls from PSTN. But the surprising thing is there is a price difference between Gizmo and SIPPhone – prices to some destinations are higher and others are lower. At least to India the charge is almost the same as what AT&T charges for PSTN customers. Given Skype’s difficulty with DTMF tones on a PSTN call, it will be interesting to know how Gizmo fares.
It is interesting to compare Gizmo to pulverCommunicator. Both are SIP based and both have plans to distribute to others with the ability to brand it. But pC has texting capability that is missing from Gizmo. Call-me link feature of pC is not widely discussed, but I hope Gizmo adds in a future release. pC does not support a wideband codec. But it can be unlocked and used with any other SIP based service. As far as I can determine Gizmo is locked to use only SIPPhone. This is from the company that sued Vonage for locking their ATAs. Have they gone native? In the same vein, I wish they supported Speex, an open source and loyalty free codec. (By the way I hope pC supports a wideband codec in the near future.)
A few days back I read about Jajah in a note written by Phil Wolff in Skype Journal. Based on that, when I visited Jajah’s website, some of the claims were outlandish. And when I read Om’s entry, I felt that we might have discussed this. (wink, wink). So I decided to elaborate on my thoughts, questioning some of the claims. As I searched for the exact references, lo and behold they were not to be found. Did I hallucinate reading these or they disappeared from the original site? I am not sure. What follows are some of the points I thought I read, but I can not locate them now.
But one amusing item is still available. It is the background story that is told via a press clipping. But there is no reference or even the date of publication. What is more, the accompanying picture seems to suggest that Bill Gates is listening to this mystic person very attentively. Is that supposed to mean something? If so, I am not sure what that is. Any currently I think the “founder” is not a real person, but a “Bourbaki”.
Given the changes, I am scaling back my total rejection. So here is a summary of Jajah. Like Skype and other IMs, the client is an integrated client that provides text, voice and video chat. The system is a P2P system (as if that bestows magical powers). They offer “Out” service. Some of the rates are much lower than available from other places. I hope it is not “an introductory offer”.
Of course I have neither installed nor used the client. People with more experience in usability aspects will eventually comment on it. But I have the same set of questions that I raised in reference to Skype: if I need to communicate with my buddies, why do I need to register with an entity and beholden to them? I am still rooting for Autonomous Communication.