RTCPeerConnection媒体流在firefox工作，但不是镀铬

Question

试图保持这个问题尽可能的简单，我创建了以下这样一个Chrome扩展媒体流：

var pc = new RTCPeerConnection(null); 
chrome.desktopCapture.chooseDesktopMedia(['screen', 'window'], null, function(streamId) { 
    var constraints = { 
     audio: false, 
     video: { 
      mandatory: { 
       chromeMediaSource: 'desktop', 
       chromeMediaSourceId: streamId 
      } 
     } 
    }, 
    success = function(stream) { 
     pc.addStream(stream); 
     pc.createOffer(function(offer) { 
      pc.setLocalDescription(offer, function() { 
       send('make_offer', name, offer); 
      }, printError); 
     }, printError); 
    }; 
    getUserMedia(constraints, success, printError); 
}); 

现在，我的报价是收到一个同伴在浏览器中访问一个页面。这看起来或多或少像这样的（m是与提供的消息对象）：

var pc = new RTCPeerConnection(null); 
pc.onaddstream = function(e) { 
    var video = document.getElementById('video'); 
    video.src = URL.createObjectURL(e.stream); 
}; 
pc.setRemoteDescription(new RTCSessionDescription(m.value), function() { 
    pc.createAnswer(function(answer) { 
     pc.setLocalDescription(answer, function() { 
      send('make_answer', m.from, answer); 
     }, printError); 
    }, printError); 
}, printError); 

我已经有和无冰的服务器，这看起来像这样做到了这一点，无论是当我使用它们：

var iceServers = { 
    iceServers: [ 
     {url: 'stun:stun.l.google.com:19302'} 
    ] 
}; 

现在，对等体在Firefox中完美地接收和显示流。没有问题。但它不适用于Chrome。下面是一些铬选择的数据：//的WebRTC-内部： 连接到Firefox：

"ssrc_3309930214_send-transportId": { 
"startTime": "2014-09-30T01:41:11.525Z", 
"endTime": "2014-09-30T01:41:21.606Z", 
"values": "[\"Channel-video-1\",\"Channel-video-1\",\"Channel-video-1\"]" 
}, 
"ssrc_3309930214_send-packetsLost": { 
"startTime": "2014-09-30T01:41:11.525Z", 
"endTime": "2014-09-30T01:41:21.606Z", 
"values": "[0,0,0,0,0,0,0]" 
}, 

连接到Chrome浏览器：

"ssrc_1684026093_send-transportId": { 
"startTime": "2014-09-30T01:41:57.310Z", 
"endTime": "2014-09-30T01:42:00.313Z", 
"values": "[\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\"]" 
}, 
"ssrc_1684026093_send-packetsLost": { 
"startTime": "2014-09-30T01:41:57.310Z", 
"endTime": "2014-09-30T01:42:00.313Z", 
"values": "[-1,-1,-1,-1]" // what is causing this?? 
}, 

那些看似重要，但我不知道确切的影响。我有更多的数据，但我不确定究竟什么是重要的。主要的想法是，数据发送到Firefox，但不是铬，虽然没有例外发生，我可以看到。在一个进一步的可疑数据块发生，如果我加载页面同行在Chrome Canary版（最新）：

Failed to load resource: net::ERR_CACHE_MISS 

这是一个控制台的错误，我不知道它从何而来。它在答复从对等体发送回主机（chrome扩展）后发生。

通过wss：//完成信令，测试对等服务器托管在https：// 我不知道该从哪里开始。

更新：基于答案和评论，我添加了onicecandidate处理程序：

pc.onicecandidate = function(e) { 
    console.log('This is the ice candidate.'); 
    console.log(e); 
    if(!e.candidate) return console.warn('no candidate!'); 
    send('got_ice_candidate', name, e.candidate); 
}; 

我还使用视频设置了从浏览器到浏览器等效等连接：

var constraints = { 
    audio: false, 
    video: true 
}; 
getUserMedia(constraints, success, printError); 

该作品很好，从火狐到Chrome和反之亦然，所以问题可能是铬扩展特定... 成功案例和扩展案例之间如何收集冰是有区别的：

• 在浏览器之间，根本没有冰。有一个事件，eCandidate是null。
• 从扩展到浏览器，有很多onicecandidate事件。他们并不完全一致。所以也许铬扩展是令人困惑的STUN服务器？我不知道。

感谢您的回答，希望对您有更多的了解。

Answer 1

你能否在两边加上处理冰候选人？

pc.onicecandidate = function(e){ send('ice_candidate', e.target) }

和关于接收到这个“消息”对方做

pc.addIceCandidate(new RTCIceCandidate(message));

Chrome会将即使要约/应答进行了交流冰候选其火狐似乎并没有这样做。