Maybe I have been working with WebRTC for too long, but I constantly see use cases for it in my daily life. One of the more recent use cases has to do with my dog, Levy. Levy is an Old English Bulldog. Many years ago, when he was a cute little puppy, we would let him up on the couch. Over the years he has turned into a massive, gassy, dandruffy, shedding beast so we gradually weaned him off this habit in favor of a oversized, ridiculously fluffy doggy bed. He had been hooked on this new amenity for a while, but in the past several weeks he has been sneakily returning to his old habit when we were not home.
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?”
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.
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.
I threw together the original webrtcHacks design in several hours without really knowing what I was doing, not sure if it would really matter anyway. 13 months later we have 49 posts and 14-15,000 unique visitors a month. My work with WebRTC has also given me a much greater appreciation for modern web design and have become increasingly bothered by our design’s shortcomings. Not to mention – well, many of you have mentioned it – it is really tough to a 3500 word technical article when you have a crappy font and poor contrast.
I’m at the IIT RTC Conference this week in Chicago which is an excellent, no-BS conference that featured many WebRTC luminaries and one of best events I have attended in a long time.
On Tuesday I moderated a panel with WebRTC contributors and ORTC promoters, Robin Raymond of Hookflash, Bernard Aboba of Microsoft, and Peter Thatcher of Google, asking many of the same questions I did on the ORTC Q&A several weeks ago.
Dan Burnett was in the room, asking a lot of questions. If you don’t know Dan, he is a long time W3C author and editor. He is also one of the Godfathers of WebRTC who was there right at the beginning. He also has a highly regarded book on WebRTC coauthored with Alan Johnston.
As discussed in previous posts, WebRTC standards do not specify a signaling protocol. In general this decision is positive by giving developers the freedom to select (or invent) the protocol that best suits the particular WebRTC application’s needs. This can also reduce the time to market since standards compliance-related tasks are minimized. WebRTC media and data protocols from the provider to the user are standardized, so the lack of a standardized signaling protocol does not hurt interoperability of subscribers within the same network service. The calling party just has to have a URL from the called party to download its web app and to establish a WebRTC session with them. They both connect to the same web server and will then utilize the same signaling scheme. This is a new paradigm that is often difficult to embrace for traditional telephony developers who are used using the SIP protocols for handling all signaling, including the User to Network Interface (UNI) and Network-to-Network Interface (NNI).
Biggie vs. Tupac. Gates vs. Jobs. Apple vs. Samsung. Nothing catches people’s attention for no legitimate reason like a feud. Unfortunately this isn’t just a celebrity phenomenon. Feuds have been endemic even to real communications as well. From the very beginning, Elisha Gray’s dispute with Alexander Graham Bell over the original telephone patent showed the industry has a propensity for squabbles. Unfortunately we have become so accustomed to feuds that we sometimes fabricate battles that do not really exist. I fear that this is often the case with one of the most important, but misunderstood efforts affecting WebRTC’s future – Object Real Time Communications (ORTC).
Taking apart WebRTC camera resolution constraints part II. Photo courtesy of Flikr user Chia Wei Ong
Last October I did a post on some quirks I found when applying camera resolutions constraints with getUserMedia. Surprisingly I found the resolutions that were returned were sometimes different than what you ask for, even if you make your constraints mandatory. Firefox didn’t support programmable video resolution constraints at all.
That was a while ago, so earlier this summer I checked my getUserMedia camera resolution finder again. This time Chrome 36 passed all my tests:
We ran a short developer survey with BlogGeek.me a couple weeks ago (see this post). We received 97 respondents as of last Friday, August 1. Tsahi randomly selected 3 winners – he has contacted them already so if you did not get his email we are sorry to say you did not win 2 free ebooks. However, you are still eligible for a 20% discount, and should have received an email with instructions with coupon codes.
97 respondents certainly is not a statistically valid sample size from a pool of thousands of active WebRTC developers (maybe more), but there several useful data points we can extract from the data.
Update: Philipp continues to reverse engineer Hangouts using chrome://webrtc-internals. Please see the bottom section for new analysis he just put together in the past couple of days based on Chrome 38.
As initiators and major drivers of WebRTC, Google was often given a hard time for not supporting WebRTC in its core collaboration product. This recently changed when WebRTC support for Hangouts was added with Chrome 36.
So obviously we wanted to check out how this worked. We also were curious to see how a non-googler could make some practical use of chrome://webrtc-internals. Soon thereafter I came across a message from Philipp Hancke (aka Hornsby Cornflower) saying he had already starting looking at the new WebRTC hangouts with webrtc-internals. Fortunately I was able to convince him to share his findings and thorough analysis.