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.
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.
At WebRTC Expo, watching a great closing panel on “where we go from here”. Craig Walker of Firespotter / Uberconference makes some great points. If Google had not open sourced the GIPs media engine, none of this would have happened in the time frame it has, it has made this technology accessible not only for browsers vendors but for the independent developer.
Great show, the next one will be even better.
For those who don’t know, SDP is an old school standards-based text format (pre-1998) for describing media, codecs, state and networking information offered by devices for use in real-time communications and more recently as the proposed format for with WebRTC. I’ve written in the past about my disdain for SDP. To me, using SDP inside the browser for WebRTC seems akin to requiring all new computers use the graphics processing unit from the Commodore 64 for all future graphics engines. As cool as it might have been in its day, it is not exactly up to the task anymore and should be left to the realm of nostalgia.
My original thinking was that the SIP guys would really love SDP in the browser since SDP is the primary media description format they use. But I must recast my opinion to say it’s really bad for the SIP folks as well. Here’s why…
- An increasing need for Session Border Controllers: As it stands, the SDP that comes from SIP devices will need to be re-written and perhaps even put through some kind of Session Border Controller (SBC)/Proxy to maintain compatibility. SIP devices could face update cycles tied to browser updates. There are some companies in the industry who sell proxies that would greatly benefit from compatibility issues (as their role is to fix them) but I would hate to think that the IETF/W3C has been usurped by those vendors to push a solution that is not to benefit the entire internet industry and end users.
- SIP feature-creep: One thing I do know about SIP vendors is they love to add their own extensions to SIP to add their favourite competitive features they offer with their devices/networks. This allows them to claim “support” for something their competition does not support. To that end, I’ve noticed a continuous stream of feature requests to the browser vendors from the SIP world (and I’m certain the alignment to a SIP vendor’s own preferred feature is pure coincidence).
The irony is that if the SIP vendors had insisted that the browsers only offer a good core media/RTC engine, they could have implemented many of the features they now demand from the browsers vendors themselves without waiting for Google, Mozilla, Opera, Microsoft and Apple and the rest of the industry to agree. Talk about a SIP vendor’s dream in being able to offer some unique feature for their network! But now they have to wait and wait and hope and whatever ends up being released in the browsers will work for them and not introduce even more problems and incompatibilities to their networks.
Browser vendors will become the choke-point.
Microsoft argued so strongly against SDP and offer/answer, they have not agreed to support WebRTC and instead produced a competing specification called CU-RTCWeb. Their proposal starts from the premise of having a good media engine/RTC controllable at a lower layer would be far better for the industry and they have (so far) not released their Internet Explorer browser with WebRTC support. Whatever your feelings about Microsoft or their particulars of their proposal, they are right about SDP offer/answer and without their market share being onboard, it will hurt WebRTC’s adoption rate, especially in the Enterprise. Apple is sitting on the sidelines giving no indication their position while the industry sorts this out. I’d love nothing more for the industry than to have all vendors on the same page and agree to implement “something” usable, but it seems the SDP offer/answer model is not helping and in fact hindering that effort.
Where do we go from here?
The crew at Microsoft is forging ahead with their “CU-RTC-Web” specification as a counter proposal to the new WebRTC / RTCWEB proposed standard in the W3C and IETF. My colleague Robin Raymond and I certainly align with Microsoft on some issues, more specifically around SDP but it would have been good if this work took place inside the IETF.
I really can’t see Microsoft changing their tune anytime soon, which means that Enterprise web application developers will likely need to support both WebRTC and CU-RTC-Web if they are to be a plugin-less solution enabling RTC across all browsers. Not ideal.