<RANT> Let’s face it, the soft phone segment of VoIP space is stagnant. There’s been little change in literally years. I’ve spent the past six months looking for a Windows soft phone that was G.722 capable. In the course of my search I’ve tried a number of soft phones. The list is getting lengthy:
- Counterpath’s X-Lite (Free edtion)
- Counterpath’s Eyebeam (Retail edtion)
- Counterpath’s Eyebeam (OEM edtion)
- Ekiga for Windows
- EyePMedia Communicator
- Pulver Communicator
- Freshtel’s Firefly
- SJ Labs SJPhone
- QuteCOM (Formerly OpenWengoPhone)
Here’s the thing. Very few of these programs support G.722 wideband audio. Yet G.722 is the baseline codec that shows up in wideband capable hardware. It’s a long established, royalty free codec.
Counterpath kinda supports G.722 in Eyebeam. But only the OEM version that they don’t sell to mere mortals online. Even then a company purchasing OEM licenses has to option the codec into the software. And then it’s only available in the PC version. Not the Mac version.
David Frankel at ZipDX was kind enough to provide me a license to further some experimentation with wideband voice. He licensed the OEM version of Eyebeam from Counterpath with G.722 since his company provides wideband conference services.
In some rudimentary testing it became very obvious that Counterpath’s G.722 implementation is at best flawed. With Eyebeam I can connect to a wideband conference bridge and the calls are great. However, any attempt to call directly between Eyebeam and my Polycom or Siemens phones has trouble.
To be more specific there is no audio from Eyebeam to the hard phone. The time stamps in the RTP stream from Eyebeam are wrong. They’re based upon a flawed practice in the RFC defining G.722. They indicate that the sample stream is 8KHz when in fact it’s 16KHz. The fact of the RFC confusion causes considerable interoperability trouble.
In practice it really shouldn’t be a big problem. The RFC specifies clearly that there was an error in an earlier RFC and it perpetuates that error for sake of backward compatibility. What developers need to do is adapt their code to deal with both cases successfully. It’s not that complicated.
One thing is certain. It’s not enough to state, “We’re RFC compliant” and think that you’re done. That’s a cop out. Your software needs to interoperate with hardware phones or the scope of your target market is considerably reduced.
In preparing for the Nov 7 VUC call on wideband telephony (mp3) we stumbled upon another interesting fact. Eyebeam doesn’t work with screen reader software. One of the participants on the call is blind and uses a screen reader to navigate through software. Eyebeam, and most other soft phones, put a lot of effort into appearance. They’re skinable at least in part so that the vendors can package them up custom branded for sale to other companies. All that focus on graphics defeats the screen readers. Perhaps there’s an opportunity for someone to make an ADA compliant soft phone?
The open source QuteCOM looks like it suffers the RTP time stamp issue as well. It’s based on the Verona library so perhaps there’s a chance that it could get fixed. It’s unclear what motivation might be required to get the developers attention.
QuteCOM also supports G.722.2 (AMR-WB) which provides wideband at lower network bit rates. AMR-WB is the codec of choice for cellular carriers as they move forward with wideband telephony. It’s lower bit rates conserve precious wireless bandwidth, enhancing the carriers network capacity.
Mirial looks interesting. It supposedly supports G.722.1 Annex C which is Polycom’s Siren 14 super wideband codec. Sadly, that only comes into play with larger teleconferencing systems, not the more common SoundPoint IP phones. Mirial doesn’t appear to support G.722 at all.
The larger players like Nortel, Avaya & Cisco don’t sell their soft phone products standalone. They generally come as part of a Unified Communication Suite, which means it’s a supporting aspect of a high $$$ installation.
No, the simple fact is that soft phones as a product category are languishing. “Counterpath has an enviable incumbency in the PC soft-phone market” according to Wirevolution’s Michael Stanford. Yet with all the frustration I’ve found as I’ve investigated this area these past months I’d suggest that they’re simply the best of a bad lot.
Soft phones, like so much of VoIP, have stalled at a point where they typically mimic the common phone functions but don’t do anything truly innovative. Some do call recording, but we were doing that with Radio Shack suction cup sticky induction loops and cheap cassette recorders back in the 1980s.
Yes, some do desktop video conferencing. So what! Of Skype’s 14 million online users how many use video calling? A trivially small number, although I accept it’s growing slowly with the adoption of services like Sightspeed and ooVoo. There’s still a big difference between telepresence and common desktop video conferencing.
And yet we do face new frontiers in telephony. Has anyone noticed how much traction wideband has been getting the past few months?
Call it HDVoice, HDVoIP, KLARVoice or whatever you like. Polycom released their Siren codec (G.722.1) under a royalty free licensing scheme. They also have a new, lower cost wideband capable phone in the SoundPoint IP450. Audio Codes is weaving wideband into all their products and introducing a new line of wideband capable phones. snom’s new model 820 is a beautiful new wideband capable device, and they’re made it possible to refit all the existing 3×0 models to wideband.
On the VUC call Nov 7 we sampled wideband as a group (mp3 link), and I for one was hooked. Of course there are issues attached to this. In moving to wideband calls need to be IP end-to-end, bypassing the PSTN altogether. All this is just more incentive to move toward the use of SIP URIs.
Shortly thereafter our tireless host Randulo found out that Talkshoe is working on migrating to a wideband capable conference bridge. This brings to mind a number of things and points to the potential opportunity in the soft phone space.
Talkshoe conferences can be joined in a variety of ways. Some will use the Shoe Phone built into the web based chat client to stream one-way audio. It’s just a Java applet. Others will use the Shoe Phone Live, which is a similar Java/Browser-based client that acts as a soft phone plug-in, no installation required. Yet another group will prefer an installable soft phone client that’s compatible with Talkshoe. I’ve used X-Lite in the narrowband past. Finally, some, like me, will prefer to use real hardware IP phones.
The fact is that three of these four connect methods could be supported in a soft phone type of product. If Verona gets its G.722 interoperability issues resolved then Veronix, an ActiveX implementation of the library, would make a browser-based plug-in a relatively simple task. One presumes that if it can be done using MS ActiveX then it would be equally possible using an approach that was more cross-browser compatible.
Or perhaps it’s an opportunity for someone using Adobe’s new AIR platform, which has newfound VoIP capabilities. Or some kind of voice enabled Web 2.0 mash-up? This is but one possible commercial example of the need for a voice enabled application.
So, the question is, who will grab the opportunity of this moment in time and claim the throne as the new king of soft phones? There’s clearly an opening. The natives are restless and the king is asleep in the chair. </RANT>