Draft: draft-ietf-rtcweb-jsep

Commentary: ICE credentials , DTLS fingerprint and SCTP port are allowed to change , which is necessary to support sequential forking with pranswers . 
 I still need to read this all carefully but at first glance looks reasonable to me . 
 LGTM . do you want to take another pass ? do you want to take a look ? 
 LGTM
Paragraph (version A):
If the ICE ufrag or password changed from the previous remote
description, then an ICE restart is needed, as described in
Section 9.1.1.1 of RFC5245.  If the description is of type
"offer", mark that an ICE restart is needed.  If the description
is of type "answer" and the current local description is also an
ICE restart, then signal the ICE agent to begin checks as
described in Section 9.3.1.1 of RFC5245.  An answer MUST change
the ufrag and password in an answer if and only if ICE is
restarting, as described in Section 9.2.1.1 of RFC5245.
Paragraph (version B):
If the PeerConnection state is "have-local-offer", and the ICE
ufrag or password changed from the previous remote description,
then an ICE restart is needed, as described in Section 9.1.1.1 of
RFC5245.  If the description is of type "offer", note that an ICE
restart is needed.  If the description is of type "answer" or
"pranswer" and the current local description is also an ICE
restart, then signal the ICE agent to begin checks as described in
Section 9.3.1.1 of RFC5245.  An answerer MUST change the ufrag and
password in an answer if and only if ICE is restarting, as
described in Section 9.2.1.1 of RFC5245.
Paragraph (version B):
If the PeerConnection state is "have-remote-pranswer", and the ICE
ufrag or password changed from the previous provisional answer,
then signal the ICE agent to discard any previous ICE check list
state for the m= section and begin checks as if this were the
first answer.  However, such an answer MAY only change the ICE
ufrag or password if the local offer is starting or restarting ICE
for the m= section.
Paragraph (version A):
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.
Paragraph (version B):
If the remote DTLS fingerprint has been changed or the dtls-id has
changed, tear down the DTLS connection.  This includes the case
when the PeerConnection state is "have-remote-pranswer".  If a
DTLS connection needs to be torn down but the answer does not
indicate an ICE restart or, in the case of "have-remote-pranswer",
new ICE credentials, 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.
Paragraph (version A):
If no SCTP association yet exists, prepare to initiate a SCTP
association over the associated ICE component and DTLS
connection, using the local SCTP port value from the local
description, and the remote SCTP port value from the remote
description, as described in I-D.ietf-mmusic-sctp-sdp,
Section 10.2.
Paragraph (version B):
If an SCTP association exists, and the remote SCTP port has
changed, discard the existing SCTP association.  This includes
the case when the PeerConnection state is "have-remote-
pranswer".
Paragraph (version B):
If no valid SCTP association exists, prepare to initiate a SCTP
association over the associated ICE component and DTLS
connection, using the local SCTP port value from the local
description, and the remote SCTP port value from the remote
description, as described in I-D.ietf-mmusic-sctp-sdp,
Section 10.2.