atom feed1 message in G.729 Codec
FromSent OnAttachments
Matthew RubensteinApr 2, 2007 10:55 am 
Subject:Using G.729 Codec
From:Matthew Rubenstein (
Date:Apr 2, 2007 10:55:55 am

I read with interest bug #176, "support for g729", at . I work with the Asterisk PBX, and I can offer some insight into how SIP-Commuicator can support G.729 without violating legal constraints on either SIP-Communicator or G.729 .

G.729 is a patented codec algorithm. That means that any software that encodes data into G.729 format, or that decodes G.729-encoded data into any other format, must operate under an explicit license originating in the G.729 patent holder. It's not clear (in murky US patent/DMCA/whatever law) whether you are prohibited from writing and operating code that implements a G.729 codec (either/both encode and/or decode) *if you do not distribute it, and do not derive any commercial gain from it*. In other words, research and education *of yourself* are commonly believed to be safe, even if you do not have a license to do so. This freedom might not be protected by law - I am not a lawyer, and I don't know of any actual court cases, especially under the G.729 patent - but the practice is widespread, specifically with G.729 codecs. In other words, the audio processing community "conventional wisdom" that is being used by many developers and researchers around the world says that it's OK to do R&D by writing and testing G.729 codecs without a patent license.

The patent is separate from the code. There are several "reference implementations" of G.729 codecs in executable code distributed as source code. There are various licenses that come with those code samples. Intel, for example, offers a code package that is widely used, but which prohibits use in commercial applications. There are a few other restrictions on the Intel code, but it is expressly supplied for R&D, and used as such fairly widely. Other implementations are offered with similar freedom for R&D. Again, they are covered under copyright restrictions, which are independent (and in addition to) the patent license restrictions.

If you want to use someone's codec, even a commercially available binary codec, you also need to have a license originating in the patent holder. Code offered commercially for execution in commercial environments usually (always, AFAIK) comes with a patent license. Sometimes those licenses are expensive, especially for multiple concurrent instances of a running codec (the terms under which the patent license is usually offered). However, Digium (the company that produces and publishes the fairly open-source Asterisk PBX) sells G.729 codecs, with patent licenses they relicense from the patent holder, for the lowest price I know. It's $10 per concurrent stream (ie, 2 streams for a typical 2-person phonecall means 2 codecs means $20 in licenses). The money pays for the license, and compensates Digium (which it also invests in its other operations, including open Asterisk development). There are other relicense sources, but they're all more expensive than buying them from Digium, except at large numbers of concurrent streams/codecs (eg. 10,000 or so, maybe fewer).

I would recommend SIP-Communicator operate in this Intellectual Property environment in the following manner: Code SIP-Communicator with an interface for *any* codec as a module, including G.729, the generic G.711, maybe GSM or some other popular codecs, all with the single "codec" API. Developers can use the Intel or other reference code in R&D to develop the API, as long as they do not distribute the G.729 code they used in violation of its copyright license (eg. noncommercial). Offer G.729 as an addon module. Then, with some finesse, perhaps the project (or someone using the project's products) can make a deal with Digium or some patent relicenser to bundle a licensed G.729 executable for a $fee, or include in an installer script an online ecommerce transaction for purchasing licenses for bundled code, etc. The optional G.729 codec can be the kind of option that distinguishes commercial installs from noncommercial. I recommend using Asterisk's G.729 inclusion techniques as a model: .

It's worth it, because G.729 is high quality for the low bandwidth, and is very popular with VoIP/PSTN gateways, and very widely supported in terminals (which means minimal transcoding, therefore maximal performance). Some gateways, especially those with low per-minute prices (and small minimum minutes committments), require G.729 to connect. So including some way for SIP-Communicator to use G.729, despite the patent/license hurdles, is a very valuable feature. I hope I can help this project to achieve that goal.