A few more changes to be made before we call for implementations, very, very close now. Should happen in next couple of weeks with new Editor’s draft.
For those who missed it, Chrome 38-39 looks like it will be shipping with ORTC 1.1 RTPSender / Receiver APIs as announced by Justin Uberti at Google I/O 2014. This really should not come as any surprise as RTPSender / Receiver APIs are now on track for WebRTC 1.0 integration as well, as per the last W3C WebRTC WG Interim meeting.
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.
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.
Very productive CG call today, here is the entire 1 hour and 40 minutes. Plenty of great feedback coming from Bernard Aboba (Microsoft), Shijun Sun (Microsoft), Justin Uberti (Google), Emil Ivov (Jitsi.org) and Robin Raymond (Hookflash).
Looks like we are shooting for a Public Draft (with sample code) by end of June, we’ll see if that is achievable (there are quite a few question marks remaining) but at least we have a target.
If you are interested in joining the ORTC Community Group, you can do that here.
There is a some interesting activity regarding Sender / Receivers on both the WebRTC WG and the ORTC CG. Robin Raymond of Hookflash (ORTC CG Editor and Chair), submitted this beauty over an hour ago. To me, this is where we begin to see some real benefits offered by an Object model that is not encumbered by SDP O/A.
Hint: SVC (Scalable Video Coding or Scalable Video Codec) becomes the norm, not the exception.
From Robin’s proposal…
Introduction After attempting to write out some use cases using the existing RTCRtpSender and RTCRtpReceiver objects and parameters for ORTC, some issues were discovered. Specifically, the application developer would need to have a fair amount of knowledge on exactly how to tweak low level parameters for anything beyond very simple use cases. For example, setting up an SVC (Scalable Video Codec) would have required knowing about what codecs support SVC, how the layering is setup for particular codecs, and finally setting up specific geometric (or temporal) attributes and layering relationship details by an application developer.
Robin also includes some great SVC use cases..
Alice wants to use a SVC (Scalable Video Codec) to send to Bob
This is for illustration purposes only. Typical benefits of SVC are
greater in conference scenarios rather than traditional point to point
scenarios. However, this scenario can presume that an intermedia
conferencing bridge would be between Alice and Bob.
Current Parameter Based API
Step 1: (Alice)
var senderCaps = RTCRtpSender.getCapabilities();
Step 2: (Bob)
var senderCaps = mysignal();
var receiverCaps = RTPRtcReceiver.getCapabilities();
Read the rest here…