There’s a catch…
We did this before, but had to take down the solution after a client flipped the script unexpectedly. This time made sure it stays.
Try it first, talk later
But…
Sure, the browser isn’t pulling off any magic tricks – it still needs a proxy, just like last time. The tech is basically unchanged, so I’ll copy the picture from there and spare you the introduction. Most of the points in the original post are still valid, found another interesting read on the topic here.
What’s new?
WebRTC evolved marginally. Products supporting it, even less. The only slightly spectacular bit is the (relatively) widespread adoption of WHIP.
Browser support for H.264 in WebRTC is now standard and more reliable across major browsers, to the point where you no longer need to transcode it for RTMP. There’s also wide support for hardware accelerated encoding that browsers can take advantage via the system’s media frameworks (like Windows Media Foundation, macOS VideoToolbox, or Linux VA-API/VDPAU).
There’s pressure on RTMP’s dominance, as major platforms offer SRT ingest as an alternative. But it will be a long while before RTMP is out of the game. On the other hand, there are efforts to improve it to support newer codecs, HDR, multi-stream, better sync, reconnections/resilience, etc.
Why doing this again?
For a while we wanted to leave wowza’s WebRTC publishing solution behind as it’s unmaintained and lacking features. Previous iterations made use of Kurento and MediaSoup respectively; while there’s merit to both, they’re painfully inconsistent and not ready for production in some respect. Long story short, eventually decided to give OvenLiveKit a try and found that it works more often than it fails.
The polished solution
…is here, you can deploy it in minutes and adjust it to your linking.
Lessons learned
WHIP is good, custom is bad: we’ve seen the wheel (read ‘signaling’) reinvented so many times it started to hurt; it’s nevertheless funny we all came to agree that a common standard would be good, despite previously praising the openness of leaving it open to custom implementations.
Things can change: browsers still evolve and they may decide to alter the way WebRTC (or signaling) works in ways you don’t care to anticipate. Issues like this and that troubled some products so badly that workarounds had to be put in place before the maintainers of the (sometimes commercial) solution published a proper fix, sometimes months later.
Scaling audio transcoding remains the true bottleneck; planning for Opus -> AAC at scale is essential, while video transcoding can often be avoided.
Latency perception matters more than absolute numbers; users tolerate 2–3s RTMP delays if the WebRTC-to-proxy handoff stays consistent.
Expect complex configurations and developer friction: any WebRTC+RTMP pipeline is full of configuration pitfalls; certificate issues, codec settings, peer connection lifecycles, signaling race conditions, misconfigured ICE/STUN/TURN, neglected firewall rules – all introduce bugs and/or user frustration.