The object real-time communications (ORTC) specification revolves around object-centric APIs to enable WebRTC in browsers, mobile endpoints and servers. Unlike WebRTC 1.0, ORTC does not mandate a media signaling protocol or format, so it doesn’t use session description protocol (SDP) within its APIs. The ORTC API requires less of a background in UC concepts like SDP and SIP and is designed to address WebRTC, mobile and server-side development needs.
The ORTC specification was recently updated, including support for simulcast and scalable video coding, as well as enhancements to the object model such as control of senders/receivers as well as communications transport aspects (ICE, DTLS and data channel).
“While additional work is still needed to complete the ORTC API specification, several missing pieces (such as support for statistics) have now been filled in, and in its recent meeting, the CG had a discussion of the remaining items and priorities. With more than 35 members (including Google, Hookflash, Microsoft, TurboBridge and Versatica) and growing traffic on the mailing list (120+ messages so far in April), a community of interest has formed to drive ORTC API forward, and the interest level continues to rise,” Adalberto Foresti, principal program manager at Microsoft Open Technologies, wrote in a blog post.
Wait – but why is SDP so wrong for WebRTC?
Iñaki Baz, one of the authors of ORTC, explained in a WebRTC Hacks interview last August some of the reasons SDP isn’t right for WebRTC, including:
- SDP comes from the telco world with no consideration for different call models that will exist in the Web world.
- The SDP format is very “flexible.” The bad side of this flexibility is that each browser in a call could generate completely different SDPs while still adhering to the same semantics. SDP generated by WebRTC compatible SIP servers in the middle of the call flow would add further complexities.
- The biggest problem with SDP (and draft-roach-mmusic-unified-plan-00 that defines the SDP format for WebRTC) is that the call initiator not only offers the remote party what he is going to send, but also indicates what that remote party can send back. Specifically, if the call initiator only offers to send its audio MIC, this results in one line of m=audio in the SDP offer. This means the remote peer can join with audio communication, but cannot add video (since the SDP answer must have the same number of m lines). Adding remote video would require another SDP O/A round trip.
- Applications like Chromecast stream your browser screen and audio to a TV. The TV is not going to send any media back to the browser. Why should the TV have to respond to your request and negotiate what codecs to use in both directions?
Hookflash, Versatica and TurboBridge are some of the forerunning companies in the ORTC space, and are pulling in Microsoft to support WebRTC. Microsoft – mostly noted in WebRTC for not jumping in with support with Internet Explorer – is behind ORTC as it fills in some of the gaps and issues with WebRTC 1.0. MS Open Tech developed a prototype implementation that shows ORTC in action – it delivers real-time video chat between browsers, which supports the STLS and ICE transport model.
The updated editor’s draft of the ORTC specification can be found here.
Edited by
Maurice Nagle
