Re: [rtcweb] Plan A, respun

[Eric Rescorla <[e-mail]>]

On Wed, 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.
>
> 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.
>

That doesn't sound *quite* right to me.

As I read the document, implementations are free to:

(a) offer entirely disjoint PTs for all the m-lines in a given bundle, in
      which case they must consume in total less than about 96 PTs
(b) offer a=ssrc in which case they must only guarantee that each
      m-line doesn't internally repeat PTs (i.e., the current guarantee
      that you don't say that 102 is both VP8 and H.264 on the same
      m-line.)

I would think that a smart implementation would try to use disjoint
PTs to the extent possible (thus allowing early demuxing) but
also offer a=ssrc, so that if they ran out of PTs, the transition was
smooth. Obviously there is potential for bugs here, but this seems
like code that would get fairly well tested in the field, no?



>  It would seem to me to be architecturally cleaner to insist that a=ssrc
> be used always.
> But in that case, I have a very large difficulty seeing the important
> advantage this has over Plan B.
>

Isn't the argument that Plan A preserves all the existing SDP negotiation
mechanisms but allows them to be used with a high level of muxing,
rather than reinventing some subset of them at the SDP level?

-Ekr


>