skip to Main Content

Soft Phones: An Opportunity For Someone

<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:

Corey Andrews over at VoIP Supply also blogged a great summary of Free SIP Soft Phones a while back.. There are a couple on this list that look promising. I’m about to try both MizuPhone and Mirial.

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.

Talkshoe Live User interface

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>

This Post Has 18 Comments
  1. If you never tried them, please check our popular Firefox VoIP toolbar out.

    or our Windows deskbar downloadable at

    Great article, I think Counterpath is very well positioned to be the leader in this area. Developing a very well designed softphone is far from being easy (my company started in 1999) and approaching the market now is really very hard, unless you use pre-exihistent “bricks”, but it’s not cheap neither easy.


  2. Luca,

    Thanks for the comment. My frustration stems in part from soft phone vendors who only seek to mimic the PSTN. Leverage the advantages possible with VoIP. Implement things like standards-based wideband calling. That’s gotta be easier to do that video, and everyone seems to to want to implement video calling…that seldom gets used.

    I’m not even looking for free software. Not even free from a service provider. I’ll happily pay for a good soft phone. But I haven’t found one worth buying.

    Counterpath has been “well positioned” for years but seems unable to execute on that advantage. Seriously, most people I speak to about their wares are very frustrated.

    This space is wide open and ripe for someone with vision and passion to walk in and take it over. It could even be an open source project.

  3. Hello Michael,
    speaking as a softphone developer for OS X, I have to agree completely with much of what
    you have written. Our original motivation for developing a softphone was simply that we could
    not find one that suited our own needs.
    We are often questioned as to why we don’t implement the features other softphones have
    such as video or some PSTN features for example.
    Without trying to sell ourselves we prefer to concentrate on ideas that bring value to end users,
    by integrating with other applications like CRM, spreadsheets for example, existing address
    books, web calendars, automated messaging, MMS or synchronising with mobile phones as
    we have done recently.

    With the big mobile carriers moving towards free calls for all, the idea of a softphone just
    providing cheap telephone calls is redundant. If the phone is going to sit on a desktop it must
    integrate with the other applications the user is using, like email, browsers, CRM and other
    productivity applications. This is the value a softphone can provide that PSTN type phones

    Luca is correct some aspects of the development are expensive as we have faced challenges
    particularly for expensive royalties for codecs which are excessive in my opinion.

    I know you are a Windows user but if you would like to contact me I would be more than
    happy to discuss your ideas and show you some of the ideas we are working on.


  4. Thanks for the rant. We probably deserve it. Let me assure everybody that we do know about the issues and we are committed to resolving them in a timely manner.

    CounterPath will be incorporating G.722 into our 1Q09 retail release.

    The main G.722 issue that we have run into stems from a bug in RFC 1890 that erroneously assigned an 8kHz sampling rate to the anticipated 16kHz sampling rate. The result is an interoperability headache. It’s interesting to point out that CounterPath originally offered G.722 using a 16kHz sampling rate, and we discovered significant issues during interop with many of our customers who expected the RFC defined 8kHz sampling rate. So we decided to signal 8kHz per the RFC. Going forward we will support an option to support the 8kHz and 16kHz sampling rate.

    On the Mac, our intention is to provide a native, Cocoa application in 2009. This application will have much improved integration with other native applications. Again, we are very committed to capitalizing on our position in the market and we look forward to feedback from you and your readers. You can always reach me at jason at


  5. Jason,

    Thanks for dropping by and responding. I would think that you’ll need to interop test with the common wideband hard phones (Polycom, Cisco, snom, Avaya, Mitel, etc.) That should be easily accomplished through a public beta. That would allow your user base to test against their own hardware. I’d certainly volunteer.

    I look forward to the coming release.


  6. I’d encourage you to engage some of the user community and make the part of your process. This can result in a broad grass roots evangelical effort around your product.

    Many companies engage large corporate concerns for these are often thought easier to deal with. You might also go the other way and approach a select group of SMB VoIP users. There are some people on the VoIP Users Conference who would probably be helpful in this regard. Their community site is at


  7. Excellent choice of topica, Michael!

    It is true that I have been connecting to Talkshoe for two years using X-Lite almost exclusively. I have always liked it better than the other SIP softphones and I’ve tried most of them. It would be of interest to a lot of people on our Friday call to hear from Counterpath.

    X-Lite comes up on the #asterisk IRC channel and on the mailing lists when someone asks about a cheap solution to experiment with asterisk.


  8. […] Soft Phones: An Opportunity For Someone Picked up via Andy Abramson this rant by Michael Graves on the state of soft phones. There's no progres or revolution afoot here. Where I'd look is where I've been playing. There's a whole host of Twitter Apps that don't yet talk but manage many conversations in different ways. I think we will want to have this level of customization to personal needs and productivity in the future. I can see many different apps evolving. Escalation to voice will be one of the capabilities that is plugged in. These app developers shouldn't have to worry about how to do voice merely have a set of commands. These new dashboards will be much more effective and flexible than the IM and softphone clients that came before. (tags: voip) […]

  9. The wider range of codec availability will enhance interoperability with a variety of wideband capable devices. However, these specific codecs are not relevant to the more common Polycom SoundPoint IP Series deskphones. They use the older G.722 codec for wideband calls.

    Within the Polycom product range Siren7 & 14 appear in the larger conference systems.

    It would be nice to have a matrix so that we could easily look up which device or system uses which codec.

  10. It looks like the Soundstation IP 7000 ( awesome phone) and IP 6000 both support the siren codecs. Hopefully they might work (through freeswitch) with some softphones, like Miral which seems to support siren 14.

  11. I am using eyebeam 1.1 3007n stamp 17816, I am receiving RTP stream for a audio after 183 session in progress but eyebeam is not playing, can anybody tlel me the root cause of this issue?

Comments are closed.

Back To Top