User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.15 Safari/537.36 Steps to reproduce: Simply re-negotiate a SDP on an ongoing WebRTC session Actual results: As soon as RTCPeerConnection::setRemoteDescription() is executed with the new remote SDP, FF sends a DTLS alert (close notify) and starts a new handshake by it's own, with a fingerprint which differs from that used in the initial negotiation. This happens before the new RTCPeerConnection local description (with the new fingerprint attribute) can be transmitted to the other peer, meaning that the DTLS server will fail on the handshake if it compares the fingerprint of the SDP and the one from the handshake. Expected results: No DTLS renegotiation should happen. NOTE: Also happens in nightly version.
Summary: dtls → DTLS re-negotation is fired on an established session when setting a new remote description
Note: prior to the 'new' DTLS handshake FF sends a STUN Binding request with a different username attribute too.
Hi, The RTCPeerConnection was being closed and a new one created on signalling re-renegotiation. So there was no RTCPeerConnection re-negotiation at all. It always was the initial handshake for two different RTCPeerConnections. Sorry for the noise. I hope no one did start checking it yet.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.