Re: Some ideas on SVC support in WebRTC 1.0 (Take 2)

Harald said:


"Bernard, I believe you reported some pushback on the removal from SFU
vendors in relation to the discussion about switching to Unified Plan
(where explict SSRCs in the SDP is not required).

But I can't find an issue on that now. Do we need to raise one?"


[BA] Here is the issue: https://github.com/w3c/webrtc-pc/issues/1174


Since SFUs currently do not support RID header extensions and SSRC multiplexing is widely used, SFU vendors need a way to obtain the SSRCs so as to allow them to be signaled.


At this point, it appears that "a=ssrc" lines will be included in Unified Plan implementations, so that SFU vendor needs can be met that way.  Given this, there did not appear to be a compelling reason to revert the removal of SSRCs from the object model.



________________________________
From: Harald Alvestrand <harald@alvestrand.no>
Sent: Wednesday, July 11, 2018 11:57:11 PM
To: public-webrtc@w3.org
Subject: Re: Some ideas on SVC support in WebRTC 1.0 (Take 2)

Bernard, I believe you reported some pushback on the removal from SFU
vendors in relation to the discussion about switching to Unified Plan
(where explict SSRCs in the SDP is not required).

But I can't find an issue on that now. Do we need to raise one?

Den 11. juli 2018 18:59, skrev Bernard Aboba:
> Harald said:
>
> "> The problem of having each SVC layer defined in a
>> RTCRtpEncodingParameters entry (within encodings array) is that all
>> those entries belonging to the same stream must share LOT of fields
>> (such as pt, ssrc, etc). Super error prune IMHO.
>>
>
> RTCRtpEncodingParameters doesn't contain either pt or ssrc. Perhaps it
> should have for the simulcast case (didn't we have an issue on that?),
> but at present it doesn't.
>
> These would be read-only, I think, so the only source of error is the
> browser, not the user's app."
>
> [BA] Right.
>
> We removed PT and SSRC from RTCRtpEncodingParameters as well as RTCRtpRtxParameters and RTCRtpFecParameters because we did
> not expect WebRTC 1.0 browser applications (as opposed to SDP-consuming
> servers) to use this (read-only) information.
>
> BTW, it does not appear necessary to reintroduce those parameters to support SVC, assuming we only support SRST codecs.
>
>
> "
>