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

[Paul Kyzivat <[e-mail]>]

On 6/29/13 8:44 AM, Colin Perkins wrote:
> On 26 Jun 2013, at 13:20, Christer Holmberg wrote:
>> Hi Colin,
>>
>>>> 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 we *will* have alternative ways of doing this:

- one way is by SSRC, specifying which SSRC goes to which m-line

- another way could be by appid (from Roni's new draft)

The only thing that is special about PT is that *every* RTP media 
section contains PTs, so it is always available to be used.

If I want to use appid, I may very well *not* want to use ssrc as well. 
I may want the same ssrc to associate with *different* m-lines in the 
bundle depending on which appid it has.

And in that case I may well not want to use PT either.

	Thanks,
	Paul