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.
One of the most vexing challenges for WebRTC developers is “what do you do with IE and Safari?” Do you ignore them? Tell your users to use something else? Can you even tell them what to do? Maybe you fall back to flash? There are no easy answers and WebRTC is supposed to be easy, right?
Perhaps you just wait and hope that Microsoft and Apple implement WebRTC soon? This brings a lot of risk – what exactly are they going to implement? For Microsoft it seems it will likely be ORTC, definitely not the current spec. When exactly are they going to implement it? What is Apple going to do? What will you miss out on in the mean time?
photo by Flickr user mattallen89 (CC BY)
WebRTC promises to greatly simplify the development of multimedia realtime communications, without the need to install an application or browser plug-in. It enables this by exposing a media engine and the network stack through a set of specialised APIs. Application developers can use these APIs to easily add realtime communication to web applications. The defined use cases that have been identified in the early stages of the standardisation have a wide range of applicability. Many of the initial applications focus on communications between applications running on web browsers, but it is expected that WebRTC will also allow for interoperability with several existing communications protocols. For that and other reasons, the signalling interfaces have been determined to be out of scope, thus allowing the service providers to choose the best suited protocol or signalling mechanism for their users.
If you just care about our developer-oriented content and could care less about how we actually author and coordinate this site then skip this post. We have some great content coming from Victor later this week.
If you are interested in more than that then please read on.
We have a new team member:
You already know him as the bloggeek.me guy. He blogs, writes reports, speaks, runs events, and consults on WebRTC. He was the first to have an independent WebRTC blog and he has the largest following of anyone in this small, but growing WebRTC community.
Ring! Sometimes you need an alert to get your attention. Traditional phone systems make this easy – if someone calls you your phone rings. The traditional telephony model assumes the called device is always on an available to ring and this is how it generally works across analog phones, mobiles, VoIP phones, and even desktop calling replacements like Skype. The challenge in the web model is that you can no longer assume the remote device is available to run your program’s ring command. Even if the called party has a browser open, it does not mean they have a tab running your app. This means you need to find some other means of telling the called party to go to your URL. That can be limiting for a lot of apps. Fortunately there are solutions for this.