Re: [MMUSIC] Proposal for what bundle should say about demux

[Paul Kyzivat <[e-mail]>]

Colin,

On 5/27/13 3:16 PM, Colin Perkins wrote:
> On 27 May 2013, at 20:08, Paul Kyzivat wrote:
>> On 5/27/13 2:08 PM, Colin Perkins wrote:
>>> Paul,
>>>
>>> On 27 May 2013, at 18:31, Paul Kyzivat wrote:
>>>> Colin,
>>>>
>>>> (I guess you know I am naive about RTP, so take this with a grain of salt.)
>>>>
>>>> In the below, you first split by SSRC. Then later you map to codec. That seems to suggest that each SSRC might have a unique mapping from PT to codec. Did you intend that?
>>>
>>> That's not how RTP has worked historically. The mapping from payload type to payload format has always been done on a per-RTP session basis, with a static mapping for some types, and a dynamic binding via SDP for others.
>>
>> Sure, I understand that. There was no way to describe that in SDP, so of course it wasn't done that way.
>>
>> The introduction of bundling makes it possible to describe more possibilities. So that it becomes necessary to decide which ones will now be valid and which will not.
>>
>> I asked because it wasn't clear. I think things can be made to work either way. If this is to be illegal, then the rules for forming bundles should say so.
>
> Without a wholesale revision to RTP and the signalling, I believe this should be illegal (i.e., you MUST NOT map the same payload type to two different payload formats in a single bundle group).
>
>>>> I also don't understand below how you expect unknown SSRCs to be handled. ISTM that the flow you show could result in establishing a bunch of state for each received SSRC, whether that SSRC is of interest or not.
>>>
>>> If you receive RTP and/or RTCP packets you need to keep some state for that SSRC. At least, you need to record the SSRC as in-use so you can avoid collisions, and you need to send RTCP reports for that SSRC. The state requirements for this are small (tens of bytes per SSRC). If you care about decoding and rendering the source there is more state, of course, but you only need that if you're rendering their media.
>>>
>>> You also need to be slightly smart to prevent DoS attacks if the other side decides to send you a stream of packets with a different, random, SSRC in each, but that's just basic robustness, and there are plenty of other ways to DoS a poorly engineered receiver at the RTP layer without playing tricks with SSRCs.
>>>
>>>> In some cases it may be that specific SSRCs are expected, and others can be ignored (or whatever). In other cases the recipient may not know what SSRCs to expect, but may have some other way of deciding which it wants to process.
>>>
>>> Sure - if you know what SSRCs you're expecting, you can pre-populate some of the state at the RTP level, and tell that layer that unknown SSRCs can be discarded. None of that changes the basic approach to de-multiplexing.
>>>
>>>> That was the point of my thread about associating packets to m-lines. If you can at least associate a packet with one of the bundled m-lines, even if it is by a means other than SSRC, then it becomes easier to decide what to do with it. For instance, I think Cullen intends that in plan A you could associate packets with m-lines via the PT, and then for each m-line process only packets for the most recently seen SSRC. (So when a new SSRC is received, drop all state for the prior SSRC and establish a new state for the new one.)
>>>
>>> I would suggest instead: de-multiplex into sources based on the SSRC and keep state for those according to the RTP timing rules. If you want to associate sources with m= lines via the PT, and determine what to render based on most recently active, that works fine, and works with all the various RTP and RTCP extensions (unlike de-multiplexing sources based on the PT), and gives you many more possible sources since the SSRC space is larger than the PT space.
>>>
>>>> The same approach can work using a header extension identifying a clue capture encoding to map to an m-line. When doing that, it won't be necessary for the PT to be unique across m-lines.
>>>
>>> The combination of an RTP Header Extension and/or RTCP SDES packet to identify an m= line would also work, and associates with the stream based on the SSRC. You don't need to use the PT to demultiplex for this.
>>
>> One of my points is that if SSRC and/or header extension value is known in advance, then putting that in the SDP and using it to associate to an m-line can relax the requirement that PTs be unique per-m-line. That makes it possible to support more m-lines in a bundle. This could be advantageous for plan A.
>
> I don't see any problem using the a=ssrc: or RTP header extension based methods to determine what m= line an RTP source maps to.

> I don't think you need to relax the requirement that PTs be unique per m= line to do this.

I agree there is no *need* to relax the PT uniqueness requirement in 
order to map the packets (or sources if you prefer) to m-lines.

But (at least with plan A) there is a concern that there will be 
insufficient PTs to keep them unique per-m-line.

What I am saying is that if you do the mapping to m-line *before* the 
mapping from PT to payload format, then you *can* relax the PT 
uniqueness requirement.

This isn't violating precedent, because there is no precedent. Neither 
the problem nor the solution are present without bundling.

	Thanks,
	Paul

> As I said in the other thread, how you decide how to render an RTP source is separate to how you demultiplex RTP sources. Most of this confusion is coming from trying to combine the two operations.
>