Does an ICE restart always result in a new DTLS connection?

[aboba]

Discussion on the MMUSIC list as to whether an ICE restart necessitates a new DTLS connection:
https://www.ietf.org/mail-archive/web/mmusic/current/msg18121.html

If the MMUSIC WG decides that an ICE restart does not always result in a new DTLS connection (that is where discussion seems to be leading), then there would be a need for ORTC to enable a DtlsTransport to change from one IceTransport to another (e.g. DtlsTransport.setTransport).

[rshpount]

Even though ICE restart does not always creates a new DTLS association, either offering or answering end point can always force a new DTLS association to be created during ICE restart. All it needs to do is to provide a new tls-id or fingerprints. Neither offering no answering side can force DTLS association to span multiple transports. Both end points need to agree (provide existing tls-id) to do so. Keep in mind, that the reason DTLS association might want to continue after ICE restart can be due to the same candidates being reused. If the same candidate pair is used after ICE restart, new DTLS association cannot be established without de-mux issues.

[aboba]

ORTC allows an existing RTCIceTransport to be restarted via a call to iceTransport.start(newGatherer, newRemoteParameters). So an ICE restart does not require a new DtlsTransport. If an answering endpoint forces a new DTLS association by providing a new tls-id or fingerprints, then currently ORTC would require creation of a new DtlsTransport. A new IceTransport would also be needed since multiple DtlsTransports cannot be multiplexed over a single IceTransport. But that problem is covered by Issue #755, so closing this one.