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

Victor Paulsamy <vpaulsamy@ditechnetworks.com> Fri, 08 October 2010 03:46 UTC

Return-Path: <vpaulsamy@ditechnetworks.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 A4C233A67E1 for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 20:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 w5-rQV5lUPJs for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 20:46:41 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 905903A67F3 for <mediactrl@ietf.org>; Thu, 7 Oct 2010 20:46:40 -0700 (PDT)
Received: by ewy21 with SMTP id 21so391931ewy.31 for <mediactrl@ietf.org>; Thu, 07 Oct 2010 20:47:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.59.76 with SMTP id k12mr2179863ebh.13.1286509663710; Thu, 07 Oct 2010 20:47:43 -0700 (PDT)
Received: by 10.213.28.73 with HTTP; Thu, 7 Oct 2010 20:47:43 -0700 (PDT)
In-Reply-To: <0C1C621D-3038-405D-97EB-5BC95E1BB7F1@standardstrack.com>
References: <C8D354FC.9350%Scott.McGlashan@hp.com> <0C1C621D-3038-405D-97EB-5BC95E1BB7F1@standardstrack.com>
Date: Fri, 8 Oct 2010 10:47:43 +0700
Message-ID: <AANLkTi=wV=QdTgx5ByZQQVS_LQrE_b61x0D63bC-ahDb@mail.gmail.com>
From: Victor Paulsamy <vpaulsamy@ditechnetworks.com>
To: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/alternative; boundary=00148531b6a5817015049212df7d
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 03:46:42 -0000

Likewise -- works for me too.

--victor

On Fri, Oct 8, 2010 at 5:37 AM, Eric Burger <eburger@standardstrack.com>wrote;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> 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
> >>
> >>
> >> _______________________________________________
> >> MEDIACTRL mailing list
> >> 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
>
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>