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

On 07/12/2018 08:10 PM, Bernard Aboba wrote:
>
> 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 SDPis 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.
>

It seems that -jsep took away the requirement to generate a=ssrc in
version -17. Should we attempt to add it back, or should we just depend
on the good graces of the implementors?


>
>
> ------------------------------------------------------------------------
> *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.
> >
> >
> > "
> >
>
>

-- 
Surveillance is pervasive. Go Dark.