Draft: draft-ietf-rtcweb-jsep

Commentary: In section 5.10 , the text that says to tear down the old TLS connections seems like it needs a tweek . For the case of a PR_ANS , I would expect it to not get torn down until the resources are freed when the ANS happens . 
 See : 
 We had a call to discuss and I think reached resolution on the SDP issue . I will prepare a PR and send to the list for approval . Separately we need to close on tls - id size , but that need not hold JSEP if we are willing to have the examples use the longer size ( which we all agree is permitted ) 
 Update : we had a call to discuss this and I think have resolution on the SDP semantics . I will prepare a PR for that and send to lists . Separately , we have to discuss the S 
  says : values . If this is an answer , the tls - id value , if present , MUST be the same as in the offer.</tBut tls - ids are independently generated on each side . 
 Examples / example generator will also need to get tweaked
Paragraph (version B):
Each "a=tls-id" line MUST stay the same unless the offerer's
"a=tls-id" line changed, in which case a new "a=tls-id" value MUST
be created, as described in I-D.ietf-mmusic-dtls-sdp, Section 5.2.
Paragraph (version A):
tls-id value, which MUST be set according to I-D.ietf-mmusic-
dtls-sdp, Section 5.  If this is a re-offer and the tls-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 tls-id value, if
present, MUST be the same as in the offer.
Paragraph (version B):
tls-id value, which MUST be set according to I-D.ietf-mmusic-
dtls-sdp, Section 5.  If this is a re-offer or a response to a
re-offer and the tls-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.
Paragraph (version A):
If the remote DTLS fingerprint has been changed or the tls-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 tls-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 tls-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 tls-id or fingerprint,
then the same DTLS connection is continued over the new ICE
channel.  Note that although JSEP requires that answerers change
the tls-id value if and only if the offerer does, non-JSEP
answerers are permitted to change the tls-id as long as the offer
contained an ICE restart.  Thus, JSEP implementations which
process DTLS data prior to receiving an answer MUST be prepared to
receive either a ClientHello or data from the previous DTLS
connection.