Re: [rtcweb] Plan A, respun

[Cullen Jennings <[e-mail]>]

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.

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

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?

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. 


> 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