Comment by Orphis

Plan-B hasn't been relevant in a very long time and Unified Plan has been in a good working shape (and used by Google Meet) for many years. Firefox has lacked many critical APIs from Unified-Plan that developer cared about for a very very long time such as everything related to simulcast and get/setParameters or codec control which are very basic and where implemented in Chromium back in 2018. Firefox didn't have them in 2024 still in working shape. So you can't really blame that long delay on Chrome or on the other APIs it shipped early.

As for the other APIs you mention, developers had wanted those shipped then, so developers got them. The risks are evaluated, but in the end, the client is king. If the standardization process is slowed down because of nitpicking and procedural mishap and not able to work with the needs of the users, it's a problem. It took years for them to be standardized while being heavily used by experts everywhere in the first version. Shipping early is also part of the standardization process where it goes to trial and it is evaluated by users, so it's not surprising to have a complex API implemented first to gather feedback. Without such feedback, none of it would have been implemented or standardized the right way. It's implementation experience that is crucial for WebRTC's domain space.

WebRTC is a live API, it's changing all the time, especially with all those expert APIs. It's not unexpected. But years long delays don't serve anyone except for late implementers that then have the newer version done and can complain that someone else is not compliant and their version is "better". No, you're just super late at implementing a live API.

That's why Firefox has been having issues with WebRTC for a long time. Having the ICE server validation WPT passing is great, but that's only an edge error case, it's not what is passed by applications in working shape or what developers need.