Draft: draft-ietf-rtcweb-jsep

Commentary: Still have a bunch of stuff to flesh out , but wanted to get this out for initial review . 
 Looks like good stuff to me . - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs . 
 Thanks for the comments . Ran out of time to resolve them today but will take another shot at it Saturday . 
 Updated based on comments . I 'd like to go ahead and merge this ASAP , and then hopefully still get another rev in before the deadline . 
 I 'm fine with merging what we have here right now . 
 The text relies on the phrase " most recent gathering phase " to describe which candidates are present in SDP . Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section ( or component thereof ): when a new m= section is ( which happens for a new RTCPeerConnection obviously ) when an m= section did have a port of 0 , but is repurposed for new media ( basically the same scenario as above ) ICE restart This needs a clearer definition , or maybe just a single clear description of what it means to do this . This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription . 
  , could you give us a PR that would satisfy you
Paragraph (version A):
The session description must follow the rules defined in RFC3264,
Section 6.
Paragraph (version A):
For each m= section, the protocol value MUST exactly match the
protocol value in the corresponding m= section in the associated
offer.
Paragraph (version B):
DTLS fingerprint values, where at least one fingerprint MUST be
present.
Paragraph (version B):
The session description must follow the rules defined in RFC3264,
Section 6, including the requirement that the number of m=
sections MUST exactly match the number of m= sections in the
associated offer.
Paragraph (version B):
For each m= section, the media type and protocol values MUST
exactly match the media type and protocol values in the
corresponding m= section in the associated offer.
Paragraph (version B):
For each specified payload type, establish a mapping between
the payload type ID and the actual media format.  [TODO: ref]
If any indicated payload type is unknown, this MUST result in
an error.
Paragraph (version B):
If the directional attribute is of type "sendrecv" or
"recvonly", enable receipt and decoding of media.
Paragraph (version B):
If the description is of type "offer", and the ICE ufrag or
password changed from the previous remote description, [TODO:
ref], mark that an ICE restart is needed.
Paragraph (version B):
Configure the ICE components associated with this media section to
use the supplied ICE remote ufrag and password for their
connectivity checks.
Paragraph (version B):
Pair any supplied ICE candidates with any gathered local
candidates, as described in [TODO: ref] and start connectivity
checks with the appropriate credentials.
Paragraph (version B):
Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in the sec.applying-an-answer section
below.
Paragraph (version B):
In addition to the steps mentioned above for processing a local or
remote description, the following steps are performed when processing
a description of type "pranswer" or "answer".
Paragraph (version B):
If no valid DTLS connection exists, prepare to start a DTLS
connection, using the specified roles and fingerprints, on any
underlying ICE components, once they are active.