> It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between b

> It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between browsers, WebRTC needs STUN, ICE and TURN support for NAT traversal and packet forwarding in the worst case. You don't need WebRTC's level of complexity to do P2P. WebRTC is an over-engineered Rube Goldberg machine for many reasons, including the fact that it tries to include so many capabilities in a single standard. It's also complex because STUN, TURN, and ICE are overly complex. WebRTC should have used a simpler underlying design. You really, really don't need all that. I say this as a developer of multiple P2P protocols including some that are used in serious applications. Then there's stuff like: https://github.com/js-platform/node-webrtc https://github.com/js-platform/node-webrtc -- you don't have to do your whole backend in Node if you don't want, but you could plug something like this in on your servers and speak WebRTC to clients. In P2P a server is just another node and there is nothing the says servers can't talk in P2P networks. I do believe it would be nice to have UDP in browsers somehow. In fact I think it would have been far better to just add UDP to the browser spec and leave WebRTC out completely. It could have been implemented in JS (and WASM in the future) using TCP and UDP transport provided by the browser. Doing it the way it's been done is like including application software in a computer's ROM. It's the wrong place to put that level of abstraction.