WebRTC DTLS re-negotiation and how to avoid it
Imagine you are on a WebRTC call on your mobile. You start it in the office and walk out of the building to get lunch. As you walked out of the building, your phone switched from the office WiFi network to the cellular network; thus, your IP address has changed.
What happened under the hood is that a new RTCPeerConnection was created and DTLS re-negotiated.
The problem with this is twofold:
- User experience is hindered as DTLS re-negotiation takes time and user may think call dropped
- DTLS negotiation takes server resources that can be spared if re-negotiation is avoided
Virtual DTLS connections come to solve both of these problems.
With this change, as long as the DTLS fingerprint (that’s a hash of the DTLS key) doesn’t change, the existing peer connection will continue and DTLS will not be renegotiated.
DTLS negotiation is done at the browser level, so there is nothing for the application to do for this to work. The only thing the application will need to do is to re-exchange the SDP offer/answer, but that would be required anyway if the IP address changed.
This is making its way, in several pieces, into in-progress IETF drafts. It will still be at least six months before it’s finalized, but implementations will exist before then.
DTLS-SRTP is defined in RFC 5764 and is used to protect data carried over a single UDP source and destination port pair (single connection). Originally it was designed for cases where the IP address is fixed. WebRTC, on the other hand, is being used quite often in scenarios where the IP address changes.
Since DTLS setup can be time and resource intensive, maintaining the same DTLS connection where possible, even if the underlying network path changes, is valuable. At the IETF meeting, the general consensus was the following:
- Consider the ICE-obtained connection to be a “virtual connection” that is largely treated as constant even if the specific source and/or destination change.
- Within the same communication/peer connection, despite multiple offers and answers, the browser/user agent will keep the same DTLS connection, UNLESS it needs to change fingerprints (change the DTLS key), in which case it will re-initialize DTLS.
- If anything else is broken, it will tear down the communication/peer connection (requiring the app to create a new one if desired)