Hacker News Reader

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.

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 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

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)

> 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.

> Until then interacting with a 'WebTransport Media API' involves...

Until then just use webrtc for client/server video. P2p protocols work just fine in centralised contexts.

If you are looking for cross-platform FOSS P2P, ProtocolLabs' (makers of IPFS) 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, 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).

+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.

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.

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.

> 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)

The majority of IPv6-capable ISPs are using prefix delegation to allow NAT-free operation. Heck, even phones are getting prefixes.

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)

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.

There are several free STUN services available, and you can fix a lot of connections with just STUN. STUN is just an IP lookup effectively, so it's very cheap to deploy.

TURN is of course an entirely different beast because it's proxying all the data between clients. It's also where some more complex video stuff happens potentially. The good news is that there are solid, open source TURN servers available to run on your own hardware. The downside is that running those servers for non-trivial amounts of clients gets pretty resource intensive pretty quick.

So would STUN allow a connection to be established between a a user inside a LAN and internet user?

In my experience you typically don't need STUN for that to work - the ICE flow of WebRTC will handle regular NAT[1].

It's typically when ICE can't determine the first few steps (eg your public address) that you need STUN to help you out.

TURN tends to be needed in hostile networking situations like double NAT'd networks or very restricted networks like hospitals.

[1] - https://webrtcglossary.com/ice/

When used in a client/server context where the server has a public IP address, webrtc can be deployed entirely without STUN/TURN. The mechanism is peer reflexive candidates, wherein the server learns the address and port of the client based on the IP packet of the incoming ICE negotiation request. I have used this approach on production systems.

For peer to peer, you'd have a tough time avoiding STUN/TURN anyhow.

Only a specific form of low-quality NAT--one that is certainly often encountered but isn't at all common at the router or ISP level--is incompatible with WebRTC in a way that would cause you to need TURN.

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.

"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

maybe it'll be here sooner than we think...

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.

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

Side note: Try browsing the internet v6-only. It's pretty eye opening.

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.

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.

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.

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.

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.

> 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.

Most human interaction where videoconferencing applies happens in small groups.

That’s a design choice. The architecture doesn’t require a middlebox.

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

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-servi...

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.

IPv6?

Still will need hole punching but no “IP discovery”.

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.

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.

Well you can give an array of stun/turn servers in the client without needing any special load balancer so its not really hard to do better than one point of failure.

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.

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

They discontinued that in 2022.

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 excited to see congestion controllers that are easily usable by others!

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.

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/ and while trying to remember that link I just came across https://chrome.google.com/webstore/detail/analyzertc-visuali... which looks promising to make the internals data more usable.

thanks, will take a look.

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.

it's P2P, not using an SFU.

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.

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.