Original text:
additional offer/answer exchanges. Regarding ICE RFC8445, JSEP decouples the ICE state machine from the <del> overall signaling state machine, as the ICE state machine must remain in the JSEP implementation, because only the implementation has the </del>  necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport.  For provisional answers. In RFC3264, the constraint at the signaling level is that only one <del> offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del>  Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer") The createAnswer method generates a blob of SDP that contains an SDP answer per RFC3264 with the supported configuration for the session that is compatible with the parameters supplied in the most recent <del> call to setRemoteDescription, which MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </del>  candidates that have been gathered by the ICE agent.  An options parameter may be supplied to provide additional control over the generated answer. section. Each "m=" section, provided it is not marked as bundle-only, MUST <del> generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </del>  For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST The example in sec.detailed-example shows a more involved case of "LS" group generation. <del> The next step is to generate "m=" sections for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </del>  offer that are also valid as media-level attributes are considered to be present in each "m=" section.  Each offered "m=" section will have an associated RtpTransceiver, as described in sec.applying-a-remote-

Reviewer comments:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM

Revised text:
additional offer/answer exchanges. Regarding ICE RFC8445, JSEP decouples the ICE state machine from the  <ins> overall signaling state machine.  The ICE state machine must remain in the JSEP implementation because only the implementation has the </ins> necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport.  For provisional answers. In RFC3264, the constraint at the signaling level is that only one  <ins> offer can be outstanding for a given session, but at the JSEP level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer") The createAnswer method generates a blob of SDP that contains an SDP answer per RFC3264 with the supported configuration for the session that is compatible with the parameters supplied in the most recent  <ins> call to setRemoteDescription; setRemoteDescription MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </ins> candidates that have been gathered by the ICE agent.  An options parameter may be supplied to provide additional control over the generated answer. section. Each "m=" section, provided it is not marked as bundle-only, MUST  <ins> contain a unique set of ICE credentials and a unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </ins> For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST The example in sec.detailed-example shows a more involved case of "LS" group generation.  <ins> The next step is to generate a "m=" section for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </ins> offer that are also valid as media-level attributes are considered to be present in each "m=" section.  Each offered "m=" section will have an associated RtpTransceiver, as described in sec.applying-a-remote-