WebRTC 永远不会在 IceCandidate 上触发

我开始使用 WebRTC 进行开发，但那东西从来没有给我提供 ICE 候选人。我设置了一切，我正在交换描述和东西，我还在那里缩小了一个超级丑陋的功能，以确保一切都正确运行，一个接一个。两者的信令状态都是稳定的，onError从未被触发（如预期），但 onIceCandidate 也被触发（不按预期），并且当我想发送随机的空 MediaStream 对象时pc1.addStream(new webkitMediaStream());，它总是会触发需要谈判.

有谁知道我的代码到底有什么问题吗？我花了几个小时浏览 Stack Overflow、HTML5 Rocks 和 W3C 文档，但我不明白。这是我的整个代码：

var config={
  'iceServers':[{
    'url':'stun:stun.l.google.com:19302'
  },{
    'url':'stun:stun1.l.google.com:19302'
  },{
    'url':'stun:stun2.l.google.com:19302'
  },{
    'url':'stun:stun3.l.google.com:19302'
  },{
    'url':'stun:stun4.l.google.com:19302'
  }]
};
var pc1=new webkitRTCPeerConnection(config);
var pc2=new webkitRTCPeerConnection(config);

var onError=function(error)
{
  console.error(error);
}

pc1.onicecandidate=function()
{
  console.log('PC1 onIceCandidate (finally) fired!');
}
pc2.onicecandidate=function()
{
  console.log('PC2 onIceCandidate (finally) fired!');
}

pc1.oniceconnectionstatechange=function()
{
  console.log('PC1 oniceconnectionstatechange fired!');
}
pc2.oniceconnectionstatechange=function()
{
  console.log('PC2 oniceconnectionstatechange fired!');
}
pc1.onnegotiationneeded=function()
{
  console.log('PC1 onnegotiationneeded fired!');
}
pc2.onnegotiationneeded=function()
{
  console.log('PC2 onnegotiationneeded fired!');
}

pc1.createOffer(function(offer){
  pc1.setLocalDescription(offer,function(){
    pc2.setRemoteDescription(new RTCSessionDescription(offer),function(){
      pc2.createAnswer(function(answer){
        pc2.setLocalDescription(answer,function(){
          pc1.setRemoteDescription(new RTCSessionDescription(answer),new Function()/*I don't need you, bro*/,onError);
        },onError);
      },onError);
    },onError);
  },onError);
},onError);

顺便说一句，我正在使用 Google Chrome 进行开发。我会确保它也能在 Firefox 中运行，但现在问题应该是跨浏览器。我想先进入数据通道...（但我并不反对使用 Firefox 或跨浏览器代码的工作解决方案）

在 Chrome 38 及更早版本中，OfferToReceiveAudio默认为true。从 Chrome 39 开始，OfferToReceiveAudio默认为 false，正如 WebRTC 工程师在PSA：对 PeerConnection.createOffer 约束 OfferToReceiveAudio 的行为更改（下面引用）。
由于此更改，SDP 返回createOffer不包含任何媒体，因此 ICE 收集过程永远不会启动。您可以通过观察从未触发 ICE 事件以及 PeerConnection 的情况来注意到此更改的后果iceGatheringState and iceConnectionState保持“新”。

为了确保 ICE 收集开始并完成，您必须将媒体添加到您的报价中，例如通过设置OfferToReceiveAudio:true在以下对您的报价的限制中（作为参数PeerConnection构造函数，或作为参数peerConnection.createOffer方法）：

{
    mandatory: {
        OfferToReceiveAudio: true
    }
}

（在 SDP 中获取媒体的其他方法包括设置OfferToReceiveVideo:true，或致电peerConnection.addStream使用您从中获得的媒体流getUserMedia)

webrtc-讨论：PSA：对 PeerConnection.createOffer 约束 OfferToReceiveAudio 的行为更改:

我将提交更改（https://webrtc-codereview.appspot.com/16309004/) 更改 RTCPeerConnection.createOffer 的行为。 该更改预计将包含在 Chrome M39 中。

改变了什么：

目前，如果在 PeerConnection.createOffer 中未指定 OfferToReceiveAudio 约束，则即使没有附加到 PeerConnection 的音轨，生成的 Offer SDP 也将具有“m=audio”行。换句话说，OfferToReceiveAudio 默认为 true。

更改后，OfferToReceiveAudio 不再默认为 true。报价 SDP 是否具有“m=audio”行取决于是否有任何音轨已附加到 PeerConnection。

没有改变的是：

为 OfferToReceiveAudio 设置显式值的行为保持不变，即 OfferToReceiveAudio:true 将导致“m=audio”行，无论音轨是否存在； OfferToReceiveAudio:false 将导致没有“m=audio”行，无论是否存在音轨，除非已使用包含“m=audio”行的 SDP 调用 setLocalDescription，在这种情况下，新的 Offer SDP 将标记音频内容不活动而不是删除音频内容。