Early in 2013, Robin and I were becoming growingly 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 writes…
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).

 

Read the rest here.. ORTC.org/History

http://ortc.org/wp-content/uploads/2014/04/ortc1.html 

15.1 Changes since 12 April 2014

1. Fixes for error handling, as described in Issue 26
2. Support for contributing sources removed (re-classified as a 1.2 feature), as described in Issue 27
3. Cleanup of DataChannel construction, as described in Issue 60
4. Separate proposal on simulcast/layering, as described in Issue 61
5. Separate proposal on quality, as described in Issue 62
6. Fix for TCP candidate type, as described in Issue 63
7. Fix to the fingerprint attribute, as described in Issue 64
8. Fix to RTCRtpFeatures, as described in Issue 65
9. Support for retrieval of remote certificates, as described in Issue 67
10. Support for ICE error handling, described in Issue 68
11. Support for Data Channel send rate control, as described in Issue 69
12. Support for capabilities and settings, as described in Issue 70
13. Removal of duplicate RTCRtpListener functionality, as described in Issue 71
14. ICE gathering state added, as described in Issue 72
15. Removed ICE role from the ICE transport constructor, as described in Issue 73

A few things have happened that lead me to believe that H.264 has already won the WebRTC codec debate, regardless of what was not decided in the IETF RTCWEB or W3C WGs…

– Cisco delivers Open Source H.264 Codec via OpenH264.org

– Google and Cisco demonstrate H.264 interop in Chrome

– WebRTC Source Code for H.264 implementation surfaces in the WebRTC Developer mail list

So it looks like Chrome will end up supporting H.264 = they will support both VP8 & 264

Mozilla / Firefox already said they will support both.

Apple seems to be getting more involved, my guess is that they will announce some level of WebRTC support for Safari at WWDC. If they do, they will also favor H.264.

Since ORTC will be compatible with WebRTC to some degree,  IE modern APIs group has indicated that ORTC is “under consideration”. Microsoft also seems to favor H.264.

That covers all the major browsers.

It feels like the MTI Video codec issue is a non-issue.

The ORTC CG is making great progress on many fronts and it looks like the conversation around RTPSenders & Receivers (formerly known as Doohickeys) is taking more shape in the WebRTC WG. They even have a name there now: RTCRTPSenders / Receivers. The WebRTC WG teleconference call today was far less controversial than I am used to, it felt like everyone is trying harder to get things done.

I am not convinced we need Constraints at all in 1.0, by the rumblings on the calls it seems as though I am not alone. You can see that conversation taking shape in the Working Group here:

http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/

Here is a decent summary on the recent ORTC API update.

Current editor’s draft of the ORTC API has been published: http://ortc.org/wp-content/uploads/2014/04/ortc.html

The next ORTC CG meeting is scheduled for April 17, 2014 at 10am Pacific. For more information on the W3C ORTC Community Group meeting you will need to join the Community Group here.