Draft: draft-ietf-rtcweb-jsep

Commentary: I do n't think this is quite ready , but PTAL 
 PTAL
Paragraph (version B):
An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp
Section 5.2.
Paragraph (version A):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=fingerprint", and "a=setup" lines MUST be included as mentioned
above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-
port" line referencing the SCTP port number as defined in I-D.ietf-
mmusic-sctp-sdp, Section 4.1.
Paragraph (version B):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as
mentioned above, along with an "a=fmtp:webrtc-datachannel" line and
an "a=sctp-port" line referencing the SCTP port number as defined in
I-D.ietf-mmusic-sctp-sdp, Section 4.1.
Paragraph (version A):
An "a=setup" line, as specified in RFC4145, Section 4, and
clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED.
Paragraph (version B):
An "a=setup" line, as specified in RFC4145, Section 4, and
clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED.  The role value MUST be consistent
with the existing DTLS connection, if one exists and is being
continued.
Paragraph (version B):
An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp
Section 5.3.
Paragraph (version A):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=candidate", "a=fingerprint", and "a=setup" lines MUST be included
under the conditions described above, along with an "a=fmtp:webrtc-
datachannel" line and an "a=sctp-port" line referencing the SCTP port
number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1.
Paragraph (version B):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST
be included under the conditions described above, along with an
"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-
sdp, Section 4.1.
Paragraph (version B):
If present, a single "a=dtls-id" line is parsed as specified in I-
D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored.
Paragraph (version A):
If present, a single "a=setup" line is parsed as specified in
RFC4145, Section 4, and the setup value is stored.
Paragraph (version B):
dtls-id value, which MUST be set according to I-D.ietf-mmusic-
dtls-sdp Section 5.  If this is a re-offer and the dtls-id
value is different from that presently in use, the DTLS
connection is not being continued and the remote description
MUST be part of an ICE restart, together with new ufrag and
password values.  If this is an answer, the dtls-id value, if
present, MUST be the same as in the offer.
Paragraph (version B):
DTLS setup value, which MUST be set according to the rules
specified in RFC5763, Section 5 and MUST be consistent with the
selected role of the current DTLS connection, if one exists and
is being continued.
Paragraph (version A):
If the remote DTLS fingerprint has been changed, tear down the
existing DTLS connection.
Paragraph (version B):
If the remote DTLS fingerprint has been changed or the dtls-id has
changed, tear down the DTLS connection.  If a DTLS connection
needs to be torn down but the answer does not indicate an ICE
restart, an error MUST be generated.  If an ICE restart is
performed without a change in dtls-id or fingerprint, then the
same DTLS connection is continued over the new ICE channel.