Archives

All posts by Reid Stidolph

MS Elephant

What about IE?

As WebRTC has matured to a state where it’s first implementations are ready for companies to launch real services around it, the readiness of various companies to adopt WebRTC has fanned out quite a bit. Some are already charging ahead as early adopters, while others are playing it conservative. Of those in the conservative camp, one of the common doubts that gives them pause is: “What about IE?”

When speaking to those interested in WebRTC, but concerned about Internet Explorer (IE), many times we’ve tried to assure them not to worry: our friends in Redmond won’t be too far behind. We often point to the undeniably significant contributions from Microsoft to WebRTC, especially considering that they bring to the table two titans of VoIP industry (Lync and Skype). We highlight some of their early IE WebRTC demos (using beta code) as signs of progress. We’ve rationalized the absence of  a Microsoft equivalent to what Chrome and Firefox are shipping, by noting the slower release cycle for IE. However, we’ve come to realize that to some, IE support is a really big deal.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone
bouquet

WebRTC JavaScript Libraries

Looking over the past few years of WebRTC growth, and the landscape of emerging WebRTC solutions, we see quite a number of  WebRTC-centric JavaScript (JS) libraries on the scene. Indeed, not long after browser vendors began shipping WebRTC implementations, a bouquet of WebRTC signaling libraries bloomed.

Each delivers a JavaScript API surface in the browser, which provides signaling services that complement the WebRTC media services. This abundance of options begs a few questions:

  • What is the real purpose of the JS library?
  • Do I need one for WebRTC?
  • What should I consider when evaluating this component of a WebRTC solution?
  • What makes a good JS library, what makes bad one?

These are the nagging questions that I wrestled in my own early research into WebRTC. At this point, I have certainly not personally used every WebRTC JS library out there, but have certainly tried quite a few. In this post I’ll attempt to address these questions, and my own thoughts on what is in a WebRTC JS library.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

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

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

Photo courtesy of Flickr user Carol Browne

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

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

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

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone
The WebRTC NAT/Firewall traversal trifecta

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

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone