为了使问题尽可能简单,我在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中不起作用。以下是chrome:// webrtc-internals中的一些选定数据:
连接到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,尽管我看不到任何异常。如果我在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);
从Firefox到Chrome,反之亦然,效果很好,因此问题可能是特定于Chrome扩展程序的...
成功案例和扩展案例之间的集冰方式有所不同:
null
。 onicecandidate
事件。他们并不完全同意。那么,chrome扩展程序可能会使STUN服务器感到困惑吗?我不知道。 感谢您的回答,希望您有更多的见解。
最佳答案
可以在双方增加可处理的冰块吗?pc.onicecandidate = function(e){ send('ice_candidate', e.target) }
另一方面,在收到此“消息”时,pc.addIceCandidate(new RTCIceCandidate(message));
即使在交换了报价/答案后,Chrome仍会发送候选冰,而Firefox似乎没有这样做。