W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2019

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

From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Feb 2019 19:16:02 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-468400511-1551381360-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:55 UTC