Hello Chrome, it's Firefox calling!

Mozilla is excited to announce that we’ve achieved a major milestone in WebRTC development: WebRTC RTCPeerConnection interoperability between Firefox and Chrome. This effort was made possible because of the close collaboration between the open Web community and engineers from both Mozilla and Google.

RTCPeerConnection (also known simply as PeerConnection or PC) interoperability means that developers can now create Firefox WebRTC applications that make direct audio/video calls to Chrome WebRTC applications without having to install a third-party plugin. Because the functionality is now baked into the browser, users can avoid problems with first-time installs and buggy plugins, and developers can deploy their apps much more easily and universally.

To help celebrate this momentous milestone, we thought it would be fun to call up our friends at Google to discuss it with them. Check out this Firefox-Chrome demonstration call between Mozilla’s Chief Innovation Officer, Todd Simpson, and Google’s Director of Product Management, Hugh Finnan, and read what Google had to say about this momentous occasion in their blog post.

This milestone builds on an earlier demo we showed late last year of WebRTC integrated with Social API. There we demonstrated an industry first with our implementation of DataChannels, a powerful component of WebRTC that can combined with an audio/video chat to allow users to share almost anything on their computer or device. Send vacation photos, memorable videos, links news stories etc., simply by dragging the item into your video chat window. Look out for more on this to come.

The purpose of WebRTC, an open standard being defined jointly at the W3C and IETF standards organizations, is to provide a common platform for all user devices to communicate and share audio, video and data in real-time. This is a first step toward that vision of interoperability and true, open, real-time communication on the web.

Posted by:
Serge Lachapelle, Chrome Product Manager and Maire Reavy, Firefox Media Product Lead

Start Developing Using RTCPeerConnection in Firefox

For JavaScript developers who haven’t tried RTCPeerConnection in Firefox yet (since it is a brand new feature for us), you can try this out using the most recent Firefox Nightly by setting the media.peerconnection.enabled pref to “true” (browse to about:config and search for the media.peerconnection.enabled pref in the list of prefs). Here is a snippet of code from a sample app that shows off how to initiate, accept, and end a WebRTC call in Firefox using RTCPeerConnection:

function initiateCall(user) {
  document.getElementById("main").style.display = "none";
  document.getElementById("call").style.display = "block";

  // Here's where you ask user permission to access the camera and microphone streams
  navigator.mozGetUserMedia({video:true, audio:true}, function(stream) {
    document.getElementById("localvideo").mozSrcObject = stream;
    document.getElementById("localvideo").muted = true;

    // Here's where you set up a Firefox PeerConnection
    var pc = new mozRTCPeerConnection();

    pc.onaddstream = function(obj) {
      log("Got onaddstream of type " + obj.type);
      document.getElementById("remotevideo").mozSrcObject = obj.stream;
      document.getElementById("dialing").style.display = "none";
      document.getElementById("hangup").style.display = "block";

    pc.createOffer(function(offer) {
      log("Created offer" + JSON.stringify(offer));
      pc.setLocalDescription(offer, function() {
        // Send offer to remote end.
        log("setLocalDescription, sending to remote");
        peerc = pc;
          "offer", {
            to: user,
            from: document.getElementById("user").innerHTML,
            offer: JSON.stringify(offer)
          function() { console.log("Offer sent!"); }
      }, error);
    }, error);
  }, error);

function acceptCall(offer) {
  log("Incoming call with offer " + offer);
  document.getElementById("main").style.display = "none";
  document.getElementById("call").style.display = "block";

  // Here's where you ask user permission to access the camera and microphone streams
  navigator.mozGetUserMedia({video:true, audio:true}, function(stream) {
    document.getElementById("localvideo").mozSrcObject = stream;
    document.getElementById("localvideo").muted = true;

    // Here's where you set up a Firefox PeerConnection
    var pc = new mozRTCPeerConnection();

    pc.onaddstream = function(obj) {
      document.getElementById("remotevideo").mozSrcObject = obj.stream;
      document.getElementById("dialing").style.display = "none";
      document.getElementById("hangup").style.display = "block";

    pc.setRemoteDescription(JSON.parse(offer.offer), function() {
      log("setRemoteDescription, creating answer");
      pc.createAnswer(function(answer) {
        pc.setLocalDescription(answer, function() {
          // Send answer to remote end.
          log("created Answer and setLocalDescription " + JSON.stringify(answer));
          peerc = pc;
            "answer", {
              to: offer.from,
              from: offer.to,
              answer: JSON.stringify(answer)
            function() { console.log("Answer sent!"); }
        }, error);
      }, error);
    }, error);
  }, error);

function endCall() {
  log("Ending call");
  document.getElementById("call").style.display = "none";
  document.getElementById("main").style.display = "block";

  document.getElementById("localvideo").mozSrcObject = null;
  document.getElementById("remotevideo").mozSrcObject = null;

  peerc = null;

You’ll notice that Firefox still prefixes the RTCPeerConnection API call as mozRTCPeerConnection because the standards committee is not yet done defining it. Chrome prefixes it as webkitRTCPeerConnection. Once the standards committee finishes its work, we will remove the prefixes and use the same API, but in the meantime, you’ll want to support both prefixes so that your app works in both browsers.

Trying Interop Yourself

For those eager to give interop a try, here are instructions and information about “trying this at home”.

This is Firefox’s and Chrome’s first version of PeerConnection interoperability. As with most early releases, there are still bugs to fix, and interop isn’t supported yet in every network environment. But this is a major step forward for this new web feature and for the Web itself. We thank the standards groups and every contributor to the WebRTC community. While there’s more work to do, we hope you’ll agree that the Web is about to get a lot more awesome.

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]…


  1. Marko

    Can’t wait for the day when I’ll finally uninstall 3-rd party VoIP software.
    Thank You Mozilla. Thank You Google.

    February 4th, 2013 at 12:40

    1. Robert Nyman [Editor]

      Thanks. :-)

      February 4th, 2013 at 13:59

  2. js audio api

    So now that there is a “red line” between Mozilla and Google, how about working on designing an interoperable JS audio API?

    Audio Data API, Web Audio API, MediaStream API… that’s a mess and a shame in year 2013 :(

    February 4th, 2013 at 13:44

    1. Robert Nyman [Editor]

      Rest assured that we work hard on interoperability in as many fields as we can, and I both hope, and believe, that we will see an improvement when it comes to audio on the web.

      For instance, Firefox plans to support the Web Audio API.

      February 4th, 2013 at 14:05

      1. Matt Montag

        Great to hear, Robert. Can’t wait to push things forward with Web Audio.

        February 5th, 2013 at 01:06

        1. Robert Nyman [Editor]

          Thanks! I have high hopes there, and I do agree that it is an area where there’s room for improvement.

          February 5th, 2013 at 01:24

  3. Ali Helmy

    WOW! Thank you Google & Mozilla…

    Internet calling and getting the family together regardless of browser and without installing any plugins will make connecting the grandparents to the grand-daughter a lot easier!

    February 4th, 2013 at 14:20

    1. Robert Nyman [Editor]

      Thanks, glad to make you happy!
      Perhaps that should be the WebRTC slogan: bringing families even closer. :-)

      February 4th, 2013 at 14:32

      1. Tin Aung Linn

        Nice Slogan

        February 5th, 2013 at 04:27

  4. Sy

    Wonderful news and looking forward for more of these but i have a small question. If you guys finally agreed and worked on something together why in the world do you keep prefixing your API with moz and webkit (and soon o and ms) ? Why couldn’t it just be RTCPeerConnection ?

    February 4th, 2013 at 14:54

    1. Robert Nyman [Editor]

      The answer to that question is mentioned in the blog post, just after the code sample:

      “You’ll notice that Firefox still prefixes the RTCPeerConnection API call as mozRTCPeerConnection because the standards committee is not yet done defining it. Chrome prefixes it as webkitRTCPeerConnection. Once the standards committee finishes its work, we will remove the prefixes and use the same API, but in the meantime, you’ll want to support both prefixes so that your app works in both browsers.”

      February 4th, 2013 at 15:08

      1. Michael

        I think Sy was probably asking: What value can their possibly be in working together and each of you naming the function call something different? And if he wasn’t (I’d bet anything he was), then I’m asking that question.

        February 5th, 2013 at 21:48

        1. Robert Nyman [Editor]

          Before something is standardized and while implementations are tested, it’s best practice to work with prefixed names. In case the standard, names etc change, it won’t break. Once things are finalized, we will be more than happy to unprefix it.

          February 6th, 2013 at 03:22

          1. Phil Hannent

            I think you should change your prefix naming convention to not be vendor specific. “test” or “nonstandard” prefixes would make the function call cross-platform and alert to the fact its not a formal standard.

            Right now you and Google are just advertising yourselves and making developers write test functions twice.

            February 6th, 2013 at 06:24

          2. Robert Nyman [Editor]

            That’s not true, though. All web browser vendors – Mozilla, Google, Microsoft and Opera (and Safari, with WebKit) – use their own prefixes for this situation (JavaScript & CSS). It’s an ongoing discussion with a common name, but in practice, it’s hard. That assumes all web browsers would implement the new feature/changed support etc and ship it at the exact same time – otherwise, it would work in one and break in another.

            That’s the reason for prefixes – to be able to test new, not-yet-standardized features in respective web browser, experiment – and when it’s finalized and standardized, remove the prefix and ship it.

            February 6th, 2013 at 07:20

  5. timrpeterson

    Google and Firefox are awesome. Thanks for working together on this!

    February 4th, 2013 at 15:12

    1. Robert Nyman [Editor]

      Thank you, glad you appreciate it!

      February 4th, 2013 at 15:17

  6. Joe Ekine

    Nice to see that Mozilla & Google take the lead for new browser technologies we all can benefit from.

    Thank you

    February 4th, 2013 at 15:19

    1. Robert Nyman [Editor]

      Thanks! It just seems like the best way to move forward, for an open web that everyone gains from!

      February 4th, 2013 at 15:21

  7. Venky

    What kind of encryption is implemented, would this allow snooping by 3rd party agencies like Skype does?

    February 4th, 2013 at 15:29

    1. Robert Nyman [Editor]

      Encryption is a big discussion, and the best read is probably Proposed WebRTC Security Architecture (PDF link).

      February 5th, 2013 at 01:09

      1. r.kofman

        Encryption to ace wrap or ace token? it is bit of your due the limit to get it on your own sides isn’t it…good luck may him be rewarded.

        March 10th, 2013 at 13:13

    2. Maire Reavy

      We use DTLS-SRTP for encryption which is completely secure against 3rd party snooping. For more details, see the document that Robert references and the IETF rtcweb mailing list.

      February 5th, 2013 at 12:03

      1. Abel Lucl

        Unless that 3rd party is (1) your voip server, (2) or anyone who can break the PKI model.

        February 6th, 2013 at 03:02

  8. Andrew Hime

    Wow, my ex-girlfriend called my newer, hotter girlfriend. Is she still renouncing 64-bit Windows and working on a phone OS nobody wants?

    February 4th, 2013 at 15:34

    1. AntiHime

      Doesn’t your new girlfriend does the same? I mean, no x64 for Win either, ChromeOS on netbooks…
      You should learn more before commenting something like this.

      February 4th, 2013 at 16:13

      1. Andrew Hime

        God, you suck at read. See below.

        February 5th, 2013 at 01:04

    2. tom jones


      February 4th, 2013 at 20:17

      1. tom jones

        also http://lmgtfy.com/?q=%22nobody%20wants%20android%22

        February 4th, 2013 at 20:22

        1. Andrew Hime

          Trolltastic, dude.

          February 4th, 2013 at 21:45

      2. Andrew Hime

        No shit, dude… but if I’m going to have to use a 32-bit browser, it’s Chrome AINEC.

        And Google *is* moving towards a 64-bit Chrome. Mozilla is moving towards taking the Nightly on my computer and “upgrading” it back to 32-bit.

        February 4th, 2013 at 21:44

    3. Robert Nyman [Editor]

      Or you could see this as two companies working together to bring interoperability to the open web. With 64-bit support, that’s a separate discussion, and some people have expressed that they aren’t happy with that decision, and it has been noted.

      With Firefox OS, the hope is to offer open smart phones for a low price, so more people can take part of the wonderful thing called Internet.

      February 5th, 2013 at 01:14

      1. Andrew Hime

        You guys know you’re wrong on 64-bit but want the conversation to go away. Not happening.

        As for Firefox OS, is openwebOS not cheap enough (hint: free and open source)? Android have no cheap devices? Bada? Blackberry currently, or in 6 months? And now Ubuntu is entering the market. There is literally no need.

        February 5th, 2013 at 01:30

        1. Robert Nyman [Editor]

          The decision and prioritization has been made for 64-bit Firefox, and the feedback has been collected.

          With Firefox OS, it’s about having a complete mobile operating system that’s open, and with carrier and hardware support. While Bada, Blackberry, Ubuntu etc might offer support for HTML5 apps, the operating system itself isn’t built on it. To my knowledge, Firefox OS is the only one where all the source code is completely open and available to everyone.

          It also comes down to performance, different approaches and offering an alternative.

          February 5th, 2013 at 01:46

          1. Andrew Hime

            Clearly you know nothing about openwebOS.

            February 5th, 2013 at 04:20

          2. Robert Nyman [Editor]

            I’d say I know a thing or two about Open webOS, and I’ve met a lot of people working on it. However – and I’d be happy to hear otherwise here – I don’t know of any carriers or hardware providers that have said they will support it, and I believe that’s one of the parts needed to reach a greater audience.

            Firefox OS, to me, is not about being better than, or “beating”, open webOS – it’s about offering an alternative.

            February 5th, 2013 at 04:31

      2. Al

        The discussion may seem separate, but there is a certain sense of
        horror when critical capability is blown off while fluff is worked on.
        There are numerous big reasons to go 64-bit.

        First, there is the fact that my browser at work (obviously Linux) is
        nearly 5 GB right now. There is no way, no how, that you can cram
        5 GB in a 2 to 4 GB can.

        Second, there is security. Heap spraying is easy when there is
        more physical RAM than virtual address space, harder when they
        are similar, and practically impossible when virtual address space
        greatly exceeds the physical RAM. ASLR works much better with
        64-bit, since there are many more bits to randomize. Going 64-bit
        is extremely helpful for security. The use of 32-bit browsers needs
        to be **very** **strongly** discouraged for this reason.

        Third, 64-bit x86 simply performs better because there are more
        registers, because registers are used for passing arguments, and
        because exception handling is done without adding overhead to the
        non-exception case.

        February 5th, 2013 at 01:42

        1. Robert Nyman [Editor]

          Just to be clear: I think the discussion is well-worth having, and by saying it’s separate, I rather mean that it should take place in a context where the engineers and more are involved. I’d be more than happy for you to contribute to that, and Update on turning off 64-bit Windows builds is probably the best place to start.

          February 5th, 2013 at 01:53

  9. bryan

    The interop page said FireFox currently is DTLS_SRTP only. Will you also support SDES for key exchange? My opinion is that the method of exchange determined be up to the application, not the browser.

    February 4th, 2013 at 15:53

    1. Robert Nyman [Editor]

      Good question. I don’t know at this time, unfortunately.

      February 5th, 2013 at 01:00

    2. Maire Reavy

      There are important security concerns and limitations with SDES. SDES trusts every signaling hop with SRTP keys, has no forward secrecy, doesn’t support adding identity, and has insecure forking and retargeting. These are some of the reasons why DTLS-SRTP is mandated by the rtcweb spec and SDES is explicitly not required. There has been lots more discussion about this on the IETF rtcweb mailing list, and I encourage anyone interested in this to read more about this there.

      February 5th, 2013 at 12:33

      1. bryan

        Yes, I understand the need for DTLS-SRTP in the P2P case. But not all apps are peer to peer. My client-server app, which uses a secure websocket for signaling, would benefit greatly from the ability to use shared keys for a group. It is just wasteful to re-encrypt the same data with different keys for each participant in a group chat. I’ve been surprised throughout the evolution of WebRTC that more attention was not paid to the needs of client server applications.

        February 15th, 2013 at 16:05

        1. mark

          I’m with you on this… peer-to-peer isn’t the only use-case!

          February 27th, 2013 at 07:27

  10. Handrus

    That’s a true milestone! Inspiring to see mozilla & google team getting the lead of a open standard that will allow a more collaborative web.
    Collaboration at its best!
    Thanks! Keep rolling!

    February 4th, 2013 at 16:01

    1. Robert Nyman [Editor]

      Thank you! And yes, we need collaboration and open standards to make sure the web continues to be the great place that it is.

      February 5th, 2013 at 01:00

  11. Clement

    nice! easier way to connect with family and clients… cool way to provide support right from the website.

    February 4th, 2013 at 16:10

    1. Robert Nyman [Editor]

      We hope so!

      February 5th, 2013 at 00:59

  12. njn

    Robert, you don’t have to respond to every single comment. It just fills up the comment thread with noise and makes it harder to read.

    February 4th, 2013 at 18:04

    1. bj

      njn, that’s a really good point!

      February 4th, 2013 at 19:24

    2. dude

      Shut up.

      February 4th, 2013 at 20:57

    3. Craig

      What a jerkish thing to say. There’s only 16 comments in total. If you find that hard to read, maybe the problem lies with you.

      February 4th, 2013 at 21:35

    4. Pluto

      Welcome you to the Internet, where everything you see is based on text. Don’t worry, you’ll never stop running out of stuff to read :)

      February 4th, 2013 at 23:03

    5. Robert Nyman [Editor]

      That’s a fair opinion. However, I personally believe that people who take the time to contribute with a comment deserves the decency of a reply. And if that in some places ends up in too much “noise”, with a few comments that are just nice, I would much rather have that, than the normal silence and one-way communication that most blogs are.

      February 5th, 2013 at 01:17

      1. Mosselman

        Thanks! Good man. I agree.

        February 5th, 2013 at 02:14

  13. Florent Tatard

    I look forward to see more of this on mobile plateform ! WebRTC really seems to be a great alternative compared to third-party VoIP application.
    Any roadmap to share on this subject ? :)

    February 4th, 2013 at 19:43

    1. Robert Nyman [Editor]

      No roadmap to share at this time, but mobile support is definitely in the works!

      February 5th, 2013 at 00:58

  14. genuine

    So uhm.. Internet Explorer wasn’t invited to this party? lol..

    February 4th, 2013 at 19:43

    1. Robert Nyman [Editor]

      Well, they could be – there is a standardization progress.

      February 5th, 2013 at 00:58

    2. Anentropic

      more like they didn’t show up

      February 5th, 2013 at 03:36

  15. rakshit

    It’s really a smart step by you smart gyz behind the absolutely smart browsers of the world ! :-)

    February 4th, 2013 at 23:27

    1. Robert Nyman [Editor]

      Thank you, glad to hear that!

      February 5th, 2013 at 00:56

  16. Kontrol

    Is it available to exchange files between Chrome and Firefox using the data channel? Or can it just chat with video?

    February 5th, 2013 at 00:34

    1. Robert Nyman [Editor]

      Right now, I’d venture a guess that file sharing through DataChannel isn’t completely in there yet.

      February 5th, 2013 at 00:56

    2. Maire Reavy

      Chrome will be implementing DataChannels as defined in the spec soon, but the implementation in Chrome is not available yet. So interop for now is just video/audio.

      February 5th, 2013 at 12:37

  17. Booderan

    It is no use for us until Explorer joins party.

    February 5th, 2013 at 00:47

    1. Robert Nyman [Editor]

      Hopefully they will. There’s a lot of standardization work being done, and I for one hope we will have the same solution for all.

      February 5th, 2013 at 00:55

    2. Maurizio

      I think that nowadays, where Chrome and Firefox toghether are the most used browsers, and people get more and more cunning, the ‘The functionality is not supported by your browser; use one between these other browsers’ is an acceptable option. If we had to wait for IE everytime, we would get stuck at every new technology

      February 5th, 2013 at 01:49

  18. Rob

    So long Skype, it was nice knowing you.

    Thanks Firefox & Chrome teams!

    February 5th, 2013 at 03:01

    1. Robert Nyman [Editor]

      Glad you like it, and hope you will get good use for it!

      February 5th, 2013 at 04:17

  19. Sourav Chakraborty

    This is great stuff! Kudos to Mozilla and Google for making this happen!

    Now, I am looking forward to the standard become “standard” and both Mozilla and Google dropping the prefixes “moz” and “webKit” from the API. I am confident that won’t be very far!

    February 5th, 2013 at 03:51

    1. Robert Nyman [Editor]

      Thanks! And absolutely, that’s definitely the direction we are moving in.

      February 5th, 2013 at 04:18

  20. Capi Etheriel

    So, this is the web, right? Can I have my favorite web service call me to notify on urgent matters (like being late for a meeting)? Can this be called from the server side (provided I’ve got a tab open listening to the service)?

    February 5th, 2013 at 04:33

    1. Robert Nyman [Editor]

      I think there will be a lot of possibilities, but I can’t say exactly how in detail all of them will work. In general with calls, like this, it’s done through RTCPeerConnection so I don’t believe a service in general would be able to push/make a call to you that way,rather a connection between two users directly.

      February 5th, 2013 at 05:00

  21. Peeyush Chandel

    Many Congrtulations to mozilla & chrome team.

    February 5th, 2013 at 05:08

    1. Robert Nyman [Editor]

      Thank you!

      February 5th, 2013 at 07:18

  22. Sam Dutton

    Great stuff! Congratulations to all those who put so much hard work into this.

    February 5th, 2013 at 05:16

    1. Robert Nyman [Editor]

      Thanks Sam, and thanks for your great articles/documentation on WebRTC!

      February 5th, 2013 at 07:18

  23. Simon Griffee

    This is most excellent. Looking forward to running this on Firefox OS someday. Thank you, Google and Mozilla.

    February 5th, 2013 at 07:18

    1. Robert Nyman [Editor]

      We do too. :-)

      February 5th, 2013 at 07:20

  24. CrazyMan

    Uhm… I have just one word about this: AWESOME!

    However … tisk tisk tisk ….
    This smells a bit like one of the next 3 things:
    1. A very thick smoke bomb for IE and Safari
    2. Mozilla working on making it to partner level in future Google (or Google-funded) projects.
    3. a 5-year-ish long takeover from Google :D

    February 5th, 2013 at 07:27

    1. Robert Nyman [Editor]

      And no, we don’t plan to be a part of Google, we just believe in collaboration and a good interoperable open web. :-)

      February 5th, 2013 at 13:05

  25. christian westman

    Great to see the two leading browser companies working together like this :)
    Keep up the good work!

    February 5th, 2013 at 07:39

    1. Robert Nyman [Editor]

      Thank you, I for one is happy to see how we’ve worked together!

      February 5th, 2013 at 13:03

  26. Andrius Kairiukstis

    I am VoIP developer, 2013 will be an WebRTC year, and we will see a lot of new products and ideas… But “Firefox browser calling a Chrome browser” phrase still shocking! :)

    February 5th, 2013 at 07:49

    1. Robert Nyman [Editor]

      I think it will be a WebRTC year too! And that’s good shock, right? :-)

      February 5th, 2013 at 13:03

  27. Afshin Mehrabani

    Big change, congrats! I think this feature will change the webinars industry.

    February 5th, 2013 at 08:15

    1. Robert Nyman [Editor]

      Absolutely, webinars will definitely be able to use this to their advantage.

      February 5th, 2013 at 13:05

  28. Stephan Bardubitzki

    Congrats! This is really cool.

    Having it also on Android and Firefox OS then the sky’s the limit…

    February 5th, 2013 at 10:09

    1. Robert Nyman [Editor]

      Thanks! And without a doubt, those are the next steps.

      February 5th, 2013 at 13:06

  29. Martin Zatroch

    Huge thanks goes to whole Mozilla team! Finally, the exact thing I was waiting for. Not sure about what are Google devs going to do about VoIP implementation inside GMail interface [that one up to these days still require additional plug-in], thou.

    PS: Cannot wait to see some decent mobile device pre-installed with FirefoxOS appear in Slovakia under regional Telefónica’s offers or elsewhere. Yay, how I hate locked-down walled-gardens. Thank you folks once more. d-_-b m/

    February 5th, 2013 at 12:17

    1. Robert Nyman [Editor]

      Glad you like it! Not sure about Gmail, but I think a fair guess is that WebRTC will definitely make it into their products.
      With regards to Firefox OS and Slovakia, I really hope we’ll be able to offer you that!

      February 5th, 2013 at 13:11

  30. Rahul patula

    Yikes.Very excited about the latest development.So hoping to see some wonderful innovations come up in near future

    February 5th, 2013 at 12:53

    1. Robert Nyman [Editor]

      You might be one of the persons with a wonderful innovation based on this. :-)

      February 5th, 2013 at 13:12

  31. Robert Kaiser


    It’s also nice to show that between Firefox and Chrome, it’s not a bad-blood relationship but actually the competition is really friendly and open (at least from Mozilla’s side, very open).
    Still fun to notice who on the call of those two people is the more commercial and who the more technical partner (one mentioning their “Google App Engine” and the other all the open technologies powering WebRTC)… ;-)

    February 5th, 2013 at 13:38

    1. Robert Nyman [Editor]

      I agree, I’m happy to show our collaboration and how we together work to make the open web better.

      February 5th, 2013 at 13:47

  32. Infinity

    Great news and even better links ! Was looking for something exciting to present for my talk on WebRTC here :)
    Anything else that I could showcase Robert? (*demos*)
    Awesome guys! Keep up the good work!

    February 5th, 2013 at 15:09

    1. Robert Nyman [Editor]

      I believe the demos in the post are the most suitable:


      February 6th, 2013 at 03:16


    Thank you, this might trigger a paradigm shift in web usability.

    Please explain, how did you cover abuse and security issues?
    Is any precaution for the user to protect himself integrated?

    I got many ideas how bad guys, spammers and advertisers will hijack this great feature to annoy people or even steal data.

    Certainly you have envisioned several abuse-scenarios and based on these build some safety belts into WebRTC, besides “disable all” – please write about it, thanks!

    February 6th, 2013 at 03:37

    1. Robert Nyman [Editor]

      It might do that, indeed!

      I think the security questions got covered in comments above, especially with the linked document:



      For users, they will be presented with a dialog where they can approve/decline camera and microphone access.

      February 6th, 2013 at 03:57

    2. Sam Dutton

      In terms of ‘architectural’ security, take a look at http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-security.

      (There are also security features inherent in the ICE framework, which I don’t go into here.)

      February 6th, 2013 at 04:34

      1. Robert Nyman [Editor]

        Thanks Sam, that’s a good resource as well!

        February 6th, 2013 at 07:14

  34. Richard norburn


    Wow is all I can say to this intiative the VC industry (Polycom, Tandburg, Life Size) should be worried. You’ll wipe out a good portions of there product suite over night. Point to Point is great, when a Open source Video bridge arrives, they will be dead !!!

    Is H323 interopabilty included. ie can a browser talk directly to VC unit. If so I’ve test on 200 staff next month?

    February 6th, 2013 at 04:42

    1. Robert Nyman [Editor]

      Not sure about that kind of interoperability at the moment. It’s a work in progress, and I’d recommend you to test the code in the demo to see if you can make it work for your purposes.

      February 6th, 2013 at 07:17

  35. Edgar

    Mozilla, you are awesome!!!

    February 6th, 2013 at 07:30

    1. Robert Nyman [Editor]

      Thanks, glad you think so! :-)

      February 7th, 2013 at 02:17

  36. maxw3st

    Thanks for the info. Much to check out, but this is exciting. I particularly like the comment made about encrypting the stream between the two of you on the call. I’ve been wanting to build a secure communications app. for some time, and it looks like WebRTC is the answer.

    February 6th, 2013 at 15:13

    1. Robert Nyman [Editor]

      Glad you like it, and we definitely hope it will be an interesting option for you!

      February 7th, 2013 at 02:19

  37. Ethan


    February 6th, 2013 at 20:32

    1. Robert Nyman [Editor]

      Thanks Ethan!

      February 7th, 2013 at 02:16

  38. Hrishi

    I cannot believe how phenomenal this would be…. No Webex, livemeetings, or anything, just your browser…. It will be a killer… Thankyou so much for this.

    February 8th, 2013 at 13:18

    1. Robert Nyman [Editor]

      Thanks, it does indeed seem exciting!

      February 12th, 2013 at 03:31

  39. VPX


    Can you guys please update libvpx to the latest version?

    February 8th, 2013 at 14:11

    1. Robert Nyman [Editor]

      You need to discuss that in the bug, that’s where the discussion takes place.

      February 12th, 2013 at 03:31

  40. Q

    Why is chrome backwards in the video?

    February 8th, 2013 at 14:37

    1. Robert Nyman [Editor]

      Different chosen ways of displaying the content.

      February 12th, 2013 at 03:30

  41. Leon Victor

    I am looking forward to more news on this thing. Nice to see that Google & Mozilla take the lead for new browser technologies. It will be beneficial for us.

    February 11th, 2013 at 01:00

    1. Robert Nyman [Editor]

      Thanks, glad you like it!

      February 12th, 2013 at 03:23

  42. Vikram Lele


    I am super excited about this development. I know this is probably not the right place for tech query, still I am going ahead –

    Will it be possible to establish two video channels if there are two video capture devices on my PC? That would open up even more exciting opportunities for application developers.

    – Vikram

    February 13th, 2013 at 13:50

    1. Robert Nyman [Editor]

      It’s a good question! I don’t know, actually – right now I think it only supports one video stream at a time.

      February 14th, 2013 at 05:44

    2. Maire Reavy

      Currently we support only one video stream per PeerConnection, but it is definitely on our roadmap to support multiple streams per PeerConnection. You can emulate this today using two PeerConnections until we have support for multiple flows per PeerConnection.

      February 27th, 2013 at 07:42

      1. Vikram Lele

        I don’t know the downside/benefits of multiple streams per peer connection v/s multiple peer connections.

        Will the multiple peer connection scheme work when one party has one source and other party has two video stream sources?

        Personally I think a solution with two peer connections is fine too. As long as there is a way to prompt the user for selecting video stream for particular purpose.

        February 27th, 2013 at 19:15

  43. john

    how can i block a video from internet i will help someone really good with this.
    Does someone got a website or something please

    February 26th, 2013 at 10:58

    1. Robert Nyman [Editor]

      Video in WebRTC will only be shared if you approve it.

      February 26th, 2013 at 16:48

  44. chenlin zhong

    there are some bugs in the sample app.my english is poor

    March 6th, 2013 at 03:32

    1. Robert Nyman [Editor]

      What kind of bugs?

      March 6th, 2013 at 03:37

  45. Fabian

    Hi Robert,

    I am very excited (and a little worried) about the webRTC development, but at the same time I find it as a simple web programmer pretty hard to understand topic. That has mainly to do with ICE/STUN. I can’t find information whether it’s mandatory to have STUN servers as an argument for the PeerConnection constructor. In your example, and others, I see the argument left out or set to null.

    I would think that the peerConnection Object consults a STUN server and passes the local ICE candidate it receives from the server to the onicecandidate, meaning a STUN server would be required to actually stream remote media –>

    According to HTMLRocks: “The acquisition and exchange of network and media information can be done simultaneously, but both processes must have completed before audio and video streaming between peers can begin.”

    March 15th, 2013 at 11:28

  46. Fabian

    Anyone interested in the answer to my question, it was answered here:


    March 20th, 2013 at 02:35

    1. Robert Nyman [Editor]


      Thanks for checking back, and sharing the solution/answer here!

      March 20th, 2013 at 06:07

Comments are closed for this article.