[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.