Как встроить IceCandidates в SDP?

Question

Механизм сигнализации, который мы реализовали, требует отправки icecandidates в самом sdp.
Вы не знаете, как встроить icecandidates в sdp?
Кроме того, если icecandidates встроены в sdp, то как PeerConnection начнет соединение p-2-p?
Или может ли PeerConnection инициировать соединение p2p сразу после установки удаленного sdp или что-то еще?

Кроме того, можете ли вы предложить что-то о том, как мы можем использовать webrtc для видеосвязи между двумя устройствами в одной сети Wi-Fi (без использования STUN/TURN)?
Я пробовал настроить iceservers на null, но тогда приложение не работает!
Я собрал сгенерированный файл sdp для обоих устройств из журналов.
У меня есть кандидаты на лед, сгенерированные для обоих. Я объединил sdp и icecandidates в один sdp. С этим я установил iceservers для RTCConfiguration как NULL. Но теперь приложение не работает!

Что я хочу знать, так это то, что если у нас есть встроенный SDP с icecandidates, как мы можем инициировать соединение p2p? Является ли соединение p2p инициированным, когда Remote IceCandidate установлен или RemoteDescription установлен?

Спасибо!

Answer 1

Кандидаты ICE включены в предложение/ответ SDP. Поэтому просто подождите, пока процесс сбора ICE будет завершен, а затем отправьте предложение/ответ SDP.

Я не уверен, что вы можете использовать WebRTC без сервера STUN/TURN, но вы можете использовать свой или публичный. Кажется, что в локальной среде все отлично работает без сервера STUN/TURN - просто передайте пустой массив на iceServers.

И для последнего вопроса - это зависит. Если реализовано TrickleICE (а в Chrome и Firefox) соединение инициируется, когда найден первый хороший кандидат ICE. И вы можете установить описание до этого. В противном случае вам нужно дождаться завершения процесса ICE gathering, а затем отправить предложение/ответ и установить его на другом уровне как удаленное описание. Затем соединение будет инициировано.

Answer 2

Я не мог вписать это в комментарий, поэтому я собираюсь опубликовать его в качестве ответа.

Мы проводим локальный тест WebRTC довольно часто, при этом не настроены серверы STUN/TURN, и он работает нормально. Это просто ограничит вашу способность подключаться через NAT-брандмауэры. Не могу пообещать, что он соединится в вашей среде, но он не должен падать. Имейте все же, чтобы попробовать это с Android, поэтому никаких комментариев нет.

Что касается отключения Trickle ICE, мы столкнулись с некоторыми проблемами с этим (главным образом, в Chrome). В основном вы должны ждать, пока не получите кандидата NULL ICE, прежде чем отправлять ПРЕДЛОЖЕНИЕ или ОТВЕТ. Вот как движок WebRTC сообщает программе, что процесс сбора ICE завершен. Когда мы настраиваем использование серверов Google STUN/TURN, существует длинная задержка (> 10 секунд) между тем, когда происходит последнее жизнеспособное событие-кандидат, и происходит событие NULL-кандидата. Я также видел случаи, когда событие кандидата NULL никогда не принималось, а звонок просто время.

Наш план состоит в том, чтобы добавить таймер, чтобы вырваться из процесса сбора ICE через несколько секунд, когда Trickle ICE отключен. Я еще не пробовал, но я не вижу причин, почему это не будет работать и должно быть гораздо более полезным. По моему опыту, все кандидаты собраны в течение первых секунд или двух.