News

ORTC / WebRTC Pioneers

webrtc_pioneers_award

TMC / WebRTC World & PKE Consulting have published a WebRTC Pioneers press release following a WebRTC Pioneers dinner at WebRTC Expo in Atlanta last week, paying homage to some of the early work being done around WebRTC.

Congratulations to W3C ORTC Community Group founders & core contributors…

Robin Raymond – Hookflash

Bernard Aboba – Microsoft

Justin Uberti – Google

There are however, many names missing from this list who have had a significant impact on early work being done around WebRTC / ORTC. Peter Thatcher (Google), Emil Ivov (Jitsi) & Shijun Sun (Microsoft), Roman Shpount (TurboBridge) and Iñaki Baz Castillo immediately come to mind.

WebRTC Object API (alpha) – Request for Feedback

From the ORCA W3C community group…

WebRTC Object API (alpha):
https://github.com/openpeer/ortc/blob/master/draft-w3c-ortc-api-00.md

Early example code, written in Node.js:
https://github.com/openpeer/ortc

It is the current authors intent to provide an alternative to the existing WebRTC API, to allow more control to web developers looking to leverage WebRTC.

Rationale for this alternate approach can be found in the informational draft submitted to the IETF RTCWEB working group several weeks ago.

Those interested in assisting in the completion of this API reference are asked to join this community group and take part in the discussions by:

On behalf of the current authors, thank you for your support and consideration.

WebRTC, SIP and Open Standards

Patience, not something we are good at.

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..

  1. SIP and XMPP are the standards, everything else should take a backseat.
  2. 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.

SDP inside WebRTC is bad for SIP

WebRTC Hamster Car

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.

It seems the idea for using SDP from within WebRTC was to allow SIP vendors to take SDP from their devices and shove it into the browsers and immediately be able to communicate between browsers and SIP devices and to offer the JavaScript guys a simple API to program against. Sounds great, right?  Wrong.  The browser’s SDP and the SIP device SDP is already diverging in their compatibility. Be it Trickle ICE, CODECS, security, or newly proposed “features”, realistically few SIP devices are going to be compatible out of the box or remain compatible for long using SDP. Likewise, providing a simple API for JavaScript developers could have been accomplished by providing a JavaScript library, similar to the way jQuery works to abstract and simplify DOM manipulation (and many other things). In other words, the primary reasons for using SDP in the browser are negated.

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).

All the demands being put onto the browser vendors to add feature after feature truly scares me. As I foresaw, the innovation of features is tied to the release cycle of each browser binary being built, upgraded and rolled out to end users on each platform. Instead of features being added by by the programming language available inside the browser (JavaScript) which is dynamically updatable, features are now going to have to crammed into the browser binary because of modifications required to the SDP. What could have been simple change in JavaScript on a webpage is now tied by the innovation curve of the IETF/W3C tracks and each browser implementing these features equally across all platforms (and let’s not forget to including mobile in that list).

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.

Worse, browsers vendors will be reluctant and cautious to change SDP for fear of “breaking things” within existing networks if the SDP / WebRTC becomes used broadly. If SIP vendors could understand that writing SDP in the JavaScript layer was in their own best interest, they would get behind the idea of dropping SDP entirely from the browser layer and instead agree to generate their network compatible SDP from within the JavaScript layer exclusively.

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?

As much as I hate to say it, I think we need to hold off on releasing WebRTC as it is until we have a lower level API. SDP offer/answer is not going to cut it for the initial release, this first version of the standard needs to live on for at least a few years. We must deprecate the current WebRTC API in favour of a more suitable low-level replacement API. The revision should focus instead on the extensions that can be added in the JavaScript layer and only put the necessary hooks in the browser at the most basic level for a media and RTC engine to be controlled. Let’s not hamper innovation!

If we need compatibility with the current WebRTC API it would be easy to create a JavaScript shim that supports the current API and allows a more long innovative approach. If there is interest in creating such a shim, I would be more than happy to be part of that development effort.

Cross-posted to IETF RTCWEB Mail list

Written by Robin Raymond
Edited by: Erik Lagerway

1 2 3 7 8
Archives
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Spotify
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound