A couple of decades ago if you bought something of any reasonable complexity, odds are it came with a call center number you had to call in case something went wrong. Perhaps like the airline industry, economic pressures on contact centers shifted their modus operandi from customer delight to cost reduction. Unsurprisingly this has not done well for contact center public sentiment. Its no wonder the web came along to augment and replace much of this experience – but no where near all it. Today, WebRTC offers a unique opportunity for contact centers to combine their two primary means of customer interaction – the web and phone calls – and entirely change the dynamic to the benefit of both sides.
I was starting to work with a big dataset and was dreading the idea of bogging down my machine with MySQL or SQLServer, so I decided to give Google’s BigQuery a try. Before I got into my project, I was pleasantly surprised to a public GitHub dataset was readily available. Tsahi does a cursory analysis of WebRTC projects on GitHub by manually counting search results every month. I was also inspired by Billy Chia‘s great NoJitter post analyzing WebRTC topics on Stack Overflow.
I was curious to see if I could extract some details from GitHub to see:
There have been many major WebRTC launches in the past months including Facebook and KimDotCom. Before those, Mozilla started bundling a new WebRTC calling service right into Firefox. Of course we wanted to check out to see how it worked.
To help do this we called on the big guns – webrtcHacks guest columnist Philipp Hancke. Philipp is one of the smartest guys in WebRTC outside of Google. In addition to his paid work for &yet he is the leading non-googler to contribute to the webrtc demos and samples and is also a major contributor to the Jitsi Meet and strophe.jingle projects. Google even asks him to proof-read their WebRTC release notes.
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.
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).