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

Colin Perkins <csp@csperkins.org> Thu, 20 June 2013 12:37 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 50E9E21F9B4C for <mmusic@ietfa.amsl.com>; Thu, 20 Jun 2013 05:37:16 -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 jApAGh7zfXfJ for <mmusic@ietfa.amsl.com>; Thu, 20 Jun 2013 05:37:11 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0004E21F9B4B for <mmusic@ietf.org>; Thu, 20 Jun 2013 05:37:10 -0700 (PDT)
Received: from [130.209.247.112] (port=64669 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Upe6s-0002Y2-Sw; Thu, 20 Jun 2013 13:37:08 +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: <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se>
Date: Thu, 20 Jun 2013 13:37:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E76ABD1D-06E4-47B8-A2A2-928C5F1DDAEE@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> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "mmusic_ietf.org" <mmusic@ietf.org>
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 12:37:16 -0000

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.

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.

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
> 



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