почему не работает onicecandidate?

У меня проблемы с пониманием webRTC с его PeerConnection и событием onicecandidate.

Насколько я понимаю, вы должны инициировать одноранговое соединение с помощью сервера STUN (или TURN), потому что он отправит вам вашего кандидата ICE для связи с другим узлом.

Я видел примеры, в которых параметр сервера объекта PeerConnection не включался, чего я тоже не понимаю, но скажем так, параметр сервера действительно нужен.

Итак, когда я записываю следующий код:

    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);
}

Я ожидаю, что событие 'onicecandidate' сработает, но оно не работает. Я пробовал и другие общедоступные STUN-серверы, но ничего не происходит. Так что я предполагаю, что, вероятно, что-то не так с моим пониманием :)


javascript webrtc stun
person Fab    schedule 18.03.2013    source источник
comment
Я не совсем уверен, почему я пишу это как комментарий, но я думаю, что вам нужно запустить pc.createOffer, когда обработчики событий настроены для фактического создания кандидата.   -  person Andreas Hultgren    schedule 19.03.2013
comment
Андреас, спасибо, обязательно попробую. Прочитав руководство «Начало работы с WebRTC» на htmlRocks, я пришел к выводу, что сбор ICE-кандидатов и информации SDP является независимым и обязательным процессом для получения удаленного потока, но вы можете быть правы.   -  person Fab    schedule 19.03.2013
comment
Возможный дубликат WebRTC никогда не запускает onIceCandidate   -  person Qix - MONICA WAS MISTREATED    schedule 15.06.2017

Ответы (1)


arrow_upward
35
arrow_downward

PeerConnection не начнет собирать кандидатов, пока вы не вызовете setLocalDescription(); информация, предоставляемая setLocalDescription, сообщает PeerConnection, сколько кандидатов необходимо собрать. (Это поведение для setLocalDescription указано в его определении по адресу http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.4)

Вот как выглядит полный поток для установления соединения между двумя 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');
}

Поскольку вы включили в свой вопрос mozPeerConnection, я отмечу, что Firefox в настоящее время не генерирует «кандидатов на утечку». Это означает, что он будет включать свои адреса-кандидаты как строки 'c' в предложении/ответе, а обратный вызов onicecandidate никогда не будет вызываться.

Недостатком этого подхода является то, что Firefox должен ждать, пока все его кандидаты будут собраны, прежде чем создавать свое предложение/ответ (процесс, который может включать в себя обращение к серверам STUN и TURN и ожидание либо ответов, либо истечения времени ожидания запросов).

person bstrong    schedule 19.03.2013
comment
Спасибо за ваше объяснение! Теперь это начинает иметь больше смысла. - person Fab; 19.03.2013
comment
Это по-прежнему не вызывает onicecandidate. - person kennysong; 09.06.2015
comment
Для меня тоже. Может быть из-за того, что оба канала находятся на одной стороне? - person zim32; 15.12.2015
comment
См. этот ответ, чтобы заставить ледяных кандидатов работать. Методология в этом ответе верна, но аргументы createOffer() изменились (уже несколько раз). - person Qix - MONICA WAS MISTREATED; 15.06.2017