The first ORTC Public Draft Specification has been published, authored by Hookflash, Microsoft, and Google. (http://ortc.org/wp-content/uploads/2014/08/ortc.html ) This specification extends WebRTC 1.0 with new functionality to create a WebRTC 1.1 API with exceptional flexibility and no loss of compatibility.
Like WebRTC, ORTC (Object Real-time Communication) enables plugin-free real-time communications for mobile, web and cloud, but is specifically tailored to provide the direct control needed to enable advanced multimedia and conferencing features.
“We heard developers say that they wanted more direct control over the technologies available in WebRTC. At the same time, we didn’t want existing developers to have to start over with a new API. ORTC is our proposal for how we can accomplish both of these things – a new set of APIs for direct control, that builds off the existing WebRTC 1.0 API set. As an evolution of the existing API, we consider this WebRTC 1.1” comments Justin Uberti, Google Tech Lead, WebRTC. “We’re grateful to Hookflash for their work to get ORTC off the ground. They have been instrumental in making this cross-industry collaboration happen, and we look forward to continuing our work with them.”
This newly published public draft has come a long way since the W3C ORTC Community Group was formed in mid-2013. As it has progressed from an initial set of ideas to a fleshed-out draft complete enough for implementations, several companies have gotten closely involved, with Microsoft and Google now joining Hookflash as authors of the emerging specification.
The W3C ORTC Community Group now numbers more than 60 participants.
“We believe the contributions to WebRTC 1.1 / ORTC will allow web communications technology to become ubiquitous and transcend nearly all communications technologies that came before it” says Hookflash Co-founder, Erik Lagerway, “We are honored to be working with some of the brightest minds at Google, Microsoft, and the other contributing members in the ORTC CG to mature WebRTC into a universal go-to toolkit enabling communications across the globe.”
Hookflash enables real-time social, mobile, and web communications for integration of voice, video, messaging with federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc.
Developers can register at (http://fly.hookflash.me) to start using the Hookflash RTC service and toolkits today. For more information on Hookflash RTC toolkits and White Labeling please visit Hookflash http://hookflash.com.
Come and work at one of the coolest companies in the space! We’re now hiring for these development positions: iOS, Android, Node.js & C++ send us your resume: email@example.com.
Hookflash – Trent Johnsen
855-466-5352 Ext: 1
The W3C ORTC Community Group has published an Editor’s Draft update to the ORTC API and is also asking for last call comments on the draft…
We are nearing completion of the ORTC specification for our initial ORTC community group draft. We are asking for last call feedback at this time. Some comments to explain some of the changes are still pending but all issues are tracked here and on github. If you would like to make comment, please have a read through and make comment either on this list or as part of our next CG meeting coming up.There are a few outstanding areas which are “pending” synchronization with WebRTC, e.g. stats, data channel, and IdP. As these have dependencies on WebRTC 1.0, we will attempt to complete the our specification as best we can but those areas will be subject to synchronization should updates come out of the WebRTC community group.Now is the time to have a read through for final review as the next stage will be to build implementations for implementation feedback.
So if you are fuzzy on where the ORTC CG is headed, you should really check out that video clip.
There might be a joint IETF/W3C WebRTC F2F meeting in May, somewhere on the North American East Coast.
From the W3C Chairs…
There has been some feedback on the dates. We propose to shift the
potential f2f meeting one day earlier to reduce the overlap with a 3GPP
The proposed dates for the meeting is therefore 19-21 of May (Mon-Wed).
Stefan for the chairs
On 2014-01-29 09:20, Stefan Håkansson LK wrote:
> Hi all – and sorry for cross-posting!
> The chairs of the WebRTC WG (and the Media Capture TF) and the chairs of
> the IETF rtcweb WG are considering an joint f2f meeting. The dates we
> chairs have arrived on as feasible are May 20-22 (Tue-Thu). We are
> considering to split up the time between W3C and IETF across all three
> days. We have not yet discussed how to split the W3C time between WebRTC
> and the Media Capture TF at all yet (and perhaps we end up in focusing
> on the WebRTC WG since that part would probably benefit most from a
> joint meeting with the IETF rtcweb WG).
> The message at this stage is: please take note of these dates in your
> calendar now.
> The target region for this interim would be East Coast of North America,
> but we have at this stage no host or set location. If you are willing to
> host, please contact the chairs.
> We haven’t decided on this f2f meeting yet, and appreciate your input
> into holding one. The goals of the meeting would be to advanced the
> state of the core documents we need to finish up.
> Stefan for the chairs
Here are the ORCA Community Group meeting details for our very first CG meeting.
Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)
• Introduction to the CG
• Quick review of progress to date
• Overview of meeting objectives
– Existing proposals review
– New proposals & review
– API discussion
• Closing remarks
• Action items
NOTE: If you are on the public mail list but have not yet joined the Community Group but would like to attend the meeting you may certainly do so. However, if you are planning on making a contribution you will need to join the CG and make those contributions on the mail list.
Here is the link to the current CG participants and a link to join:
Looking forward to seeing you!
There’s a lot of noise and plenty of dust getting kicked up around WebRTC these days. Every hour it seems there is another company announcing support for WebRTC or have built an app that uses the technology. In many cases it’s an extension to the existing offer, where WebRTC is leveraged as a web-based SIP softphone for instance.
For the love of Pete, does the world need yet another phone?
What does excite me is when I start thinking about the effects that WebRTC and ORTC will have on rich media OTT (Over The Top) communications moving forward.
If we look at the success of apps like Whatsapp, Tango, Viber, Voxer, Facebook Messenger etc etc these are all OTT applications that have already won in mobile communications. Placing a phone call, is nearly the last thing a teen or twenty-something user is looking to do with their phone. Just by pure observation, we can see this demographic using mobiles devices for messaging and now video chat more and more. Btw, this is the generation that will be leading our Enterprise companies in the not so distant future.
We know this, but we still insist on integrating old tech that does not seem to be accelerating in growth. Why? To answer my own question, “because lots of us continue to buy VoIP phones and SIP PBXs for our business”. And to that I say, good for you! But that is not the real opportunity for those developers who embrace WebRTC and ORTC.
WebRTC & ORTC will allow us to push the envelope and do things we can’t do today. And to do things we can do today but in a much more efficient and enjoyable manner. Maybe RTC will find its way into social news, citizen journalism, or maybe media rich banking, healthcare and CRM apps, in your TV, mobile devices, browsers et al. The possibilities are nearly endless but one thing is quite clear, it’s not going to happen unless we change our current approach.
Chair: Taking the discussion back to the list.
Harold: We are witnessing a massive abuse of IETF policies. We have spent months on this.
Long line at the mic now
NEITHER CODEC WAS SELECTED
VP8 – about 30% of the room
Jabber: 30 for VP8 and 10 for 264
H.264 – about half the room
Chair / Ted Hardie:
Regarding the consensus call, raise your hand for either or both but not neither. This is not a call but simply calrification
Chair / Cullen: Agreed, hugs coming your way.
Martin: Keep in mind there are some that can’t get up and talk about that.
Chair / Cullen: We want to ask if you can’t live with either one of these codecs please get to the mic.
Tim Terryberry: Re: JR we need a royalty bearing codec if webrtc is to take off. I don’t think I need to tell the people in this room how excited everyone is about video in a browser without a plugin, ll of those are VP8.
Justin ? : Risk and Trust. Free codecs sounds good but today that’s not a reality. One of the advantages of going through an SVDO process is that the members must declare IPR, free codecs do not go through that. VP8 is not a free and the wind codec, it’s owned by Google. Google controls all of what VP8 is, can they be trusted. Who has implemented VP8 from the spec, not source.
?? – Technology is for people. The decision is for what we have today, not yesterday. Google has done a great job.
Harold Alvestrand: If people think that this announcement from Cisco of “later to be provided code” then I have real issues with the IETF process. Sooner or later we should find a way forward to rely on un-encumbered patent- less codecs, and if not now, then when?
Eric Rescorla: Mozilla intends to support 264 and VP8. We intend to support 264 via Cisco’s code/plugin on desktop. We will try hard to use the hw codecs since that works better on mobile. The user experience, during the install the codec will be installed (part of the install process). VP8 will be shipped with both mobile and desktop.
Bernard Aboba: It’s ok JR we do love you, hugs later.
Blackberry ?: Like the idea we would have a track towards better quality. The license is a big issue. VP8 is not a specification in the MPEG LA, but since it’s not there we have no mitigation there so we can’t make VP8 the MTI.
Randell Jesup: Those who are not making a browser but instead a server like asterisk or the like, their users would also have to download this plugin codec as well. It’s unclear if this would fall into the personal non-commercial use category. IT is not going to like this either, dealing with plugin codecs will make their lives potentially rather difficult.
JR: Arguing that we must choose a MTI codec or they can’t ship
Robin Raymond: I think it’s great that this new 264 codec is out there but if we make it mandatory the little guys lose. Mobile can’t download a binary, it must be part of the app before deployed. If you need H.264 you can add it if you need it but don’t force that royalty bearing codecs on all of us.
JR: Users don’t need to get plugins, apps do that.
Dean Willis: I don’t build browsers. For the last 7 years I have made my career on IPR consulting. If we were to pick 264 as MTI and since Cisco is not part the MPEG LA there seems to be risk there. Seems to me no choice works as well.
Roman Mahy: The most compelling items were the embedded platforms. My experience it was at one point very hard to find hw accelerated encoding, in the past.
Peter Thatcher: We turned on transcoding for a well known chat service and no one noticed. We are better off allowing the market to decide as Martin indicated months ago.
Justin Uberti: Regarding Adam’s comments regarding someone recording calls does not the understand the current laws. If you want to ship h.264 you can, no one is stopping you but not as the MTI codec.
John Peterson: This Wg has made plenty of decisions re: interop and we have saddled this WG with SIP /OA, but I think we should go with H.264
Roberto ?: The bias seems to be present, that larger companies have an easier time sending people here. If you choose to make 264 the MTI you are cutting out the small guys. I think the best option is to choose neither.
Matt ?: There are plenty of lawsuits against 264 so to say there is no risk with 264 that is simply not true. External plugins are not cool.
Ted Hardie (independent) : I offered JR a hug as he seemed to feel the free 264 effort was not appreciated. One of things we were trying to avoid is a plugin scenario and this (other things were added) is the reason we can’t invoke 264 as the MTI video codec. Royalties will push away numerous developers, big and small. Since 264 is now free (not free from royalty), we can add that codec as a non-mti codec.
JR: Transcoding degrades quality.
Martin Thompson: Let’s stop messing about with semantics, 264 is clearly the correct choice here so let’s get on with it.
Chair / Cullen Response: That was put to the list months ago and no one came forth with a proposal so that is not on the table today.
Jeremy ?: We could also consider both codecs.
Jean ?: Calling Nokia to the mic to clarify why there is a patent claim on VP8 and not on 264.
Peter Thatcher: Seems there are 2 broad categories, H.264 is better and the patent argument. The first is simply perspective and the second the patent being mentioned with Nokia is not resolved and if we are making a decision to implement 264 maybe those making that decision should wait until that is resolved.
Justin Uberti: Interop is misunderstood. Transcoding is cheap so that does not hold in the commercial world. VP8 is shipping in plenty of endpoints. Hardware Codecs are quite a ways off, there is LOTS of works that needs to be done here.
Monty Montgomery: If we go down this 264 path we are staking our future on a binary law environment.
Harold: To Cisco, please publish your findings
JR / Cisco Conclusion
JR Arguing Risk Analysis
JR Arguing Risk Assessment
JR Arguing Distribution
JR arguing the results in Germany (re: Nokia VP8 patent being put down in Germany) may or may not be a consideration
JR arguing that VP8 is a target for patent trolls
JR arguing patent risk
JR arguing both codecs perform nearly the same so let’s get past that
Justin asking, which of these represent (slide below) actual Real-time encoode/decode
Cisco response: much smaller percentage
H.264 vs VP8 Deployment & Standard
H.264 Shipping Date
Jonathan Rosenberg on H.264 for Cisco is at the mic
—- that was fast, thanks Harold! —-
Harold is at the mic..
NOTE: This post may not be entirely accurate. I am not the fastest typist in the world and I ad-lib when I can to get the general gist in the post.
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.