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

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

On Tue, 4 Dec 2018 at 10:58, Magnus Westerlund
<[e-mail]> wrote:
> However, an RTP middlebox has the freedom to introduce those header
> extensions when switching. They do not need to be sent end-to-end all
> the time. So after the initial establishment of them, I see it as the
> central middlebox responsibility to ensure that they are included in the
> down stream legs towards the conference participants. Also at least for
> video introducing them only on reception of a FIR also makes sense.

The problem here is well known and happens often in this WG: the lack
of proper layer separation in SDP / RTP. The thing is:

1) MID/RID is valid within the context of a transport, nothing else.
And a transport is hop by hop. The receiver (an endpoint, a SFU, a
MCU, whatever) checks packet MID and then packet RID/RRID to figure
out the corresponding "transceiver" or m section and the corresponding
stream (media, simulcast, RTX).

2) If the receiver is a SFU which is gonna multiplex such a "track"
with many others to send them to a receiver over a single transport
(Bundle) then MID/RID does not make any sense because MID is typically
"0" or "1" etc. So the SFU would need to rewrite MID for each receiver
or just not announce MID support at all in the other leg.

3) In the case of RTX this is much more easier: RTX is just hop by
hop. If there is a SFU in the middle, you don't send a RTX packet
directly to the endpoint. You send it to the SFU (assuming the SFU
sent you a NACK). The SFU "decodes" and stores it. If the receiver in
the other leg sends a NACK, the SFU encapsulates such a stored packet
into a new RTX packet and sends it to the receiver. So RTX is hop by
hop, and hence it does not make any sense to talk about reusing
MID/RID headers for same reasons given in 2).

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