Comments 16
Справедливости ради, во Flash был P2P с помощью RTMFP :) но теперь это уже не так важно
Более того, уже в 2008 был Adobe Cirrus (https://labs.adobe.com/technologies/cirrus/) — сервер, располагающийся у Adobe и выполняющий роль «соединителя» между звонящими друг другу ноутбуками из статьи. Нужно было всего лишь подключиться к Cirrus со своими ID и ключом (аналог ключа разработчика Google Play, только бесплатно), и можно начинать P2P-соединения.
патчит SDP-пакеты
А можно об этом поподробней? Что имеется ввиду под словом «патчим», вы же формируете SDP-пакеты, разве нет? Или вы используете какой-то особый формат или особые параметры?
Формирует WebRTC в браузере. И делает это не всегда правильно. Чтобы все работало кроссплатформенно между Chrome-Firefox-Safari-Edge нужно в этих пакетах еще ручками копаться, увы. Но это тема для отдлеьной хабрастатьи :)
А можете ткнуть пальцем где почитать? Как раз P2P assisted streaming сделали на RTCDataChannel (привет Edge), а Firefox c Safari не коннектится…
У нас несколько инженеров это все вручную изучает :( В Edge, если что, нет DataChannel :) Если не коннектиться, то в первую очередь надо идти в «webrtc-internals» и смотреть что проиходит на уровне offer, answer и кандидатов. Если непонятно — подписаться на все эвенты (там есть эвенты «ошибка» и так далее) и смотреть что WebRTC говорит по поводу подключения.
Про WebRTC информации очень много, но она рассчитана или на тех, кто с ним еще не работал, или очень мутная. Спасают только примеры от Google и исходники.
Из статьи можно понять, что для работы вам понадобиться два сервера (сигнальный + TURN). На этом полезная информация заканчивается… Протокол обмена offer, answer и candidates описаны в туториалах довольно подробно.
При этом не освященных нюансов очень много.
Например сложно найти информацию о том, что можно во время установленного соединения сгенерировать еще один offer для других MediaDevices и все будет ок. Или о том, что WebRTC под native iOS (еще не проверял на других платформах) позволяет создать виртуальную камеру и перенаправлять в нее потоки от задней и фронтальной без каких-либо проблем.
Жестко не хватает good practice по работе с WebRTC. Мы например пришли к StateMachine как на сервере, так и на клиентах. Она нас спасла от кучи проблем с коллизиями при встречных звонках.
Я последний год очень плотно работаю с WebRTC под iOS и если есть вопросы, то могу помочь. Было бы круто, если кто-то сможет поделиться инфой по вопросам:
1. Как быстро восстановить соединения при смене сети пользователем? Например телефон перешел из WiFi в сотовую сеть.
2. Как подружить RTCAudioSession, AVAudioSession и CallKit для воспроизведения сигнальных звуков.
Из статьи можно понять, что для работы вам понадобиться два сервера (сигнальный + TURN). На этом полезная информация заканчивается… Протокол обмена offer, answer и candidates описаны в туториалах довольно подробно.
При этом не освященных нюансов очень много.
Например сложно найти информацию о том, что можно во время установленного соединения сгенерировать еще один offer для других MediaDevices и все будет ок. Или о том, что WebRTC под native iOS (еще не проверял на других платформах) позволяет создать виртуальную камеру и перенаправлять в нее потоки от задней и фронтальной без каких-либо проблем.
Жестко не хватает good practice по работе с WebRTC. Мы например пришли к StateMachine как на сервере, так и на клиентах. Она нас спасла от кучи проблем с коллизиями при встречных звонках.
Я последний год очень плотно работаю с WebRTC под iOS и если есть вопросы, то могу помочь. Было бы круто, если кто-то сможет поделиться инфой по вопросам:
1. Как быстро восстановить соединения при смене сети пользователем? Например телефон перешел из WiFi в сотовую сеть.
2. Как подружить RTCAudioSession, AVAudioSession и CallKit для воспроизведения сигнальных звуков.
А зачем вот это вот всё засунули в браузер? Сделали открытый стандарт и хорошо, пусть люди пишут свои клиенты/плагины и т.п. Можно было бы и библиотеку для всех сделать открытую, чтобы легче было поддержку добавить.
Шел 2017 год, здравых людей, ставящих неизвестные плагины, осталось исчезающей мало
Я не имел в виду плагины к браузеру, а плагины к существующим коммуникаторам. То есть к приложениям, которые давно этим занимаются и умеют коммуникации гораздо лучше браузера. Зачем это тащить в браузер?
Потому что скоро останется только одна программа — браузер.
Никто вам не запрещает использовать плагины для/или определенных приложений.
Конечно раздражает оверхед на ресурсы, но меня лично радует когда я знаю что определенная вещь заработает из коробки почти по одному клику + на телефоне/компе/телевизоре/планшете. И если помнить что типичный пользователь не отличает вайфай от интернета и логин от пароля, то ему это точно понравится (даже не узнает)…
Конечно раздражает оверхед на ресурсы, но меня лично радует когда я знаю что определенная вещь заработает из коробки почти по одному клику + на телефоне/компе/телевизоре/планшете. И если помнить что типичный пользователь не отличает вайфай от интернета и логин от пароля, то ему это точно понравится (даже не узнает)…
Ну, как бы, это в другую сторону работает. WebRTC — опенсорс и его встраивают во всякие мессенджеры, а не наоборот.
Помогите разобраться, сможет ли TURN-сервер, имя две сетевые карты, обслуживать видео поток, если одной сетевой он подключен к интернету, а второй в закрытую частную сеть без доступа к интернету. Клиенты также находятся один в частной сети, а собеседник в интернете. В настройках браузеров будет включен режим общения только через TURN-сервер.
Sign up to leave a comment.
WebRTC: как два браузера договариваются о голосовых и видеозвонках