Embedding WebRTC Video Chat Right Into Your Website

Most of you remember the Hello Chrome, it’s Firefox calling! blog post right here in Mozilla Hacks demonstrating WebRTC video chat between Firefox and Chrome. It raised a lot of attention. Since then we here at Fresh Tilled Soil have seen a tremendous amount of startups and companies which have sprung up building products based WebRTC video chat technology. Tsashi Levent-Levi who is a WebRTC evangelist has been interviewing most of these companies on his blog, the list is quite impressive!

WebRTC chat demo

Much like most of early adopters we have been playing around with WebRTC for quite awhile now. We have of course created our own WebRTC video chat demo and have also very recently released WebRTC video chat widgets.

The widgets work very simply, anybody can take the following HTML embed code:


and add this code to any website or blog post. You’ll see the following widget on their website:

From here it’s dead simple to start a WebRTC video chat, just make up a name for a room, type it in and click start chat. Tell the other person to do the same and you’re all set.

As always make sure you’re giving this a try in Firefox Nightly or the latest stable build of Google Chrome. If you are on a tablet make sure you are on Google Chrome beta if you are using the Google Chrome browser.

Something else to note is that for this first version our video chat is limited to just two participants per a room. If a room name is occupied by two people the third person who tries to connect to this room simply won’t be able to connect.

How It Works

Without getting too deep into the code behind how WebRTC video chat actually works, let’s briefly go over what is actually happening behind the scenes when you click the start chat button and how WebRTC video chat actually works. Here is a step by step timeline of what actually happens to give you a better idea:

A quick note about this step: “Once remote media starts streaming stop adding ICE candidates” – this is a temporary solution which might result in suboptimal media routing for many network topologies. It should only be used until Chrome’s ICE support is fixed.

A quick and very important tip to remember when you are trying to get this to work. We used a ‘polyfill’ like technique as shown in this article by Remy Sharp. As Remy describes we wrote a piece of code to adapt for the Firefox syntax to get cross-browser functionality.

Issues We Ran Into and How We Solved Them

As you might expect we ran into a number of problems and issues trying to build this. WebRTC is evolving quickly so we are working through a number of issues every day. Below are just some of the problems we ran into and how we solved them.

PeerConnection capability in Google Chrome

While working with the new PeerConnection capability in Chrome we discovered a strict order of operation for it to work; more specifically:

  • Peers must be present with local streaming video before sending SIP (offer/answer SDP)
  • For ‘Answerer’; Do not add ICE candidate until the peer generates the ‘Answer SDP’
  • Once remote media starts streaming stop adding ICE candidates
  • Never create peer connect for answerer until you get the ‘Offer SDP’

We fixed it by handling those issues and handling the connection in the order described above. This was crucial to making the connection work flawlessly. Before we did that it would work only every once in a while.

Added latency due to lag

When streaming to a mobile device there is added latency due to lag and limitations of surfing the net via mobile phone.

We solved this by making the resolution of streamed video reduced via a hash tag at the end of the URL. URL can optionally contain '#res=low' for low resolution stream video & '#res=hd' for HiDefinition streaming video as an optional URL parameter. A quick note here that other configurable properties are now available such as frames per second which you can use for this same purpose.

Recording the WebRTC demo

We’ve been dabbling with recording video WebRTC demo. When recording video we used the new JavaScript type arrays to save the streaming data. We quickly discovered that it is only possible to record the video and audio separately.

We solved this by creating two instances of recording, one for the audio and one for the video, that utilized the new javascript data types and recorded both streams simultaneously.

Conclusion

It’s exciting to dabble in this stuff, we love WebRTC so much that we created an entire page dedicated to our experiments with this technology and others which we believe will transform the web in 2013. If you have any question please give us a shout.

About Dmitry Dragilev

Dmitry Dragilev is a Tech Evangelist at Fresh Tilled Soil, a team of designers, coders and UX experts that helps entrepreneurs and businesses create bloody brilliant user experiences for web and mobile applications through consulting, training, and events. Since 2005 they’ve helped 300+ clients including General Electric, Microsoft, MIT, Harvard, TEDx, Time Warner Cable, Walgreens, Hubspot among many others.

More articles by Dmitry Dragilev…

About Paul Greenlea

Senior Front-End Developer & Strategist at Fresh Tilled Soil. Paul is an inventor. He's been tinkering with electronics and technology since he can remember. He started designing and programming at age 12 when he began creating his own computer games, and over the years he's led teams through strategy, concept, and execution phases in positions ranging from UI designer to lead engineer. He currently follows the rapidly evolving industry of mobile closely and firmly believes it is the future.

More articles by Paul Greenlea…

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…


26 comments

  1. Emanuel Hoogeveen

    This is pretty exciting stuff. One thing I’m missing is the ability to password protect rooms, and any mention of encryption. I expect the former is simply a matter of setting up a frontend with accounts and the like, but it also ties into the latter.

    It would be great to (optionally) have one or two layers of security for these calls: 1) encryption via a hash of the chosen password and 2) encryption based on standard public-private key encryption. Of course this would add a fair bit of extra computation client side, but that seems like small price to pay as long as it’s still feasible!

    May 7th, 2013 at 07:40

    1. Adam Roach

      One of the really neat things about WebRTC is that it has encryption baked right into it; there’s actually no way to send unencrypted media using a WebRTC implementation. Currently, this is based on DTLS-SRTP keying, which does a key exchange in the media channel (gritty details in RFC 5764), although there is some discussion of allowing Security Descriptions (RFC4568) as well, which would allow applications to provide their own keying material.

      As a user, one thing you want to be careful about is that encryption is one of many tools you need to combine in order to ensure confidentiality. For example, unless you know who is at the other end of an encrypted connection, you could easily be sending your media to a server that is either capable of sharing your media with an arbitrary third party, or actually sending your media to a hostile third party itself. This is why the WebRTC identity work (see http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity) is considered integral to the overall mechanism. While Firefox doesn’t currently support the identity mechanism, it is something that is very important to us that we plan to add soon.

      The other thing users will need to be careful about is making sure that the media isn’t being copied by the javascript itself and being sent to an alternate destination. This isn’t part of the current specification, but we’re working on adding a standardized mechanism that will allow specific user media streams to be limited so that they can only be sent, over an encrypted channel, to a specified identity (and nowhere else).

      As a service provider, of course, you don’t need to worry about the interception and copying issues, but your users might. So, if you’re truly interested in providing a secure communications experience, you will want to take advantage of these mechanisms as they become available.

      May 7th, 2013 at 08:38

      1. Emanuel Hoogeveen

        Excellent! It sounds like you’re on top of things :)

        May 7th, 2013 at 09:54

      2. Lennie

        Encryption is great, but it is useless if you are talking to the wrong person.

        You should add something like Persona so people can be sure they are talking to the person they expect to be talking to.

        Persona verifies email addresses, so you could add a button, after the address has been verified you could display a verified email address on the screen of the other party.

        May 8th, 2013 at 08:34

  2. Alexander Farkas

    I like!!!

    BUT:

    Unfortunately this widget script is quite obtrusive.

    For example it doesn’t work async. Embedding a third party script, which can’t be loaded async is a SPOF and epic fail.

    Another thing, it includes Modernizr and overrides all already existing tests. There is no page of mine, where I could embed this thing, without breaking other things.

    I don’t know, but writing a script with the purpose to embed it in many other different sites, needs very defensive scripting. This script isn’t a good example.

    May 7th, 2013 at 14:21

    1. alexander farkas

      my comment above sounds a little bit tooo harsh. sorry :-D

      May 7th, 2013 at 23:21

      1. Robert Nyman [Editor]

        No worries, I think it’s valid feedback. I’ll let Dmitry/Paul respond to that, and give feedback on how they are moving forward.

        May 8th, 2013 at 02:46

    2. Dmitry Dragilev

      Thanks for the comment Alexander. This script is just a demonstration of what is possible with WebRTC video chat. The purpose of this article and demo is to show what people can do with this technology and capabilities which they should be exploring. We want to inspire developers to go out and get their hands dirty with this stuff.

      By no means is this a product that we are selling or trying to make a service out of. This is simply a demonstration of what can actually be accomplished. As you mentioned currently this does not work on all environments on the web. This is the initial version. Going forward we will improve it and try to make sure most of the issues you pointed out are fixed.

      May 8th, 2013 at 07:31

    3. Paul Greenlea

      Thanks for your feedback, Alexander! Dmitry is right on…this was an experiment, developed in a few days, to play with the dreamed up possibility of quickly embedding this exciting new web capability into a page! In hindsight, I kick myself in the head for taking some of these shortcuts; as I only saved a little bit of time (Modernizr being one of them). My focus, at the time of developing this, was to take the shortest route possible to make this idea into reality using http://jsfiddle.net & http://codepen.io/ as test beds (if you haven’t seen it in action; try it on jsFiddle or CodePen). In the meantime, I’ll be updating the script in the next few days given feedback from this blog as well as additional ideas for optimizing performance!

      May 8th, 2013 at 19:36

  3. agilob

    View from my camera is up-side-down, any help? On Linux this problem is known with Skype, the bug exists in v4l1compat. Any help with Firefox?

    May 8th, 2013 at 03:17

    1. Paul Greenlea

      Hmmm…I’m using the html video tag, which can easily be rotated 180 degrees (giving you the right-side-up view). I can update the JavaScript to detect the OS and do the rotation, but am worried that it could be a device specific bug. Do you know if this Skype issue affects all devices running Linux? When I update the code over the next few days I’ll look into adding an optional parameter that can be passed into the URL to do the rotation.

      May 8th, 2013 at 19:48

      1. agilob

        I know that this bug is popular on Asus and Acer notebooks. The bug exists in Skype, but doesn’t in any other application (at least I have not found so far another, except Firefox and Chromium now).
        I spent some minutes trying to fix it the same way I did with skype, had some troubles, but I did it :)

        $ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so firefox
        ERROR: ld.so: object ‘/usr/lib/libv4l/v4l1compat.so’ from LD_PRELOAD cannot be preloaded: ignored.
        this is wrong for 64bits OS and camera is still up-side-down, causes warnings.

        but this one:
        $ LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so firefox

        works great :)
        It’s enough to use 64bits library.

        It’s hardware specific so I won’t report it as a bug, I’ll just describe it on my blog to help others.

        May 9th, 2013 at 16:58

    2. Robert Nyman [Editor]

      Best way to get help is probably to file a bug and choose WebRTC in the form.

      May 9th, 2013 at 03:58

  4. Fabian

    Although I think WebRTC is great technology I too run into ‘the strict order of operations’. There seems to be no consistency in the order though between different browser and the only way to find out the order is by trial and error.

    Rightnow I am also trying to have datachannels and webcam work together. In FF aurora/nightly I can instantly create a datachannel, exchange ICE and SDP and the have a connection.

    However, I noted that in FF too you need to add a local stream before you can create an offer and send it. The problem is I already created an offer in order to open a data channel. The only way around this I think can think of is to create two different peer connections: one for webcam stream and one for datachannels. I don’t think that is how it intented to be?

    May 8th, 2013 at 04:17

    1. Fabian

      As a follow up to my previous post: apparently when you want to add something new to the peerconnection you must have a negotiationneeded event. I understand now that this is not built in yet and that’s why things are going a bit strange. As the w3c specs say:

      In particular, if a RTCPeerConnection object is consuming a MediaStream and a track is added to one of the stream’s MediaStreamTrackList objects, by, e.g., the add() method being invoked, the RTCPeerConnection object must fire the “negotiationneeded” event. Removal of media components must also trigger “negotiationneeded”.

      May 9th, 2013 at 01:07

      1. Robert Nyman [Editor]

        Thanks for sharing your experiences!

        May 9th, 2013 at 03:55

  5. Steve Souders

    Dmitry: This *did* inspire me to get my hands dirty. It’s amazing how easy it was to get a working demo – just a few minutes. Hard part is finding browsers that support WebRTC.

    I wanted to mention that on Chrome for Android the demo code says “Please click allow” but there’s no “allow” button. Instead, I went into chrome://flags and enabled the “WebRTC” experiment. This generated a prompt in Chrome for Android that I could approve and get the channel working.

    Another issue was my corp network didn’t work. I switched to a public wifi network and that worked.

    Another issue I found was the lack of tool support. Specifically, I wanted to watch the network traffic using Chrome Dev Tools, but WebRTC doesn’t show up there. My officemate (Ilya Grigorik) pointed me to chrome://webrtc-internals. This is okay – but I had to refresh the page. I’d rather see the traffic as it happens. Of course, the tooling will come, but I wish it was there now – it’s during these early times that we need the most help.

    Thanks for the great snippet. (Hi Robert!)

    May 8th, 2013 at 09:59

    1. Robert Nyman [Editor]

      Hi Steve. :-)

      Thanks for the feedback!
      I agree that tooling will definitely need to improve, but believe people experimenting with the technology – like you, Dmitry and lots of others – also help us see both how the technology itself and developer tools can improve to support that.

      Early and exciting days!

      May 9th, 2013 at 03:54

  6. Roy

    Can you share a gist showing how you used typed arrays to record the video and audio streams?

    May 8th, 2013 at 10:20

  7. xinzhou ye

    How Can I use webRTC with audio only?I mean without video is okay for me.

    May 8th, 2013 at 19:40

  8. ash

    tried this on my samsung note 10.1 with chrome and firefox they both asked for actions which could not be done, chrome said click allow but there was no allow to click on, and firefox said something similar but there was nothing obvious to action. shame

    May 9th, 2013 at 06:08

    1. Dmitry Dragilev

      Hey Ash – We haven’t tried it on a Samsung Note yet, lets try to troubleshoot it though. Which version of Chrome did you run on your samsung note? Chrome Beta? What version of Firefox?

      Could it be that your resolution needs to change because the “Allow button” is hidden?

      May 9th, 2013 at 07:34

  9. ash

    ok the chrome version is 26.0.1410.58 apparently it varies with devices firefox 20.0.1 varies with devices.

    when i access through the laptop you get the allow drop down from under the address bar but on the samsung nothing happens, same with firefox you get the webcam icon but nothing again on the note I will see if there are some advanced setting for the webcam and access privileges on the note

    May 9th, 2013 at 08:39

  10. Chauffagiste compétent Paris: dépannage chauffage

    Thank you for the great article but i still wanna ask you which version of Chrome did you run on your samsung note in other words Chrome Beta or with Firefox browser !

    May 16th, 2013 at 11:17

    1. Dmitry Dragilev

      Thanks for the question Chauffagiste. We actually ran the demo on Nexus 7, not Samsung Note. We never tried it on Samsung note, we don’t have the device. We would experiment with Mozilla nightly on Samsung note and Chrome beta and see if those work for you.

      May 16th, 2013 at 14:10

  11. Gozzin

    This is very exciting. Will desktop sharing be included?

    May 25th, 2013 at 09:29

Comments are closed for this article.