WebRTC onicecandidate :我只用 sdpMid=audio 获得 ICE 候选，但不适用于视频
WebRTC onicecandidate: Am getting ICE candidates with sdpMid=audio only but not for video
使用的浏览器是Chrome...我有调用方和接收方代码来生成 SDP 和 ICE 候选。我得到了调用方代码以使用 sdpMid=video 生成正确的 SDP 和 ICE 候选，但对于接收器，我只为 sdpMid=audio 生成了 ICE 候选项。
更新：以下是更改后接收器的本地会话描述SDP，如建议的那样：
v=0
o=- 7912682607537349212 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:0D1hLEwxnqReQosQ
a=ice-pwd:Nsc4EAtefrfgzTetHjJA5lsg
a=fingerprint:sha-256 6C:85:D8:33:D8:C6:CB:CE:D4:8E:B4:7A:C2:F5:2F:D0:67:04:25:B2:74:F9:C6:3A:2E:96:E6:56:E7:27:B0:F8
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2958641119 cname:Iu8s16HLxglPDg9k
a=ssrc:2958641119 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd bb63739b-cca2-4aa5-90a6-cf4bbaa199af
a=ssrc:2958641119 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
a=ssrc:2958641119 label:bb63739b-cca2-4aa5-90a6-cf4bbaa199af
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:0D1hLEwxnqReQosQ
a=ice-pwd:Nsc4EAtefrfgzTetHjJA5lsg
a=fingerprint:sha-256 6C:85:D8:33:D8:C6:CB:CE:D4:8E:B4:7A:C2:F5:2F:D0:67:04:25:B2:74:F9:C6:3A:2E:96:E6:56:E7:27:B0:F8
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 3143004909 4248148453
a=ssrc:3143004909 cname:Iu8s16HLxglPDg9k
a=ssrc:3143004909 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd 778ef702-e7fc-47ea-bb3a-477e0b4262ba
a=ssrc:3143004909 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
a=ssrc:3143004909 label:778ef702-e7fc-47ea-bb3a-477e0b4262ba
a=ssrc:4248148453 cname:Iu8s16HLxglPDg9k
a=ssrc:4248148453 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd 778ef702-e7fc-47ea-bb3a-477e0b4262ba
a=ssrc:4248148453 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
a=ssrc:4248148453 label:778ef702-e7fc-47ea-bb3a-477e0b4262ba
这是为相应的 getUserMedia 生成的，如下所示：
navigator.getUserMedia({ audio: true, video: { width: 1280, height: 720 } },...
ICE候选生成代码为：
pc.onicecandidate = function (event) {
console.log("Generated Icecandidate:" );
console.log(event);
...
};
在控制台.log上，我看到了 ICE 候选者，如下所示：
RTCIceCandidate
candidate: "candidate:211156821 1 udp 2122260223 192.168.1.5 41811 typ host generation 0 ufrag kV5Snl0LQhJlYujt"
sdpMLineIndex:0
sdpMid:"audio"
不用说，我无法显示远程视频。我正在本地网络上尝试这个，所以实际上甚至不需要 STUN。
我想知道，为什么我没有获得任何 sdpMid=video 的 ICE 候选人。此外，在生成的四个ICE候选者中，三个ICE候选者具有sdpMLineIndex：0并且一个 ICE 候选项的候选属性为 null！
更新1：我得到了上一个问题的答案...候选属性为 Null。"注意：RTCPeerConnection.onicecandidate 将被调用一次，带有一个空的候选属性，以表示涓流 ICE 事件的结束。此处对此进行了解释。
在呼叫者方面，我收到了 10 多个 ICE 候选人，有些带有音频，有些带有视频。
我哪里出错了？
更新 2：这是接收器部分的代码，它不会为视频生成ICE候选。我已经剥离了身份验证和其他部分，只关注相关部分。我删除了 ICE 候选者的缓存并按原样发送：
$(document).ready(function () {
var socket = io.connect();
var pc = new RTCPeerConnection ({
"iceServers": [{"url": "stun:stun.l.google.com:19302"}]
});
pc.onicecandidate = function (event) {
socket.emit('candidateFromReceiver',event.candidate);
console.log("Candidate Generated:");
console.log(event.candidate);
};
pc.onaddstream = function(ev) {
stream = ev.stream;
var video = $('#vid2');
video.attr('src', URL.createObjectURL(stream));
video.onloadedmetadata = function(e) {
video.play();
}
};
socket.on('connect',function() { console.log("Socket connected"); });
socket.on('candidateFromCaller', function (data) {
pc.addIceCandidate(new RTCIceCandidate(data));
});
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia;
if (navigator.getUserMedia) {
navigator.getUserMedia({ audio: true, video: { width: 1280, height: 720 } },
function(stream) {
var video = $('#vid1');
video.attr('src', URL.createObjectURL(stream));
video.onloadedmetadata = function(e) {
video.play();
}
pc.addStream(stream);
},error);
socket.on('sdpOffer', function(data) {
var sdpOffer = new RTCSessionDescription(data.sdpOffer);
pc.setRemoteDescription(sdpOffer, function() {
pc.createAnswer(function(sdpAnswer) {
localSessionDescription = new RTCSessionDescription(sdpAnswer);
pc.setLocalDescription(localSessionDescription, function() {
socket.emit('sdpAnswer',localSessionDescription);
},error);
}, error);
},error);
});
}
function error(err) {
console.log("ERROR!!!!");
console.log(err);
}
}); // End of document.ready function
如果我在获取用户媒体后插入代码以生成报价（如我在呼叫者代码中所做的那样），则生成的 ICE 候选项也包括视频候选者。当然，正如预期的那样，这只是为了测试之后的其余代码炸弹。
（从评论中听起来您正在缓存 ICE 候选项。别这样。我也怀疑时间问题可能是一些候选人落选的原因。
涓流ICE的全部意义在于涓滴候选人，也就是说，一旦候选人可用，就立即发送候选人。
使用 WebRTC，您的应用程序负责在对等方之间发出信号，这是对时间敏感的。所以：
- 不迟于
setLocalDescription成功回调发送pc.localDescription。 - 期望
pc.onicecandidate在该回调后立即开始触发。发送它们。
双方都是如此（提供和回答）。您想在电线上看到的是：
offer, candidate, candidate, candidate
另一种方式：
answer, candidate, candidate, candidate
不该做什么：
- 不要缓存 ICE 候选项。
- 不要等到你得到答案，那只会浪费时间。
- 当接收端出于任何原因收到报价时，不要延迟致电
setRemoteDescription，否则它将无法准备好接收候选人。
更新 2：
您的 sdp 说 a=recvonly 而不是 a=sendrecv ，这意味着接收者只能接收，而不发送任何回报。以下两种情况之一可能导致此问题：
- 调用方设置创建提供选项，如
offerToReceiveVideo:false和/或offerToReceiveAudio:false。 - 接收方没有及时呼叫
pc.addStream（之前）pc.setLocalDescription。
如果getUserMedia和收到报价之间存在竞争，则可能会发生第二种情况。
更新 3：
如果所有其他方法都失败了，请与工作代码进行比较。我之前在其他答案中分享过一个交叉表演示，但它只发送了视频，没有收到任何视频。
这是该演示的修改版本，它仅从远程摄像机接收视频。像往常一样，在同一浏览器中的两个选项卡中打开它。
请注意，在Firefox中，点击后 Call ，您必须物理聚焦另一个选项卡，然后它才能允许访问相机。
你正在处理的东西叫做捆绑。要约人和应答者同意将所有 ICE 传输捆绑到单个 ICE 传输中。因此，对于第一个 m 部分，您只能获得一个 ICE 候选者。
提供方仍然为您提供所有这些视频 m 部分的 ICE 候选者，因为它不知道回答者是否会同意使用捆绑包。
正如AlexD在他的回答中指出的那样，您可以通过"捆绑政策"在提供者方面影响这种行为。例如，"maxBundle"作为策略将导致提供者假设应答者将理解捆绑，因此仅为单个传输创建ICE候选者。
但是，只要提供者提供捆绑包，如果它支持它，回答者就会使用它。
我能够通过设置来解决这个问题：
rtcConfiguration.bundlePolicy = "max-compat"
参见：http://w3c.github.io/webrtc-pc/#dom-rtcbundlepolicy-max-compat
- WebRTC onicecandidate :我只用 sdpMid=audio 获得 ICE 候选，但不适用于视频
- WebRTC:确定选定的ICE候选者
- 为什么我的冰候选请求触发了 6 次而不是 1 次
- 我不能't使用srvflx候选者在同一局域网中的两个客户端之间建立ice连接
- 单向流媒体-ICE连接在添加候选者之前失败
- 正在获取ice候选项收集的超时问题
- SyntaxError在WebRTC中发送远程ice候选者
- 无法添加ICE候选人
- 是否可以使用ICE直接连接，然后在WebRTC中直接进行点对点信令?
- EasyRTC只能在同一局域网内工作(ICE失败)
- keyXXX上的Javascript事件在icefaces 1.8.2 ice上不起作用:selectionputext
- 无法在webrtc中添加远程ice候选者
- 如何开始收集ICE候选人进行对等连接
- WebRTC Ice State = "failed"黑色的视频
- WebRTC候选信息末尾的数据是什么?
