Draft: draft-ietf-rtcweb-jsep

Commentary: Also fix a bunch of TODOs and a few places where text was obsolete . 
 I suspect we might need to say a bit more in this section this but this all looks good good so LGTM
Paragraph (version B):
Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as
described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line
MUST also be filled in with the port and address of the
appropriate default candidate, either the default RTP or RTCP
candidate, depending on whether RTCP multiplexing is currently
active or not.  Note that if RTCP multiplexing is being offered,
but not yet active, the default RTCP candidate MUST be used, as
indicated in RFC5761, section 5.1.3.  In each case, if no
candidates of the desired type have yet been gathered, dummy
values MUST be used, as described above.
Paragraph (version A):
The createOffer method takes as a parameter an RTCOfferOptions
object.  Special processing is performed when generating a SDP
description if the following constraints are present.
Paragraph (version B):
The createOffer method takes as a parameter an RTCOfferOptions
object.  Special processing is performed when generating a SDP
description if the following options are present.
Paragraph (version A):
The createAnswer method takes as a parameter an RTCAnswerOptions
object.  Special processing is performed when generating a SDP
description if the following constraints are present.
Paragraph (version A):
Handling of the "VoiceActivityDetection" option in answers is the
same as is indicated for offers in sec.voiceactivitydetection1.
Paragraph (version B):
When createAnswer is called a second (or later) time, or is called
after a local description has already been installed, the processing
is somewhat different than for an initial answer.
Paragraph (version B):
The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment if the session
description changes in any way from the previously generated
answer.
Paragraph (version B):
The "s=" and "t=" lines MUST stay the same.
Paragraph (version B):
Each "m=" and c=" line MUST be filled in with the port and address
of the default candidate for the m= section, as described in
RFC5245, Section 4.3.  Note, however, that the m= line protocol
need not match the default candidate, because this protocol value
must instead match what was supplied in the offer, as described
above.  Each "a=rtcp" attribute line MUST also be filled in with
the port and address of the appropriate default candidate, either
the default RTP or RTCP candidate, depending on whether RTCP
multiplexing is enabled in the answer.  In each case, if no
candidates of the desired type have yet been gathered, dummy
values MUST be used, as described in the initial answer section
above.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same.
Paragraph (version B):
Within each m= section, for each candidate that has been gathered
during the most recent gathering phase (see sec.ice-gather-
overview), an "a=candidate" line MUST be added, as specified in
RFC5245, Section 4.3., paragraph 3.  If candidate gathering for
the section has completed, an "a=end-of-candidates" attribute MUST
be added, as described in I-D.ietf-mmusic-trickle-ice,
Section 9.3.
Paragraph (version B):
For MediaStreamTracks that are still present, the "a=msid",
"a=ssrc", and "a=ssrc-group" lines MUST stay the same.
Paragraph (version B):
The createAnswer method takes as a parameter an RTCAnswerOptions
object.  The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the OfferToReceiveAudio,
OfferToReceiveVideo, and IceRestart options mentioned in sec.options-
handling1 are meaningless in the context of generating an answer, as
there is no need to generate extra m= lines in an answer, and ICE
credentials will automatically be changed for all m= lines where the
offerer chose to perform ICE restart.
Paragraph (version B):
The following options are supported in RTCAnswerOptions.
Paragraph (version B):
Silence suppression in the answer is handled as described in
sec.voiceactivitydetection1.