Миллион видеозвонков в сутки или «Позвони маме!»

[ianzag]

Судя по картинке гусей Боб не очень то хочет в данный момент устанавливать видеозвонок с Алисой…

[Hixon10]

Добрый день. Спасибо за доклад, очень круто!

Таким образом пробиваем NAT — ходим на один STUN-сервер, на другой, смотрим разницу, сравниваем и пробуем еще раз отдать свой порт уже с этим инкрементом или декрементом. То есть Алиса пытается отдать Бобу свой порт, уже скорректированный на константу, зная, что в следующий раз он будет именно такой.

Скажите, пожалуйста, вы решили не вливать эти изменения в публичную реализацию webrtc? Если да, то почему — NDA, или такая оптимизация приминима далеко не всегда, и в общем случае так делать не стоит?

[alatobol]

инкрементить номера портов это скорее хак, чем фича
мы это сделали на уровне приложения, чтобы обновление библиотеки происходило более безболезненно
Но вообще идея хорошая, можем сделать патч для webRTC

[Hixon10]

Да, было бы очень здорово. Я даже боюсь представить, сколько вы сможете сэкономить мирового трафика TURN-серверов (если на ваших данных вышло 12% прироста P2P).

[vasilevkirill]

Позанудствую

NAT вроде как защищает сеть

Правильно настроенный NAT не защищает сеть, но неправильно настроенный NAT открывает новые дырки.
Это очень большое заблуждение что NAT способствует безопасности сети.

А за статью спасибо, очень интересно.

[alatobol]

и я позанудствую — вы абсолютно правы
но я не хотел в докладе на этом останавливаться, поэтому использовал «вроде как» ;)

[u_story]

А разве NAT не позволит скрыть от злоумышленника информацию о количестве компьютеров в сети?

[arheops]

Допустим, максимальная нагрузка наблюдается 10 часов в сутки.
Также допустим, что распределена она равномерно и средний видеозвонок 30 минут(на самом деле меньше, порядка 10).
1000000/10/3600=27.7 звонков в секунду. 50тысяч одновремнных звонков, причем они все p2p.
Поскольку используется opensource webrtc и p2p, то 4к там или 360 — сказать нельзя, пока сввязь не установится, и размер потока вообще никак не влияет на загрузку(он тупо идет от клиента клиенту).
В принципе, должен справится ОДИН сервер kamailio.
Точно hi-load?

[alatobol]

только 40% трафика идет через p2p, остальное через turn

на видео доклада говорится что в докладе не будет Highload-а ;)
и доклад про то как работает сервис видеозвонков

[arheops]

Ну так 10-50тыс звонков через turn это тоже не супер нагрузка для него. Нет, больше одного сервера, но тоже не сильно сложно.
Сложен сам клиент, про который както мало чего рассказано.

[alatobol]

да, клиент это сложная задача:
нужно скомпилировать webRTC одной командой и прикрутить в ваше iOS или Android приложение, а на вебе 5 шагов pastebin.com/EjsdJx1h (ссылка из статьи)

повторюсь: на видео доклада говорится что в докладе не будет Highload-а ;)
и доклад про то как работает сервис видеозвонков

[alatobol]

все так, но как звонящему понять, что канал действительно защищенный?
как раз в этой задаче поможет zRTP

[alatobol]

да в статье идет речь про такой вариант mitm в webRTC:
p2p соединение скомпрометировано и mitm проксирует все сообщения в data канале, т.е. mitm делает два DTLS (по одному с каждым абонентом) и получает доступ к трафику
в этом случае нет возможности валидировать, что вы DTLS делаете именно с вашим абонентном, а не злоумышленником

[alatobol]

да, signaling должен быть скомпрометировать