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

[Colin Perkins <[e-mail]>]

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.

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

Colin



> 	Thanks,
> 	Paul
> 
> On 5/27/13 9:57 AM, Colin Perkins wrote:
>> I don't agree with the phrasing about "packet processing pipelines", but can't tell if this is a terminology disagreement or a more fundamental disconnect. The way I see the demultiplexing logically working is:
>> 
>>                     |
>>                     | packets
>>     +--             v
>>     |           +----------+
>>     |           |UDP socket|
>>  A  |           +----------+
>>     |        RTP ||  |  |
>>     |   and RTCP ||  |  +------> SCTP
>>     |            ||  +---------> STUN/ICE
>>     +--          ||
>>     +--          ||
>>     |       split by SSRC
>>     |       ||   ||   ||
>>     |       ||   ||   ||
>>  B  |      +--+ +--+ +--+
>>     |      |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc.
>>     |      +--+ +--+ +--+
>>     +--      |   |     |
>>     +--      |  /      |
>>     |        +---+     |
>>     |         /  |     |
>>  C  |      +--+ +--+ +--+
>>     |      |CR| |CR| |CR| Codecs and rendering
>>     |      +--+ +--+ +--+
>>     +--
>> 
>> If your algorithm is for demultiplexing at layer C, i.e., to figure out what codec and rendering pipeline to use, then I think we're in agreement apart from terminology.
>> 
>> For layer B, I believe the SSRC is the right thing to use to demultiplex, and fits with RTP and RTCP. This is where RTCP is processed, playout de-jitter buffering happens, FEC is processed, NACKs are sent, etc. It's logically independent of the decoding and rendering process since you can start filling your de-jitter buffer for an SSRC before you figure out if/how/where you're going to render that SSRC.
>> 
>> For layer A, there was a clear-cut way of doing this with RTP, RTCP, and STUN. I haven't looked at SCTP enough to know how that affects things. I do think it's a logically separate issue, and should be documented separately to BUNDLE though, since it the same issues arise with non-bundled sessions.
>> 
>> An implementation might merge these together, of course, but to avoid confusion the standards should be clear what level they're considering.
>> 
>> Colin
>> 
>> 
>> 
>> On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote:
>>> Great - sounds like we agree this algorithm will work.
>>> 
>>> On May 27, 2013, at 6:41 AM, Colin Perkins <[e-mail]> wrote:
>>> 
>>>> I'm not sure I agree.
>>>> 
>>>> As I said in my previous message to the list, if we are agreed that the m= lines in a BUNDLE group form a single RTP session, then I believe we need unique payload types across all m= lines. In this case, BUNDLE can simply say that regular RTP source demultiplexing based on the SSRC has to be performed, then the payload type can be used to match sources to m= lines for those applications that care about doing so.
>>>> 
>>>> If we're not agreed that the m= lines in a BUNDLE group form a single RTP session, then we have a lot more to discuss...
>>>> 
>>>> Colin
>>>> 
>>>> 
>>>> 
>>>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote:
>>>>> Here's is my proposal for roughly what the bundle draft should say about this demux topic
>>>>> 
>>>>> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows:
>>>>> 
>>>>> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping
>>>>> 
>>>>> 2) If the PT type is uniquely identifies a mapping, use that to form the mapping
>>>>> 
>>>>> 3) If application knows the SSRC the other side will use, use that to form the mapping
>>>>> 
>>>>> 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known
>>>>> 
>>>>> This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on.
>>>>> 
>>>>> We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Colin Perkins
>>>> http://csperkins.org/
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>> 
>> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
Colin Perkins
http://csperkins.org/