[api]

Just tweeted this and plan to publicize. If we had web UDP we could port ZeroTier pretty easily to run in the browser, allowing web apps to coexist with machines on true virtual networks.

It'd probably be lighter weight than WebRTC, which is IMHO an over-engineered nightmare. I'd like to see just the A/V encode/decode parts of WebRTC live on and the rest of it get deprecated in favor of web UDP and open-ended browser based P2P implementations. That's what should have happened, not a monolithic katamari ball of a standard.

[xg15]

I think there is some value in having a (relatively) small number of transport-level protocols with known semantics.

If every web page would effectively reinvent their own transport-level protocol* including subtly different connection handling, congestion behavior and drop/reorder tolerance, that sounds like it would make life a nightmare for all network intermediaries.

(* I know the transport-level protocol is technically UDP but that doesn't count because all he practically relevant aspects are defined on top of it)

Also, ICE etc solves a real problem - that users of Web UDP would have to deal with as well. Why demand that everyone reinvents the solution for themselves if we can include a standard solution in the browsers for everyone?

[kelnos]

I don't consider WebRTC over-engineered at all. It's not a trivial protocol, sure. But doing p2p sessions over today's Internet isn't trivial.

Yes, if you just consider a client-server model where the server has a public, routable, non-firewalled IP, then you can do away with ICE/STUN/TURN, and it gets simpler. But that's not what WebRTC was designed for.

The SDP stuff might seem a bit arcane, and I would agree with you, but it's a widely-used telephony industry standard and there are libraries that will generate/parse them for you without you needing to do much.

Bona fides: I've implemented server-side WebRTC in C++ and Java. Was it trivial? No. Was it ridiculously difficult? No.

[api]

It doesn't have to be as complex as the ICE/STUN/TURN stack but that's not really my point.

Building blocks and programmability are better for a long lived platform like the web than giant inflexible monoliths. UDP and web assembly lets you implement the stack you describe and anything else that comes down the pike.

[bewo001]

The telephony argument for SDP was brought up a lot in the IETF. However, few SIP devices -- if any -- understand all the SDP extensions WebRTC has introduced. With RTP/RTCP the situation is even worse. You always need a gateway.

[mintplant]

Any insight as to why this comment has been so heavily downvoted? I don't see anything that would justify it.

[jandrese]

I don't know about other people, but it smells a bit to me like "this standard is too complicated, how hard can it be?", and then people implement their own thing and end up reinventing pretty much the entire standard, only in a nonstandard way.