Original text:
SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]] <del> Lastly, while the exact media parameters are only known only after a </del>  offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where <del> the app specifies the number of media streams to gather candidates for.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del>  application immediately via the ICE candidate callback.  If the pool becomes depleted, either because a larger-than-expected number of media streams is used, or because the pool has not had enough time to RFC3261 defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of <del> the media plane which is relevant.  When forking happens at the </del>  signaling layer, the Javascript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Otherwise, it MUST use the same <del> ICE credentials and candidates that were used in the m= section that it is being bundled into.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </del>  For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they <del> MUST all have the same RFC4572fingerprint value, or this value MUST </del>  be a session-level attribute. Each m= section should be generated as specified in RFC4566, For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the <del> payload type fo the primary codec, as specified in RFC4588, </del>  Section 8.1. For each supported FEC mechanism, a corresponding "a=rtpmap" line further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should <del> then generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </del>  SAVPF".  If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each associated local MediaStreamTrack, the appropriate directionality attribute, as specified in RFC3264, Section 6.1.  If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and <del> there a local MediaStreamTrack has been associated, the </del>  directionality MUST be set as sendrecv.  If the offer was sendonly, and the remote MediaStreamTrack is still "live", the directionality MUST be set as recvonly.  If the offer was For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  For audio, the codecs specified in I- <del> D.ietf-rtcweb-audio, Section 3, MUST be be supported.  Note that for simplicity, the answerer MAY use different payload types for </del>  codecs than the offerer, as it is not prohibited by Section 6.1. If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an <del> "a=fmtp" line that references the payload type fo the primary </del>  codec, as specified in RFC4588, Section 8.1. For each supported FEC mechanism that is present in the offer, a gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. <del> For the current default candidate, a "c=" line, as specific in </del>  RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1.

Reviewer comments:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep

Revised text:
SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]]  <ins> Lastly, while the exact media parameters are only known only after an </ins> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where  <ins> the app specifies the number of media streams for which to gather candidates.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate callback.  If the pool becomes depleted, either because a larger-than-expected number of media streams is used, or because the pool has not had enough time to RFC3261 defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of  <ins> the media plane that is relevant.  When forking happens at the </ins> signaling layer, the Javascript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Otherwise, it MUST use the same  <ins> ICE credentials and candidates as the m= section into which it is being bundled.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </ins> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they  <ins> MUST all have the same RFC4572 fingerprint value, or this value MUST </ins> be a session-level attribute. Each m= section should be generated as specified in RFC4566, For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the  <ins> payload type of the primary codec, as specified in RFC4588, </ins> Section 8.1. For each supported FEC mechanism, a corresponding "a=rtpmap" line further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should  <ins> then be generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </ins> SAVPF".  If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each associated local MediaStreamTrack, the appropriate directionality attribute, as specified in RFC3264, Section 6.1.  If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and  <ins> there is a local MediaStreamTrack that has been associated, the </ins> directionality MUST be set as sendrecv.  If the offer was sendonly, and the remote MediaStreamTrack is still "live", the directionality MUST be set as recvonly.  If the offer was For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  For audio, the codecs specified in I-  <ins> D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for </ins> codecs than the offerer, as it is not prohibited by Section 6.1. If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an  <ins> "a=fmtp" line that references the payload type of the primary </ins> codec, as specified in RFC4588, Section 8.1. For each supported FEC mechanism that is present in the offer, a gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3.  <ins> For the current default candidate, a "c=" line, as specified in </ins> RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1.