Change:
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. NAME do you want to take another pass? NAME do you want to take a look?
LGTM

Discussion:
parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> 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. </del> <ins> 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. 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. </ins> Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their

described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has <del> 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. </del> <ins> 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. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any

If the m= section proto value indicates use of SCTP: <del> If no SCTP association yet exists, prepare to initiate a SCTP </del> <ins> 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". If no valid SCTP association exists, prepare to initiate a SCTP </ins> 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