pthatcherg

It is possible to have conference calls with e2e encryption.

Many conference calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.

For those types of conference calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

As far as I know, there's nothing special about telehealth that prevents it from using e2e encryption.

There are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption incurs negligible processing and bandwidth. Do you worry about the processing and bandwidth increase when using HTTPS/SSL? Probably not. Same goes for 1:1 calls.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU). One benefit of SFUs is that they take much less processing for the server than the other kinds (where the video is re-encoded by the server). For those types of group calls, e2e encryption can be implemented with negligible increases to processing and bandwidth.

However, you are correct that it is harder to implement correctly. And it does prevent certain features to be added to the product, such as recording and server-based processing of information (for example, meeting transcriptions).

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

First of all, there are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption doesn't cause any problem at all.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.

For those types of group calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

I haven't used the desktop Signal app, but there appears to be one:

https://signal.org/download/

https://w3c.github.io/webrtc-quic/ is "outside" of webrtc in the sense that it doesn't use PeerConnection and doesn't require signaling. But it currently doesn't require some form of ICE (not stun or turn, but ICE lite on a server). But we're considering adding support for an ICE-less version, and I've already started a pull request to add that.

At TPAC last week the WebRTC WG decided to adopt the spec, although it needs to be verified on the mailing list, as there were some members present not in favor of adopting it.

(I'm an editor of the document and am in favor of it).

You can do the same with QUIC streams (size them appropriately and get a 1:1 mapping with UDP packets).

It's been there for years and they've been steadily improving it. If anything, it will keep getting better, not go away.

(I work at Google, on Chrome)

I know both people from both the MSE team and the Project Stream team. Project Stream doesn't use MSE (it uses WebRTC) and the code in Chrome to detect live streams and optimizing them has been around long time, (see, for example, this change from almost 4 years ago: https://codereview.chromium.org/692323002) and they've steadily added better support for live streams over the years. It's not "game-streaming tech in a web browser". It's just a few simple heuristics to function better for low-latency streams. You can read the code for yourself if you'd like:

https://cs.chromium.org/chromium/src/media/renderers/video_r...

As I just commented higher up in the thread, it is possible to force UDP if that's what you want.

And while WebRTC is complex, you can ignore almost all of that if you're just doing client to server data channels. You just need to speak ICE lite, DTLS, and SCTP, all of which have libraries. See some of my comments from months ago for more details.

I've already commented at length about this, but I'll repeat: UDP without congestion control in browsers is not really an option. UDP with congestion control is basically what QUIC is. So we might as just get p2p QUIC connections working instead (which we are doing in the ORTC community group).

You can cause effectively force UDP by doing two things:

1. Don't signal TCP ICE candidates. 2. Don't provide TCP TURN servers.

If you do those two things, it's impossible to get a TCP connection. In fact, just doing #2 will nearly guarantee it (since a TCP connection outside of TURN is so rare).

But ICE will almost always prefer UDP over TCP, so if it's using TCP it's because otherwise you simply wouldn't be connected at all. And if you'd prefer not to be connected, you could simply close the connection when you observe it's over TCP.

You don't need to give a server. It works fine with just host ICE candidates from the server and no stun or relay candidates.

(Member of the Google WebRTC team here)

We are aware that it's a pain to use just the data channel, and we're working on it. We're refactoring the native API to be more ORTC-like and make it possible to compile without all the audio/video parts. It will take time, but it should become easier as we make progress.

I disagree that the solution is to expose UDP API to the web. Writing good congestion control is very hard, and it would not be safe to let web apps do that; doubly so for crypto. As for native apps (even JS/node ones): you already have a UDP API.

The solution is to make the WebRTC API easier to use and simplify the protocol stack. We're working on the first, as I mentioned. And we're experimenting with the second (by using QUIC instead of SCTP+DTLS). Again, it will take time, but eventually we'll get there (probably).

You need to implement DTLS and SCTP for client->server, just not ICE. But client->server ICE is fairly trivial with ICE lite. It's DTLS+SCTP that are complex, and they don't go away client->server.

Replacing DTLS+SCTP with QUIC would be a good reduction in complexity, and we (the WebRTC team) are experimenting with doing so (https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...). It has a long way to go, but hopefully someday just having QUIC on your server will be enough.

(I work on WebRTC)

Are you using the data channel p2p or client-to-server?

(I work on WebRTC and implemented much of the data channel; I'm always interested when someone uses it)

QUIC Crypto design doc:

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...

You can receive data messages our of order. That's all there is to it. If you could receive TCP out of order, you could just use TCP.

Indeed, I misread your comment. Well, hopefully in the future how I read the comment will be correct. I don't think it would be that hard to write a data-channel-only server using BoringSSL and usrsctplib. See a comment of mine further down on the page of how you could do that.

Or you can just wait until we have our code refactored :).

Which API? PeerConnection? Would you prefer an API like ORTC?

If you want to force all traffic through a proxy, you must enable it using an extension, such as this one:

https://chrome.google.com/webstore/detail/webrtc-network-lim...

There was a discussion about this on go-nuts:

http://grokbase.com/t/gg/golang-nuts/161wbn1vf0/go-nuts-nati...

There are two bindings for Go built on top of the WebRTC code at webrtc.org:

https://github.com/keroserene/go-webrtc https://github.com/fd/webrtc

By the way, I work on the WebRTC team at Google, and I don't think it would be that hard to write a data channel server in Go. Here's how you should do it.

1. Get an "SDP offer" from the client. Parse it mainly to get the DTLS fingerprint. You may also choose to get the SCTP max message size.

2. Open a UDP socket. Listen for incoming STUN binding requests and send back binding responses:

You can see how the WebRTC client code constructs requests here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...

You can see how the WebRTC client code processes responses here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...

Or you can read the RFC (warning: not light reading): https://tools.ietf.org/html/rfc5245

3. Once a valid STUN binding request is received, listen for DTLS packets and hand those over to BoringSSL. Also listen to when BoringSSL wants to send a packet and send those out on the UDP socket back to the client.

You can see how the WebRTC client code passes DTLS packets down to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...

You can see how the WebRTC client code gets packets to send from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...

4. Once BoringSSL finishes the DTLS handshake and is processing incoming SCTP packets, listen for those and hand those over to usrsctplib. Also listen to packets usrsctplib wants to send and hand those over to DTLS to send.

You can see how the WebRTC client code reads decrypted packets from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...

And how it passes them down to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...

You can see how the WebRTC client code gets packets to send from usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...

And how it passes them to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...

5. Process data channel messages from usrsctplib and send data channel message through usrsctplib. Note that you can ignore the whole "OPEN message" protocol if you call PeerConnection.createDataChannel with the "negotiated: true" option on the WebRTC client side. You can specify the SID you want to use for the data channel as well.

You can see how the WebRTC client code passes messages to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...

And how it receives them: https://cs.chromium.org/chromium/src/third_party/webrtc/medi... https://cs.chromium.org/chromium/src/third_party/webrtc/medi...

6. Serialize an "SDP answer" message which basically just hands back the same looking blob of text, but with a different DTLS fingerprint (the one for the certificate of the server). It also must have two random strings: the ICE username fragment (ufrag) and ICE password (pwd). If you pass that answer to the WebRTC client, all the ICE, DTLS, and SCTP work should happen and after around 6 round trips on the network, you should incoming and outgoing messages.

Ok, that probably sounds like a lot, but most of the work is done by BoringSSL and usrsctplib. The bulk of the Go code would be implementing the STUN messages and gluing everything together. Good luck to whoever tries :).

Hi, I'm a member of the WebRTC team at Google, and I wrote a lot of the data channel and network code that's part of that behemoth.

I'm glad you got this to work :). I've always hoped someone would do exactly what you've done (use the data channel code on a server to do low-latency client<->server communication).

We're aware of the difficulty and are actively working on making it easier to work with just he components you need for data channels (ICE, DTLS, and SCTP). It might take a while, but it's one of our goals.

The WebRTC implementation found at webrtc.org, which is used by Chrome, can also be used by mobile apps, including iOS. It's BSD licensed and used by many mobile apps.

(I work on the WebRTC team)

What kind of an RTC API would you like to see?

You can control WebRTC's network behavior, including forcing it to go through a proxy, by using this Chrome extension:

https://chrome.google.com/webstore/detail/webrtc-network-lim...

It's published by the Chrome WebRTC (of which I am a member) for just that purpose: to let you control that behavior.

Member of the WebRTC team here.

If you go read the bug you linked to, you can see that we added code to Chrome to specifically make this extension possible. It's in many CLs, but here is an example of one:

https://chromium.googlesource.com/chromium/src/+/7c98bab0212...

Further, we recently open sourced our own version of the extension and put it on github:

https://github.com/webrtc/samples/tree/master/src/content/ex...

And we intend to keep this advanced control, and perhaps more in the future, well-supported long-term.

For access to the mic and camera, that's basically what it does already: prompt for permission.

So what you're really asking for is "can the web app know my non-NATed IP address if I'm behind a NAT and my non-VPN IP address if I'm behind certain kinds of VPNs"?

I know that one big deal is fewer round trips. DTLS+SCTP requires several round trips to establish a secure connection (around 4 I think). DTLS 1.3 should improve that on the DTLS side of things, but QUIC is designed from the beginning to have 0 round trips for many cases, and 1 round trip in the worst case. For high RTT scenarios, that can make a big difference.