Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 20 June 2013 14:32 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 0243721F9BCB for <mmusic@ietfa.amsl.com>; Thu, 20 Jun 2013 07:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.331
X-Spam-Level:
X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 2QlyTrx0fK+W for <mmusic@ietfa.amsl.com>; Thu, 20 Jun 2013 07:32:44 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0872421F9CAD for <mmusic@ietf.org>; Thu, 20 Jun 2013 07:32:42 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id qbJL1l0030EZKEL5CeYiYN; Thu, 20 Jun 2013 14:32:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id qeYi1l0063ZTu2S3MeYiKv; Thu, 20 Jun 2013 14:32:42 +0000
Message-ID: <51C3128B.20402@alum.mit.edu>
Date: Thu, 20 Jun 2013 10:32:43 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, <BLU169-W56DEA51EC84C8180A7DCD5938D0@phx.gbl>, <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <BLU169-W1288AEADA7A090C209F376C938D0@phx.gbl> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> <E76ABD1D-06E4-47B8-A2A2-928C5F1DDAEE@csperkins.org>
In-Reply-To: <E76ABD1D-06E4-47B8-A2A2-928C5F1DDAEE@csperkins.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371738762; bh=gmHbB5HoZXNimm5xhaHi2Uzz/FS2ZckZXKSyFC8gei0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mmXGQM9RDRlhIuFdeOPhEfkLpUDk62QS1IoC0h07TvnkfaM/wEQ+Lz5zSg1FskgI0 Fwg18s3N/PpXn8aygrp6J1jsl1T/WgqDIJm3rwsbf7aQ7Cr+fv4JbiLu2KINdLK9kq sht7TmWUU/SxwKj/7Xs8P093j8tMVAH6HIJ22xU3/kVoRJPT2JIe1f7ONc4K0bVJ9/ 5jn837SGZ9gqK/KDjXsWVXOOWAqaNWuBLMHLy4eFIT6AhsUgaS38rtMpwle1ao3BE4 rBn8/kRkFlrbSmTS7qviLLVt++xHiVSGFgSVx/adgAcDqEg3cHvv1v2EvBfrQqA+Tt aBxFfoI7w9LNA==
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
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: Thu, 20 Jun 2013 14:32:50 -0000

On 6/20/13 8:37 AM, Colin Perkins wrote:
> On 20 Jun 2013, at 05:53, Christer Holmberg wrote:
>>>> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs.
>>>
>>> Agree.
>>
>> So, we DO agree that the usage of the *same* PT value (even if in different m= lines) for different codecs, or different codec configurations, is not allowed.
>>
>> Is there some specific section in some specific RFC that can be referenced to show that?
>
> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says:
>
>     ...
>     mechanisms for defining dynamic payload type bindings have been
>     specified in the Session Description Protocol (SDP) and in other
>     protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
>     associate the registered name of the encoding/payload format, along
>     with any additional required parameters, such as the RTP timestamp
>     clock rate and number of channels, with a payload type number.  This
>     association is effective only for the duration of the RTP session in
>     which the dynamic payload type binding is made.  This association
>     applies only to the RTP session for which it is made, thus the
>     numbers can be re-used for different encodings in different sessions
>     so the number space limitation is avoided.
>
> You'll note that the association is per RTP session, not per SSRC or other subset of the session.

I'm not inclined to argue the details of RTP with an RTP expert!
But just wearing my standards-lawyer hat I read all of the above 
references, and could not find anything that clearly justified the 
assertions you make. I read them as clearly stating that the *static* 
ones are defined for a profile. I guess the key part of the quote above 
is: "This association is effective only for the duration of the RTP 
session". That seems to *bound* the scope of the association, but 
doesn't explicitly state that it must be unique within that scope.

But maybe that is just a matter of me not reading it right, or of the 
text not having captured every nuance of the intent.

> If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT mapping across all the m= lines.

Of course. So I think that means its important for bundle to clearly 
state the requirement, if it is to be a real one.

	Thanks,
	Paul

> Colin
>
>
>>>> The corner case where we're discussing whether one can use the same payload type is if you have two M-lines that both specify VP8, with
>>>> the same codec parameters - whether they can both use 96, given that it's the same codec.
>>>
>>> Surely yes, but you lose the ability to distinguish the m= line based on the PT if you use the same PT (mapped to the exact same codec and set of codec parameters) in
>>> several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can
>>> use the same PT to represent the same codec across multiple m= lines.
>>
>> Exactly. So, I think it's a good idea to have some text about that in BUNDLE.
>>
>> Regards,
>>
>> Christer
>>
>
>
>