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.
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.
We happy share a lot of information here at webrtcHacks, but now we have a request of you. We have partnered with BlogGeek.me to conduct a super-quick, 6-question WebRTC developer survey. You will benefit from seeing analysis of the data here and on BlogGeek.me. As an extra bonus, Tsahi got Packt Publishing to agree to giving away 2 free digital books to 3 respondents and give a 20% discount on these books to everyone else who responds.
Please click here to go to the survey.
The webrtcHacks and BlogGeek.me WebRTC Developer survey will only take a minute