Intent to deprecate and remove: RTP data channels

903 views
Skip to first unread message

Harald Alvestrand

unread,
Aug 13, 2020, 5:52:22 AM8/13/20
to blink-dev
Primary eng (and PM) emails
h...@chromium.org, dead...@chromium.org, hu...@chromium.org

Summary
We intend to remove support for the non-standard RTP data channels in WebRTC.
Users should use the standard SCTP-based data channels instead.

Motivation
RTP data channels was a nonstandard feature introduced into the WebRTC codebase at its creation. Standardization efforts resulted in the definition of SCTP-based datachannels, which are much more common, and interoperate with other browsers.
The continued support of RTP data channels adds significant complexity to the codebase.

This should be deprecated in M86, and removed in M87.

Interoperability and Compatibility Risk

Edge: Never supported
Firefox: Never supported
Safari: Never supported

Alternative implementation suggestion for web developers
Developers should switch to the standardized, interoperable SCTP datachannels.

Usage information from UseCounter
https://www.chromestatus.com/metrics/feature/popularity#RTCConstraintEnableRtpDataChannelsTrue

Entry on the feature dashboard
https://www.chromestatus.com/feature/6485681910054912

PhistucK

unread,
Aug 13, 2020, 7:45:59 AM8/13/20
to Harald Alvestrand, blink-dev
I am very much in favor (long overdue ;) I forgot it still exists), but the numbers seem a bit worrying (0.8% and growing, while the usual deprecation bar is at 0.02%).

Can you tell how many of those are Chrome-to-Chrome?
- That usage should not be problematic at all once the gradual release completes.
- During the gradual release, will it be problematic (one browser version adheres to the flag and the other does not, will data channels work?)?

Can you tell how many of those are Chrome-to-server/non-Chrome?
- Those will probably break entirely (unless they also support Firefox and feature detection), right?

☆PhistucK


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFpOSerQHXiyo4NeWfsXgyzDLOD%3D8zf9suee3zeodmU%3Dw%40mail.gmail.com.

Harald Alvestrand

unread,
Aug 13, 2020, 8:38:51 AM8/13/20
to PhistucK, blink-dev
https://www.chromestatus.com/metrics/feature/timeline/popularity/3344 hasn't populated top sites yet - the counter is rather new, basically only available in Dev and Canary. I'm not sure how chromestatus.com compensates for the lack of data from Stable.

Note - use of RTP data channels and SCTP data channels is mutually exclusive - you either use one or you use the other; there's no fallback.

PhistucK

unread,
Aug 13, 2020, 8:53:47 AM8/13/20
to Harald Alvestrand, blink-dev
I thought so - but who makes the call of what to use? Is it the offering side or the receiving side? Or both of them?

☆PhistucK

Philip Jägenstedt

unread,
Aug 13, 2020, 9:14:38 AM8/13/20
to PhistucK, Harald Alvestrand, blink-dev
https://www.chromestatus.com/metrics/feature/timeline/popularity/3344 was added in https://chromium.googlesource.com/chromium/src/+/f0fc6257ecc087c8440c5eb2592c0374893ddbbd which looks like it will be in M86, which is a long way from stable still.

I don't think that chromestatus.com compensates for this. However, we can look at the internal data and get similar numbers. Looking at data from M86 (all platforms/channels) it looks like usage is 0.88%. (This is so close I wonder if chromestatus.com does compensate...)

Anyway, this is high usage. Do you know what explains it? Is the use counter maximally conservative and only counting established connections, or could there be some overcounting?

If web developers don't do anything in response to the removal, what will the failure mode be? If it will silently fall back to SCTP, then that should significantly lower the risk of this.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JSJD19KT_SwEkzHuZJ1FpekxtrKsRKC_1WcZFaX1ReYA%40mail.gmail.com.

Harald Alvestrand

unread,
Aug 13, 2020, 9:30:53 AM8/13/20
to Philip Jägenstedt, PhistucK, blink-dev
The use counter counts every application that initializes for use of RTP data channels, whether they use them or not.
It's possible that there is a significant amount of copy/paste code out there that initializes for RTP data channels without using them.
It's also possible that there are apps that really use RTP data channels. I'm hoping to flush them out.

If developers don't do anything, the result depends on how we handle the removal:

- If we throw an exception ("overconstrained", most likely) when you attempt to set the mode post-removal: Apps will stop working
- If we ignore the attribute and default to datachannels: For browser-to-browser, we won't establish a connection with older browsers, but once both ends are upgraded, things will start working again (unless they depended on features of RTP datachannels that aren't working the same in SCTP). For browser-to-server, things will not work.

I think failing the app hard is the right thing to do. 

(to phistuck: both ends have to select the feature in order to achieve interoperation.)

Philipp Hancke

unread,
Aug 13, 2020, 9:32:37 AM8/13/20
to Philip Jägenstedt, PhistucK, Harald Alvestrand, blink-dev
Am Do., 13. Aug. 2020 um 15:14 Uhr schrieb Philip Jägenstedt <foo...@chromium.org>:
https://www.chromestatus.com/metrics/feature/timeline/popularity/3344 was added in https://chromium.googlesource.com/chromium/src/+/f0fc6257ecc087c8440c5eb2592c0374893ddbbd which looks like it will be in M86, which is a long way from stable still.

I don't think that chromestatus.com compensates for this. However, we can look at the internal data and get similar numbers. Looking at data from M86 (all platforms/channels) it looks like usage is 0.88%. (This is so close I wonder if chromestatus.com does compensate...)

Anyway, this is high usage. Do you know what explains it? Is the use counter maximally conservative and only counting established connections, or could there be some overcounting?

That is a good question actually. A lot of the crappier ip gathering scripts have been using createDatachannel("") and we've seen those skewing numbers before, e.g. during the DTLS 1.0 deprecation.
Harald: can you modify the counter to only count established connections?
 
If web developers don't do anything in response to the removal, what will the failure mode be? If it will silently fall back to SCTP, then that should significantly lower the risk of this.

Web developers should have learned by now this isn't interoperable, search discuss-webrtc or stackoverflow for the topic.
Rtp data channels have been broken a couple of times in the past, e.g. in Chrome 46:
Sadly they seem to be working again, it would have been good if it had been bust.

I suspect much of the actual usage is from a particular server system that also refuses to use DTLS instead of SDES despite the 2013 decision that SDES is a MUST-NOT. No, not hangouts, they updated :-)

Yoav Weiss

unread,
Aug 13, 2020, 11:54:49 AM8/13/20
to Philipp Hancke, Philip Jägenstedt, PhistucK, Harald Alvestrand, blink-dev
I support further constraining the counters to make them tighter and closer to actual usage. Alternatively, an HTTPArchive that tries to explain the current counter and gives us examples of actual usage might also be beneficial.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2B2V3RkuphkNP%3Dg%3D7Wqr4zxr2diqjE%3DKLTnzHoDn3G6jw%40mail.gmail.com.

Philip Jägenstedt

unread,
Aug 20, 2020, 9:02:55 AM8/20/20
to Yoav Weiss, Philipp Hancke, PhistucK, Harald Alvestrand, blink-dev
Harald, can you show an example of the typical code that would hit this use counter? Like Yoav suggests, perhaps we can search httparchive for the snippets of code involved and find out what's driving this.

If a lot of usage in the wild really does exist still, then I wonder why it's not broken in other browsers. If we're lucky, maybe there are code paths they avoid that Chrome could also avoid going down if we remove the right things. It's probably UA sniffing, but one might get lucky.

Harald Alvestrand

unread,
Aug 20, 2020, 10:03:43 AM8/20/20
to Philip Jägenstedt, Yoav Weiss, Philipp Hancke, PhistucK, blink-dev
The code will contain something like this:

 var mediaConstraints = {
    optional: [{ RtpDataChannels: true }]
  }
  var pc = new RTCPeerConnection({}, mediaConstraints)

(this is code from the test that verifies the code path in Chrome)
Other browsers never offered it, so anyone who uses it at all is probably using UA sniffing.

Philipp Hancke

unread,
Aug 25, 2020, 4:44:06 AM8/25/20
to Philip Jägenstedt, Yoav Weiss, PhistucK, Harald Alvestrand, blink-dev
a lot of that code goes back to the one shown here:
(ignoring that WebRTC stopped giving out IPs a while ago...)

We have a new counter
which ignores that (abnormal) usage and it seems to be lower.

Mike West

unread,
Sep 10, 2020, 3:27:36 PM9/10/20
to blink-dev, foo...@chromium.org, yo...@yoav.ws, phis...@gmail.com, h...@google.com
The new counter looks pretty low, which is good. Can you help us place that in terms of WebRTC usage? That is, it looks like low usage on the web at large, but is it used in a significant portion of pages that use WebRTC?

-mike
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Harald Alvestrand

unread,
Sep 10, 2020, 3:48:00 PM9/10/20
to Mike West, blink-dev, Philip Jägenstedt, Yoav Weiss, PhistucK
Fippo also added a few counters that reflect overall WebRTC usage much better; one of them (RTCPeerConnectionSetRemoteDescription, which indicates an attempt to complete negotiation, so should rarely be seen outside real usage) is here:


That counter seems to have missed the 86 cut :-( - the canary numbers are in the ballpark of 30x the "RTCLegacyRtpDataChannelNegotiated", so that indicates that RTP data channels are used in perhaps 3% of WebRTC usage cases - but it's canary numbers, so treat with suspicion.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Oct 2, 2020, 3:40:11 AM10/2/20
to Harald Alvestrand, blink-dev, Philip Jägenstedt, Yoav Weiss, PhistucK
LGTM1 to deprecate for 2 releases, and then remove.

I talked with Harald this morning, and it seems that the usage is wrapped up in a small number of large applications (legacy version of Hangouts, for instance). These applications work in Firefox, which never supported RPT data channels, so we're pretty sure they have code they can migrate to quickly. Ideally, they're feature detecting, and will Just Work. It's possible, however, that they're branching on vendor instead. We agreed that it would be reasonable to deprecate this feature for 2 releases to give them a chance to migrate, and Harald a chance to do some outreach. Removal after that deprecation period should be straightforward.

-mike

Yoav Weiss

unread,
Oct 2, 2020, 5:25:17 AM10/2/20
to Mike West, Harald Alvestrand, blink-dev, Philip Jägenstedt, PhistucK
The above sounds like a reasonable plan.

LGTM2

Chris Harrelson

unread,
Oct 2, 2020, 12:02:16 PM10/2/20
to Yoav Weiss, Mike West, Harald Alvestrand, blink-dev, Philip Jägenstedt, PhistucK
LGTM3 for this plan.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhC61h8vikTjTFO1xwDdyAc3VF8Qn1ofT7NBbUzK9%2Bbig%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages