5 ms·

webrtc is such a complex technology still after so many years. I wonder why web standards didnt decide to just deprecate old tech and create something that is u

by seydor 3y ago

webrtc is such a complex technology still after so many years. I wonder why web standards didnt decide to just deprecate old tech and create something that is usable out of the box without stun/turn servers and all the other complexity that i don't even know. In the year 2001 it was much simpler to set up an all-to-many video chat with Flash and an open source media server. it feels like this tech has been chasing its tail

torginus 3y ago
The issue comes from the technology using UDP which creates all sorts of funky networking situations when NAT is involved necessitating turn/stun. I think that will be unavoidable unless HTTP3/QUIC or IPv6 gains widespread support on all kinds of network infrastructure.
- sylware 3y ago
  That's why they should have eaten the bullet: ipv6 and tcp, only.
  - predictabl3 3y ago
    Except they wanted to build something usable? If I could snap my fingers and make IPv6 deployment and usability, I and I'm sure WebRTC folks would. This entire stance is even more hard to mesh with the real world given how long WebRTC has been in development and use.
    - sylware 3y ago
      Well, the idea behind would be to move to a clean ipv6/tcp protocol stack at the same pace than ipv6 deployment. The best compromise would have been a dual stack: the clean pure p2p ipv6/tcp, and the brain f*cked ipv4/nat/upnp/turn/stun/etc. To have a clean and brutal split between the 2. In my country, people would mostly run the clean ipv6/tcp protocol stack. And I am thinking REALLY simple: no transcode in the protocol (only the node will decide if it needs to transcode), one stream, buffered (it's not a video call). Yeah... excrutiatingly simple, then with many alternative implementations, aka sane. But, it is kind of a dream, I know CDNs and streaming services won't let that happen in any way, I would not be surprised to see some DDOS-ing "from" them to keep people slaves of their big tech "centralized" services.
- mort96 3y ago
  TCP makes NAT traversal harder, not easier. WebRTC can be peer to peer thanks to its use of UDP, not in spite of it. The complications of STUN comes from NAT, not from UDP. The complications of TURN comes from firewalls (or overly restrictive (i.e bad) NATs), not from UDP.
crazygringo 3y ago
It has nothing to do with web standards, or the web at all. Back in 2001 your computer was probably connected directly to the internet over Ethernet with a dedicated IP address so the simple setup worked fine. But then Wi-Fi came out and people had routers at home and NAT became the norm. This forced STUN/TURN. It's entirely a networking issue, not a web issue. IPv6 could have made NAT a thing of the past, but obviously it hasn't. But firewalls are also the norm now in a way they weren't back in 2001 because security has to be tighter now.
- sylware 3y ago
  As far as I know, many IPv4 internet gateways, if not nearly all, have gateway UPNP support. The issue is the browser unable to deal with gateway UPNP... well since the web engines are now real cluster f*ks of everything, they could add a DOM interface for it.
  - crazygringo 3y ago
    The main problem is that malware can leverage UPNP to do real harm. A smaller secondary problem is that UPNP doesn't work well on large corporate networks (something about the "chattiness" of so many messages). Browser permissions to open up a port through UPNP is the "easy" part. The hard part is how your router will distinguish that as a legitimate request, versus local botnet malware opening up a request. There are some extensions around UPNP to add user authentication as part of the process, but they don't seem to be widely adopted. To the contrary, general security recommendations are usually to disable UPNP. I had thought that videoconferencing would indeed finally be the impetus to solve this in a secure way, but meetings with much more than 2 participants require a centralized server anyways to prevent bandwidth from exploding, so relaying video calls through a server just became standard.
    - sylware 3y ago
      We are talking about domestic usage, not corporate, and in my country nearly all domestic internet users have ipv6, hence no NAT or similar abomination. It is even bigger: major mobile internet provider provides ipv6 by default. It has been like that for years. We are talking tens of millions of people with native IPv6, mobile and domestic. NAT is something which should not have existed in the first place.
mort96 3y ago
STUN and TURN isn't unnecessary complexity. They're absolutely essential due to NAT. You need something like STUN to be able to communicate peer to peer through NAT, and you need something like TURN to tunnel traffic through a server in the case where NAT hole punching is impossible. Maaybe there's some unnecessary incidental complexity in the way the STUN and TURN protocols work? I don't know, I honestly haven't investigated the details of the protocols. But the actually problematic complexity comes from the fact that something like STUN and TURN is needed at all, and that's essential complexity which arises from the problem domain.
- vxNsr 3y ago
  I could be wrong but I think GP is arguing for dropping ipv4 to avoid all the complexity that comes from still supporting it.
capableweb 3y ago
So, what are you suggesting to do instead of STUN/TURN, in order to solve the issue that STUN/TURN is designed to solve? It sounds to me, that you don't know what problem is being solved, so therefore you don't understand why the solution looks like it looks like.

by seydor 3y ago

torginus 3y ago

The issue comes from the technology using UDP which creates all sorts of funky networking situations when NAT is involved necessitating turn/stun. I think that will be unavoidable unless HTTP3/QUIC or IPv6 gains widespread support on all kinds of network infrastructure.

sylware 3y ago
That's why they should have eaten the bullet: ipv6 and tcp, only.
- predictabl3 3y ago
  Except they wanted to build something usable? If I could snap my fingers and make IPv6 deployment and usability, I and I'm sure WebRTC folks would. This entire stance is even more hard to mesh with the real world given how long WebRTC has been in development and use.
  - sylware 3y ago
    Well, the idea behind would be to move to a clean ipv6/tcp protocol stack at the same pace than ipv6 deployment. The best compromise would have been a dual stack: the clean pure p2p ipv6/tcp, and the brain f*cked ipv4/nat/upnp/turn/stun/etc. To have a clean and brutal split between the 2. In my country, people would mostly run the clean ipv6/tcp protocol stack. And I am thinking REALLY simple: no transcode in the protocol (only the node will decide if it needs to transcode), one stream, buffered (it's not a video call). Yeah... excrutiatingly simple, then with many alternative implementations, aka sane. But, it is kind of a dream, I know CDNs and streaming services won't let that happen in any way, I would not be surprised to see some DDOS-ing "from" them to keep people slaves of their big tech "centralized" services.
mort96 3y ago
TCP makes NAT traversal harder, not easier. WebRTC can be peer to peer thanks to its use of UDP, not in spite of it. The complications of STUN comes from NAT, not from UDP. The complications of TURN comes from firewalls (or overly restrictive (i.e bad) NATs), not from UDP.

crazygringo 3y ago

It has nothing to do with web standards, or the web at all. Back in 2001 your computer was probably connected directly to the internet over Ethernet with a dedicated IP address so the simple setup worked fine. But then Wi-Fi came out and people had routers at home and NAT became the norm. This forced STUN/TURN. It's entirely a networking issue, not a web issue. IPv6 could have made NAT a thing of the past, but obviously it hasn't. But firewalls are also the norm now in a way they weren't back in 2001 because security has to be tighter now.

sylware 3y ago
As far as I know, many IPv4 internet gateways, if not nearly all, have gateway UPNP support. The issue is the browser unable to deal with gateway UPNP... well since the web engines are now real cluster f*ks of everything, they could add a DOM interface for it.
- crazygringo 3y ago
  The main problem is that malware can leverage UPNP to do real harm. A smaller secondary problem is that UPNP doesn't work well on large corporate networks (something about the "chattiness" of so many messages). Browser permissions to open up a port through UPNP is the "easy" part. The hard part is how your router will distinguish that as a legitimate request, versus local botnet malware opening up a request. There are some extensions around UPNP to add user authentication as part of the process, but they don't seem to be widely adopted. To the contrary, general security recommendations are usually to disable UPNP. I had thought that videoconferencing would indeed finally be the impetus to solve this in a secure way, but meetings with much more than 2 participants require a centralized server anyways to prevent bandwidth from exploding, so relaying video calls through a server just became standard.
  - sylware 3y ago
    We are talking about domestic usage, not corporate, and in my country nearly all domestic internet users have ipv6, hence no NAT or similar abomination. It is even bigger: major mobile internet provider provides ipv6 by default. It has been like that for years. We are talking tens of millions of people with native IPv6, mobile and domestic. NAT is something which should not have existed in the first place.

mort96 3y ago

STUN and TURN isn't unnecessary complexity. They're absolutely essential due to NAT. You need something like STUN to be able to communicate peer to peer through NAT, and you need something like TURN to tunnel traffic through a server in the case where NAT hole punching is impossible. Maaybe there's some unnecessary incidental complexity in the way the STUN and TURN protocols work? I don't know, I honestly haven't investigated the details of the protocols. But the actually problematic complexity comes from the fact that something like STUN and TURN is needed at all, and that's essential complexity which arises from the problem domain.

vxNsr 3y ago
I could be wrong but I think GP is arguing for dropping ipv4 to avoid all the complexity that comes from still supporting it.

capableweb 3y ago

So, what are you suggesting to do instead of STUN/TURN, in order to solve the issue that STUN/TURN is designed to solve? It sounds to me, that you don't know what problem is being solved, so therefore you don't understand why the solution looks like it looks like.