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> wrote:
> 
> Harald has raised a rather interesting question in Issue 2014 (https://github.com/w3c/webrtc-pc/issues/2014 <https://github.com/w3c/webrtc-pc/issues/2014>). 
> 
> 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