Re: [webrtc-pc] Not clear how to set # of layers when answering an offer with a track

@fippo @alvestrand  This seems like quite an important question to answer. 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. 

In such a situation, the application will receive a track event providing the transceiver that has been created as a result applying the SFU's Offer in setRemoteDescription(). To configure that transceiver to send simulcast, the only viable mechanism is transceiver.sender.setParameters(). In such a situation, I wouldn't expect that transceiver.sender.getParameters() would return much information of interest since the sender hasn't been configured and transceiver.receiver.getParameters() provides minimal information on what was Offered (only the number of encodings to be received and the rid). 

The part that makes me uncomfortable is that while an Offer to send simulcast can be responded to by an Answer with an indication of willingness to receive, an Answer specifying simulcast sending cannot. So what happens if the browser want to send simulcast to the the SFU, but the SFU doesn't want it to do so? 

Section 5.4.1 says "This specification does not define how to configure createOffer to receive multiple RTP encodings."  I believe this statement should be expanded to apply to createAnswer as well, since there is no receiver.setParameters() method.

-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2014#issuecomment-432874655 using your GitHub account

Received on Thursday, 25 October 2018 00:42:56 UTC