Standards

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. ...  Continue reading

The first post we published on webrtcHacks was ‘A Hitchhiker’s Guide to WebRTC standardization’ (July 2013) where we gave some initial insight on activities in the 3GPP around WebRTC and  IMS. Since then the situation has certainly evolved (well, probably not as fast as some would have expected). Since we regularly receive emails asking about the status/progress on WebRTC standardization within the 3GPP, we spent some time with our friend Antón Román, CTO at Quobis and author of the popular post ‘Anatomy of a WebRTC SDP’ to summarize the current status of the ‘WebRTC access to IMS’ effort. ...  Continue reading

As detailed in previous posts on webrtcHacks, the Internet Engineering Task Force (IETF) has worked for the past few years to standardize the “on-the-wire” protocols that make up the WebRTC engine. It is coming up on 3 months since IETF 88 in Vancouver, where the IETF was to have settled the matter of a mandatory-to-implement (MTI) video codec. The process resulted in no consensus, and the task of finalizing WebRTC 1.0 drags on with MTI video codec(s) in question.  A recent straw poll among IETF participants shows how divided the issue remains. ...  Continue reading

As WebRTC implementations and field trials evolve, field experience is telling us there are still a number of open issues to make this technology deployable in the real world and the fact that we would probably do some things differently if we started all over again. As an example, see the recent W3C discussion What is missing for building (WebRTC) real services or Quobis‘ CTO post on WebRTC use of SDP.

Tim Panton, contextual communications consultant at Westhawk Ltd,  has gone through some of these issues. During the last couple of years we had the chance to run some workshops together and have some good discussions in the IETF and W3C context. Tim’s expertise is very valuable and I thought it would be a good idea to have him here to share some of his experiences with our readers. It ended up as a rant. ...  Continue reading

With all the drama of the video codec debate ramping up for a Mandatory To Implement (MTI) decision (previously discussed here and here), hopefully it will be a minor footnote in the history of the WebRTC very soon.  If you had to summarize the possible outcomes, interested stakeholders, and sentiments in one picture, here is what the webrtcHacks team thinks it might look like:

A few notes explaining the diagram- Sentiments of “happy with it”, “fine, I’ll live with it”, or “this crushes all my hopes and dreams” in this case centers mostly around the desire for interoperability.  The case of “VP8 & H.246”, it assumes that all the browser implementations end up fully supporting both codecs, but that they are completely negotiable (and possibly constrainable) on a session-by-session basis for each application using them.  This way non-browser implementations could implement VP8 or H.264 depending on their preference, and be guaranteed interoperability. ...  Continue reading

We had a lot of traffic to Victor’s post on the WebRTC mandatory video codec earlier this week. Given the news from Cisco yesterday we figured this warranted a quick follow-up post beyond what we could add to the comments area.

Quick debate recap

Engineers don’t like lawyers, and as Victor mentioned in his post earlier this week, much of the debate over assigning a mandatory video codec for WebRTC has been about avoiding the lawyers. While debate over the technical merits of H.264 vs. VP8 yielded no overwhelming winner (they are both great codecs), the debate has more recently revealed it’s true form as a mostly IPR related issue.  The H.264 camp speculated that there could be legal issues with VP8 despite Google’s claims otherwise. There are certainly inherent issues with H.264.  Which one has more risk?  It would take lots of lawyers to sort through this and no one pays for lawyers to go to standards meetings. Even if they did,  it wouldn’t matter – lawyers use arbitrators and the legal system, not technical standards procedures to work through disagreements. ...  Continue reading

In the WebRTC standardisation post I mentioned that one of the controversial discussions in the IETF context was the mandatory to implement (MTI) video codec battle for WebRTC. While there are some technical arguments on the topic (i.e this  VP8 vs H.264 – subjective evaluation and this performance comparisons discussion), there is no dispute both are high quality and efficient video codecs. The issue here is all about IPR and licensing as described in this interesting and ongoing discussion: “VP8 vs H.264 – the core issue“. ...  Continue reading

Updated 25 Aug 2013 –  some minor edits fixing some ORTC API references and added ORTC sample code.

In my post on WebRTC standardization I mentioned that one of the controversial points of discussion in the W3C context was whether the SDP Offer/Answer model and the current API provided the level of flexibility a wide range of WebRTC use cases would require. In order to avoid the endless and repetitive discussions that have already occurred on this topic, developers unsatisfied with the current API have just announced an alternative to the existing WebRTC API. This new proposal is called WebRTC Object API, motivation behind it is presented in this IETF draft and some example code can be found on GitHub. Note that this is not the first time an alternative API aiming to provide more control to web developers has been proposed- Microsoft’s CU-RTC-Web introduced last year took a similar approach by introducing an alternative along with a working prototype. ...  Continue reading

As I anticipated in my post on WebRTC standardization, the IETF 87th meeting took place last week in Berlin, Germany. One of the agenda items for WebRTC was whether SDES should be part (and how) of WebRTC.

According to the IETF drafts, any WebRTC compliant implementation must support the RTP/SAVPF profile which builds on top of the Secure RTP profile RTP/SAVP. This means that media channels (e.g. audio, video) must be secured via Secure RTP (SRTP), which provides media encryption among other security features. In fact, the use of plain (unencrypted) RTP is explicitly forbidden by the WebRTC specifications. ...  Continue reading

Next week the IETF 87th standardization meeting will take place in Berlin, Germany. Most of the sessions I’m planning to attend are related to SIP, Diameter and of course WebRTC. When a week ago I started preparing some material for the meeting, a customer called and asked me to provide a training session on WebRTC standardization and implementation status for their R&D team. While this is something I’m planning to do in the next month, I thought I could start my contribution to this blog by providing a brief introduction to WebRTC standards and describe what’s going on in each group. This introductory post is meant to provide a very initial overview and I’m planning to go into technical details in future blog entries. ...  Continue reading