Re: [MEDIACTRL] Issue with mixer package <codec> element

"McGlashan, Scott" <> Thu, 07 October 2010 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EA153A6E7E for <>; Thu, 7 Oct 2010 01:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NKFWI8oLKO0c for <>; Thu, 7 Oct 2010 01:48:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D75163A6ECA for <>; Thu, 7 Oct 2010 01:48:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9B0F384D8; Thu, 7 Oct 2010 08:49:29 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 7 Oct 2010 08:49:12 +0000
Received: from ([]) by ([]) with mapi; Thu, 7 Oct 2010 08:49:12 +0000
From: "McGlashan, Scott" <>
To: Jonathan Lennox <>, "" <>
Date: Thu, 07 Oct 2010 08:49:09 +0000
Thread-Topic: [MEDIACTRL] Issue with mixer package <codec> element
Thread-Index: Actl/INUJhm3G1UwQNKvpuaMh2fAnQ==
Message-ID: <>
In-Reply-To: <C3759687E4991243A1A0BD44EAC82303053842DE@BE235.mail.lan>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MEDIACTRL] Issue with mixer package <codec> element
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Oct 2010 08:48:29 -0000

Hi Jonathan,

Thanks for the comment and apologies for the delay.

Reviewing the XCON's definition, I see that they have a name attribute
which we have mistakenly not put in our definition of <codec>.

Unless anyone on the mailing list objects, I'll add a mandatory name
attribute to the <codec> element which specifies the top-level media type
of the codec. I'll also fix up the definitions of name and <subtype> to
map to the type-name and subtype-name of RFC 4288 as well as the examples.



On 25/03/2010 21:58, "Jonathan Lennox" <> wrote:

>I'm sorry this is being raised so late, but I was looking over the mixer
>package's definition of <codec> (to recommend that MRB copy its
>definition for its <rtp-codec>), and realized there was a problem.
>The problem is that mixer package's definition of <codec> includes only
>the media subtype (e.g. pcmu or h264), not its top-level media type
>(audio or video).  In most cases subtypes are unique, but there are a few
>"container" subtypes (e.g. rtx, fec, or red) that are registered as
>multiple top-level types.  I believe this is only by convention and good
>practice, however; RFC 4288 requires only that the type/subtype pair be
>My recommendation would be to add a <type> element under <codec>, whose
>definition is the top-level content type, leaving <subtype> as the
>subtype.  (An alternative would be to change to only using <type> as
>type/subtype, e.g. audio/pcmu, which would probably be equally good, but
>this might make life unnecessarily harder for implementations that want
>to try to maintain backward compatibility with the draft as-is.)
>It is probably also worth pointing out that both type and subtype names
>are not case-sensitive.
>The other (minor) problem is that I'm not sure the defining the values of
><subtype> by reference to a column IANA's RTP Payload Format media types
>table is the best choice, among other reasons being that that table is
>very incomplete, missing, for instance, video/h264.  (This has been
>raised with IANA.)  I would instead define the value simply as "the name
>of the subtype of the codec's media format".  The reference to RFC 4855
>can remain.
>Jonathan Lennox
>Vidyo, Inc
>MEDIACTRL mailing list
>Supplemental Web Site: