Change:
Fixes URL
LGTM
Updated to incorporate feedback from comments. Some more detail needed in the last para, but the narrative should be complete.
PTAL
LGTM
In WebRTC section 5.1, addTransceiver(), it says 'When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [JSEP], the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver’s sender.getParameters() will reflect the encodings negotiated.' It is not obvious what to use as the JSEP reference because there does not seem to be a single place that talks about receipt of multiple encodings.
The specification of signalling that you can recevie multiple encodings seems to belong in either the RID spec or the JSEP spec. A decision was made some time back that WebRTC entities are only required to support receiving one incoming stream, but all the specs need to be clear on what that means in practice.
I think it makes sense for us to add some text in JSEP for this and create a link
The plan is to add a new section in JSEP section 3 that would give an overview of simulcast, perhaps a summary of URL, section 6.2.

Discussion:
3.7. <ins> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or answer, are indicated in SDP markings on the corresponding m= section, as described below.  Receivers that understand simulcast and are willing to receive it will also include SDP markings to indicate their support, and JSEP endpoints will use these markings to determine whether simulcast is permitted for a given RTPSender.  If simulcast support is not negotiated, the RTPSender will only use the first configured encoding. Note that the exact simulcast parameters are up to the sending application.  While the aforementioned SDP markings are provided to ensure the remote side can receive and demux multiple simulcast encodings, the specific resolutions and bitrates to be used for each encoding are purely a send-side decision in JSEP. 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.  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.  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. When using JSEP to transmit multiple encodings from a RTPSender, the techniques from I-D.ietf-mmusic-sdp-simulcast and I-D.ietf-mmusic-rid are used.  Specifically, when multiple encodings have been configured for a RTPSender, the m= section for the RTPSender will include an "a=simulcast" attribute, as defined in I-D.ietf-mmusic-sdp-simulcast, Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each encoding, as specfied in I-D.ietf-mmusic-rid, Section 4; the use of RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. 3.8. </ins> Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP RFC3261 defines both a "Parallel Search" and "Sequential Search".

Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.7.1. </del> <ins> 3.8.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one

with a timer; at this point, the application could reapply the pending remote description as a final answer. <del> 3.7.2. </del> <ins> 3.8.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple