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

[Colin Perkins <[e-mail]>]

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
http://csperkins.org/