Original text:
m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic- <del> 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. </del>  DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the 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 <del> channel. </del>  If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any

Reviewer comments:
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: URL
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
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked

Revised text:
m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> 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. </ins> Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic-  <ins> 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. </ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the 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  <ins> 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. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any