javascript 为什么“onicecandidate”不起作用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/15484729/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
why doesn't "onicecandidate" work?
提问by Fab
I'm having trouble understanding webRTC with it's PeerConnection and 'onicecandidate' event.
我无法通过 PeerConnection 和“oniceccandidate”事件理解 webRTC。
As far as I understand it you mustinitiate a peerconnection using a STUN (or TURN) server, because it will send you back your ICE candidate for communication with another peer.
据我了解，您必须使用 STUN（或 TURN）服务器启动对等连接，因为它会将您发送回 ICE 候选对象，以便与另一个对等端进行通信。
I've seen examples leaving the server parameter of the PeerConnection object out, which I don't understand as well, but let's just say it does need the server parameter.
我已经看到一些示例将 PeerConnection 对象的服务器参数保留在外面，我也不明白，但我们只是说它确实需要服务器参数。
So, when I write down the following code:
所以，当我写下以下代码时：
var pc, ice = { "iceServers": [{ "url": "stun:stun.l.google.com:19302" }] };
if(typeof mozRTCPeerConnection === 'function') {
pc = new mozRTCPeerConnection(ice);
}
else {
console.log('google');
pc = new webkitRTCPeerConnection(ice);
}
pc.onicecandidate = function(event) {
console.log(event);
}
I expect that the 'onicecandidate' event will fire, but it doesn't work. I tried other public STUN servers as well, but nothing happens. So I assume there is probably something wrong with my comprehension :)
我希望 'onicecandidate' 事件会触发，但它不起作用。我也尝试过其他公共 STUN 服务器，但没有任何反应。所以我认为我的理解可能有问题:)
回答by bstrong
The PeerConnection won't start gathering candidates until you call setLocalDescription(); the information supplied to setLocalDescription tells PeerConnection how many candidates need to be gathered. (This behavior for setLocalDescription is indicated in its definition at http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.4)
在您调用 setLocalDescription() 之前，PeerConnection 不会开始收集候选对象；提供给 setLocalDescription 的信息告诉 PeerConnection 需要收集多少候选者。（ setLocalDescription 的这种行为在http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.4 的定义中指明）
Here's what a complete flow looks like for establishing a connection between two PeerConnections in the same browser window (adding of MediaStreams omitted to focus on the signaling):
这是在同一浏览器窗口中在两个 PeerConnections 之间建立连接的完整流程的样子（省略了 MediaStreams 的添加以专注于信令）：
var pc1, pc2, offer, answer;
pc1 = new webkitRTCPeerConnection(options);
pc2 = new webkitRTCPeerConnection(options);
pc1.onicecandidate = function(candidate) {
pc2.addIceCandidate(candidate);
};
pc2.onicecandidate = function(candidate) {
pc1.addIceCandidate(candidate);
};
pc1.createOffer(onOfferCreated, onError);
function onError(err) {
window.alert(err.message);
}
function onOfferCreated(description) {
offer = description;
pc1.setLocalDescription(offer, onPc1LocalDescriptionSet, onError);
}
function onPc1LocalDescriptionSet() {
// after this function returns, pc1 will start firing icecandidate events
pc2.setRemoteDescription(offer, onPc2RemoteDescriptionSet, onError);
}
function onPc2RemoteDescriptionSet() {
pc2.createAnswer(onAnswerCreated, onError);
}
function onAnswerCreated(description) {
answer = description;
pc2.setLocalDescription(answer, onPc2LocalDescriptionSet, onError);
}
function onPc2LocalDescriptionSet() {
// after this function returns, you'll start getting icecandidate events on pc2
pc1.setRemoteDescription(answer, onPc1RemoteDescriptionSet, onError);
}
function onPc1RemoteDescriptionSet() {
window.alert('Yay, we finished signaling offers and answers');
}
Since you included a mozPeerConnection in your question, I'll note that Firefox does not currently generate 'trickle candidates'. This means that it will include its candidate addresses as 'c' lines in the offer/answer, and the onicecandidate callback will never be called.
由于您在问题中包含了 mozPeerConnection，我会注意到 Firefox 目前不会生成“涓流候选”。这意味着它将在报价/答案中将其候选地址作为“c”行包含在内，并且永远不会调用 onicecandidate 回调。
The downside to this approach is that Firefox must wait for all of its candidates to be gathered before creating its offer/answer (a process which can involve contacting STUN and TURN servers and waiting for either the responses or for the requests timeout).
这种方法的缺点是 Firefox 在创建它的提议/答案之前必须等待它的所有候选者被收集（这个过程可能涉及联系 STUN 和 TURN 服务器并等待响应或请求超时）。
