5 ошибок при разработке WebRTC звонков из браузера

[alextsybulko]

После прочтения статьи возникло несколько вопросов. Можете ответить?
1. Чем плохи публичные STUN сервера? Например тот же stun.l.google.com:19302
2. На сколько я понимаю использовать STUN или TURN решает WebRTC. Если нет, то как это происходит?
3. Чем плохо указывать 2-3 STUN сервера?
4. Я не совсем понял проблему использования PeerJS. Сигнализация же ни как не связана с WebRTC и может быть любой. Что конкретно может пойти не так?

[Softer]

1. ИМХО — полагаю что это просто неразумно:

• Если все общение внутри локалки — зачем нам внешний STUN?
• Через неделю гугл (или владелец иного публичного STUN) закроет сервис — будем бегать и в спешке поднимать свой?
• Через 3 дня те кого нельзя называть объявят вышеуказанную компанию «врагом». См. предыдущий пункт :)

[grigoryvp]

1. Он тестовый. То есть в любой момент может сделать ой, или затупить на несколько минут, или вернуть странное.
2. При инициализации WebRTC мы передаем ей список серверов. Далее предлагаем сделать offer и движок начинает с ними общаеться. Делает offer, мы через сигнализацию передаем его второму браузеру и предлагаем ему сделать answer. Тот тоже начинает с серверами общаться. Затем передаем answer обратно и по паре offer-answer первый браузер решает, как коннектиться. В процесс можно вмешиваться руками, меняя offer/answer перед тем, как передать его движку (это просто строка текста или объект для oRTC).
3. Вот тут я не знаю, к сожалению. irbisadm?
4. PeerJS вызывает API WebRTC и рассчитывает на определенное поведение. Которое уже успело сильно поменяться.

[alextsybulko]

Про PeerJS понял, спасибо. Мы используем WebSocket и таких проблем нет.
А вот зачем менять offer/answer руками не понял. Какая в этом может быть выгода?

[grigoryvp]

Если, к примеру, SDP роняет браузер на той стороне :) Или в оффере слишком маленький битрейт по умолчанию предлагается. Множество причин может быть.

[Ogra]

На сколько я понимаю использовать STUN или TURN решает WebRTC. Если нет, то как это происходит?

STUN используется только при установке соединения и нужен практически всегда, если вы сидите за любым NAT (вроде роутера).
TURN же используется только если не удается установить соединение напрямую, нужен для p2p соединений, когда a) оба собеседника за NAT, b) NAT определенным образом сконфигурирован и соединение по определенным через STUN адресам невозможно. При использовании публичного медиа-сервера не нужен.
WebRTC будет использовать STUN, если его указать. Сходит к серверу, получит внешний ip:port, но если оба клиента в локалке, то использоваться будут локальные адреса, а не внешние. В принципе, возможна ситуация, что коннект по локалке произойдет до того, как браузер попробует получить внешний адрес. Но это тестировать надо ;)
WebRTC будет использовать TURN, только если прямые, более приоритетные способы невозможны.

[alextsybulko]

В статье написано:

Не отправляйте все сессии через TURN, если вы совершенно точно не знаете зачем это вам.

В вашем комментарии все верно. Я просто не понял, зачем надо руками вмешиваться в эту работу.

[Ogra]

По идее, если не указать STUN сервера, а указать тольк TURN, то куча соединений пойдет через TURN. Но я не пробовал и никому не советую ;)

[Ovoshlook]

Самые главные ошибки построения сервисов на базе webRTC в том, что:
1 Каждый второй строит свой велосипед на уровне сигнализации, в итоге получая проприетарщину, котороая к тому же не работает.
2 Каждый второй не понимает как работает медиа и что вообще написано в SDP и не пытается понять.

Ну это — если не считать публичных STUN/TURN/ICE Серверов в продакшнах.

[inoyakaigor]

Меня вот интересует вопрос почему нельзя обойтись без медиасервера?

[grigoryvp]

Можно. Для peer-to-peer звонков. У нас в Voximplant до 1000 пользователей в месяц peer-to-peer вообще бесплатно.

Проблемы начинаются, когда в 20% случаев Peer-to-peer не получается и нужно или идти через TURN, или через медиа сервер. Или когда нужно писать голос/видео на стороне сервера. Или когда нужно делать голосовую/видеоконференцию на много человек. Вообщем для большинства практических задачь понадобится медиа сервер. А в простых случаях и для разработки можно без него, да. Я как-то демку показывал, где два MS Edge делали видеозвонок даже без сигналинга — я копипастил между ними офферы и ансверы :)

[inoyakaigor]

когда нужно делать голосовую/видеоконференцию на много человек

А можно с этого места поподробнее? Почему нельзя один стрим с одного браузера отсылать пяти разным клиентам (и так пять раз)?

[apapacy]

Это пояснено в статье трафик пятикратный получится

[grigoryvp]

Можно. Только вот браузер не умеет один энкодер на всех. Это будет по кодированию + стриму на КАЖДОГО, кто захочет увидеть этого человека в видеоконфе. А если таких десять? Сжатие видео, даже аппратное — это не самый дешевый по CPU/GPU процесс. Через сколько таких видеопотоков средний ноутбук отбросит лапки? Спойлер: 3-4 будет вполне достаточно ^_^

[BigD]

а это в каком сервисе такое бесплатно у вас?

[grigoryvp]

voximplant.com, до 1000 пользователей Peer-to-peer бесплатно

[BigD]

да это понятно, что voximplant :) работаем с вами потихоньку
пытаюсь, вспомнить, где у вас что бесплатно.
если даже sip поминутно тарифицируется через платформу

[grigoryvp]

Вот тут хорошо (надеюсь) все расписали: voximplant.com/pricing

[BigD]

понятно, спасибо
а почему при использовании sip to sip такого free tier нет?

[grigoryvp]

Медиапоток через нашу платформу идет. Это довольно большая нагрузка на сервера. А когда Peer-to-peer через нас только сигнализация, JavaScript сценария и STUN/TURN. Тоже неприятно, но можно потерпеть.

[BigD]

хм, а почему медиапоток через вас идет в случае с sip, если транскодинг не нужен?

[grigoryvp]

Потому что SIP так работает. Он не умеет peer-to-peer, в отличие от WebRTC. Нужен сервер, через который пойдет SRTP. И это наши сервера.

[akadex]

Я вот все прицеливаюсь в своих продуктах на конференции для корпоративной связи. Понимаю, что достаточно сервисов, но так сложилось, что почти всегда идёт интеграция с локальной софтварной АТС. То бишь с аудиочастью проблем нет, но вот видео иногда требуется. Так вот из того что понравилось больше всего для этой цели — это FreeSwitch Verto. Можно долго рассказывать, но рекомендую всем. Очень не дурно реализовано.

[grigoryvp]

FreeSwitch и Asterisk — классические решения для сборки самому. Именно с них к нам в Voximplant переходит больше всего клиентов :)

[akadex]

А у Вас ПО — это полностью самостоятельная разработка в части медиа-сервера?

[grigoryvp]

Увы, да. Когда миллионы звонков — нужен полный контроль над происходящим. Чтобы не текло, не падало и без сюрпризов. Несколько сильных VoIP плюсовиков-затейников, несколько лет разработки, никакой магии.