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

[Paul Kyzivat <[e-mail]>]

On 7/1/13 5:55 AM, Colin Perkins wrote:
> On 29 Jun 2013, at 16:44, Paul Kyzivat wrote:
>> 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.
>
> Every RTP packet contains an SSRC, so that's always available to use too. You may not chose to use it, but it seems strange to ignore it.

The think about PT is that it is guaranteed to be in the SDP.

There are lots of things in the RTP, but most of them are sometimes, or 
usually, not in the SDP.

While we have a way of putting SSRC into the SDP, we have heard much 
discussion of cases where the SSRC values aren't known at the time the 
SDP is sent.

The AppId draft, if it progresses, will provide another way. That makes 
three mechanisms. We *could* define an *algorithm* for mapping that is 
based on the sometimes presence of some or all of these in the SDP. But 
then I think it may need to be extensible for new attributes that might 
be used for this.

I did specify an abstract algorithm of this sort in an earlier reply.

(I suspect we aren't in fundamental disagreement. We are probably just 
talking about this is very different ways. For me the fundamental point 
is that a valid O/A must always define (perhaps implicitly) the 
algorithm to do the association.)

	Thanks,
	Paul

> Colin
>
>> 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
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>