If you are new to WebRTC then you have missed out on years of drama in the standards bodies over various issues like SDP and codecs. These standards dictate what vendors must implement so they ultimately dictate the industry roadmap. To get a deep perspective and appreciation of the issues, we like to ask Dan Burnett, W3C editor to comment on where we are at with the standardization process. I caught up with Dan at this year’s IIT Real Time Communications Conference and had the more detailed Q&A with him shortly thereafter.
Sorry. We really wanted to do a post-cap of the W3C WebRTC and IETF RTCweb meetings that took place at the end of October and November, but we did not get to it. Victor and Reid provided some commentary on the codec debate prior to the IETF discussion. The outcome of that discussion was widely publicized and we did not have a lot of value to add to this for the developer community.
Last year we interviewed Oleg Moskalenko and presented the rfc5766-turn-server project, which is a free open source and extremely popular implementation of TURN and STURN server. A few months later we even discovered Amazon is using this project to power its Mayday service. Since then, a number of features beyond the original RFC 5766 have been defined at the IETF and a new open-source project was born: the coTURN project.
Today we are catching up with Oleg again to see what’s new and to learn what coTURN is about.
webrtcH4cKS: ~ WebRTC Standards Update Webinar
One of the first posts we published on this blog a year ago was a ‘A Hitchhiker’s Guide to WebRTC standardization‘. Since then, the work has certainly progressed and we have been sharing here a number of updates on the topic. This week we’re having qn IETF meeting in Canada and when it comes to WebRTC some of the topics in the agenda include ALPN (Application Layer Protocol Negotiation), STUN Consent Freshness and audio (interop with legacy) and video (H.264 vs VP8 as mandatory codec is NOT discussed this week but you can see VP9 and H.265 are already mentioned in the slides) requirements. Several Working Groups other than RTCWeb will also discuss this week topics that are relevant to the WebRTC effort (e.g. MMUSIC WG). During the STRAW WG session, the working group I co-chair at the IETF, we’ll discuss some features of interest for those implementing WebRTC in servers like MCUs, Application Servers, WebRTC-SIP gateways or WebRTC-enabled SBCs: DTLS-SRTP, STUN and RTCP traversal/termination are examples.
webrtcH4cKS: ~ orca.js: open real-time communications API
WebRTC promises to greatly simplify the development of multimedia realtime communications, without the need to install an application or browser plug-in. It enables this by exposing a media engine and the network stack through a set of specialised APIs. Application developers can use these APIs to easily add realtime communication to web applications. The defined use cases that have been identified in the early stages of the standardisation have a wide range of applicability. Many of the initial applications focus on communications between applications running on web browsers, but it is expected that WebRTC will also allow for interoperability with several existing communications protocols. For that and other reasons, the signalling interfaces have been determined to be out of scope, thus allowing the service providers to choose the best suited protocol or signalling mechanism for their users.