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

[Harald Alvestrand <[e-mail]>]

On 11/05/2018 11:16 PM, Bernard Aboba wrote:
> Harald said: 
>
> "Note that our current spec text says that when addTrack is called, a
> transceiver is created with the max number of simulcast encodings set to
> 1, and that this number cannot be increased. This would have to change."
>
> [BA] Most of the code examples I have seen that use addTrack for
> simulcast call setParameters prior to createOffer().  To allow this,
> we might consider saying that when addTrack returns, the encodings are
> initially null, and so can be set by setParameters(). 

We could also allow the number of encodings to be changed in general,
with the proviso that if you increase the number, you have to inspect
the result to see how many you got (browser would drop extra elements).

But this is now deep in API-land, and has wandered far from the original
point: That JSEP doesn't allow configuring simulcast from an incoming offer.

I think that if JSEP did not make this statement, it would be OK - since
we would then be able to obey the rules in -simulcast (if the browser
supported it), and leave the rest of the discussion to the API documents.

>
> On Mon, Nov 5, 2018 at 4:30 PM Harald Alvestrand <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote:
>     > 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?
>
>     Yes, I believe so. This is also precisely what I was proposing, except
>     for the requirement to call addTrack.
>
>     Note that our current spec text says that when addTrack is called, a
>     transceiver is created with the max number of simulcast encodings
>     set to
>     1, and that this number cannot be increased. This would have to
>     change.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
Surveillance is pervasive. Go Dark.