All posts tagged Brief

As we discussed in previous posts, the IETF is meeting this week in Vancouver. Lots of interesting discussing including two sessions for the RTCWeb WG; the agenda for the two sessions can be found here. The first session, which was held on Monday, was mainly about updates on the JSEP (Javascript Session Establishment Protocol) specification, DataChannel, and RTP Usage with some interesting discussion on simulcast. During Monday’s session the security drafts [1][2] were also covered, but those unfortunately have not been updated since July and do yet not reflect discussions held during the last IETF meeting. Some preliminary notes from Monday can be found here...  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

Last week I attended the Illinois Institute of Technology Real-Time Communications (IIT-RTC) Conference in Chicago.  This event has a history of attracting key players from around the RTC world. It features discussion that is distilled down to the key trends and technology challenges in the industry, with very little “fluff” on top.  This year the IIT-RTC conference was co-located with IPTComm as well, adding to the quality of the content.

Topics at the conference touched on many segments of RTC, including IMS, RCS, E-911, OTT, and more.  Our own Victor Pascual sits on the steering committee for the Web and Emerging Technologies track, where WebRTC was given particular focus.   It began with a fantastic WebRTC tutorial from Alan Johnston (co-author of the SIP specification and a dozen other IETF RFCs) and Dan Burnett (co-editor of the W3C WebRTC specification).  They are also both co-authors of “WebRTC:  APIs and RTCWeb Protocols of the HTML5 Real-Time Web”, and provided a fantastic expert introduction to WebRTC APIs and methodologies.  This set the tone for lots of excellent presentation, expert perspective, demonstrations, and discussion on WebRTC over the next few days.  Here are some discussions I found particularly interesting: ...  Continue reading

In my last post (a long time ago) I introduced the issue of NATs and Firewalls, and the tools WebRTC uses to overcome them.  First off, my apologies for the lengthy hiatus after promising to continue the discussion of NAT/Firewall traversal.  Since that entry, I became a Dad for the 2nd time, and lets just say that so far it seems like 1+1 > 2, in terms of time and energy spent on daddy-duty!  Thankfully, Chad has saved me with a brand new baby monitor solution using WebRTC 😉

So, picking up where we left off…To better understand how exactly STUN, ICE, and TURN overcome the problem of NAT and Firewalls, lets take a closer look at a standard WebRTC use case:  Bob calls Alice using WebRTC. ...  Continue reading

As I described in the standardization post, the model used in WebRTC for real-time, browser-based applications does not envision that the browser will contain all the functions needed to function as a telephone or video conferencing unit. Instead, is specifies the browser will contain the functions that are needed to run a Web application which would work in conjunction with back-end servers to implement telephony functions as required. According to this, WebRTC is meant to implement the media plane but to leave the signalling plane up to the application. Different applications may prefer to use different protocols, such as SIP or something custom to the particular application. In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the configuration necessary to establish the media plane. In other words, WebRTC does not specify a particular signalling model other than the generic need to exchange SDP media descriptions in the offer/answer fashion. However, the browser is totally decoupled from the actual mechanism by which these offers and answers are communicated to the remote side.  ...  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

Most folks that set out to write an application, or build an architecture, begin with nothing but features and functionality in mind.  Many might start out assuming they will be traversing flat, reliable, and secure networks.  Inevitably, reality sets in as one starts to demo or prototype much beyond the friendly confines of the lab, and suddenly you begin finding scenarios not working properly, quality issues cropping up, or your stuff gets hacked.  “Phase 2” of the design emerges, backing in all the necessary tools to cover the gaps. ...  Continue reading