WebRTC, SIP and Open Standards
Some of the SIP proponents out there are not very happy about a recent JavaScript Object Rationale Draft that was published on the IETF RTCWEB mail list ahead of the WebRTC Expo in Atlanta. Full disclosure, I am one of the authors of that draft.
So, what’s all the hub-bub? Some of the reasoning seems to be..
- SIP and XMPP are the standards, everything else should take a backseat.
- The current WebRTC model should be the priority, stop asking for changes, you are just getting in the way of progress.
I understand the reasoning, I used to be one of those SIP advocates and I still believe that SIP has its place. To say that SIP and XMPP should rule all is just a bit much.
The one thing I am rather sure of is that SIP will not be the signalling protocol that ultimately ends up powering web communications. It’s just not practical. This doesn’t mean that SIP won’t be part of WebRTC, it just means that eventually we will move towards a more web-centric model.
To be clear, we are not against SDP in WebRTC. In fact, we believe that any API proposal should have both a lower-level Object model and also provide real support for SDP at a higher level.
To that end, we have created a new Object-RTC draft proposal that outlines this model in detail, which also supports SDP Offer / Answer. Yes, you can have have your cake and eat it too. This draft is about JavaScript, SDP (not baked into the browser) and the Open Web.
The question is, “When is the best time to submit the Object RTC proposal to the IETF and accompanying API docs to the W3C?”
We are not hell-bent on derailing the current progress being made in the respective working groups (contrary to what others may think). So potentially, you may not see the Object RTC draft in the wild before the conclusion of the next IETF meeting in Berlin, only a few short weeks away.
Here’s to making marked progress on v1 in Berlin so we can get on with 2.0.
From the Sidelines, My Introduction into RTCWEB
I’ve been following the RTCWEB standardization for a while now from an architecture and technology standpoint. For the most part, I’ve been quiet and I’ve assumed a rather neutral stance in regards to the RTCWEB process when it comes to Open Peer, but my opinion has changed and I can no longer maintain a neutral standpoint.
There are many companies taking stances who all need to have a say in what happens because they want to make sure their technology does not get left out in the cold when RTCWEB comes into reality, as most people think this technology will be huge with consumers and businesses. The big guys with SIP, XMPP and Skype have various established offerings and they are married to existing technology that is difficult to change. They need to make sure that RTCWEB closely follows, or at the very least, does not hinder their own technology from functioning otherwise they will get left behind. The process of adapting existing systems to a new standard is understandably costly.
Thus, I have to ask, who am I with Open Peer to come along and push back against these tides as a new protocol when I have much more flexibility in our implementation than existing deployed systems? Further, the Open Peer protocol particularities didn’t even exist until recently and it has been under revision as Hookflash tested the implementation. We’ve just recently published our specification and source code and we’ve just undergone a significant update based on internal and external feedback from our initial implementations.
To be honest, architecting, designing and implementing a brand new protocol with such an ambitious scale for a small company has kept me extremely engaged and busy. I could listen to what’s happening from a 1,000-foot high perspective, but unfortunately that has also been a factor in my personal ability to participate. I don’t think it’s a great secret for those already involved that it takes immense devotion of time resources to follow the details, let alone participate in these long drawn procedures in ratifying a specification complex as RTCWEB that spans two organizations, namely the IETF and W3C groups. This is unfortunate that such time commitments are so huge as I think having those on the front lines much more actively involved would be healthy, but I digress.
In reality though, Hookflash is in a unique position with Open Peer. I am working on this protocol with a clean slate and a future thinking sense. I do not have the old technology shackles and I didn’t have to design with legacy deployed services in mind which would no doubt confound my decision making process. Likewise, I’ve had the experience of these legacy systems to help avoid their pitfalls (specifically as the original author of the X-Lite/X-Pro SIP softphone client for CounterPath years back with SIP).
For those unaware, Open Peer is an open peer-to-peer signaling protocol that has an initial implementation in C++ and Hookflash is in the process of writing a pure JavaScript version. The idea is to allow secure peer-to-peer signaling communication straight from browser-to-browser and capability to talk to native mobile device applications as well.
The Open Peer implementation goes beyond basic call flow signaling and even beyond peer-to-peer signaling and incorporates identity and federation concepts with strong privacy and security considerations in mind.
Having just completed the next iteration of the protocol that is going through internal testing, I plan to spend much more time actively examining the details of RTCWEB standards. Even though I’m later to the table representing a newer company with newer technology, I hope the input will be welcome to the discussion. I do understand that decisions may be too immovable to change peoples’ minds and there is an active amount of established legacy systems, but hopefully coming from a unique perspective will help bring fresh blood and deeper insight. Forgive me if I argue points already lost, but I will always explain my reasoning for wanting to push certain aspects even if I am ignored in the end.
Ultimately, Open Peer will leverage RTCWEB and the implementation will adapt accordingly to the mutually agreed standards. I’m still going to give my opinion for whatever it is worth and I hope to prove it worthy, unique and valuable.
There are many bright people involved in the process and many companies with unique corporate political angles and agendas. My perspective and motivation will be straight up front. I want RTCWEB to succeed as soon as possible, but with an equal emphasis on ensuring the technology is sound from the future perspective as well, obviously in relation to plans with Open Peer utilizing RTCWEB.
WebRTC is live. Flash, take cover!
Update 2: To the hundreds/thousands of repetitive spam tweets / twits, “Will WebRTC replace / kill Skype”, the answer is NO!! It will not. WebRTC is using broken Jingle in the browser, it does not support chat and can only make and receive calls., there is no buddy / contact list to speak of etc etc. NO it will not replace Skype. Stop with the spam tweets already, please!
Update: It seems to me that until all the browsers are on board, native clients will be required to make this go. Which is not outside the realm of possibility, considering Google has open sourced the GIPS audio and video engine along with WebRTC.
Something to remember, WebRTC is not RTCWEB! It may sound silly but it’s true. WebRTC is a Google-centric project using Google code etc. RTCWEB is essentially an IETF effort, a working group driving towards open real-time communications on the web. They are not the same, which can be rather confusing.
— Original Post —
Google has been busy it would seem, last night WebRTC appeared to the public for the first time. This has some pretty serious implications for Flash, which was the de-facto technology one had to use to get real-time communications in a browser, that has now been circumvented, at least to a certain degree.
The sessions are not run by a signaling protocol per se, not Jingle, no XMPP, not SIP not anything we have seen before. All the session management looks to be coming from libjingle. Which, to me means Jingle is in the browser.
A few early comments:
1. Where does Google stand on websockets? Google have said they will block it if an exploit emerges.
2. Chrome, Opera & Firefox are the supported browsers. Where does Safari and IE land? My guess is that Microsoft will not be in any hurry to implement this considering their recent Skype acquisition.
3. Web-cam captures from HTM5 has not been ratified, although this is likely not as serious as the former points.
SIP + RTCWEB marriage in question?
The RTC WEB sessions in Prague made it pretty clear, to me at least, that everyone knows that SIP is broken and we also know that it’s not going away anytime soon. That being said it will likely not be the only protocol to be used in conjunction with RTC WEB.
I think it’s a consensus, at least of the IETF participants of the RTC WEB BOF, that we should not be discussing signaling protocols within RTCWEB at this early stage in the process of creating a WG (working Group) in the IETF.
It’s likely the correct approach. If we pigeon hole the community into using one protocol over another we are not really doing the future of communications any great service. In the same breath I also think it is important that we do not lose sight of the fact that the business world today runs on SIP and will continue to do so for some time to come.
The one thing that stuck out is the obvious gap that exists between what we have today and what we need in order to make RTCWEB a huge success, although I do know of a few companies that can move rather quickly when presented with a challenge as well so maybe it’s not such a big deal.
Prague was great, on many levels. It will be very interesting to see the progress we make between now and Quebec.
WebRTC.is 