Closed
Bug 1191343
Opened 9 years ago
Closed 9 years ago
DTLS re-negotation is fired on an established session when setting a new remote description
Categories
(Core :: WebRTC, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: jmillan, Unassigned)
Details
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.
Reporter | ||
Updated•9 years ago
|
Summary: dtls → DTLS re-negotation is fired on an established session when setting a new remote description
Reporter | ||
Comment 1•9 years ago
|
||
Note: prior to the 'new' DTLS handshake FF sends a STUN Binding request with a different username attribute too.
Reporter | ||
Comment 2•9 years ago
|
||
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
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•