Re: Simulcast Issue 2014: Not clear how to set # of layers when answering an offer with a track

Nils said:

"It works already today in Firefox that the server includes simulcast and RID attributes in the offer and then Firefox generates an answer in which it indicates how many RTP simulcast streams it is willing/capable to do.

What is strange is this scenario is that the browser needs to handle all the scenarios where the amount of simulcast streams in the SDP does not match the amount of streams requested via JS API."

[BA] A few questions about the Firefox implementation:

If the SFU offers to receive a maximum of N simulcast streams, once the transceiver is provided in the track Event, does Firefox require that the application provide for N streams in transceiver.sender.setParameters()?  Or does it permit the application to provide a lesser number of streams?

For an offerer, the spec states that setParameters() cannot change the "simulcast envelope" (maximum number of streams, encoding order) established by addTransceiver via sendEncodings.  So wondering if the same constraint is enforced for an Answer, or whether Firefox allows for the application to change the number of encodings via setParameters().

b. Are all the parameters provided in the SFU Offer available in transceiver.sender.getParameters()?  I'd expect the rid, as well as the maximum number of encodings. Wondering about other parameters such as scaleResolutionDownBy, maxBitrate or maxFramerate.
________________________________
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Sent: Friday, October 26, 2018 10:53 AM
To: Bernard Aboba
Cc: public-webrtc@w3.org
Subject: Re: Simulcast Issue 2014: Not clear how to set # of layers when answering an offer with a track


On 24Oct, 2018, at 17:59, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:

Harald has raised a rather interesting question in Issue 2014 (https://github.com/w3c/webrtc-pc/issues/2014<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebrtc-pc%2Fissues%2F2014&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C63f735ef4ef84754f36508d63b6be185%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636761731889540925&sdata=YHX0Eup4cda9eSbw49UIX1bKKjJKVAvBxKNJv%2BFIJFk%3D&reserved=0>).

In a typical conference the SFU sends the Offer because it alone knows how many participants are in the conference. The SFU will typically not have simulcast configured in its Offer m-lines (because the browser typically won't support receiving simulcast). Yet the browser may be sending simulcast to the SFU, so it needs to be able to configure how many simulcast streams it will send in the Answer. How does this work?

My (somewhat shaky) response is that the SFU indicates how many simulcast streams it is willing to receive by including a=rid:x recv lines, and when the application handles the track event it can determine how many streams can be sent by consulting the number of encodings and rids included in transceiver.sender.getParameters().

It works already today in Firefox that the server includes simulcast and RID attributes in the offer and then Firefox generates an answer in which it indicates how many RTP simulcast streams it is willing/capable to do.

What is strange is this scenario is that the browser needs to handle all the scenarios where the amount of simulcast streams in the SDP does not match the amount of streams requested via JS API.

Best
   Nils Ohlmeier