WebRTC isn’t much different than its predecessors. Except for its approach.
When it comes to VoIP, you can say that the relevant solutions consist of 4 different parts:
- The codecs part, where specific codecs are selected. Usually ones that don’t provide any real capability. And then there are a whole slew of optional codecs.
- The media part, where different algorithms can be used to send the data from one side to the other.
- The signaling part, which being all encompassing, ends up having the word “SHOULD” in every other sentence, making each and every feature optional in nature.
- The infrastructure part, where server side components are defined, usually with a bit too much detail.
The end result? Long specifications with too many ways of interpretation. It becomes everything and nothing at the same time.
Ever tried running an interoperability test between 2 video endpoints of 2 different vendors? Got any video? Great! Have you tried the same vendors when adding to the requirements list security? Or NAT traversal? Or a newer/older codec? Maybe screen sharing?
It fails miserably. There are just too many permutations to test, each with its own interpretation by each of the vendors.
And then came WebRTC.
- It defined the codec part to the point of having religious wars as we speak on the mandatory codecs. Since the implementers are web browsers and not the vendors, there’s no real sense in the optional codecs that can be theoretically used.
- It provided the “best media part money can buy” simply by giving away GIPS engines for free and under a BSD license.
- It ignored signaling and left it to the implementers.
- And it provided vendors the imperative to provide innovation on the infrastructure part.
What it did best was to keep things simple. NAT is mandated and engrained within the specification from day one. There’s no option for security – or rather EVERYTHING is secured – there’s no other option.
What can I say? WebRTC chose the Tango over other dances…