Early 2013
The ORTC Community Group history has an interesting beginning and backstory. Here you’ll find some context as to why this CG was formed in the first place and how things have developed along the journey thus far.
Early in 2013, Robin and Erik were becoming more concerned about the direction the WebRTC WG in the W3C and the RTCWEB WG in the IETF were taking, specifically with respect to mandating SDP and not taking into consideration those who might want an Object interface versus a C++ / SDP O/A interface.
Robin and Erik decided to craft an RTCWEB WG email that would link to the blog post “SDP, the WebRTC Boat Anchor”. Here is the email that Robin sent to the IETF mail list back in March of 2013:
Do we need SDP “blob” format in the exchange in the first place? All media can be done without SDP given an intelligent stream API. An API already exists to create these streams (albeit somewhat lacking if we remove the SDP ‘blob’). This API helps “simplify” creating this blob for later exchange. But the blob is truly not needed. Each side could in fact create the desired streams, pass in the appropriate media information such as codecs and ICE candidates and chose the socket pair to multiplex upon. Yes, it’s a bit more low level but it certainly can be done (and cleanly).
https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
Nothing wrong with the draft in an SDP/SIP mindset but I’m going to take it from a totally different non-SDP angle. I have to say, the ideas presented are very good. I appreciate FEC, and synchronizing streams is cool. But SDP isn¹t needed to do it. Let me as the programmer worry about how to manage streams and the features on the streams and associations between the streams via an API only.
Point 4, 5 and 6 in the specification all have to do with the complexities of having to describe the intentions of mixing in SDP. So no comment beyond ³don¹t use SDP².
As for 7.1 ³this is because the sender choses the SSRC² only true because we are forced to use SDP and the assumptions is that it¹s SIP. We could have the receiver dictate what the sender should use in advance of any media. In our case, we establish in advance what we want from all parties before even ³ringing² the other party. We do not have SSRC collisions as we reversed the scenario allowing the receiver to pick the expected SSRC. Coordinating the streams is a problem with SIP because of how they do forking/conferencing. This specification forces this issue on those not using SIP. If SIP has problems with streams arriving early to their stateful offer/answer then let them worry about ³how² they intend to match the streams at a higher SDP layer and get this draft out of the RTCWEB track on the SIP track. To be clear, the proposal seems entirely reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for general use.
On that note, what I do need in the API is an ability to dictate the SSRC when I create an RTP stream for sending (should I care to do that).
7.2 Multiple render
Again this is an issue of SIP/SDP. We can control the SSRCs to split them out to allow multiplexing easily on the same RTP ports with multiple parties/sources. If given the primitives to control the streams just, this specification could be used to dictate how to negotiate issues in their space.
7.2.1 I¹m feeling the pain. How about just giving me an API where I can indicate what streams are FEC associated.
7.3 Give me API to give crypto keys to RTP layer. Let me handle the fingerprint and security myself beyond that.
8. Let’s just say politely that I would not want to be the developer assigned to programming around all this stuff.
Again, a perfect illustration why I don¹t want SDP.
Media is complicated for good reason as there are many untold use cases. The entire IETF/W3C discussion around video constraints illustrates some of the complexities and competing desires for just one single media type. If we tie ourselves to SDP we are limiting ourselves big time, and some of the cool future stuff will be horribly hampered by it.
My issues with SDP can be summarized as:
– unneeded – much too high level an API
– arcane format – legacy and problematic
– offer/answer
– incompatibilities
– lack of API contact
– doesn’t truly solve goal of interoperability with legacy systems (eg.
SIP)Regret that I did not have time for feedback earlier. As you can tell, I am not at all happy with where we sit today wrt requiring SDP. IMHO we need a lower level API if we are going to insist on using SDP.
You can read my entire (long) rant against SDP here
http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
This set off a chain reaction which sent the IETF RTCWEB mail list into a frenzy! Some praised them for standing up and calling it as they saw it whereas some referenced this as a disruption to progress which resulted in them being asked to not drop bombs like this unless they were prepared to deliver proposals to back it up.
July, 2013
So, several enthusiastic developers got together and wrote the first WebRTC Object API proposal and submitted it to the IETF.
July 2013: WebRTC JS Object API Rationale
Some rejoiced and again some were not as excited (see above)! It was decided that if success as a community group was going to be had, a W3C Community Group needed to be formed so that appropriate direction could be taken to not disrupt the IETF WG. As a result, the ORCA Community Group was formed in late July, 2013 with early support coming from Microsoft and Microsoft Open Technologies.
ORCA Community Group W3C Site: http://www.w3.org/community/orca/
Public Mail list archive: http://lists.w3.org/Archives/Public/public-orca/
October, 2013
In October 2013, the ORCA CG had put together the first API draft specification.
http://www.w3.org/community/orca/2013/08/15/webrtc-object-api-alpha-request-for-feedback/
November, 2013
By November 2013 the draft was published as the first report in the CG.
http://specs.ortc.org/2013/20131103/
The ORCA CG organized a ORTC API Walkthrough at the IETF 88 meeting in Vancouver in November 2013. The Walkthrough Meeting was a huge success – standing room only! Shortly after the meeting Robin and Erik saw many others join the CG including Justin Uberti and Peter Thatcher from Google. To have the original authors of WebRTC be part of their CG was a very big deal!
http://www.w3.org/community/orca/2013/10/29/orca-walk-through-ietf-88/
Video from the event: http://www.ustream.tv/channel/ortc-live
December, 2013
In December 0f 2013 ORTC.org was formed as a result of needing one place to point to all the resources. The URL seemed to fit well with the API.
January, 2014
The New Year of January 2014 began with the publishing of an updated API draft.
February, 2014
Soon after it was announced that the first Community Group meeting was to be held in February 2014. When the CG meeting was announced some of the feedback included reference to other projects that W3C members were members of so they asked the ORCA CG to rename the CG to something else.
The ORCA CG grew from a handful of like-minded organizations and individuals to 43 members in less than 6 months.
ORCA List of Participants: http://www.w3.org/community/orca/participants
The CG Meeting took place on February 13, 2014 and went well. The community group agreed to change the name of the CG from ORCA to ORTC.
http://www.w3.org/community/orca/2014/02/13/our-first-orca-cg-meeting/
Minutes, Slides and Audio from that meeting W3C ORTC CG Meeting 1 – Feb 20 2014
The new CG was set up and existing members were asked to move to the new CG. Sadly, the W3C could not automate this process and it had to be handled manually. As a result, a few members were lost in the transition but the group also gained a few members as well.
http://www.w3.org/community/orca/2014/03/08/action-required-orca-cg-name-change-and-new-home/
April, 2014
The second Community Group meeting was held on April 17, 2014. Considerable progress was made on the API.
W3C ORTC CG Meeting 2 – April 17 2014
On April 29, 2014, the progress made in those last 9 months was nothing short of awesome. The editors were getting ever so close to publishing a ORTC API Public Draft, which would be a call to all to implement using the API, which is where the rubber meets the road.
June, 2014
In June 24, 2014, the ORTC API went into last call before asking for implementation requests.
Oct 27, 2014
As a major announcement, in October 27, 2014 Microsoft announced it will bring ORTC API implementation in their browser.
ORTC Lib was also taking shape as an independent implementation of the ORTC API focused on mobile scenarios.
Sept, 2015
In September 18, 2015, Microsoft announced that ORTC was generally available in Microsoft Edge.
https://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-now-available-in-microsoft-edge/
Spring 2016
The ORTC Lib implementation was made generally available. The initial release was made for UWP with planned support for other mobile operating systems.
Join Us! http://www.w3.org/community/ortc/participants
ORTC Site: http://ortc.org
W3C ORTC CG Home Page: http://www.w3.org/community/ortc/
Current mail list: http://lists.w3.org/Archives/Public/public-ortc/
Historial pages:
Archived ORCA Home Page: http://www.w3.org/community/orca/
Archived ORCA Maillist: http://lists.w3.org/Archives/Public/public-orca/
If you are interested in finding out more about ORTC you can reach out to anyone on the ORTC public mail list or you free free to contact us.
History page initially written by Erik Lagerway.*
* Edited for clarity and updated by Robin Raymond.
ORTC 
One thought on “History”
Comments are closed.