It isn’t being deprecated. It is just that new technologies that are part of WebRTC get their own API surface.

While 1:1 remains a very important use-case it is boring. You can’t tweak and differentiate much, the game there is reliability.

I completely agree with Tsahi about this changes will increase the barriers to develop applications into the “new WebRTC” also can segregate fast and short communications like a simple phone call.

Well, let’s see what could happen in the future because new use cases incoming because COVID introduced a new very big needs of society.

There is no change for Chromium. WebRTC is part of HTML5 and this isn’t going to change, so Chrome and Chromium will continue supporting it.

If Chromium still has WebRTC in it. Would it still be Chrome, but suboptimized or would it be deliberately removed?

Kind Regards,
Carl

Alex,

Everything I portrayed is interoperable in theory as it all relies on web standards and not proprietary tech – the proprietary parts are added on top, mostly via WASM.

If unbundling can damage communication between me on mobile Chrome and the peer on MS Edge behind the call-center firewall, then it would be a bad move for the community as whole.

On the other hand, if unbundling provides more opportunities for independent vendors to come up with browser-based and/or native solutions for their challenges, this would be most welcome, and increase the market demand for us, software engineers who understand something about RTC.

Too many questions to answer here 🙂

NetEq isn’t overhyped. I think some of it can be implemented in WASM. In such a case, why not?

I don’t think this has anything to do with reasoning behind using or not using PION. It as well as GStreamer have their place in the world (mostly in embedded and client on a server side scenarios is my guess).

Zoom started alongside WebRTC and decided not to adopt it. It worked for them. Didn’t work for others like WebEx that did… almost the same. Execution is a lot more than the specific technology being chosen.

I think the binary web is a necessity. I prefer H.323 over SIP but prefer WebRTC over both of them. Does that make any sense?

I also think the binary web will have a lot of JS around it to stitch it together and keep the higher logic. WASM is better served at speeding up certain tasks than replacing everything is my guess.

APIs are never useful without your own parts. If they were, we’d call them SaaS… a full service.

Congestion control will either be added to WebTransport or be enabled on top of it so you’ll be able to WASM your way into it. Again – my guess on where this will go.

W3C probably doesn’t look at such an eventuality. It will happen in small steps while focusing on other use cases and scenarios and then finding out that vendors adopted it for real time communications.

🙂