Change:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.

Discussion:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer API.  The <del> application then uses that offer to set up its local config via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </del> <ins> application then uses that offer to set up its local configuration via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer API to generate an appropriate answer, applies it using

decoupling of the ICE and signaling state machines allows it to accommodate either model. <del> Through its abstraction of signaling, the JSEP approach does require the application to be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </del> <ins> Although it abstracts signaling, the JSEP approach requires that the application be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer;

willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are <del> declarative, and the remote side MUST either accept them or reject </del> <ins> declarative, and the remote side must either accept them or reject </ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered

RFC8839.  Note that this field does not contain an "a=" prefix, as indicated in the following example: <del> The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </del> <ins> The IceCandidate object contains a field to indicate which ICE username fragment (ufrag) it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </ins> The IceCandidate object also contains fields to indicate which "m=" section it is associated with, which can be identified in one of two

3.6.1. <del> The receiver will first intersect any known local limits (e.g., hardware decoder capabilities, local policy) to determine the </del> <ins> The receiver will first combine any known local limits (e.g., hardware decoder capabilities or local policy) to determine the </ins> absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. If these local limits preclude receiving any video, i.e., the

The createOffer method generates a blob of SDP that contains an offer per RFC3264 with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the <del> codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </del> <ins> codec, RTP, and RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </ins> parameter may be supplied to provide additional control over the generated offer.  This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing

functionality for the session (functionality that is supported but not desired by default may be omitted); for each SDP line, the generation of the SDP will follow the process defined for generating <del> an initial offer from the document that specifies the given SDP line. The exact handling of initial offer generation is detailed in </del> <ins> an initial offer from the specification that defines the given SDP line.  The exact handling of initial offer generation is detailed in </ins> sec.initial-offers below. In the event createOffer is called after the session is established,

As an answer, the generated SDP will contain a specific configuration that specifies how the media plane should be established; for each SDP line, the generation of the SDP MUST follow the process defined <del> for generating an answer from the document that specifies the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </del> <ins> for generating an answer from the specification that defines the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </ins> Session descriptions generated by createAnswer MUST be immediately usable by setLocalDescription; like createOffer, the returned