8 ms·

This is so exciting. WebRTC is our best hope to have video interop between platforms. I love that it works outside web browsers, compeitors like WebTransport as

This is so exciting. WebRTC is our best hope to have video interop between platforms. I love that it works outside web browsers, compeitors like WebTransport assume a 100% browser world. Or you have protocols like RTMP/SRT... that will never make it into the browser. WebRTC might be our best bet to establish P2P connectivity between all languages/platforms. Would love to get rid of the single point of falure in Pub/Sub systems. WebRTC also feels like a great path towards easy cloud-agnostic code. You can use lots of different languages, and not dependent on SDKs/Servers. * https://github.com/aiortc/aiortc https://github.com/aiortc/aiortc (Python) * GStreamer’s webrtcbin (C) * https://github.com/shinyoshiaki/werift-webrtc https://github.com/shinyoshiaki/werift-webrtc (Typescript) * https://github.com/pion/webrtc https://github.com/pion/webrtc (Golang) * https://github.com/webrtc-rs/webrtc https://github.com/webrtc-rs/webrtc (Rust) * https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded) * https://webrtc.googlesource.com/src/ https://webrtc.googlesource.com/src/ (C++) * https://github.com/rawrtc/rawrtc https://github.com/rawrtc/rawrtc (C++) ---- Then you have a couple that aren't Open Source. But proves it is possible for these platforms also. * Shiguredo (Erlang) * |pipe| (Java) ---- If you are new to WebRTC I have been working on making it more accessible https://webrtcforthecurious.com https://webrtcforthecurious.com. I am currently pretty tied up with Pion so haven't been able to make much progress lately.

api 6y ago
WebRTC is also a decent P2P data protocol, and to have a P2P protocol like that enshrined in IETF standards means that P2P is now considered a "normal" thing on the Internet. This in turn means that symmetric NAT will be considered sort of broken, which it should be as it is horrible for anything P2P or any novel protocol for that matter. Of course IPv6 is the ultimate long term solution.
- taf2 6y ago
  "Of course IPv6 is the ultimate long term solution." I feel like this is similar to "We'll have nuclear fusion in the next 30 years." :) However if you look at the graph from google - https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html maybe it'll be here sooner than we think...
  - api 6y ago
    Nuclear fusion may be closer than you think too. We've been developing better and better superconductors that could yield more compact and more powerful electromagnets, which is a major bottleneck to making it practical. ITER is huge and fabulously expensive, but it's intended to be more of an experiment/testbed that happens to maybe generate some power. It's not intended to be a practical reactor.
  - LinuxBender 6y ago
    It would be nice if they broke that chart down by AS numbers, as I suspect much of that is the mobile carriers. Here is some data [1] looks like about 27k AS numbers comprise all of the ipv6 usage. I stand corrected, looks like mostly mobile and Amazon for the US and then the rest is several other countries that are primarily using ipv6. [1] - https://www.cidr-report.org/v6/as2.0/#Aggs https://www.cidr-report.org/v6/as2.0/#Aggs
  - solarkraft 6y ago
    Side note: Try browsing the internet v6-only. It's pretty eye opening.
  - kevin_thibedeau 6y ago
    We've never had practical fusion. We used to have frictionless P2P with talk, ytalk, and similar chat tools. Then NAT came along and ruined everything.
    - api 6y ago
      True story: I was giving a talk on ZeroTier (I'm the original author/founder) at a university. After explaining some of the networking, a student raised his hand and asked me how it could transfer data between devices without a "cloud." This student didn't understand that it was possible for one device to talk to another device directly.
- lazyjeff 6y ago
  My understanding is that currently people set up a STUN/TURN server to relay WebRTC, so it's not really used as P2P but there is still some benefit to the protocol itself. To move to true P2P for WebRTC seems impossible, as even if 80% of web users were on IPv6 without NAT (and even 80% seems a bit hopeless at this point considering we've been transitioning to IPv6 for 20 years now), you'd still need a fallback configuration for the 20% that don't. There doesn't seem to be a feasible gradual transition strategy. This is not really my area of expertise, so I'd love to be proven wrong.
  - api 6y ago
    STUN doesn't relay. It assists with P2P connection setup. TURN relays, and is intended as the path of last resort. The vast majority of WebRTC traffic is P2P.
    - tpetry 6y ago
      The vast webrtc traffic is in reality between a peer and a sfu (selective forwarding unit) on a server. There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers.
      - SahAssar 6y ago
        > There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers. Many providers choose to use SFU's even when not needed because they have features like recording that require it. I've gotten much better quality and latency on normal webrtc than I have over slack, teams, hangouts, even over bad mobile networks.
      - zurn 6y ago
        Most human interaction where videoconferencing applies happens in small groups.
      - api 6y ago
ignoramous 6y ago
If you are looking for cross-platform FOSS P2P, ProtocolLabs' (makers of IPFS) https://libp2p.io https://libp2p.io (P2P conns over TCP, UDP, QUIC, WebSockets, WebRTC) with implementations in various languages (Go, Rust, JavaScript) with varying degrees of features is great to have in the toolbox, as well. Unless of course you're sold into a solution like https://tailscale.com https://tailscale.com, who I believe are readying a userspace embeddable implementation of their P2P mesh wireguard overlay network, which then would be a compelling alternative, too, in the not so distant future, especially because of its security posture (though only the clients are FOSS).
- pojntfx 6y ago
  +1 for libp2p. While I've found their public WebRTC stars (basically signaling servers) quite slow for now, js-libp2p is growing very quickly and quite usable from my experience.
kodablah 6y ago
Don't forget Google's which is probably the most robust: https://webrtc.org/ https://webrtc.org/ (source at https://webrtc.googlesource.com/src https://webrtc.googlesource.com/src). Other libs, such as mediasoup, take pieces from this.
- craftinator 6y ago
  They discontinued that in 2022.
- Sean-Der 6y ago
  Updated! This is my list of 'Other WebRTC implementations' from FOSDEM talk, mea culpa :( mediasoup is moving towards dropping Google's implementation https://github.com/versatica/mediasoup/issues/344 https://github.com/versatica/mediasoup/issues/344 excited to see congestion controllers that are easily usable by others!
dillondoyle 6y ago
There's still a single point of failure: STUN server. Comment below talks about some ideas that are new to me about how to navigate around nAT
- Sean-Der 6y ago
  Unless we get NAT-PMP or PCP in the browser I don't know if we have an alternative. In the LAN I am excited about this thread https://discourse.wicg.io/t/idea-local-devices-api-lan-services/5056 https://discourse.wicg.io/t/idea-local-devices-api-lan-servi...
- fckthisguy 6y ago
  If you're running a Web etc app, you can always run a STUN server too. It's not perfect but it's a step in the right direction. I'd love to see a pool of STUN servers available for this, with some randomization.
- topranks 6y ago
  IPv6? Still will need hole punching but no “IP discovery”.
- SahAssar 6y ago
  Why is a STUN server a single point of failure? You can specify multiple and a STUN server does not need to keep any state at all, it is simply a way for a client behind a NAT to get their public IP/port, right? STUN servers are cheap to run (they require very little processing and bandwidth as opposed to TURN), and setting up a few on each public cloud should be easy for anyone using ICE seriously. There are also public STUN servers still available, although I would not rely on them personally.
  - dillondoyle 6y ago
    That's interesting thanks for that info I've never setup webrtc with two stun servers. But still I think at least how I read single point of failure: it's reliant on a 3rd party. even if multiple 3rd party it's not realistically trustable in the way 'owning' the full stack would be. Though host your own as someone else points out below.
josephg 6y ago
Huh? Webtransport isn’t trying to compete with webrtc. It’s a server/client protocol not a p2p protocol. And it’s not designed with video conferencing in mind like webrtc is. Webtransport is trying to be a better alternative for websockets with support for h2/h3 and unreliable delivery. > WebTransport assume a 100% browser world. Webtransport should work anywhere that http is available. There’s nothing browser specific about it.
- Sean-Der 6y ago
  WebTransport (QuicTransport) was cited to be an alternative by one of the RFCs authors [0] he gives his reasoning in the thread. I consider WebRTC Agnostic because you just need to exchange the Offer/Answer. With something like https://tools.ietf.org/html/draft-murillo-whip-00 https://tools.ietf.org/html/draft-murillo-whip-00 it means I can upload video without running any kind of SDK/blobs locally. With WebTransport we are going to have no interop between services/clients. There will be need to be code to signal with each. [0] https://news.ycombinator.com/item?id=23540253 https://news.ycombinator.com/item?id=23540253
  - vasilvv 6y ago
    I am not sure I follow this. WebTransport defines a way to transfer arbitrary data over HTTP/3, it's not a media protocol. I expect that a well-defined media transfer protocol will eventually emerge for media over WebTransport, and it will make its way to IETF. (FWIW, you can send RTP over WebTransport datagrams, instead of using SRTP and ICE-lite)
    - Sean-Der 6y ago
      > a well-defined media transfer protocol will eventually emerge Until then interacting with a 'WebTransport Media API' involves me running code distributed by the person running the API. With WebRTC I can exchange a Offer/Answer and then have a bi-directional media session. I appreciate that these lower level APIs help companies that need the flexibility. I worry that the complexity will lock out Open Source and smaller companies. Smaller companies are going to have to figure out things took years to solve with WebRTC. Stuff like * Congestion Control/Error Correction trade-offs and Latency * Simulcast * Re-negotation * Rollbacks * Capability Negotation I was always a big fan of ORTC. Give flexibility to the power users, but give an even playing field to small players. > RTP over WebTransport datagrams I don't feel strongly about QUIC vs S(RTP). WebTransport doesn't force RTP, so it doesn't help unless I control everything. Bridging will get a lot harder. Right now it is nice that Reports/NACKs/etc.. can cross protocols.
qwertox 6y ago
Thank you for the effort you have put into "WebRTC For The Curious". I was looking for information on WebRTC and this looks like a good introduction.
curtis3389 6y ago
I agree that WebRTC is super exciting, but if you want to deploy it into production, you need to have a STUN server and a TURN server. Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.
- qwantim1 6y ago
  This is why I didn’t get really excited about WebRTC when I looked into it before. And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault. A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control. But it is what it is.
- gcblkjaidfj 6y ago
  > Until/unless we've all moved to IPv6 without any NAT hell will freeze before that happens. This is the bread and butter of ISP. Without NAT they lose too many revenue sources. They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)
  - wmf 6y ago
    The majority of IPv6-capable ISPs are using prefix delegation to allow NAT-free operation. Heck, even phones are getting prefixes.
  - detaro 6y ago
    Which ISPs do deploy/force NAT with IPv6? (I don't trust the industry enough to say there are none, but it'd be highly unusual)
  - martyvis 6y ago
    What revenue sources does an ISP get for having NAT? In Australia, you pay retail ISPs to provide backhaul from the national broadband provider. I pay $10 per month extra for a fixed public IPv4 address, the public /64 for IPv6 comes free. That's it.
jokethrowaway 6y ago
I think webrtc's success for video will be hugely dependant on which codecs can be used with it. The gap between webm and zoom proprietary scalable codec still makes or breaks a call. I've seen news of av1 working in real time up to 720p but I haven't tried it myself yet. That could make a difference for the open web.
- wildermuthn 6y ago
  Can’t you use WebRTC data channels to send and receive arbitrary data? I don’t know a whole lot about this, but I saw a WebRTC version of Jacktrip that seemed to do this.
detaro 6y ago
Might as well piggy-back on this: any hints for debugging WebRTC issues? Was on a call again today that had a weird mix of people not seeing some other people, sometimes only getting audio or only video, ... where I'd liked to but couldn't try to pinpoint where the issue is coming from.
- porterde 6y ago
  If you’re using Chrome you can get some insight by opening chrome://webrtc-internals in another tab. There is some documentation here https://testrtc.com/webrtc-internals-documentation/ https://testrtc.com/webrtc-internals-documentation/ and while trying to remember that link I just came across https://chrome.google.com/webstore/detail/analyzertc-visualize-webr/jmichaepiaolacmdlbngnoephpomigcm https://chrome.google.com/webstore/detail/analyzertc-visuali... which looks promising to make the internals data more usable.
  - detaro 6y ago
    thanks, will take a look.
- ShroudedNight 6y ago
  It's not obvious that this is an issue with the WebRTC sessions themselves. If a server is responsible for muxing the streams, each client could be in a properly negotiated session with the server, and due to an internal software defect with how the server renders the streams for a client, the client could experience exactly the symptoms you describe.
  - detaro 6y ago
    it's P2P, not using an SFU.

api 6y ago

WebRTC is also a decent P2P data protocol, and to have a P2P protocol like that enshrined in IETF standards means that P2P is now considered a "normal" thing on the Internet. This in turn means that symmetric NAT will be considered sort of broken, which it should be as it is horrible for anything P2P or any novel protocol for that matter. Of course IPv6 is the ultimate long term solution.

taf2 6y ago
"Of course IPv6 is the ultimate long term solution." I feel like this is similar to "We'll have nuclear fusion in the next 30 years." :) However if you look at the graph from google - https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html maybe it'll be here sooner than we think...
- api 6y ago
  Nuclear fusion may be closer than you think too. We've been developing better and better superconductors that could yield more compact and more powerful electromagnets, which is a major bottleneck to making it practical. ITER is huge and fabulously expensive, but it's intended to be more of an experiment/testbed that happens to maybe generate some power. It's not intended to be a practical reactor.
- LinuxBender 6y ago
  It would be nice if they broke that chart down by AS numbers, as I suspect much of that is the mobile carriers. Here is some data [1] looks like about 27k AS numbers comprise all of the ipv6 usage. I stand corrected, looks like mostly mobile and Amazon for the US and then the rest is several other countries that are primarily using ipv6. [1] - https://www.cidr-report.org/v6/as2.0/#Aggs https://www.cidr-report.org/v6/as2.0/#Aggs
- solarkraft 6y ago
  Side note: Try browsing the internet v6-only. It's pretty eye opening.
- kevin_thibedeau 6y ago
  We've never had practical fusion. We used to have frictionless P2P with talk, ytalk, and similar chat tools. Then NAT came along and ruined everything.
  - api 6y ago
    True story: I was giving a talk on ZeroTier (I'm the original author/founder) at a university. After explaining some of the networking, a student raised his hand and asked me how it could transfer data between devices without a "cloud." This student didn't understand that it was possible for one device to talk to another device directly.
lazyjeff 6y ago
My understanding is that currently people set up a STUN/TURN server to relay WebRTC, so it's not really used as P2P but there is still some benefit to the protocol itself. To move to true P2P for WebRTC seems impossible, as even if 80% of web users were on IPv6 without NAT (and even 80% seems a bit hopeless at this point considering we've been transitioning to IPv6 for 20 years now), you'd still need a fallback configuration for the 20% that don't. There doesn't seem to be a feasible gradual transition strategy. This is not really my area of expertise, so I'd love to be proven wrong.
- api 6y ago
  STUN doesn't relay. It assists with P2P connection setup. TURN relays, and is intended as the path of last resort. The vast majority of WebRTC traffic is P2P.
  - tpetry 6y ago
    The vast webrtc traffic is in reality between a peer and a sfu (selective forwarding unit) on a server. There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers.
    - SahAssar 6y ago
      > There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers. Many providers choose to use SFU's even when not needed because they have features like recording that require it. I've gotten much better quality and latency on normal webrtc than I have over slack, teams, hangouts, even over bad mobile networks.
    - zurn 6y ago
      Most human interaction where videoconferencing applies happens in small groups.
    - api 6y ago

ignoramous 6y ago

If you are looking for cross-platform FOSS P2P, ProtocolLabs' (makers of IPFS) https://libp2p.io https://libp2p.io (P2P conns over TCP, UDP, QUIC, WebSockets, WebRTC) with implementations in various languages (Go, Rust, JavaScript) with varying degrees of features is great to have in the toolbox, as well. Unless of course you're sold into a solution like https://tailscale.com https://tailscale.com, who I believe are readying a userspace embeddable implementation of their P2P mesh wireguard overlay network, which then would be a compelling alternative, too, in the not so distant future, especially because of its security posture (though only the clients are FOSS).

pojntfx 6y ago
+1 for libp2p. While I've found their public WebRTC stars (basically signaling servers) quite slow for now, js-libp2p is growing very quickly and quite usable from my experience.

kodablah 6y ago

Don't forget Google's which is probably the most robust: https://webrtc.org/ https://webrtc.org/ (source at https://webrtc.googlesource.com/src https://webrtc.googlesource.com/src). Other libs, such as mediasoup, take pieces from this.

craftinator 6y ago
They discontinued that in 2022.
Sean-Der 6y ago
Updated! This is my list of 'Other WebRTC implementations' from FOSDEM talk, mea culpa :( mediasoup is moving towards dropping Google's implementation https://github.com/versatica/mediasoup/issues/344 https://github.com/versatica/mediasoup/issues/344 excited to see congestion controllers that are easily usable by others!

dillondoyle 6y ago

There's still a single point of failure: STUN server. Comment below talks about some ideas that are new to me about how to navigate around nAT

Sean-Der 6y ago
Unless we get NAT-PMP or PCP in the browser I don't know if we have an alternative. In the LAN I am excited about this thread https://discourse.wicg.io/t/idea-local-devices-api-lan-services/5056 https://discourse.wicg.io/t/idea-local-devices-api-lan-servi...
fckthisguy 6y ago
If you're running a Web etc app, you can always run a STUN server too. It's not perfect but it's a step in the right direction. I'd love to see a pool of STUN servers available for this, with some randomization.
topranks 6y ago
IPv6? Still will need hole punching but no “IP discovery”.
SahAssar 6y ago
Why is a STUN server a single point of failure? You can specify multiple and a STUN server does not need to keep any state at all, it is simply a way for a client behind a NAT to get their public IP/port, right? STUN servers are cheap to run (they require very little processing and bandwidth as opposed to TURN), and setting up a few on each public cloud should be easy for anyone using ICE seriously. There are also public STUN servers still available, although I would not rely on them personally.
- dillondoyle 6y ago
  That's interesting thanks for that info I've never setup webrtc with two stun servers. But still I think at least how I read single point of failure: it's reliant on a 3rd party. even if multiple 3rd party it's not realistically trustable in the way 'owning' the full stack would be. Though host your own as someone else points out below.

josephg 6y ago

Huh? Webtransport isn’t trying to compete with webrtc. It’s a server/client protocol not a p2p protocol. And it’s not designed with video conferencing in mind like webrtc is. Webtransport is trying to be a better alternative for websockets with support for h2/h3 and unreliable delivery. > WebTransport assume a 100% browser world. Webtransport should work anywhere that http is available. There’s nothing browser specific about it.

Sean-Der 6y ago
WebTransport (QuicTransport) was cited to be an alternative by one of the RFCs authors [0] he gives his reasoning in the thread. I consider WebRTC Agnostic because you just need to exchange the Offer/Answer. With something like https://tools.ietf.org/html/draft-murillo-whip-00 https://tools.ietf.org/html/draft-murillo-whip-00 it means I can upload video without running any kind of SDK/blobs locally. With WebTransport we are going to have no interop between services/clients. There will be need to be code to signal with each. [0] https://news.ycombinator.com/item?id=23540253 https://news.ycombinator.com/item?id=23540253
- vasilvv 6y ago
  I am not sure I follow this. WebTransport defines a way to transfer arbitrary data over HTTP/3, it's not a media protocol. I expect that a well-defined media transfer protocol will eventually emerge for media over WebTransport, and it will make its way to IETF. (FWIW, you can send RTP over WebTransport datagrams, instead of using SRTP and ICE-lite)
  - Sean-Der 6y ago
    > a well-defined media transfer protocol will eventually emerge Until then interacting with a 'WebTransport Media API' involves me running code distributed by the person running the API. With WebRTC I can exchange a Offer/Answer and then have a bi-directional media session. I appreciate that these lower level APIs help companies that need the flexibility. I worry that the complexity will lock out Open Source and smaller companies. Smaller companies are going to have to figure out things took years to solve with WebRTC. Stuff like * Congestion Control/Error Correction trade-offs and Latency * Simulcast * Re-negotation * Rollbacks * Capability Negotation I was always a big fan of ORTC. Give flexibility to the power users, but give an even playing field to small players. > RTP over WebTransport datagrams I don't feel strongly about QUIC vs S(RTP). WebTransport doesn't force RTP, so it doesn't help unless I control everything. Bridging will get a lot harder. Right now it is nice that Reports/NACKs/etc.. can cross protocols.

qwertox 6y ago

Thank you for the effort you have put into "WebRTC For The Curious". I was looking for information on WebRTC and this looks like a good introduction.

curtis3389 6y ago

I agree that WebRTC is super exciting, but if you want to deploy it into production, you need to have a STUN server and a TURN server. Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.

qwantim1 6y ago
This is why I didn’t get really excited about WebRTC when I looked into it before. And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault. A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control. But it is what it is.
gcblkjaidfj 6y ago
> Until/unless we've all moved to IPv6 without any NAT hell will freeze before that happens. This is the bread and butter of ISP. Without NAT they lose too many revenue sources. They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)
- wmf 6y ago
  The majority of IPv6-capable ISPs are using prefix delegation to allow NAT-free operation. Heck, even phones are getting prefixes.
- detaro 6y ago
  Which ISPs do deploy/force NAT with IPv6? (I don't trust the industry enough to say there are none, but it'd be highly unusual)
- martyvis 6y ago
  What revenue sources does an ISP get for having NAT? In Australia, you pay retail ISPs to provide backhaul from the national broadband provider. I pay $10 per month extra for a fixed public IPv4 address, the public /64 for IPv6 comes free. That's it.

jokethrowaway 6y ago

I think webrtc's success for video will be hugely dependant on which codecs can be used with it. The gap between webm and zoom proprietary scalable codec still makes or breaks a call. I've seen news of av1 working in real time up to 720p but I haven't tried it myself yet. That could make a difference for the open web.

wildermuthn 6y ago
Can’t you use WebRTC data channels to send and receive arbitrary data? I don’t know a whole lot about this, but I saw a WebRTC version of Jacktrip that seemed to do this.

detaro 6y ago

Might as well piggy-back on this: any hints for debugging WebRTC issues? Was on a call again today that had a weird mix of people not seeing some other people, sometimes only getting audio or only video, ... where I'd liked to but couldn't try to pinpoint where the issue is coming from.

porterde 6y ago
If you’re using Chrome you can get some insight by opening chrome://webrtc-internals in another tab. There is some documentation here https://testrtc.com/webrtc-internals-documentation/ https://testrtc.com/webrtc-internals-documentation/ and while trying to remember that link I just came across https://chrome.google.com/webstore/detail/analyzertc-visualize-webr/jmichaepiaolacmdlbngnoephpomigcm https://chrome.google.com/webstore/detail/analyzertc-visuali... which looks promising to make the internals data more usable.
- detaro 6y ago
  thanks, will take a look.
ShroudedNight 6y ago
It's not obvious that this is an issue with the WebRTC sessions themselves. If a server is responsible for muxing the streams, each client could be in a properly negotiated session with the server, and due to an internal software defect with how the server renders the streams for a client, the client could experience exactly the symptoms you describe.
- detaro 6y ago
  it's P2P, not using an SFU.