Mozilla

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").play();
    document.getElementById("localvideo").muted = true;
 
    // Here's where you set up a Firefox PeerConnection
    var pc = new mozRTCPeerConnection();
    pc.addStream(stream);
 
    pc.onaddstream = function(obj) {
      log("Got onaddstream of type " + obj.type);
      document.getElementById("remotevideo").mozSrcObject = obj.stream;
      document.getElementById("remotevideo").play();
      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;
        jQuery.post(
          "offer", {
            to: user,
            from: document.getElementById("user").innerHTML,
            offer: JSON.stringify(offer)
          },
          function() { console.log("Offer sent!"); }
        ).error(error);
      }, 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").play();
    document.getElementById("localvideo").muted = true;
 
    // Here's where you set up a Firefox PeerConnection
    var pc = new mozRTCPeerConnection();
    pc.addStream(stream);
 
    pc.onaddstream = function(obj) {
      document.getElementById("remotevideo").mozSrcObject = obj.stream;
      document.getElementById("remotevideo").play();
      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;
          jQuery.post(
            "answer", {
              to: offer.from,
              from: offer.to,
              answer: JSON.stringify(answer)
            },
            function() { console.log("Answer sent!"); }
          ).error(error);
        }, 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.stop();
  document.getElementById("localvideo").mozSrcObject = null;
  document.getElementById("remotevideo").mozSrcObject = null;
 
  peerc.close();
  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.

128 comments

Comments are now closed.

  1. Marko wrote on February 4th, 2013 at 12:40:

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

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 13:59:

      Thanks. :-)

  2. js audio api wrote on February 4th, 2013 at 13:44:

    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 :(

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 14:05:

      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.

      1. Matt Montag wrote on February 5th, 2013 at 01:06:

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

        1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:24:

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

  3. Ali Helmy wrote on February 4th, 2013 at 14:20:

    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!

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 14:32:

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

      1. Tin Aung Linn wrote on February 5th, 2013 at 04:27:

        Nice Slogan

  4. Sy wrote on February 4th, 2013 at 14:54:

    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 ?

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 15:08:

      Thanks!
      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.”

      1. Michael wrote on February 5th, 2013 at 21:48:

        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.

        1. Robert Nyman [Editor] wrote on February 6th, 2013 at 03:22:

          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.

          1. Phil Hannent wrote on February 6th, 2013 at 06:24:

            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.

          2. Robert Nyman [Editor] wrote on February 6th, 2013 at 07:20:

            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.

  5. timrpeterson wrote on February 4th, 2013 at 15:12:

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

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 15:17:

      Thank you, glad you appreciate it!

  6. Joe Ekine wrote on February 4th, 2013 at 15:19:

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

    Thank you

    1. Robert Nyman [Editor] wrote on February 4th, 2013 at 15:21:

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

  7. Venky wrote on February 4th, 2013 at 15:29:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:09:

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

      1. r.kofman wrote on March 10th, 2013 at 13:13:

        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.

    2. Maire Reavy wrote on February 5th, 2013 at 12:03:

      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.

      1. Abel Lucl wrote on February 6th, 2013 at 03:02:

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

  8. Andrew Hime wrote on February 4th, 2013 at 15:34:

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

    1. AntiHime wrote on February 4th, 2013 at 16:13:

      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.

      1. Andrew Hime wrote on February 5th, 2013 at 01:04:

        God, you suck at read. See below.

    2. tom jones wrote on February 4th, 2013 at 20:17:

      http://mozillamemes.tumblr.com/post/36304685682/im-just-going-to-let-that-sit-there-without

      1. tom jones wrote on February 4th, 2013 at 20:22:

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

        1. Andrew Hime wrote on February 4th, 2013 at 21:45:

          Trolltastic, dude.

      2. Andrew Hime wrote on February 4th, 2013 at 21:44:

        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.

    3. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:14:

      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.

      1. Andrew Hime wrote on February 5th, 2013 at 01:30:

        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.

        1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:46:

          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.

          1. Andrew Hime wrote on February 5th, 2013 at 04:20:

            Clearly you know nothing about openwebOS.

          2. Robert Nyman [Editor] wrote on February 5th, 2013 at 04:31:

            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.

      2. Al wrote on February 5th, 2013 at 01:42:

        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.

        1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:53:

          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.

  9. bryan wrote on February 4th, 2013 at 15:53:

    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.

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:00:

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

    2. Maire Reavy wrote on February 5th, 2013 at 12:33:

      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.

      1. bryan wrote on February 15th, 2013 at 16:05:

        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.

        1. mark wrote on February 27th, 2013 at 07:27:

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

  10. Handrus wrote on February 4th, 2013 at 16:01:

    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!

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:00:

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

  11. Clement wrote on February 4th, 2013 at 16:10:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:59:

      We hope so!

  12. njn wrote on February 4th, 2013 at 18:04:

    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.

    1. bj wrote on February 4th, 2013 at 19:24:

      njn, that’s a really good point!

    2. dude wrote on February 4th, 2013 at 20:57:

      Shut up.

    3. Craig wrote on February 4th, 2013 at 21:35:

      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.

    4. Pluto wrote on February 4th, 2013 at 23:03:

      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 :)

    5. Robert Nyman [Editor] wrote on February 5th, 2013 at 01:17:

      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.

      1. Mosselman wrote on February 5th, 2013 at 02:14:

        Thanks! Good man. I agree.

  13. Florent Tatard wrote on February 4th, 2013 at 19:43:

    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 ? :)

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:58:

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

  14. genuine wrote on February 4th, 2013 at 19:43:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:58:

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

    2. Anentropic wrote on February 5th, 2013 at 03:36:

      more like they didn’t show up

  15. rakshit wrote on February 4th, 2013 at 23:27:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:56:

      Thank you, glad to hear that!

  16. Kontrol wrote on February 5th, 2013 at 00:34:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:56:

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

    2. Maire Reavy wrote on February 5th, 2013 at 12:37:

      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.

  17. Booderan wrote on February 5th, 2013 at 00:47:

    It is no use for us until Explorer joins party.

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 00:55:

      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.

    2. Maurizio wrote on February 5th, 2013 at 01:49:

      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

  18. Rob wrote on February 5th, 2013 at 03:01:

    So long Skype, it was nice knowing you.

    Thanks Firefox & Chrome teams!

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 04:17:

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

  19. Sourav Chakraborty wrote on February 5th, 2013 at 03:51:

    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!

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 04:18:

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

  20. Capi Etheriel wrote on February 5th, 2013 at 04:33:

    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)?

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 05:00:

      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.

  21. Peeyush Chandel wrote on February 5th, 2013 at 05:08:

    Many Congrtulations to mozilla & chrome team.

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 07:18:

      Thank you!

  22. Sam Dutton wrote on February 5th, 2013 at 05:16:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 07:18:

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

  23. Simon Griffee wrote on February 5th, 2013 at 07:18:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 07:20:

      We do too. :-)

  24. CrazyMan wrote on February 5th, 2013 at 07:27:

    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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:05:

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

  25. christian westman wrote on February 5th, 2013 at 07:39:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:03:

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

  26. Andrius Kairiukstis wrote on February 5th, 2013 at 07:49:

    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! :)

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:03:

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

  27. Afshin Mehrabani wrote on February 5th, 2013 at 08:15:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:05:

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

  28. Stephan Bardubitzki wrote on February 5th, 2013 at 10:09:

    Congrats! This is really cool.

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:06:

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

  29. Martin Zatroch wrote on February 5th, 2013 at 12:17:

    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/

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:11:

      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!

  30. Rahul patula wrote on February 5th, 2013 at 12:53:

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

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:12:

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

  31. Robert Kaiser wrote on February 5th, 2013 at 13:38:

    Awesome!

    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)… ;-)

    1. Robert Nyman [Editor] wrote on February 5th, 2013 at 13:47:

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

  32. Infinity wrote on February 5th, 2013 at 15:09:

    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!

    1. Robert Nyman [Editor] wrote on February 6th, 2013 at 03:16:

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

      https://github.com/jesup/nightly-gupshup
      http://www.webrtc.org/demo

  33. BUGHUNTER wrote on February 6th, 2013 at 03:37:

    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!

    1. Robert Nyman [Editor] wrote on February 6th, 2013 at 03:57:

      It might do that, indeed!

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

      https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/comment-page-1/#comment-1984843

      https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/comment-page-1/#comment-1985436

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

    2. Sam Dutton wrote on February 6th, 2013 at 04:34:

      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.)

      1. Robert Nyman [Editor] wrote on February 6th, 2013 at 07:14:

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

  34. Richard norburn wrote on February 6th, 2013 at 04:42:

    Hi,

    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?

    1. Robert Nyman [Editor] wrote on February 6th, 2013 at 07:17:

      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.

  35. Edgar wrote on February 6th, 2013 at 07:30:

    Mozilla, you are awesome!!!

    1. Robert Nyman [Editor] wrote on February 7th, 2013 at 02:17:

      Thanks, glad you think so! :-)

  36. maxw3st wrote on February 6th, 2013 at 15:13:

    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.

    1. Robert Nyman [Editor] wrote on February 7th, 2013 at 02:19:

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

  37. Ethan wrote on February 6th, 2013 at 20:32:

    Awesome

    1. Robert Nyman [Editor] wrote on February 7th, 2013 at 02:16:

      Thanks Ethan!

  38. Hrishi wrote on February 8th, 2013 at 13:18:

    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.

    1. Robert Nyman [Editor] wrote on February 12th, 2013 at 03:31:

      Thanks, it does indeed seem exciting!

  39. VPX wrote on February 8th, 2013 at 14:11:

    https://bugzilla.mozilla.org/show_bug.cgi?id=763495

    Can you guys please update libvpx to the latest version?

    1. Robert Nyman [Editor] wrote on February 12th, 2013 at 03:31:

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

  40. Q wrote on February 8th, 2013 at 14:37:

    Why is chrome backwards in the video?

    1. Robert Nyman [Editor] wrote on February 12th, 2013 at 03:30:

      Different chosen ways of displaying the content.

  41. Leon Victor wrote on February 11th, 2013 at 01:00:

    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.

    1. Robert Nyman [Editor] wrote on February 12th, 2013 at 03:23:

      Thanks, glad you like it!

  42. Vikram Lele wrote on February 13th, 2013 at 13:50:

    Hi,

    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

    1. Robert Nyman [Editor] wrote on February 14th, 2013 at 05:44:

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

    2. Maire Reavy wrote on February 27th, 2013 at 07:42:

      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.

      1. Vikram Lele wrote on February 27th, 2013 at 19:15:

        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.

  43. john wrote on February 26th, 2013 at 10:58:

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

    1. Robert Nyman [Editor] wrote on February 26th, 2013 at 16:48:

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

  44. chenlin zhong wrote on March 6th, 2013 at 03:32:

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

    1. Robert Nyman [Editor] wrote on March 6th, 2013 at 03:37:

      What kind of bugs?

  45. Fabian wrote on March 15th, 2013 at 11:28:

    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.”

  46. Fabian wrote on March 20th, 2013 at 02:35:

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

    http://stackoverflow.com/questions/15484729/why-doesnt-onicecandidate-work

    1. Robert Nyman [Editor] wrote on March 20th, 2013 at 06:07:

      Hi,

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

Comments are closed for this article.