GIPS Comments On G.722

Not long ago Dr. Jan Linden, V.P. Of Engineering at GIPS, wrote a really good blog post called G.722 Revisited. In it he considers the trend toward the use of G.722 in the rollout of new wideband telephony projects.

Dr. Linden collected a nice stable of facts in making his points regarding the use of G.722. It’s simply old and less than optimal for use over IP networks. It’s not as bandwidth efficient as many of the new codecs, resulting is lower call quality for a given data-rate. He points to a 2007 study of ITU standard wideband codecs that is quite clear that G.722 is back-of-the-pack from a pure performance perspective.

The post is a great collection of information and he is absolutely correct in making all of his points. But I think that there may be more to it than the argument he lays out, strong though it may be.

It’s true that there are a wide variety of technical advances that have come along in the 20+ years since G.722 was introduced. The list of advancements is very impressive:

  • More efficient coding techniques yielding better quality/kbps
  • Packet loss concealment techniques
  • More intelligent jitter buffering
  • Forward error correction (redundancy in the datastream)
  • Possible backward compatibility with legacy codecs
  • Data rates adaptive to network conditions

However, many of the more modern codecs, with all their advantages, face other hurdles in the realm of intellectual property rights, aka IPR.

As the telecom world as a whole considers wideband telephony there appears to be some tacit acceptance that, lacking for one clear codec of choice across all networks and platforms, vendors may be forced to implement a small number of codecs. While no-one in the hardware business wants to implement more than a fraction of the diverse range of codecs available, there is even greater reluctance to live with the kind of licensing headaches that the industry has faced with various proprietary legacy codecs like G.729a. This very reality is a significant part of the fuel that keeps the fires burning in the ongoing codec debates.

Not all complexity is technological. Sometimes it’s legal. Both represent significant hurdles to progress.

Yet, week after week people are making growing use of wideband voice based upon the availability of G.722 in various end-points and services. The VoIP Users Conference has met just about every week this year using the ZipDX wideband bridge, using lame old G.722. Admittedly, we’re enthusiasts, yet in some strange way we find ourselves on the vanguard of this issue. Some in-the-know people have noted that our VUC conferences are the single most public example of wideband telephony in routine use in North America.

When we started using ZipDX it was to be a one-time thing in November 2008. There were only a few of us with G.722 capable phones. As I recall we had about 12-14 on the wideband bridge that day. Around half were only able to join in wideband because ZipDX was gracious enough to gift us some OEM licenses for Counterpath’s G.722 capable Eyebeam soft phone.

In the months that have followed our use of the wideband bridge has grown considerably. In recent gatherings we have had  as many as 30 people on the wideband bridge, more than the number of people joining using the G.711 Talkshoe bridge. The VUC calls have given our group a reason to own wideband capable systems. This has driven a large portion of our group to acquire suitably capable end-points. Some use soft phones, but many have purchased hardware. They’re voting for wideband, even G.722 based wideband, with their wallets.

From the perspective of a podcaster the wideband bridge has been tremendous. It allows us to offer our calls as recordings in dramatically better quality than was previously possible.

The simple fact is that the primary benefits of wideband can be realized using G.722. It might be less than ideal in many ways, but that might not matter in many circumstances.  Our weekly meetings prove that it’s more than just workable, it’s desirable. We don’t routinely suffer problems of packet loss, bandwidth constraint, or uncontrolled jitter.

We more often suffer the presence of Darth Vader…in wideband! It seems that in glorious wideband audio conference etiquette is even more of an issue. We are constantly reminding folks to mute themselves, either locally on their phones or by using *6, which seems to be the universal command for mute/unmute on conference bridges.

For all it’s faults, G.722 is serving us well. The fact is that we have G.722 capable phones from a variety of manufacturers including; Avaya, Cisco, Gigaset, Mitel, Nortel, Polycom and Snom, with Aastra announcing their support recently. Even lesser names like Grandstream and Yealink are getting into the game with G.722 capable offerings. Then add to that the fact that G.722 is embedded in the CATiq specifications, and that technology had been adopted by Cable Labs for inclusion in a new generation of CableCo CPE.

Very recently Tim Panton of Phone From Here has an experimental implementation of a Java soft phone that runs in a web browser and is G.722 capable. Over the past couple of weeks I’ve been using this to have an associate working at a customer site in Montreal call me in my office in Houston. He just gets online with his laptop and visits a web address, the call is placed automatically, ringing my Polycom phones by SIP URI. We have the advantage of bone fide wideband audio and don’t suffer the cellular coverage at his location, or the roaming and long distance charges of using his US issued cell phone in Canada.

I’ve been very happily surprised at just how well the Phone From Here Java soft phone works. I expected there would be problems because of network unknowns, but it’s been very good. Tim did comment that G.722 was a “fairly brain dead” codec. It’s very simplicity worked in his favor when creating a Java-based implementation. I have to commend Tim for the effort and a job well done.

Given all of the above there is certainly a lot of momentum behind the application of G.722 in real-world installations today. In enterprise and consumer voip-space G.722 is exposing people to wideband telephony right now.

The mobile network operators face perhaps the most demanding technical operating environments, and so need more bandwidth efficient coding schemes. The 3GPP group has already standardized upon AMR-WB (aka G.722.2) for GSM related networks, while the CDMA derived networks are moving in the direction of EVRC-WB. That very difference of opinion dictates that there will be transcoding.

Even today most cell phone calls are transcoded, often more than once. The call from the handset to the tower might be AMR, but at the local cell site it gets transcoded to G.711 for backhaul on the carriers wireline network. If the call is to another cell phone it most definitely gets transcoded back to AMR or EVRC at the far end cell site.

Given the reality of the mobile operators it has long been my impression that the very best we could do was arrive at a small set of codecs in common use when the dust settles. Perhaps as few as two or three if we’re lucky.

For the moment, the massive and growing installed base of G.722 capable devices is a resource to be tapped. Over time we may find that it falls into disfavor. When all facets of telecom are actively deploying wideband solutions a more advanced codec may rise to the top, and bring will it all the advantages that Dr Linden desires. I look forward to that day. But for the moment I will carry on using G.722 where I can, and continue enjoying the very real benefits of wideband telephony.

If we simply wait for the future to come then I suspect it will look remarkably like a shabbier version of the present. So let us press on extolling the benefits of wideband telephony, even if it is for the moment based on that venerable old codec…G.722.

Jan Linden
  • rod178

    Why not Speex?
    No ip issues and far superior in performance to g722.

    • It’s a good question and it comes up often. Simply put, hardware manufacturers are reluctant to use open source codecs. They fear law suits over IPR. It’s not enough to say that “there are no IPR issues.” It needs to be proven, possibly even tested in court, or some form of indemnification made available. Otherwise the first major company to use the technology could face a law suit. That law suit would be the test case for the IPR issue, but the one company in question would bear the sole cost of fighting that battle. It could be just a nuisance suit, but it may still be very costly and potentially damaging.

      If you look around at the codec landscape you’ll find that the popular ones are those that were once patent protected, but where such time has lapsed that the patents have expired. This means that the IPR question is definitely answered. They (large manufacturers) know who held the IPR and that it’s no longer an issue. This is why G.722 remains a viable codec option even today.

      FWIW, even when a company licenses G.729 for use in their products VoiceAge does not provide comprehensive indemnification against legal proceedings. I’m told that they cannot because not all of the IPR holders belong to the patent pool that the represent.

      This appears to be why Speex (and CELT) simply don’t make significant inroads in hardware implementations.

  • Then why don’t the phone vendors publish the specs to make it possible for third parties to add codecs as software modules? The vendors don’t have to take the risk, and they increase the value of their phones.

    • It’d be very difficult from them to do this based upon their hardware platform and development environment. It would be easiest for a company like snom who bases their product on an embedded Linux. Even then there seems to be little interest in third party firmware additions.

      Plus, there’s more to deploying a codec than the software implementation of the codec itself. There may be optimizations elsewhere in the device that are required to make use of the codec. Witness what Aastra calls Hi-Q, which is G.722 implemented along side DSP-based enhancements to compensate for the standard issue transducers.