Re: [rtcweb] Plan A, respun

[Colin Perkins <[e-mail]>]

On 10 May 2013, at 17:37, Cullen Jennings wrote:
> On May 8, 2013, at 4:00 AM, Harald Alvestrand <[e-mail]> wrote:
>> The paragraph that worries me most is this one:
>> 
>>  Offerers conformant to this specification MUST do one of the
>>  following:
>> 
>>  o  Use non-overlapping PT values for each m-line in any given bundle
>>     group.
>> 
>>  o  Provide distinct a=ssrc attributes for each m-line which uses
>>     overlapping PT values with any other m-line.  [Technically, this
>>     is a general case of the previous point.]
>> 
>> 
>> 
>> To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.
> 
> As a slide note, as I imagine you are aware,  it is not 32 but in the roughly 100 range 
> 
>> 
>> To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point.
> 
> The problem is that SSRC are not a stable demux point due to collision and early media issues so, for applications that care about theses, they can use PT. For things that need the properties of the larger code space, they can use SSRC or other future extension to RTP.  The code is very simple to deal with demux on both PT and SSRC . If someone wants to later add a RTP header extensions with another tag that can be used for demux, that is fine too. The idea is that the device will use what it currently knows (both PT and SSRC) to do the best demux it can do given the information at hand. This gives us the best of SSRC demux and PT demux and actually allows a combination of the two that scales to much larger numbers than either alone. And it's trivial to implement.

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. 

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

>> It would seem to me to be architecturally cleaner to insist that a=ssrc be used always.
> 
> There rare two major disadvantages to doing this 
> 
> 1) The side receiving the media can't tell the other side what SSRC to use in the offer. That means you can not demux until after the answer is received in the best case. This adds latency and cause media clipping. It does not work with early media in some cases. 

You can always use the SSRC to demux based on source, then use the PT to direct to the appropriate codec, irrespective of whether you've received signalling of the SSRC in advance. I don't see how using the PT as the primary demultiplexing point helps here.

> It may not matter to the use case you have in mind but it does matter to use cases other have in mind. Note there is no problem for the use case you are interested in just using the SSRC and not caring what happens with the PT. For applications that want to do that, the mechanism in this draft works just fine.  
> 
> 2) the other problem is that SSRC collide and it takes a long time to get the the updated information about how the collision was resolved and in that time the data may actually go the wrong place.  Just sort of curios if chrome has implemented dealing with collisions yet?

If the colliding sources send the required RTCP packets immediately, as RFC 3550 allows in unicast scenarios, you should be able to determine how collision was resolved straight away. 

And, if you're signalling SSRCs, an SSRC collision is no more likely than a PT collision, and gives you a bigger space to work with to identify streams.

> I will note that using PT + SSRC in the way Adam's draft has them actually allows for a theoretical maximum of more like 3 million RTP flows per port. 

Using the SSRC to distinguish sources allows this anyway, and as I noted above, you can't run multiple sources with the same SSRC and different PT values without breaking RTCP.

>> But in that case, I have a very large difficulty seeing the important advantage this has over Plan B.
>> 
>> 
>> 
>> On 05/07/2013 08:30 PM, Adam Roach wrote:
>>> In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture. 
>>> 
>>> The cleaned up, new-and-improved description of the Plan A approach is available here: 
>>> 
>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt 
>>> 
>>> Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document: 
>>> 
>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt 
>>> 
>>> Thanks. 
>>> 
>>> /a 
>>> _______________________________________________ 
>>> rtcweb mailing list 
>>> [e-mail] 
>>> https://www.ietf.org/mailman/listinfo/rtcweb 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



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