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

[Sergio Garcia Murillo <[e-mail]>]

On 04/12/2018 12:34, Iñaki Baz Castillo wrote:
> 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.

Yes, they could be sent in all packets until the first received RTCP RR 
for that ssrc (to ensure binding on the received side) and then only on 
first packet of an intra frame for video.


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


+1

btw, I use an alternative approach for signaling back rids/ssrc 
association for chrome sdp mangling in order to havea single processing 
algo on the SFU (note the ssrc attribute on the rid which is completely 
valid accoding to the rid ABNF ;)

a=ssrc-group:FID 3267388881 2718767991
a=ssrc:3267388881 cname:jwLMsXS4a6eBfofC
a=ssrc:3267388881 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:3267388881 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:3267388881 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 cname:jwLMsXS4a6eBfofC
a=ssrc:2718767991 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:2718767991 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 100 101
a=ssrc:100 cname:jwLMsXS4a6eBfofC
a=ssrc:100 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:100 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:100 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 cname:jwLMsXS4a6eBfofC
a=ssrc:101 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:101 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 102 103
a=ssrc:102 cname:jwLMsXS4a6eBfofC
a=ssrc:102 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:102 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:102 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 cname:jwLMsXS4a6eBfofC
a=ssrc:103 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:103 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:SIM 3267388881 100 102
a=simulcast:send a;b;c
a=rid:a send ssrc=102
a=rid:b send ssrc=100
a=rid:c send ssrc=3267388881

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

Neither for non-simulcast scenarios


Best regards

Sergio