Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId

[Iñaki Baz Castillo <[e-mail]>]

On Tue, 4 Dec 2018 at 10:35, Sergio Garcia Murillo
<[e-mail]> wrote:
>
> On 03/12/2018 22:26, Iñaki Baz Castillo wrote:
> > On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
> > <[e-mail]> wrote:
> >> My point is that there is a single source in the transceiver/MID why
> >> should we add default RID and waste 2 more bytes in each media and rtx
> >> packet?
> > Regardless what browsers do today, both MID and RID headers should be
> > just included in the first packets. The receiver is supposed to update
> > its ssrc table for faster matching.
> >
> > NOTE: The sender should also resend MID and RID if the SSRC changed
> > because some RFCs state that SSRCs may conflict and things that
> > absolutely never happen.
> >
> Kind of agree, but from a theoretical point of view remember that we
> introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which
> ssrc conflicts may happen, so in order to cover those scenarios the
> MIDs/RIDs values must be included in every packet.

I don't think that rationale is correct. No need for MID/RID in
*every* packet, but just in the first ones (despite what browsers do).
Once magic SSRC conflict happens (AM I READY TALKING ABOUT SSRC
CONFLICT??) the sender should just choose a new SSRC and add MID/RID
in the next packets.

> If we ignore that,
> then could just go back to ssrc signaling and avoid mids/rids
> completely, which I would be in favor of.

Definitely signaling ssrcs instead of MID/RID is *much* easier for
anyone who has implemented this stuff. I'm still waiting for any good
reason to not signal ssrcs (NOTE: I do not believe in SSRC conflicts
and will not believe in it no matter which "RTP middlebox stuff"
rationale is given to me).

Said that, if we go that way (signal MID and RID instead of ssrcs)
it's ok as far as we can also properly signal simulcast + RTX, which
is not clear given the length of this thread.

-- 
Iñaki Baz Castillo
<[e-mail]>