Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls?

[Sergio Garcia Murillo <[e-mail]>]

By the way, according to the simulcast draft that should not be a 
problem at all:

    An answerer that receives an offer with simulcast that lists a number
    of simulcast streams, MAY reduce the number of simulcast streams in
    the answer, but MUST NOT add simulcast streams.


On 05/11/2018 14:22, Iñaki Baz Castillo wrote:
> May be, but without knowing in advance the limit in different 
> devices/browsers, how many rids do you expect those SFUs will place in 
> the offer? It would be the "lowest common denominator" which would not 
> satisfy to anyone.
>
> El lun., 5 nov. 2018 14:17, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[e-mail]>> escribió:
>
>     if remote offer has more rids than what the browser support then
>     the m line should be rejected.
>
>
>     El lun., 5 nov. 2018 14:14, Iñaki Baz Castillo <[e-mail]
>     <mailto:[e-mail]>> escribió:
>
>         As Harlad said before, sender.getParameters() should not
>         return more times than the number of encodings the browser
>         supports, so of the remote offer has more than those, we have
>         an API problem.
>
>         El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo
>         <[e-mail]
>         <mailto:[e-mail]>> escribió:
>
>             On 05/11/2018 12:45, Harald Alvestrand wrote:
>             > I do fear that simulcast will continue to affect parts
>             of the spec that
>             > we don't expect it to. But we don't have the luxury of
>             specifying it
>             > halfway; either we rip it out altogether, or we specify
>             it in enough
>             > detail for interoperable implementation.
>
>             I agree to that. If we are able to find an "easy" (i.e.
>             not introducing
>             too many changes) I would not have any issues adding
>             support to that.
>
>             Something like:
>
>             - Browser adds a track via addTrack
>
>             - Browser call SRD with a recv simulcast m-line offer
>
>             - The transceiver is created with one send encoding per
>             rid offered by
>             the SFU with default values and all send encodings except
>             first one with
>             active=false (this would be the only required change)
>
>             ----- browser encodes/sends a single rtp stream, same as
>             if the remote
>             offer was a non simulcast stream--
>
>             -Browser calls sender.getParameters(), modifies the
>             desired send
>             encoding parameters ( scaleResolutionDownBy, maxFramerate,
>             maxBitrate,
>             etc) and enables them by setting active=true
>
>             Would this approach fulfill the requirements?
>
>             Best regards
>
>             Sergio
>
>