DTLS re-negotation is fired on an established session when setting a new remote description

RESOLVED INVALID

Status

()

Core
WebRTC
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: José Luis Millán, Unassigned)

Tracking

39 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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

3 years ago
Summary: dtls → DTLS re-negotation is fired on an established session when setting a new remote description

Updated

3 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
(Reporter)

Comment 1

3 years ago
Note: prior to the 'new' DTLS handshake FF sends a STUN Binding request with a different username attribute too.
(Reporter)

Comment 2

3 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
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.