Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration

Jonathan Lennox <jonathan@vidyo.com> Tue, 10 September 2013 19:18 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E51F11E8129 for <mmusic@ietfa.amsl.com>; Tue, 10 Sep 2013 12:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNLxvzR9t-ru for <mmusic@ietfa.amsl.com>; Tue, 10 Sep 2013 12:18:32 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id CAC7221F9EAD for <mmusic@ietf.org>; Tue, 10 Sep 2013 12:18:31 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E69858BE5E3; Tue, 10 Sep 2013 15:18:30 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 384448BE568; Tue, 10 Sep 2013 15:18:30 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 10 Sep 2013 15:18:29 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tue, 10 Sep 2013 15:18:28 -0400
Thread-Topic: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
Thread-Index: Ac6uWiQ8ZZ25xrIWQ9uGIhhZCQtEKA==
Message-ID: <D1946496-4880-4F3F-9E53-153C4F33D04F@vidyo.com>
References: <7594FB04B1934943A5C02806D1A2204B1C47766D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C49D736@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C49D736@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D194649648804F3F9E53153C4F33D04Fvidyocom_"
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 19:18:37 -0000

My strawman proposal at the mic in Berlin was that a codec configuration is defined by the top-level media type of the m= line and the content of a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with all its parameters.

The questions I would have to this straw man are:

* Is this excessive?  E.g., should items like H.264's sprop- parameters be allowed to differ across m= line blocks?

* Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-lines as well?

My suggestion would be that this work should be folded into the work being done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be integrated with BUNDLE).  Currently (I believe) the mux-attributes draft assumes that PTs are unique across m-lines, so this work is going to imply changes to the analysis of a number of attributes in that draft, regardless.  Probably a new category will need to be defined for attributes which have to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:


Hi,

Below is the “official” (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.

Questions:

Q1: “Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration?”
Q2: “If Q1, do we agree that we need EXPLICIT text somewhere*, as there are opinions that simply referencing RFC 3550 might not be clear enough?”
Q7: “Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration?”

Outcome:

Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term “codec configuration”.
Q7: Yes.

So, again, we need definition text for “codec configuration”. Jonathan promised to submit something, but anyone is of course welcome to do that.

The other alternative is to not say anything about PT value usages within the scope of BUNDLE, but that is not what the meeting wanted.

Regards,

Christer


From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> [mailto:mmusic-bounces@ietf.org<mailto:bounces@ietf.org>] On Behalf Of Christer Holmberg
Sent: 23. elokuuta 2013 13:53
To: mmusic
Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration

Hi,

One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage of any given PT value.

My take of the outcome was that:

-          We agreed that any given PT value can only be used for a single codec configuration (Q1)
-          We agreed that we need some definition text for “codec configuration” (Q2)
-          We agreed that, within a BUNDLE group, any given PT value can be used in multiple m- lines, as long as it is used for a single codec configuration (Q7).

Jonathan Lennox promised to suggest some definition text for “codec configuration”, so let’s wait for that until we go into those discussions.

But, if you have any issues with the agreements in general, please bring them up :)

Regards,

Christer




--
Jonathan Lennox
jonathan@vidyo.com<mailto:jonathan@vidyo.com>