你好,Chrome,这里是 Firefox!

Mozilla 激动地宣布,我们在 WebRTC 开发方面取得了重要的里程碑:Firefox 和 Chrome 之间的 WebRTC RTCPeerConnection 互操作性。这项成果的取得归功于开放 Web 社区以及 Mozilla 和 Google 工程师的密切合作。

RTCPeerConnection(也简称为 PeerConnection 或 PC)互操作性意味着开发者现在可以创建 Firefox WebRTC 应用程序,直接与 Chrome WebRTC 应用程序进行音视频通话,而无需安装第三方插件。由于此功能现在已内置于浏览器中,用户可以避免首次安装和插件错误的问题,开发者也可以更轻松、更普遍地部署他们的应用程序。

为了庆祝这一重要的里程碑,我们认为致电我们在 Google 的朋友并与他们进行讨论会很有趣。观看这段 Mozilla 首席创新官 Todd Simpson 与 Google 产品管理总监 Hugh Finnan 之间的 Firefox-Chrome 演示通话视频,并在他们的博客文章中阅读 Google 对这一重要时刻的看法。

这一里程碑建立在我们去年年底展示的与 Social API 集成的 WebRTC的早期演示的基础上。我们在那里展示了 DataChannels 的业界首个实现,DataChannels 是 WebRTC 的一个强大组件,可以与音视频聊天结合,允许用户共享他们电脑或设备上的几乎任何内容。只需将项目拖到视频聊天窗口中,即可发送度假照片、难忘的视频、新闻故事链接等。敬请期待更多相关信息。

WebRTC 是一个在 W3C 和 IETF 标准组织联合定义的开放标准,其目的是为所有用户设备提供一个通用的平台,以便实时通信和共享音频、视频和数据。这是朝着互操作性和真正的、开放的、实时的 Web 通信愿景迈出的第一步。

发布者:
Serge Lachapelle,Chrome 产品经理和 Maire Reavy,Firefox 媒体产品负责人

开始在 Firefox 中使用 RTCPeerConnection 进行开发

对于尚未在 Firefox 中尝试 RTCPeerConnection 的 JavaScript 开发者(因为这对我们来说是一个全新的功能),您可以通过将 media.peerconnection.enabled 首选项设置为“true”来使用最新的 Firefox Nightly 进行尝试(浏览到 about:config 并在首选项列表中搜索 media.peerconnection.enabled 首选项)。以下是示例应用程序中的一段代码,展示了如何在 Firefox 中使用 RTCPeerConnection 发起、接受和结束 WebRTC 通话

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;
}

您会注意到 Firefox 仍然将 RTCPeerConnection API 调用加上前缀 mozRTCPeerConnection,因为标准委员会尚未完成对它的定义。Chrome 将其加上前缀 webkitRTCPeerConnection。一旦标准委员会完成其工作,我们将删除前缀并使用相同的 API,但与此同时,您需要支持这两种前缀,以便您的应用程序在这两种浏览器中都能正常工作。

自己尝试互操作性

对于那些渴望尝试互操作性的人,这里有“在家尝试”的说明和信息

这是 Firefox 和 Chrome 的第一个 PeerConnection 互操作版本。与大多数早期版本一样,仍然存在需要修复的错误,并且并非所有网络环境都支持互操作性。但这对于这项新的 Web 功能以及 Web 本身来说都是向前迈出的重要一步。我们感谢标准组织和 WebRTC 社区的每一位贡献者。虽然还有很多工作要做,但我们希望您同意 Web 将变得更加出色。

关于 Robert Nyman [荣誉编辑]

Mozilla Hacks 的技术推广者和编辑。发表演讲和博客,内容涉及 HTML5、JavaScript 和开放 Web。Robert 是 HTML5 和开放 Web 的坚定信徒,自 1999 年以来一直在瑞典和纽约市从事 Web 前端开发工作。他还定期在 http://robertnyman.com 上撰写博客,并且热爱旅行和结识新朋友。

Robert Nyman [荣誉编辑] 的更多文章…


128 条评论

  1. Marko

    迫不及待地想卸载第三方 VoIP 软件的那一天。
    谢谢 Mozilla。谢谢 Google。

    2013年2月4日 12:40

    1. Robert Nyman [编辑]

      谢谢。 :-)

      2013年2月4日 13:59

  2. js audio api

    既然 Mozilla 和 Google 之间已经有了“红线”,那么如何设计一个可互操作的 JS audio API 呢?

    Audio Data API、Web Audio API、MediaStream API……在 2013 年,这真是一团糟,太可惜了:(

    2013年2月4日 13:44

    1. Robert Nyman [编辑]

      请放心,我们正在尽最大努力在尽可能多的领域实现互操作性,我希望并且相信,我们将在 Web 音频方面看到改进。

      例如,Firefox 计划支持Web Audio API

      2013年2月4日 14:05

      1. Matt Montag

        很高兴听到这个消息,Robert。迫不及待地想推动 Web Audio 的发展。

        2013年2月5日 01:06

        1. Robert Nyman [编辑]

          谢谢!我对此寄予厚望,而且我确实同意这是一个有改进空间的领域。

          2013年2月5日 01:24

  3. Ali Helmy

    哇!谢谢 Google 和 Mozilla……

    无论使用什么浏览器,也无需安装任何插件,就能进行网络通话并将家人聚集在一起,这将使祖父母与孙女联系起来变得更加容易!

    2013年2月4日 14:20

    1. Robert Nyman [编辑]

      谢谢,很高兴能让你开心!
      也许这应该成为 WebRTC 的口号:让家人更亲近。 :-)

      2013年2月4日 14:32

      1. Tin Aung Linn

        不错的口号

        2013年2月5日 04:27

  4. Sy

    这是个好消息,我很期待更多这样的消息,但我有个小问题。如果你们最终达成一致并一起合作,为什么还要在 API 前面加上 moz 和 webkit(很快还有 o 和 ms)的前缀呢?为什么不能直接用 RTCPeerConnection 呢?

    2013年2月4日 14:54

    1. Robert Nyman [编辑]

      谢谢!
      这个问题的答案在这篇博文的代码示例之后有提到。

      “你会注意到 Firefox 仍然将 RTCPeerConnection API 调用加上 mozRTCPeerConnection 的前缀,因为标准委员会尚未完成对它的定义。Chrome 将其加上 webkitRTCPeerConnection 的前缀。一旦标准委员会完成其工作,我们将移除这些前缀并使用相同的 API,但与此同时,你需要支持这两种前缀,以便你的应用程序在这两种浏览器中都能正常工作。”

      2013年2月4日 15:08

      1. Michael

        我认为 Sy 可能想问的是:既然你们一起合作,却各自给函数调用命名不同的名称,这有什么意义呢?如果他不是这个意思(我敢打赌他就是这个意思),那么我就问这个问题。

        2013年2月5日 21:48

        1. Robert Nyman [编辑]

          在标准化之前以及在实现进行测试期间,最佳实践是使用带前缀的名称。万一标准、名称等发生变化,它就不会失效。一旦事情最终确定,我们将非常乐意取消前缀。

          2013年2月6日 03:22

          1. Phil Hannent

            我认为你们应该更改前缀命名约定,不要使用特定于供应商的名称。“test”或“nonstandard”前缀可以使函数调用跨平台,并提醒人们它不是正式标准。

            现在,你和谷歌只是在宣传自己,并让开发者编写两次测试函数。

            2013年2月6日 06:24

          2. Robert Nyman [编辑]

            但事实并非如此。所有网络浏览器供应商——Mozilla、谷歌、微软和 Opera(以及使用 WebKit 的 Safari)——在这种情况下(JavaScript 和 CSS)都使用自己的前缀。这是一个持续讨论的共同名称,但在实践中很难实现。这假设所有网络浏览器都会实现新功能/更改支持等,并在完全相同的时间发布——否则,它会在一个浏览器中工作,而在另一个浏览器中失效。

            这就是使用前缀的原因——以便能够在各自的网络浏览器中测试新的、尚未标准化的功能,进行实验——并在最终确定和标准化后,移除前缀并发布。

            2013年2月6日 07:20

  5. timrpeterson

    谷歌和 Firefox 太棒了。感谢你们在这方面的合作!

    2013年2月4日 15:12

    1. Robert Nyman [编辑]

      谢谢你的赞赏!

      2013年2月4日 15:17

  6. Joe Ekine

    很高兴看到 Mozilla 和谷歌引领了我们都能受益的新浏览器技术。

    谢谢

    2013年2月4日 15:19

    1. Robert Nyman [编辑]

      谢谢!这似乎是让开放网络向前发展,让每个人都受益的最佳方式!

      2013年2月4日 15:21

  7. Venky

    实现了什么样的加密?这是否会允许像 Skype 那样的第三方机构进行窥探?

    2013年2月4日 15:29

    1. Robert Nyman [编辑]

      加密是一个很大的话题,最好的读物可能是《WebRTC 安全架构建议》(PDF 链接)http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

      2013年2月5日 01:09

      1. r.kofman

        加密到 ace wrap 还是 ace token?这有点像你自己的责任,要靠你自己去获得它,不是吗……祝你好运,愿他得到回报。

        2013年3月10日 13:13

    2. Maire Reavy

      我们使用 DTLS-SRTP 进行加密,这对于防止第三方窥探是完全安全的。更多详情,请参阅 Robert 提到的文档和 IETF rtcweb 邮件列表。

      2013年2月5日 12:03

      1. Abel Lucl

        除非该第三方是 (1) 你的 voip 服务器,(2) 或任何可以破解 PKI 模型的人。

        2013年2月6日 03:02

  8. Andrew Hime

    哇,我的前女友打电话给我的新女友,她更漂亮。她还在放弃 64 位 Windows 并开发一个没人想要的手机操作系统吗?

    2013年2月4日 15:34

    1. AntiHime

      你的新女友不是也一样吗?我的意思是,Win 也没有 x64,上网本上运行的是 ChromeOS……
      你应该多了解一些再发表这样的评论。

      2013年2月4日 16:13

      1. Andrew Hime

        天哪,你的阅读能力真差。见下文。

        2013年2月5日 01:04

    2. tom jones

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

      2013年2月4日 20:17

      1. tom jones

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

        2013年2月4日 20:22

        1. Andrew Hime

          伙计,你真是太会抬杠了。

          2013年2月4日 21:45

      2. Andrew Hime

        废话,伙计……但如果我不得不使用 32 位浏览器,那肯定是 Chrome。

        而且谷歌*正在*向 64 位 Chrome 发展。Mozilla 正在朝着在我的电脑上使用 Nightly 并将其“升级”回 32 位的方向发展。

        2013年2月4日 21:44

    3. Robert Nyman [编辑]

      或者你可以把这看作是两家公司合作,为开放网络带来互操作性。关于 64 位支持,这是一个单独的讨论,有些人表示他们对这个决定不满意,这一点已经注意到了。

      对于 Firefox OS,希望以低廉的价格提供开放的智能手机,以便更多的人能够参与到互联网这个美好的事物中来。

      2013年2月5日 01:14

      1. Andrew Hime

        你们知道你们在 64 位问题上是错的,但又想让这个话题消失。这不可能。

        至于 Firefox OS,openwebOS 不够便宜吗(提示:免费和开源)?Android 没有便宜的设备吗?Bada 呢?黑莓目前,或者 6 个月后呢?现在 Ubuntu 也进入了市场。这完全没有必要。

        2013年2月5日 01:30

        1. Robert Nyman [编辑]

          关于 64 位 Firefox 的决定和优先级已经确定,并且已经收集了反馈。

          使用 Firefox OS,我们拥有一个完全开放的移动操作系统,并得到了运营商和硬件的支持。尽管 Bada、Blackberry、Ubuntu 等也可能支持 HTML5 应用,但操作系统本身并非基于 HTML5 构建。据我所知,Firefox OS 是唯一一个所有源码都完全开放且人人可用的操作系统。

          这也归结于性能、不同的方法以及提供一种替代方案。

          2013年2月5日 01:46

          1. Andrew Hime

            显然你对 openwebOS 一无所知。

            2013年2月5日 04:20

          2. Robert Nyman [编辑]

            我想说我对 Open webOS 略知一二,并且我见过很多从事这方面工作的人。然而——我很乐意在此听到不同的意见——我不知道有任何运营商或硬件供应商表示会支持它,我相信这是覆盖更广泛受众的必要条件之一。

            对我来说,Firefox OS 并不是要比 open webOS 更好,或者“打败”它,而是要提供一种替代方案。

            2013年2月5日 04:31

      2. Al

        讨论看起来可能无关,但在关键功能被忽略而一些无关紧要的功能却在开发时,确实会让人感到
        恐惧。
        有很多重要的理由转向 64 位。

        首先,我工作中使用的浏览器(显然是 Linux)
        现在接近 5 GB。你根本不可能
        把 5 GB 的东西塞进 2 到 4 GB 的空间里。

        其次,是安全性。当物理内存大于虚拟地址空间时,堆喷射很容易实现,当它们
        相近时就比较困难,而当虚拟地址空间
        远远大于物理内存时,几乎不可能实现。ASLR 在
        64 位系统下工作得更好,因为它有更多位可以随机化。转向 64 位
        对安全性非常有帮助。出于这个原因,需要
        **非常** **强烈地** 劝阻使用 32 位浏览器。

        第三,64 位 x86 的性能更好,因为它有更多
        寄存器,因为寄存器用于传递参数,而且
        因为异常处理不会给非异常情况增加开销。

        2013年2月5日 01:42

        1. Robert Nyman [编辑]

          澄清一下:我认为这个讨论很有价值,说它无关,我的意思是它应该在一个工程师和其他更多人参与的背景下进行。我很乐意你为此做出贡献,关于关闭 64 位 Windows 版本的更新可能是个不错的起点。

          2013年2月5日 01:53

  9. bryan

    互操作性页面说 Firefox 目前只支持 DTLS_SRTP。你们也会支持 SDES 进行密钥交换吗?我认为交换方法应该由应用程序决定,而不是浏览器。

    2013年2月4日 15:53

    1. Robert Nyman [编辑]

      好问题。可惜我现在还不知道。

      2013年2月5日 01:00

    2. Maire Reavy

      SDES 存在重要的安全问题和限制。SDES 信任每个信令跳的 SRTP 密钥,没有前向保密性,不支持添加身份,并且具有不安全的 forking 和 retargeting。这些是 rtcweb 规范强制要求 DTLS-SRTP 且明确不要求 SDES 的一些原因。IETF rtcweb 邮件列表上对此进行了更多讨论,我鼓励对此感兴趣的人在那里阅读更多相关信息。

      2013年2月5日 12:33

      1. bryan

        是的,我理解在 P2P 情况下需要 DTLS-SRTP。但并非所有应用程序都是点对点的。我的客户端-服务器应用程序使用安全的 websocket 进行信令,如果能够为一个组使用共享密钥,将会非常受益。为群聊中的每个参与者使用不同的密钥重新加密相同的数据,这纯粹是浪费。在 WebRTC 的发展过程中,我一直很惊讶没有更多地关注客户端-服务器应用程序的需求。

        2013年2月15日 16:05

        1. mark

          我同意你的观点……点对点并不是唯一的用例!

          2013年2月27日 07:27

  10. Handrus

    这是一个真正的里程碑!很高兴看到 Mozilla 和 Google 团队引领了一个开放标准,它将使网络更加协作化。
    最好的协作!
    谢谢!继续努力!

    2013年2月4日 16:01

    1. Robert Nyman [编辑]

      谢谢你!是的,我们需要协作和开放标准,以确保网络继续保持其优良的特性。

      2013年2月5日 01:00

  11. Clement

    好极了!更轻松地与家人和客户联系……从网站提供支持的酷炫方式。

    2013年2月4日 16:10

    1. Robert Nyman [编辑]

      我们希望如此!

      2013年2月5日 00:59

  12. njn

    Robert,你不必回复每一条评论。这只会让评论区充满噪音,使阅读更加困难。

    2013年2月4日 18:04

    1. bj

      njn,这确实是一个好观点!

      2013年2月4日 19:24

    2. dude

      闭嘴。

      2013年2月4日 20:57

    3. Craig

      这话说得真混蛋。总共只有 16 条评论。如果你觉得难以阅读,也许问题出在你身上。

      2013年2月4日 21:35

    4. Pluto

      欢迎来到互联网,你看到的一切都是基于文本的。别担心,你永远不会没有东西可读 :)

      2013年2月4日 23:03

    5. Robert Nyman [编辑]

      这是一个合理的观点。然而,我个人认为,那些花时间发表评论的人应该得到回复的尊重。如果这在某些地方会导致过多的“噪音”,有一些评论只是出于好意,我宁愿这样,也不愿像大多数博客那样保持沉默,进行单向沟通。

      2013年2月5日 01:17

      1. Mosselman

        谢谢!好人。我同意。

        2013年2月5日 02:14

  13. Florent Tatard

    我期待在移动平台上看到更多这方面的内容!与第三方 VoIP 应用程序相比,WebRTC 似乎真的是一个很好的替代方案。
    有什么路线图可以分享吗?:)

    2013年2月4日 19:43

    1. Robert Nyman [编辑]

      目前没有路线图可以分享,但移动支持肯定正在进行中!

      2013年2月5日 00:58

  14. genuine

    那么,呃……Internet Explorer 没有被邀请参加这个派对吗?哈哈……

    2013年2月4日 19:43

    1. Robert Nyman [编辑]

      嗯,他们可以——有一个标准化进程。

      2013年2月5日 00:58

    2. Anentropic

      更像是他们没来

      2013年2月5日 03:36

  15. rakshit

    对于世界上绝对聪明的浏览器背后的聪明人来说,这真是明智之举! :-)

    2013年2月4日 23:27

    1. Robert Nyman [编辑]

      谢谢,很高兴听到这个消息!

      2013年2月5日 00:56

  16. Kontrol

    可以使用数据通道在 Chrome 和 Firefox 之间交换文件吗? 还是只能进行视频聊天?

    2013年2月5日 00:34

    1. Robert Nyman [编辑]

      现在,我斗胆猜测,通过 DataChannel 共享文件的功能还没有完全实现。

      2013年2月5日 00:56

    2. Maire Reavy

      Chrome 很快将按照规范中的定义实现 DataChannels,但 Chrome 中的实现尚不可用。因此,目前互操作性仅限于视频/音频。

      2013年2月5日 12:37

  17. Booderan

    在 Explorer 加入之前,这对我们来说没什么用。

    2013年2月5日 00:47

    1. Robert Nyman [编辑]

      希望他们会加入。目前正在进行大量的标准化工作,我个人希望我们能有一个通用的解决方案。

      2013年2月5日 00:55

    2. Maurizio

      我认为,如今,Chrome 和 Firefox 共同成为最常用的浏览器,人们也越来越精明,“你的浏览器不支持此功能;请使用以下其他浏览器”是一个可接受的选项。如果我们每次都要等 IE,那么每一项新技术都会停滞不前。

      2013年2月5日 01:49

  18. Rob

    再见了,Skype,很高兴认识你。

    感谢 Firefox 和 Chrome 团队!

    2013年2月5日 03:01

    1. Robert Nyman [编辑]

      很高兴你喜欢它,希望你能好好利用它!

      2013年2月5日 04:17

  19. Sourav Chakraborty

    这太棒了!感谢 Mozilla 和 Google 让这一切发生!

    现在,我期待着这个标准真正成为“标准”,Mozilla 和 Google 都能从 API 中去掉“moz”和“webKit”前缀。我相信这一天不会太远!

    2013年2月5日 03:51

    1. Robert Nyman [编辑]

      谢谢!当然,这绝对是我们前进的方向。

      2013年2月5日 04:18

  20. Capi Etheriel

    这就是网络,对吧? 我可以让我最喜欢的网络服务打电话通知我紧急事件吗(例如开会迟到)? 这可以从服务器端调用吗(假设我有一个选项卡打开了正在监听服务)?

    2013年2月5日 04:33

    1. Robert Nyman [编辑]

      我认为将有很多可能性,但我无法确切地说所有这些可能性将如何运作。一般来说,像这样的呼叫是通过 RTCPeerConnection 完成的,所以我认为一般服务无法以这种方式向您推送/拨打电话,而是两个用户之间的直接连接。

      2013年2月5日 05:00

  21. Peeyush Chandel

    热烈祝贺 Mozilla 和 Chrome 团队。

    2013年2月5日 05:08

    1. Robert Nyman [编辑]

      谢谢!

      2013年2月5日 07:18

  22. Sam Dutton

    太棒了!祝贺所有为之付出辛勤工作的人。

    2013年2月5日 05:16

    1. Robert Nyman [编辑]

      谢谢你,Sam,也谢谢你关于 WebRTC 的精彩文章/文档!

      2013年2月5日 07:18

  23. Simon Griffee

    这真是太棒了。期待着有一天在 Firefox OS 上运行它。谢谢 Google 和 Mozilla。

    2013年2月5日 07:18

    1. Robert Nyman [编辑]

      我们也一样。 :-)

      2013年2月5日 07:20

  24. CrazyMan

    嗯……关于这个,我只想说一个词:太棒了!

    然而……啧啧啧……
    这闻起来有点像以下三件事之一
    1. 给 IE 和 Safari 放的一颗很大的烟雾弹
    2. Mozilla 正在努力使自己成为未来 Google(或 Google 资助的)项目的合作伙伴。
    3. Google 大约 5 年的收购计划 :D

    2013年2月5日 07:27

    1. Robert Nyman [编辑]

      谢谢!
      不,我们不打算成为 Google 的一部分,我们只是相信合作和一个良好的互操作的开放网络。 :-)

      2013年2月5日 13:05

  25. christian westman

    很高兴看到两家领先的浏览器公司像这样合作 :)
    继续努力!

    2013年2月5日 07:39

    1. Robert Nyman [编辑]

      谢谢,我个人很高兴看到我们是如何合作的!

      2013年2月5日 13:03

  26. Andrius Kairiukstis

    我是一名 VoIP 开发人员,2013 年将是 WebRTC 年,我们将看到很多新产品和想法……但“Firefox 浏览器呼叫 Chrome 浏览器”这句话仍然令人震惊!:)

    2013年2月5日 07:49

    1. Robert Nyman [编辑]

      我认为这也会是 WebRTC 年!那是好的震惊,对吧? :-)

      2013年2月5日 13:03

  27. Afshin Mehrabani

    巨大的变化,恭喜!我认为这项功能将改变网络研讨会行业。

    2013年2月5日 08:15

    1. Robert Nyman [编辑]

      当然,网络研讨会肯定能够利用这一点来发挥它们的优势。

      2013年2月5日 13:05

  28. Stephan Bardubitzki

    恭喜!这真的很酷。

    如果它也能在 Android 和 Firefox OS 上运行,那么天空就是极限……

    2013年2月5日 10:09

    1. Robert Nyman [编辑]

      谢谢!毫无疑问,这些都是接下来的步骤。

      2013年2月5日 13:06

  29. Martin Zatroch

    非常感谢整个 Mozilla 团队!终于,我一直在等待的正是这个。 不过,我不确定 Google 开发人员将如何处理 GMail 界面内的 VoIP 实现(到目前为止,它仍然需要额外的插件)。

    PS:我迫不及待地想看到一些预装 FirefoxOS 的像样的移动设备出现在斯洛伐克 Telefónica 的区域优惠或其他地方。耶,我多么讨厌封闭的花园。再次感谢大家。 d-_-b m/

    2013年2月5日 12:17

    1. Robert Nyman [编辑]

      很高兴你喜欢它!我不确定 Gmail 的情况,但我认为 WebRTC 肯定会进入他们的产品,这是一个合理的猜测。
      关于 Firefox OS 和斯洛伐克,我真的希望我们能够为你提供!

      2013年2月5日 13:11

  30. Rahul patula

    哎呀。对最新的发展感到非常兴奋。希望在不久的将来看到一些精彩的创新出现

    2013年2月5日 12:53

    1. Robert Nyman [编辑]

      你可能会成为基于此做出精彩创新的人之一。 :-)

      2013年2月5日 13:12

  31. Robert Kaiser

    太棒了!

    也很高兴看到 Firefox 和 Chrome 之间并非恶性竞争,而是真正的友好和开放的竞争(至少从 Mozilla 方面来看,非常开放)。
    注意到这两个人中谁更具商业性,谁更具技术性仍然很有趣(一个提到他们的“Google App Engine”,另一个提到所有支持 WebRTC 的开放技术)…… ;-)

    2013年2月5日 13:38

    1. Robert Nyman [编辑]

      谢谢!
      我同意,我很高兴展示我们的合作以及我们如何共同努力使开放网络变得更好。

      2013年2月5日 13:47

  32. Infinity

    好消息,还有更好的链接! 我正在寻找一些令人兴奋的东西来展示我在这里关于 WebRTC 的演讲 :)
    还有什么我可以展示的吗,Robert? (*演示*)
    太棒了,伙计们! 继续努力!

    2013年2月5日 15:09

    1. Robert Nyman [编辑]

      谢谢!
      我认为帖子中的演示最合适

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

      2013年2月6日 03:16

  33. BUGHUNTER

    谢谢,这可能会引发网络可用性范式的转变。

    请解释一下,你们是如何处理滥用和安全问题的?
    是否集成了任何预防措施来保护用户自身安全?

    我想到很多坏人、垃圾邮件发送者和广告商会如何劫持这个强大的功能来骚扰人们,甚至窃取数据。

    当然,除了“全部禁用”之外,你们肯定已经预想到了几种滥用场景,并基于这些场景在 WebRTC 中构建了一些安全措施——请写一下,谢谢!

    2013年2月6日 03:37

    1. Robert Nyman [编辑]

      确实可能会那样!

      我认为安全问题已在上面的评论中得到了解答,尤其是链接的文档

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

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

      对于用户,他们将会看到一个对话框,可以在其中允许/拒绝访问摄像头和麦克风。

      2013年2月6日 03:57

    2. Sam Dutton

      关于“架构”安全性,请查看http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-security

      (ICE 框架中也有一些固有的安全特性,我在这里就不赘述了。)

      2013年2月6日 04:34

      1. Robert Nyman [编辑]

        谢谢 Sam,这也是一个很好的资源!

        2013年2月6日 07:14

  34. Richard Norburn

    你好,

    对于这项计划,我只能说“哇”,视频会议行业(Polycom、Tandberg、LifeSize)应该感到担忧。你们一夜之间就会淘汰掉他们很大一部分产品套件。点对点很棒,当开源视频桥出现时,他们就完蛋了!!!

    是否包含 H323 互操作性?例如,浏览器可以直接与视频会议单元通话吗?如果是这样,我下个月会在 200 名员工身上进行测试?

    2013年2月6日 04:42

    1. Robert Nyman [编辑]

      目前还不确定这种互操作性。这项工作仍在进行中,我建议你测试演示中的代码,看看它是否能满足你的目的。

      2013年2月6日 07:17

  35. Edgar

    Mozilla,你们太棒了!!!

    2013年2月6日 07:30

    1. Robert Nyman [编辑]

      谢谢,很高兴你这么认为! :-)

      2013年2月7日 02:17

  36. maxw3st

    感谢提供的信息。有很多东西需要查看,但这很令人兴奋。我特别喜欢关于在通话双方之间加密流的评论。我一直想构建一个安全的通信应用程序,看来 WebRTC 就是答案。

    2013年2月6日 15:13

    1. Robert Nyman [编辑]

      很高兴你喜欢它,我们当然希望它会成为你感兴趣的选择!

      2013年2月7日 02:19

  37. Ethan

    太棒了

    2013年2月6日 20:32

    1. Robert Nyman [编辑]

      谢谢 Ethan!

      2013年2月7日 02:16

  38. Hrishi

    我简直不敢相信这会有多惊人……无需 Webex、livemeetings 或任何其他工具,只需你的浏览器……它将会是一个杀手级应用……非常感谢你们。

    2013年2月8日 13:18

    1. Robert Nyman [编辑]

      谢谢,这确实看起来很令人兴奋!

      2013年2月12日 03:31

  39. VPX

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

    你们能把 libvpx 更新到最新版本吗?

    2013年2月8日 14:11

    1. Robert Nyman [编辑]

      你需要在 bug 报告中讨论这个问题,那才是讨论的地方。

      2013年2月12日 03:31

  40. Q

    为什么 Chrome 中的视频是反的?

    2013年2月8日 14:37

    1. Robert Nyman [编辑]

      显示内容的方式选择不同。

      2013年2月12日 03:30

  41. Leon Victor

    我期待着关于这件事的更多消息。很高兴看到 Google 和 Mozilla 领导了新的浏览器技术。这对我们大家都有好处。

    2013年2月11日 01:00

    1. Robert Nyman [编辑]

      谢谢,很高兴你喜欢!

      2013年2月12日 03:23

  42. Vikram Lele

    你好,

    我对这项开发感到非常兴奋。我知道这可能不是提出技术问题的合适地方,但我还是想问——

    如果我的电脑上有两个视频采集设备,是否可以建立两个视频通道?这将为应用程序开发人员带来更多令人兴奋的机会。

    – Vikram

    2013年2月13日 13:50

    1. Robert Nyman [编辑]

      这是个好问题!实际上我不知道——现在我认为它一次只支持一个视频流。

      2013年2月14日 05:44

    2. Maire Reavy

      目前我们每个 PeerConnection 只支持一个视频流,但在我们的路线图中肯定有支持每个 PeerConnection 多个流的计划。在我们支持每个 PeerConnection 多个流之前,你可以使用两个 PeerConnection 来模拟这一点。

      2013年2月27日 07:42

      1. Vikram Lele

        我不知道每个对等连接多个流与多个对等连接的优缺点。

        当一方有一个源而另一方有两个视频流源时,多个对等连接方案是否有效?

        我个人认为使用两个对等连接的解决方案也很好。只要有一种方法可以提示用户为特定目的选择视频流即可。

        2013年2月27日 19:15

  43. john

    如何阻止来自互联网的视频?我将在这方面帮助某人。
    有人有网站或其他什么吗?

    2013年2月26日 10:58

    1. Robert Nyman [编辑]

      只有在你批准的情况下,WebRTC 中的视频才会被共享。

      2013年2月26日 16:48

  44. chenlin zhong

    示例应用程序中有一些错误。我的英语不好。

    2013年3月6日 03:32

    1. Robert Nyman [编辑]

      是什么样的错误?

      2013年3月6日 03:37

  45. Fabian

    你好,Robert,

    我对 webRTC 的开发感到非常兴奋(也有点担心),但与此同时,作为一个简单的 web 程序员,我发现它是一个很难理解的主题。这主要与 ICE/STUN 有关。我找不到关于是否必须将 STUN 服务器作为 PeerConnection 构造函数的参数的信息。在你的示例和其他示例中,我看到该参数被省略或设置为 null。

    我认为 peerConnection 对象会咨询 STUN 服务器,并将从服务器接收到的本地 ICE 候选传递给 onicecandidate,这意味着实际上需要 STUN 服务器来流式传输远程媒体 –>

    根据 HTMLRocks:“网络和媒体信息的获取和交换可以同时进行,但在对等方之间开始音频和视频流传输之前,这两个过程都必须完成。”

    2013年3月15日 11:28

  46. Fabian

    任何对我的问题的答案感兴趣的人,都可以在此处找到答案

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

    2013年3月20日 02:35

    1. Robert Nyman [编辑]

      你好,

      感谢你回来查看,并在此处分享解决方案/答案!

      2013年3月20日 06:07

本文的评论已关闭。