WebRTC HowTo PeerConnection через локальную сеть с 2 браузерами
Так как несколько дней я пытаюсь построить базовый веб-видеочат. У меня есть демки, работающие локально, даже через локальную сеть. Но теперь я хочу создать один за другим по-настоящему без особых перегрузок, которые есть в некоторых демках.
Но я все еще не получаю полное одноранговое соединение.
Например. этот пример, кажется, не работает, потому что я не могу "createSignalingChannel();" w3.org/TR/webrtc/#simple-example
Некоторые другие примеры ( https://webrtc-experiment.appspot.com/) хотят, чтобы я связывал их сценарии, но я не буду этого делать, потому что я хочу понять магию соединения между равноправными узлами и как получить рукопожатие между двумя браузерами,
Я также исследовал примеры с Google App Engine, но это не то, что я хочу.
Я хочу запустить его в действительно простом JS и HTML, как минимум по мере необходимости.
Вот мой код: https://github.com/mexx91/basicVideoRTC EDIT: должно работать сейчас
Так что я должен добавить, чтобы получить рукопожатие и одноранговое соединение, чтобы я мог отправить, например. MediaStream для друг друга.
Большое спасибо!
2 ответа
createSignalingChannel() Это только псевдокод, чтобы проиллюстрировать существование отдельного канала. Вам нужно для первоначального подключения обрабатывать отдельный канал сообщений.
Этого можно добиться с помощью размещенных сервисов, таких как Pusher, Brightcontext или PubNub, или вы можете разместить свой собственный бэкэнд с проектами с открытым исходным кодом, такими как socket.io или SignalR.
Тогда вам просто нужно отправить предложения, ответы и iceCandidates через ваш отдельный канал.
Список услуг в реальном времени: http://www.leggetter.co.uk/real-time-web-technologies-guide
Представьте себе веб-приложение для видеоконференций, к которому пользователи A и B изначально обращаются с какого-либо веб-сервера. Предположим, что веб-приложение поддерживает присутствие, поэтому веб-сервер знает, кто в данный момент онлайн. Представьте себе, что пользовательский интерфейс позволяет A попытаться выполнить видеозвонок на B. С помощью, скажем, XMLHttpRequest(), браузер A сообщает серверу, что это нужно, и javascript B выдает что-то, говорящее, что A хочет вызвать B. Нет WebRTC вообще не произошло еще. Но на этом этапе A может косвенно связаться с B, отправляя сообщения, используя, например, XMLHttpeRequest. На языке WebRTC это "канал сигнализации". Таким образом, A и B могут взаимодействовать со своими агентами ICE для обнаружения адресов-кандидатов и описаний SDP и отправлять их каждому другому через сервер по этому сигнальному каналу. Например, веб-приложение на А вызывает API WebRTC для получения своих кандидатов в ICE и упаковывает их по своему усмотрению, чтобы отправить их читателю Б. Читатель Б получает это сообщение с сервера (например, через WebSocket или длинный опрос) и проверяет его. может распаковать его и отформатировать по мере необходимости для отправки агенту ICE на B, используя объект RTCPeerConnection. Аналогично, предложение / ответ SDP можно отправлять между двумя приложениями и передавать в агону ICE в браузерах для получения согласованных форматов мультимедиа и т. Д. На этом этапе подключения к медиафайлам могут устанавливаться браузером (добавляются потоки meida). к RTCPeerConnection изначально (которые не обмениваются данными, но у которых есть атрибуты, которые можно запрашивать для описания кодека и т. д., и когда API запрашивают создание описания SDP, он делает это с использованием этих атрибутов, но настраивает IP-адрес и порт, основанный на том, как агент ICE в каждом локальном браузере выяснил, какие адреса могут достигать этот локальный браузер / порт (обход NAT).