Re: [webrtc-pc] `ssrc` in `RTCRtpEncodingParameters` is inconsistent with ORTC (#1174)

@aboba I think the discussion and original consensus is on a much broader subject - unified plan scenario as a whole and chrome has lived up to that and signaled SSRCs for all of the existing backwards compatible scenarios.

If our goal is to have SSRCs everywhere (both new and existing apis), then we should consider putting it explicitly in the spec. And we might as well standardize `a=ssrc-group:SIM` in the SDP instead of the `a=simulcast` attribute to achieve the same. 
I'm glad you tagged this issue with March interim as we should have a broad discussion.

This is a new API surface and it might not fall under the same rules because the semantics are different (no existing clients, mandates SFUs, RIDs must be negotiated, etc.). We might want to keep this scenario exempt from signaling these SSRCs because without directly tying them to RIDs it could be destructive. Here are a few examples of things that could go wrong:

imagine i want to send you 3 simulcast layers and you want to accept only two (you reject one layer).
how would you know which ssrc is the one you should remove along with the RID? what if you reject simulcast altogether, how do you know which of the 3 ssrcs that were proposed is the one that will be used in the single layer that eventually gets sent?

Simulcast needs to be acknowledged by the receiving party, that means that the ssrcs from the sender will need to be in the answer along with the ssrc for video sent from the SFU on the same section. This will be different than any existing scenario (SSRCs are never acked).

RTX, flex, or any other SSRCs that might need to be signaled along on the same section would cause more confusion on which SSRCs are associated with which streams. how would the implementation know how to disambiguate them as well?

The simulcast receiver (SFU) could be the one initiating the call using `a=simulcast:recv 1;2;3`.
Should it also indicate the ssrcs that correspond to each rid? that would be different than any existing scenario.

GitHub Notification of comment by amithilbuch
Please view or discuss this issue at using your GitHub account

Received on Thursday, 28 February 2019 23:46:49 UTC