- From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Feb 2019 18:11:47 +0000
- To: public-webrtc-logs@w3.org
This is my personal opinion and is not the official opinion of my employer. I think i need to understand the "backwards-compatibility" motivation a bit more. The way i see it, this is new functionality and a "new spec" in unified plan. Work needs to be done in SFUs in order to support it, as we can't expect the SFUs to understand the a=simulcast attribute and understand what it needs to signal it back to acknowledge receipt of simulcast. So this won't work out of the gate even if we were to include SSRCs. On the other hand, I feel that it is reasonable to assume that an SFU that understands a=simulcast should also understand RIDs and MIDs, as those specs are in the dependency chain for simulcast. It is worth noting that we did not take away the legacy simulcast munging scenario, and that can still be used. Nor did we remove SSRCs from any existing supported scenario, only in the spec-compliant simulcast scenario where SSRCs "conflict" with RIDs as the source of truth regarding layer identification. I also feel that continuing to push to a hybrid of plan-b and unified-plan specs (which is what is happening de facto, with all the support that gets baked into implementations) hurts us in the long run, as it gives more excuses for applications not to migrate (they keep seeing new features), while also creating unnecessarily complicated (and therefore buggy) software. In the end, it leads to the opposite of what we want, as i have seem multiple spec scenarios that won't work as intended because implementations also require parts borrowed from other specs, as is evident by some of the things that break when SSRCs are not signaled. -- GitHub Notification of comment by amithilbuch Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1174#issuecomment-468377522 using your GitHub account
Received on Thursday, 28 February 2019 18:11:49 UTC