[rtcweb] JSEP Section 3.7:Simulcast

[Bernard Aboba <[e-mail]>]

   JSEP currently does not provide an API to configure receipt of
   simulcast.  This means that if simulcast is offered by the remote
   endpoint, the answer generated by a JSEP endpoint will not indicate
   support for receipt of simulcast, and as such the remote endpoint
   will only send a single encoding per m= section.

[BA] In the description of addTransceiver, WebRTC 1.0 Section 5.1 states:

However whensetRemoteDescription is called with a corresponding remote
description that is able to send multiple RTP encodings as defined in
[JSEP <https://www.w3.org/TR/webrtc/#bib-JSEP>], the RTCRtpReceiver
<https://www.w3.org/TR/webrtc/#idl-def-rtcrtpreceiver> may receive
multiple RTP encodings and the parameters retrieved via the
transceiver's receiver.getParameters() will reflect the encodings
negotiated.

This appears to indicate that a JSEP endpoint may indicate support for
receipt of simulcast in an answer.

   In addition, when
   the JSEP endpoint is the answerer, the permitted encodings for the
   RTPSender must be consistent with the offer, but this information is
   currently not surfaced through any API.

[BA] Not sure what this is trying to say. Once setRemoteDescription is

called on the JSEP endpoint, won't it be possible to retrieve the sender

settings via sender.getParameters() and the receiver settings via

receiver.getParameters()?

   This means that established
   simulcast streams will continue to work through a received re-offer,
   but setting up initial simulcast by way of a received offer requires
   out-of-band signaling or SDP inspection.  Future versions of this
   specification may add additional APIs to provide this control.

[BA] Does this mean that a JSEP endpoint cannot respond to an offer to receive

simulcast with an Answer indicating that it will send simulcast? Note sure why

this would be the case, particularly if addTransceiver was called prior to

setRemoteDescription indicating the ability to send simulcast.