1307996 - Implement RTCDtlsTransport.iceTransport

Status: NEW

(Core :: WebRTC: Networking, enhancement, P3)

Description

[Nils Ohlmeier [:drno]]

Per latest webrtc spec we are missing the RTCDtlsTransport interface.
https://w3c.github.io/webrtc-pc/#rtcdtlstransport-interface

At least partially implementing this interface, specifically the |state| attribute and |onstatechange| event, would allow WebRTC site to detect for the first time if something went wrong with DTLS. Implementing these two should be easy as it only means we would expose internal variables of the transportlayerdtls code.

Allowing to fetch the remote certificate and getting a handle to the RTCIceTransport (bug 1307994) is probably a little bit more effort.

Comment 1

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 2

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 3

[Byron Campen [:bwc]]

We had to disable some stuff over in wpt (bug 1517444) for this recently.

Comment 4

[Marcin Rataj]

Is this still on the roadmap?

With RTCDtlsTransport API: getRemoteCertificates the networking stack used by js-ipfs (js-libp2p) should be able to let WebRTC handle encryption & stream muxing in the browser, improving overall performance.

Comment 5

[Byron Campen [:bwc]]

Roughly speaking, this is on the roadmap after get/setParameters is brought up to spec.

Comment 6

[Byron Campen [:bwc]]

Was misnamed. We have this, but are missing iceTransport, getRemoteCertificates(), and onerror. Repurposing. Will update wpt meta file links accordingly.

Comment 7

[Byron Campen [:bwc]]

Safari seems to partially support this (is missing RTCIceTransport.getRemoteCandidates()).

Comment 8

[Jim Mathies [:jimm]]

I don't feel this should be a webcompat priority. We generally work on things that partners ask us for and no one has mentioned support for these. Will chat with the team about it though.

Comment 9

[Thomas Wisniewski [:twisniewski]]

We can certainly lower the webcompat risk, but I would still consider it at least a moderate risk (unless we're more confident now than before that sites will at least reach out to us if they run into a WebRTC compat issue, rather than just blocking Firefox).

Comment 10

[Jim Mathies [:jimm]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #9)

We can certainly lower the webcompat risk, but I would still consider it at least a moderate risk (unless we're more confident now than before that sites will at least reach out to us if they run into a WebRTC compat issue, rather than just blocking Firefox).

It's not a risk unless web sites are leveraging it and that in turn is causing breakage. WebRTC is a massive spec, every browser vendor works to complete support but there are lots of 'gaps'. The web conferencing team prioritizes everything based on partner feedback in our partner discussion groups. Bugs like this are included in spec gap metas -

Bug 1805496 - [Meta] WebRTC 1.0+extensions API gap (according to WPT)

By marking this bug or anything else in bugzilla as 'webcompat:risk-high' or webcompat:risk-moderate' you are essentially prioritizing this work over other work within a team that has limited resources. Please be conscious of that when adding these tags.

Comment 11

[Thomas Wisniewski [:twisniewski]]

I see, I understand. If you are sure the risk is lower and nobody is using this API beyond our awareness, then I'll trust your judgment.

Comment 12

[Maire Reavy [:mreavy]]

I chatted with Jim, and for tracking purposes, we're re-adding webcompat:risk-high based on likelihood of possible future breakage