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

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

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]> 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]> 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
>>
>>
>>