Re: [rtcweb] Plan A, respun

[Bernard Aboba <[e-mail]>]

Colin said: 

The RTP demultiplexing process, as I always understood it, was to look at the SSRC first, and based on that find your SRTP context, jitter buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at the PT to determine what codec to use for the stream (noting that SSRCs can switch between PT values, and multiple SSRCs can use the same PT). Using the PT as the de-mux point for streams doesn't let you find the appropriate RTCP state or SRTP context, since those are indexed by SSRC, and requires you to use unique PT values for each stream, which is a much more limited space than the SSRC space (and, unlike the SSRC space, has no collision resolution built-in). 
[BA]  That is typically how I've seen it done, yes.  
Colin also said: 
I'm confused about what you mean by using a combination of SSRC and PT demux. You can't have two distinct SSRCs using the same PT values in a single RTP session, because you can't distinguish the RTCP packets for the two SSRCs, and we mandated the use of RTCP. 
[BA]  The statement above seems inconsistent with the earlier statement that "multiple SSRCs can use the same PT".  Or did you mean having multiple SSRCs, each using multiple PT values?  
Since the RTCP packets include the SSRC (but not the PT), distinguishing the RTCP packets by SSRC isn't a problem. I have seen multiple SSRCs use the same PT within an RTP session to enable several scenarios.  This includes RTP stream demux (e.g. the objective of "Plan B"), as well as simulcast and layered coding.  In the simulcast/layered coding case there are issues with understanding which RTP streams go together purely at the RTP level (e.g. adding this info to an SDES packet would be helpful), but it doesn't seem to cause problems for de-muxing.