[HN Gopher] WebRTC is now a W3C and IETF standard
___________________________________________________________________
WebRTC is now a W3C and IETF standard
Author : kaycebasques
Score : 229 points
Date : 2021-01-27 19:50 UTC (3 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| lxe wrote:
| I've dabbled with WebRTC API over the years, and I think I
| understand and can explain fairly clearly (to myself) the user's
| end of it.
|
| Having said that, it's an absolute nightmare of an API that
| should probably be re-done from scratch.
| kaycebasques wrote:
| Any specific problems you recall?
| kaycebasques wrote:
| Aside: I've heard about web platform tests, but I never realized
| that it could be a viable alternative to MDN for representing
| browser compatibility information. In this case they have a
| pretty good collection of tests [1] that give you a picture of
| overall WebRTC compatibility. Of course MDN is still the gold
| standard and we on web.dev will always link there as our default
| choice when they do a good job representing browser compatibility
| data, but in this case they don't seem to have a good table
| representing the state of WebRTC at large [2] (happy to update
| the article if it's just an oversight on my part and they do have
| a good browser compat table somewhere that I missed).
| Specifically, it seems like the WebRTC API page [3] should have a
| list of the browser compatibility of each of the interfaces that
| are mentioned on the page.
|
| [1]
| https://wpt.fyi/results/webrtc?label=experimental&label=mast...
|
| [2] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
|
| [3] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
|
| Disclosure: I edited the web.dev announcement
| ocdtrekkie wrote:
| Probably an issue that should've gotten addressed ahead of
| standardization, IMHO: https://github.com/w3c/webappsec-
| csp/issues/92
| Sean-Der wrote:
| 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 (Python)
|
| * GStreamer's webrtcbin (C)
|
| * https://github.com/shinyoshiaki/werift-webrtc (Typescript)
|
| * https://github.com/pion/webrtc (Golang)
|
| * https://github.com/webrtc-rs/webrtc (Rust)
|
| * https://github.com/awslabs/amazon-kinesis-video-streams-webr...
| (C/Embedded)
|
| * https://webrtc.googlesource.com/src/ (C++)
|
| * 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. I am currently pretty
| tied up with Pion so haven't been able to make much progress
| lately.
| josephg wrote:
| 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 wrote:
| 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
| vasilvv wrote:
| 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)
| qwertox wrote:
| 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 wrote:
| 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.
| dillondoyle wrote:
| 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 wrote:
| 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...
| api wrote:
| 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.
| lazyjeff wrote:
| 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 wrote:
| 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 wrote:
| 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.
| taf2 wrote:
| "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...
| solarkraft wrote:
| Side note: Try browsing the internet v6-only. It's pretty
| eye opening.
| api wrote:
| 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 wrote:
| 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
| kevin_thibedeau wrote:
| 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.
| ignoramous wrote:
| 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).
| pojntfx wrote:
| +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 wrote:
| 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.
| craftinator wrote:
| They discontinued that in 2022.
| Sean-Der wrote:
| 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!
| TrueGeek wrote:
| Can we now get support for it in Safari WebView on iOS?
| chovybizzass wrote:
| i always stayed away from WebRTC because of that tunnel thing
| that seemed like a real pain in the a55
| viktorcode wrote:
| > WebRTC implementations are required to support both Google's
| free-to-use VP8 video codec and H.264 for processing video.
|
| I understand that backwards compatibility is very important, but
| this adds to technical debt.
| dane-pgp wrote:
| I don't know if people remember the fraught Codec War of 2014,
| but the choice of VP8 and H.264 both being "Mandatory To
| Implement" was the compromise that the IETF reached, despite
| much opposition from both sides.[0]
|
| As often happens with wars, though, the outcome in 2014 wasn't
| enough to permanently settle the matter, and there was a
| further outbreak of fighting later between VP9 and HEVC. More
| recently, some are saying[1] that the Codec Wars are back, with
| the arrival of AV1 as a contender.
|
| [0] https://bloggeek.me/winners-losers-webrtc-video-mti/
|
| [1] https://bloggeek.me/av1-vs-hevc-webrtc-codec/
| Sean-Der wrote:
| It is pretty nice to have both!
|
| For beefier machines VP8 works great, and you don't need to
| worry about cost. For IoT/Embedded space you usually just get
| H264 (from a hardware encoder). If we didn't have both I think
| it would shut out a lot of interesting use cases.
| thomzane wrote:
| Jitsi made it into the announcement!
| ChrisArchitect wrote:
| how far this has come.....from a dream, over 10 years ago, to
| this. I know it still seems complicated in some regards etc but
| the possibility of video over web, p2p capabilities etc instead
| of having to use terrible apps, Apple stuff, quicktime, etc just
| to have some video conferencing....was a pipe dream
| qwerty456127 wrote:
| Does it still leak IP addresses?
| aerovistae wrote:
| I have tried using this API and found it incredibly technical and
| complex. Personally I find the PeerJS library an excellent
| wrapper rendering it useable.
|
| Hopefully over time it will become more accessible.
| kaycebasques wrote:
| Any specific problems you recall?
| afavour wrote:
| I think that what it's doing is sufficiently complex that the
| API is always going to be difficult. As long as abstractions
| like PeerJS exist I'm OK with that.
| amelius wrote:
| The main achievement of the technology is to work around the
| shortcomings of other technologies. Complex might be the wrong
| word as it's not rocket science; convoluted sounds better.
___________________________________________________________________
(page generated 2021-01-27 23:00 UTC)