People are talking about how WebRTC could in fact create more silos in communication that it potentially tears down. The fact that this video codec debate may never be resolved is not really the biggest issue, video codecs are not that easy to come by so as developers it’s likely we will all implement the most common and accessible codecs out there, including: VP8 and H.264, that is certainly the approach we are taking @hookflash.

The more glaring issue it seems could in fact center around the lack of a defined signalling protocol on the wire. Currently developers are left to their own devices (no pun intended) when identifying and signalling between endpoints in their interpretation of WebRTC. Which begs a question, “How one implementation of WebRTC communicate with another implementation of WebRTC?”

There are plenty of answers, most of them include “http, oauth, etc”. Which in itself is great, leve the developers decide, after all it’s their app! Some more telephony-centric developers will gravitate towards a SIP or Jingle implementation. But what about those who want to federate with other P2P-centric WebRTC offers out there and still maintain some sort if interoperability?

Tsahi Levent-Levi says…

I’ve been working for over a decade with SIP and H.323 – developing interoperable SDK solutions for the rest of the industry. At the end of the day, none of it mattered:

• We ended up as an industry with single vendor deployments for enterprises
• Interoperability was only skin-deep. The moment you wanted to do something real (security, collaboration, video), it just didn’t work
• Extending communication beyond the boundaries of the organization was impossible without PSTN

To me this seems awfully close to what you can achieve with WebRTC with two minor differences:

1. WebRTC takes that for granted and makes a real statement of it: there is no signaling – do whatever it is you feel like
2. It provides a common API with a common delivery platform (the browser)

As it stands today, there is nothing that fills that gap, but that is changing quickly. “Open Peer” is being positioned as a P2P signalling protocol on the wire for WebRTC with full control over Voice, Video, Messaging and Identities: local & social. As a founder @hookflash (creators of Open Peer), I may be somewhat biased (and sometimes I have a big mouth) but if you are building for WebRTC you really do owe it to yourself to check out Open Peer: http://openpeer.org and the Open Peer SDKs on Github.

RTT (Real Time Text) is something that some may think is important as part of the RTCWEB initiative, after all having a text component baked into the spec might make interoperability real, it also might help out with the hearing impaired.

Others feel that current technologies out there are more than sufficient to deliver RTT and we should leave it up to the developers eg. XMPP, SIMPLE, Open Peer, etc. etc. I would have to agree with that.

It seems the dataChannel was partially conceived to deal with this type of content, and adding more work to the heap there now is just going to delay things in the working groups. Let’s get the dataChannel supporting protocols, this seems like more important work and it might just take care of any RTT requirement by a developer?