- From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Feb 2019 19:16:02 +0000
- To: public-webrtc-logs@w3.org
@aboba I think we should look at this in the context of the two separate scenarios. SSRCs are signaled in the SDP in all scenarios except in the spec-compliant simulcast. Unified plan can still be used for simulcast with SSRCs with SDP munging. As such i do not think that we should revert that PR. In the spec-compliant simulcast scenario, we require the endpoint to respond with `a=simulcast`, `a=rid` and acknowledge the rid header extension, but we are not requiring it to actually stand behind what signaling these attributes means? If the endpoint does not signal `a=rid` or `a=simulcast` simulcast cannot be used and the PC will revert to sending only the first layer. The alternative would be to introduce something like @murillo128 suggested `a=rid:a send ssrc=123`. But this would be new SDP grammar. It seems that unless the SDP is munged to add `a=rid` and `a=simulcast`, changes have to be made to SFUs to support the spec-compliant scenario. If it is the intent of owners of these endpoints to munge the SDP to achieve this, then there is a supported legacy scenario that already covers the behavior. -- GitHub Notification of comment by amithilbuch Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1174#issuecomment-468400511 using your GitHub account
Received on Thursday, 28 February 2019 19:16:03 UTC