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

Colin Perkins <csp@csperkins.org> Wed, 19 June 2013 20:24 UTC

Return-Path: <csp@csperkins.org>
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 7B32E21F9FEA for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 13:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 KQNX+B0SVVQq for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 13:23:54 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 22DFE21F9FE0 for <mmusic@ietf.org>; Wed, 19 Jun 2013 13:23:54 -0700 (PDT)
Received: from [81.187.2.149] (port=42608 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UpOus-0004ub-54; Wed, 19 Jun 2013 21:23:44 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <51C203EF.4090404@alvestrand.no>
Date: Wed, 19 Jun 2013 21:23:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.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>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "mmusic_ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
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: Wed, 19 Jun 2013 20:24:05 -0000

On 19 Jun 2013, at 20:18, Harald Alvestrand wrote:
> On 06/19/2013 07:09 PM, Emil Ivov wrote:
>> On 19.06.13, 18:47, Christer Holmberg wrote:
>>>>> The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints.
>>>>> 
>>>>> For example, a client can choose to use unique PT values per m- values, within a given BUNDLE group, and everything should work fine. And, if the endpoint runs out of PT values, the create a new BUNDLE group. Now, whether it's religiously correct, I don't know :)
>>>>> 
>>>>> OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that.
>>>>> 
>>>>> OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that.
>>>>> 
>>>> OR, if they don't care which M-line the stream is associated with, the question may be moot.
>>> 
>>> Correct.
>>> 
>>>> In all cases, the payload type MUST clearly identify the codec configuration it's associated with.
>>> 
>>> *IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines?
>> 
>> Let's assume that it could ... but then how would you know that your peer also supports the same demuxing technique as yourself?
>> 
>> In SIP for example, when constructing a first offer, you may want to map both Opus and VP8 to 96, then add SSRCs for demuxing. This means that you expect your peer to support SSRC demuxing and you can't expect that unless we mandate it.
> 
> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs.

Agree.

> 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.

-- 
Colin Perkins
http://csperkins.org/