[dispatch] IETF "Royalty-Free" codecs

"Michael Ramalho (mramalho)" <mramalho@cisco.com> Mon, 01 June 2009 21:18 UTC

Return-Path: <mramalho@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F623A6B9A for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 14:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jrEQGzwTyqg for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 14:18:25 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E29F83A692E for <dispatch@ietf.org>; Mon, 1 Jun 2009 14:18:24 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.41,286,1241395200"; d="scan'208,217"; a="45794809"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2009 21:18:24 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n51LIORu008407 for <dispatch@ietf.org>; Mon, 1 Jun 2009 17:18:24 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n51LIO3O029964 for <dispatch@ietf.org>; Mon, 1 Jun 2009 21:18:24 GMT
Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jun 2009 17:18:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E2FE.7F85F402"
Date: Mon, 01 Jun 2009 17:18:47 -0400
Message-ID: <AA847E176042A54CBB8BA283835E7BCEDEB92D@xmb-rtp-219.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IETF "Royalty-Free" codecs
Thread-Index: Acni/oz+T97fyHVwSuKgma6uS9Zeqg==
X-Priority: 5
Priority: Non-Urgent
Importance: low
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: dispatch@ietf.org
X-OriginalArrivalTime: 01 Jun 2009 21:18:24.0728 (UTC) FILETIME=[7F9C2580:01C9E2FE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24760; t=1243891104; x=1244755104; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20<mramalho@c isco.com> |Subject:=20IETF=20=22Royalty-Free=22=20codecs |Sender:=20 |To:=20<dispatch@ietf.org>; bh=I5yyf7XQnGwFWzlwgxYMQOF/J51LLTlmGEyt97mGRWc=; b=XvJFhG+qWuECiXcIFTTQJ+qf6qhKKi9dfGGkefjcYqHh+CGhFzEdhhWdZj Il+erb8ZELPxBpxacULSZuUkIoEWLgrcV+Cr1MOAKYcVsvInJyAbouqXxO3P DVt87lSleu;
Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Mailman-Approved-At: Mon, 01 Jun 2009 14:23:10 -0700
Subject: [dispatch] IETF "Royalty-Free" codecs
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2009 21:18:34 -0000

All, 

 

I have read, with some interest and comment, Jason Fischl's email
proposing a working group for codec development that would produce a
"royalty-free" codec designed "specifically for the Internet".

 

While one cannot always know if there is IPR "lurking" in something that
someone has built (i.e., an "unknowing" infringement on a 3rd party
right), the goal of designing a codec with "old or otherwise
unencumbered" technology is an idea worth pursuing.

 

I do note, as Roni Even did, that most of the of the "codec expertise"
resides in other SDO groups (such as ITU-T SG16, and ETSI). Most of
those subject matter experts are represented by companies that also
participate in the IEFT.

 

I also remember that AVT has been down this road before with iLBC (the
result being an EXPERIMENTAL RFC  - not a standards track RFC).

 

However, I have explicitly noted that other SDO groups such as ITU-T
SG16 have NO APPARENT INTEREST in developing a "royalty-free" designs.
In my observation the ITU-T SG16 tends to focus on bringing the "best
technology" from participating members to create a codec that meets a
given goal (specified by a Terms of Reference, ToR, document). Since the
requirements are written from the perspective of what "new technology
can do", they have the tendency to rule out "old/known/existing"
technology.

 

Thus, it doesn't appear to me that the ITU-T or similar groups would
even strive to have a goal of "royalty-free" as a codec design criteria.
And that is OK, given the way they operate. They produce high-quality
results for the work they perform.

 

Additionally, some SDOs explicitly request that  "royalty", or
"royalty-free" statements NOT be made at their meetings except in a
narrow-context of what their company position is given the SDOs IPR
policy. In other words, detailed discussion of the IPR dimensions of the
work are not to be discussed when developing the codec.

 

So  given:

 

Given 1: There are a bunch of folks that desire to specify a codec that
does not KNOWINGLY infringe on IPR/patents (perhaps by using "old or
previously disclosed" technology),

 

Given 2: That no SDO organization that I know of that works on codec
issues explicitly allows the discussion of specific IPR issues or
"royalties" in their meetings, and

 

Given 3: That some IETF participants desire a codec that does not
KNOWINGLY infringe on IPR and can be made "royalty-free" (except for
potentially lurking IPR).

 

The questions (for me) become:

 

Question 1: Where is such work to be performed?

 

Corollary Question 1: Does anyone know of a SDO that would allow for the
criteria of "no known IPR" in the design?

 

Question 2: Assuming that the IETF would allow such a "royalty-free"
criteria and that this work COULD be performed here, are there enough
"qualified people" in the IETF to perform such work?

 

I don't know the answers to the above, but I would be interested in this
work.

 

Regardds,

 

Michael A. Ramalho, Ph.D.

 

<Jason's initial email on dispatch@ietf.org follows>

 

All,

 

I would like to request agenda time inside the DISPATCH meeting to
propose

the formation of a new working group to define a Proposed Standard
wideband

audio codec.

 

The text of the proposal is below. Comments, questions, and suggestions

welcomed.

 

Regards, 

Jason

 

 

Internet Wideband Audio Codec (IWAC)

Mailing Lists: TBD

Chairs: TBD

Area Directorate: Real Time Applications (RAI)

 

Purpose:

 

This new working group would be chartered with the purpose of collecting

expertise within the IETF in order to review the design of audio codecs

specifically for use with the Internet. Unlike other SDOs, these codecs

would be optimized for use on the Internet, and as much as possible
choose

technology that does not require paying patent royalties.

 

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was
felt

that subsequent work should not be done in the AVT working group. This
new

working group will have as its primary purpose the standardization of a

multi-purpose audio codec that can be used in various situations on the

Internet. Some of the proposed Internet-specific requirements include:

* scalable and adaptive bit rate;

* various sampling rate profiles from narrow-band to super-wideband;

* scalable complexity;

* low latency; and 

* resilience to packet loss.

 

There are a number of wide-band capable codecs defined by other SDOs.
For

instance, G.722 is seeing adoption in Enterprise applications since it
is

relatively simple and low-cost to deploy. However, it has a high, fixed

bitrate and is not appropriate for mobile applications where spectrum

efficiency is important or in consumer applications where available

bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been
adopted

by the 3GPP as a wideband standard for mobile applications. G.722.2 is

relatively high cost due to patent royalties and is seeing minimal

deployments outside of mobile handsets making it challenging to create

wideband experiences on Internet-capable mobile devices when extending

beyond the mobile network. In other cases, proprietary codecs are being

adopted which further create islands with no interoperability unless

widespread transcoding is performed. Transcoding leads to higher costs
and

lower quality. 

 

The goal of this working group is to define a single codec with multiple

profiles which can be made available on a wide variety of
Internet-capable

devices including low-power, mobile devices as well as devices capable
of

utilizing high quality, high bitrate audio.

 

Proposed Deliverables:

 

1) Requirements for wideband, Internet audio codec(s).

2) Algorithm description for wideband, Internet audio codec(s) as
Proposed

Standard. 

3) Specification of payload format(s) for defined codecs as Proposed

Standard