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

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

On 04/12/2018 11:51, Magnus Westerlund wrote:
> On 2018-12-04 11:01, Sergio Garcia Murillo 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.
>> Same could be said about changing the ssrc to avoid collisions and we
>> would have avoided our selves to introduced all this new ids.
> I think you are significantly misrepresenting the reasons why RID's are
> needed. The fact that we have multiple models for how RTP middleboxes
> works is a significant contributing factor. The next is in RTP ancestry
> as a non-centralized multi-party protocol, i.e. intended to work over
> any source multicast. And as simulcast do implies a selection by the
> middlebox that aspect do needs to be handled. A clean-slate approach
> could possibly select another set of constraints and maybe be somewhat
> simpler but not a lot.
>
> I do note that also the MIDs and RIDs only have per signalling context
> and may require translation between the various legs of the conference
> in a multi-party one.


I disagree with several of those statements, but my intention was not to 
start a new discussion about the need of mids/rids, but the usage in RTX 
which I have not yet got a good answer.

Trying to get back to the discussion:

  * What headers should contain a RTX packet from a track added via
    addTrack or addTransceiver without encodings
  * What headers should contain an RTX packet from a track added via
    addTransceiver with several encoding+rids

Best regards

Sergio