我知道adapter.js，它试图：
使应用程序免受规格更改和前缀差异的影响。
但是adpater.js仅涵盖非常基本的WebRTC API。我仅setRemoteDescription作为一个例子。
在2013年，它的名称如下：
pc.setRemoteDescription(offer);
根据https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection，当前的API是？
pc.setRemoteDescription(new RTCSessionDescription(offer), function() {
pc.createAnswer(function(answer) {
pc.setLocalDescription(new RTCSessionDescription(answer), function() {
// send the answer to a server to be forwarded back to the caller (you)
}, error);
}, error);
}, error);
我目前正在阅读2015年的一篇文章，该文章似乎是：
pc2.setRemoteDescription(pc1_offer).then(step3, failed);
编辑
http://www.w3.org/TR/webrtc/已经不远了，但我宁愿找一些地方Firefox的和Chrome的API的目前的执行情况可以遵循（是过会，是如果是有道理的）。
WebRTC仍在开发中，因此，目前没有比规范更好的资源，并且随时了解其更改的最佳位置是：http : //w3c.github.io/webrtc-pc
当涉及到各个浏览器以及实现的方式时，它会变得更加困难。只需看一下：http : //iswebrtcreadyyet.com
您在问题中观察到的主要API差异是2014年对promise的支持。现在，所有异步方法都返回Promise，而不是执行一对成功和失败回调。Chrome尚未实现此功能，但Firefox已实现。
以下是可在Firefox中运行的完整WebRTC调用（注意：使用箭头功能）：
var pc1 = new mozRTCPeerConnection(), pc2 = new mozRTCPeerConnection();
pc1.onicecandidate = e => !e.candidate ||
pc2.addIceCandidate(e.candidate).catch(failed);
pc2.onicecandidate = e => !e.candidate ||
pc1.addIceCandidate(e.candidate).catch(failed);
pc2.onaddstream = e => v2.mozSrcObject = e.stream;
function start() {
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
.then(stream => pc1.addStream(v1.mozSrcObject = stream))
.then(() => pc1.createOffer())
.then(offer => pc1.setLocalDescription(offer))
.then(() => pc2.setRemoteDescription(pc1.localDescription))
.then(() => pc2.createAnswer())
.then(answer => pc2.setLocalDescription(answer))
.then(() => pc1.setRemoteDescription(pc2.localDescription))
.then(() => log("Connected!"))
.catch(failed);
}
var log = msg => div.innerHTML += "<p>" + msg + "</p>";
var failed = e => log(e.name +": "+ e.message +" line "+ e.lineNumber);<video id="v1" height="120" width="160" autoplay></video>
<video id="v2" height="120" width="160" autoplay></video><br>
<button onclick="start()">Start!</button><div id="div"></div>那是20行代码，比您可能看到的其他版本小很多。
如果它看起来很神秘，请不要失望，因为Promise和箭头函数是新概念，需要一点时间来适应，特别是在像这样组合使用时。我建议使用上面的链接单独阅读它们。
旧的回调版本仍可用于所有RTCPeerConnection方法，因此使用promises是可选的。Chrome在浏览器中支持promises（仅不用于WebRTC），但是还没有箭头功能，因此可能需要一段时间才能实现上述功能。
除了这种差异，Chrome和Firefox在进行高级呼叫设置甚至重新协商时都非常稳定。规范中仍在更改的区域与新的较低级别的控制表面（如RTCRtpSender）有关，以及从指定流到指定轨道（用addTrack代替addStream等）的重新聚焦。
不幸的是，我知道没有专门针对浏览器的文档链接。正如您指出的那样，MDN链接已过时（尽管getUserMedia的MDN链接是最近更新的，所以希望它会改变）。我发现查看工作的演示和示例仍然是找出不同浏览器支持的功能的最有用方法。
我知道一些区别：
{ offerOptions: true }使用例如较旧的版本{ mandatory: OfferOptions: true }（请注意区分大小写的“ o”与“ O”），因为这在两种浏览器中均有效。addStream(stream)现在（尽管Firefox尚未实现，removeStream所以请removeTrack在此处使用）。由于前缀和其他差异，您仍然需要adapter.js，但是有更多并且可以这样做。希望它的更新版本可以通过为上述某些差异提供一个polyfill来进一步缩小这一差距。
我对Firefox的了解比对Chrome的了解要好，所以如果我错过了一些东西，我深表歉意。
我希望其中一些帮助。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句