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
Let’s have some more fun with getUserMedia by creating a simple mirror application and determining its frame rate.
If your user is going to send their video, it is a general best practice to let them see what they are sending. To do this you simply route the local video stream capture by getUserMedia to a <video> element inside the DOM. That is pretty easy, but the challenge is the video you see is not mirrored. When you are looking at yourself you expect to see a mirrored image. When you don’t it feels off and leads to a poor user experience. Ok, so everyone mirrors their local video, so let’s do that.
We probably talk about existing telephony stuff too much here, but the reality is there are billions of phone about there that want to be connected to the web like nearly everything else. This is especially important for any business that wants to link its website with its internal phone system.
If you are a modern enterprise or contact center, odds are you connect your phone system to the PSTN using a SIP trunk. This approach is light years ahead of previous technologies, but what about allowing callers to come in from the web with WebRTC? Often this means buying your own gateway or connecting your website to a hosted API provider. Is there something like a WebRTC trunk?
Augmented reality demonstration using the open source Kurento project
Sending real time communications from point A to point B? That functionality is relatively easy with WebRTC. Processing the media in real time to do something cool with it? That is an area I find a lot more interesting, but it is a lot tougher to do. When I was building my Motion Detecting Baby Monitor project, I wished I had some kind of media server to handle the motion detection processing. That would give me some flexibility to take the processor intensive algorithm off of my phone and stick that in the cloud if I wanted to save on battery. That also got me thinking – if you can do motion detection why not apply other more advanced image processing algorithms to the WebRTC stream? How about facial recognition, object detection, gesture tracking or many of the other cool features that are popping up all the time in the popular Open Source Computer Vision (OpenCV) project? I wrote this dream off as science fiction for another year or two.