Re: [rtcweb] Comments on draft-jennings-rtcweb-plan-01

[Martin Thomson <[e-mail]>]

In general, I believe that this is a largely reasonable proposal.

I too find the header extension problematic.  However, signaling based
on SSRC alone doesn't mesh well with the possibility that SSRC can
change in response to collisions.

In light of the solution for layer/simulcast-relationships, maybe the
right response is to have the first few messages on the new SSRC
indicate the old SSRC in a CSRC in case of renumbering.

That would give us the following semantics for CSRC:
 - Mixing/switching: this stream is derived from another stream
through mixing, switching or similar and this is the SSRC of that
contributing source
 - Layers: this stream depends on another stream, because it is
incomplete without it (we'd have to ensure that the pointer runs in
the one direction only, only dependent layers would have CSRC)
 - Simulcast: this stream is a (higher/lower) quality variant of the
stream with the given SSRC, either can be used as an entire
replacement (all variants would have CSRCs for all other variants)
 - Renumbering: this stream was previously known by another SSRC

A receiver can treat mixing, simulcast and renumbering using the same
logic: it can render the last packet that arrives, with the normal
allowances for selecting from simulcast streams.  Layered association
uses the mechanisms appropriate to the codec.

Stefan said:
> Is there a
> risk that the ICE -candidate's references to m-lines gets out of sync?

That one's a non-issue.  You can't remove m-blocks, so the index is consumed.