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

Christer Holmberg <> Sun, 30 June 2013 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C17D21F9B85 for <>; Sun, 30 Jun 2013 10:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.027
X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K4FzkRXQJzaB for <>; Sun, 30 Jun 2013 10:10:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A6F2021F9B15 for <>; Sun, 30 Jun 2013 10:10:17 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-4e-51d06678965a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DB.CD.06741.87660D15; Sun, 30 Jun 2013 19:10:16 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 19:10:16 +0200
From: Christer Holmberg <>
To: Colin Perkins <>
Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?
Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAryLEAAAfraoAAk+azAAA/Mr5Q///hcQD//93/UA==
Date: Sun, 30 Jun 2013 17:10:15 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW5F2oVAg+Oz1SyWvzzBaDF1+WMW ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugSvjx6Y+loLJUhWzTr5hbmBsFO1i5OSQEDCR uPBjCTuELSZx4d56NhBbSOAwo8SvztguRi4gexGjxN+m76xdjBwcbAIWEt3/tEFqRARUJXYc /8cIEmYWUJe4ujgIJCwsECex58ZysLCIQLzEoVlGENVhEp+mXGICsVmAOl+ufcYKYvMK+Eo0 7nrADrHpF5PEvo4pYAlOAUeJRY9/M4LYjECnfT+1BqyZWUBc4sPB68wQJwtILNlzHsoWlXj5 +B8rhK0k0bjkCStEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuaklxtuYgTGx8Etv3V3MJ46J3KIUZqDRUmcd5PemUAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjIFz0k909j7gOrjuZw3T5sqexQf6Z/F3fTFKMOvXYitMSD0361+Ud8IuHUEB Y/sFHfm5p76qXD6qx89g/rzqyb5TNixny4okmAJ2P2EvdjJ4tbvJJvJT9+yvx+omzeXPUnuV +1zc8sa/c5vS7m6MnHIu0aUux+nxN79VJzTKrV96/s0yUX7MpcRSnJFoqMVcVJwIAI8X+ohd AgAA
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:10:24 -0000


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

Ok, so you want to have explicit text about usage of a=ssrc, if present. But, I still don't think we should forbid usage of other mechanisms, eventhough we won't describe them in the BUNDLE spec.