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

Lorenzo Miniero <lorenzo@meetecho.com> Fri, 08 October 2010 11:08 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D553A686D for <mediactrl@core3.amsl.com>; Fri, 8 Oct 2010 04:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 QYoCsqfn-uIe for <mediactrl@core3.amsl.com>; Fri, 8 Oct 2010 04:08:05 -0700 (PDT)
Received: from smtplq01.aruba.it (smtplq-out9.aruba.it [62.149.158.29]) by core3.amsl.com (Postfix) with SMTP id F28013A6883 for <mediactrl@ietf.org>; Fri, 8 Oct 2010 04:08:04 -0700 (PDT)
Received: (qmail 27594 invoked by uid 89); 8 Oct 2010 11:08:57 -0000
Received: from unknown (HELO smtp4.aruba.it) (62.149.128.201) by smtplq01.aruba.it with SMTP; 8 Oct 2010 11:08:57 -0000
Received: (qmail 24841 invoked by uid 89); 8 Oct 2010 11:08:54 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp4.ad.aruba.it with SMTP; 8 Oct 2010 11:08:54 -0000
Date: Fri, 8 Oct 2010 13:06:28 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Chris Boulton <chris@ns-technologies.com>
Message-Id: <20101008130628.6f640b40.lorenzo@meetecho.com>
In-Reply-To: <4CAEEF0F.4070006@ns-technologies.com>
References: <C8D354FC.9350%Scott.McGlashan@hp.com> <0C1C621D-3038-405D-97EB-5BC95E1BB7F1@standardstrack.com> <AANLkTi=wV=QdTgx5ByZQQVS_LQrE_b61x0D63bC-ahDb@mail.gmail.com> <4CAEEF0F.4070006@ns-technologies.com>
Organization: Meetecho
X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] Issue with mixer package <codec> element
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2010 11:08:07 -0000

It's ok for me as well.

L.


On Fri, 08 Oct 2010 11:14:39 +0100
Chris Boulton <chris@ns-technologies.com> wrote:

>   +1.
> 
> 
> On 08/10/2010 04:47, Victor Paulsamy wrote:
> > Likewise -- works for me too.
> >
> > --victor
> >
> > On Fri, Oct 8, 2010 at 5:37 AM, Eric Burger 
> > <eburger@standardstrack.com <mailto:eburger@standardstrack.com>> wrote:
> >
> >     Works for me. Anyone else?
> >
> >     On Oct 7, 2010, at 4:49 AM, McGlashan, Scott wrote:
> >
> >     > 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.
> >     >
> >     > Thanks
> >     >
> >     > Scott
> >     >
> >     >
> >     >
> >     >
> >     > On 25/03/2010 21:58, "Jonathan Lennox" <jonathan@vidyo.com
> >     <mailto:jonathan@vidyo.com>> 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
> >     >> unique.
> >     >>
> >     >> 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
> >     >> jonathan@vidyo.com <mailto:jonathan@vidyo.com>
> >     >>
> >     >>
> >     >> _______________________________________________
> >     >> MEDIACTRL mailing list
> >     >> MEDIACTRL@ietf.org <mailto:MEDIACTRL@ietf.org>
> >     >> https://www.ietf.org/mailman/listinfo/mediactrl
> >     >> Supplemental Web Site:
> >     >> http://www.standardstrack.com/ietf/mediactrl
> >     >
> >     > _______________________________________________
> >     > MEDIACTRL mailing list
> >     > MEDIACTRL@ietf.org <mailto:MEDIACTRL@ietf.org>
> >     > https://www.ietf.org/mailman/listinfo/mediactrl
> >     > Supplemental Web Site:
> >     > http://www.standardstrack.com/ietf/mediactrl
> >
> >
> >     _______________________________________________
> >     MEDIACTRL mailing list
> >     MEDIACTRL@ietf.org <mailto:MEDIACTRL@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/mediactrl
> >     Supplemental Web Site:
> >     http://www.standardstrack.com/ietf/mediactrl
> >
> >
> >
> > _______________________________________________
> > MEDIACTRL mailing list
> > MEDIACTRL@ietf.org
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> 
> 
> -- 
> Chris Boulton
> CTO & Co-founder
> NS-Technologies <http://www.ns-technologies.com>
> m: +44.7876.476681
> 


-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com