为了使问题尽可能简单,我在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扩展程序的...
成功案例和扩展案例之间的集冰方式有所不同:
  • 在浏览器之间,根本没有冰。有一个事件,e.candidate是null
  • 从扩展程序到浏览器,都有许多onicecandidate事件。他们并不完全同意。那么,chrome扩展程序可能会使STUN服务器感到困惑吗?我不知道。

  • 感谢您的回答,希望您有更多的见解。

    最佳答案

    可以在双方增加可处理的冰块吗?
    pc.onicecandidate = function(e){ send('ice_candidate', e.target) }
    另一方面,在收到此“消息”时,
    pc.addIceCandidate(new RTCIceCandidate(message));
    即使在交换了报价/答案后,Chrome仍会发送候选冰,而Firefox似乎没有这样做。

    07-24 09:50
    查看更多