Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

Colin Perkins <> Sun, 30 June 2013 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEC2721F9BAA for <>; Sun, 30 Jun 2013 10:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.849
X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ibwVeOHJPZT for <>; Sun, 30 Jun 2013 10:04:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9608521F9AFE for <>; Sun, 30 Jun 2013 10:04:57 -0700 (PDT)
Received: from [] (port=38421 helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UtL3X-0008HB-SF; Sun, 30 Jun 2013 18:04:56 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <>
In-Reply-To: <>
Date: Sun, 30 Jun 2013 18:04:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Christer Holmberg <>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "" <>
Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Jun 2013 17:05:03 -0000

On 30 Jun 2013, at 17:57, Christer Holmberg wrote:
> Hi,
>>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP 
>>>>> data to m- lines should be based on PT. Applications are allowed to 
>>>>> use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).
>>>>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines?
>>>> I think the BUNDLE specification needs to define how RTP flows can be 
>>>> associated with m= lines, but ought not mandate that applications do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism.
>>> Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?, on whether BUNDLE shall mandate that the receiver must always be able to map received data to an m- line.
>>> So far only Paul has commented on that discussion, but I assume it's 
>>> just a question of hours before your input will be posted? :)
>>>>> Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?
>>>> I think we should specify how the combination of PT values and a=ssrc: lines can be used to associate RTP data with m= lines, for applications that want to do so. 
>>>> I don't think just using PT values is sufficient, since the PT space 
>>>> is small (I can imagine applications that want to send lots of flows using the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).
>>> If you run out of PTs, and have to re-use the same PT in multiple m- lines (for the same codec configuration, though), you will obviously need something else for mapping RTP to m- lines, and we should probably state that.
>>> But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what to use. Correct?
>> No. 
>> Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single
>> algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient.
> But, what if there is no a=ssrc? Are you suggesting we shall mandate usage of a=ssrc in case of multiple RTP m- lines in a BUNDLE group?

No, I'm saying that we should define a single algorithm for mapping the RTP flows to m= lines. That algorithm should take into account a=ssrc: lines, if present, as well as payload type mapping.

> As Paul says in his reply, there may be different mechanisms which can be used (and in future there might be even more). You seem to suggest that BUNDLE shall say "Mechanism X is the only mechanism for mapping RTP media to m- lines". Or?

I'm suggesting we specify something tractable: one algorithm, if at all possible. I'm unconvinced that too much flexibility is a good thing here.

Colin Perkins