Openmeetings — видео/аудио за локальной сетью, как быть?

Question

[RS-qrsk]

В связи с необходимостью, потребовалось развернуть сервер видеоконференций Openmeetings, все отлично работает, НО только в локальной сети.

Никак не могу победить обмен аудио/видео со внешкой, все клиенты из внешней сети видят сами себя, но не видят остальных и не слышат.
Порты 5080, 5443, 8888 были первым делом проброшены на UFW. Для теста были открыты эти же порты и на брандмауэрах win-клиентов.
Клиенты авторизовываются по 5443 порту https, но ssl не выпущен, пока просто игнорируя предупреждение о безопасности.

OM 5 (tomcat3 script)
Ubuntu 18.04

Вопрос: неужели отсутствие ssl является помехой для передачи потока? Кто-нибудь сталкивался с такой проблемой? Как решили?

Comments

[RS-qrsk]

Может кто подскажет, как можно отследить трафик, что бы точно знать где он теряется? Wireshark поможет в данном случае?

Answer 1

[Дмитрий Александров]

неужели отсутствие ssl является помехой для передачи потока?

да является, браузеры не дают доступа к камере\микрофону без нормального ssl. Хотя возможно, но маловероятно, что то изменилось.
Кроме того могут еще и антивирусы мозги парить, писали что стандартный виндовый антивирь блочит и нужно добавлять исключения.
Ну и еще малоприятное это вездесущие NATы, много настроек с разных сторон, turn\stun\ice и прочие прелести rtp трафика.

Comments

[RS-qrsk]

В разрешениях браузера доступ к камере и микро есть, по крайней мере я же сам себя вижу.
Пробовал конечно через Firefox, говорят там более лояльно к ssl относятся, но тоже безуспешно.
Антивируса нет на тестовом внешнем клиенте, а стандартный я отключил, в том числе и брандмауэр.
Клиент не за NAT'ом, но сервер за ним, там порты тоже открыты.
Что я еще пропустил?)

[Дмитрий Александров]

Клиент не за NAT'ом, но сервер за ним, там порты тоже открыты.

уверен процентов на 99 что проблема именно тут.
rtp трафик использует огромную кучу udp портов, которые очень вероятно вы не открыли.
Помимо этого идет проблема с указанием ip адреса медиа сервера. Т.е. клиент подключается, пытается подняться rtp сессия и отправляется клиенту настройки в которых будет фигурировать ip вашего сервера в вашей локальной сети(скажем 192.168.1.10), соответственно клиент из интернета получает это и начинает слать траффик на адрес 192.168.1.10 вместо вашего белого публичного адреса(ну к примеру 200.100.50.25).

[RS-qrsk]

Т.е. клиент подключается, пытается подняться rtp сессия и отправляется клиенту настройки в которых будет фигурировать ip вашего сервера в вашей локальной сети(скажем 192.168.1.10), соответственно клиент из интернета получает это и начинает слать траффик на адрес 192.168.1.10 вместо вашего белого публичного адреса(ну к примеру 200.100.50.25).

Можно про это поподробней, диапазон rtp я открыл, но видео по-прежнему не появилось.
Может действительно проблема в ip адресах, хотя в base url сервера указан внешний адрес.

[Дмитрий Александров]

RS-qrsk, звук пошел?
Вообще правильный вариант сесть wireshark'ом с обоих концов и смотреть трафик, что и куда идет.
Более конкретно врядли подскажу т.к. именно с Openmeetings особо не сталкивался но принципы и проблемы точно такие же как и в любой ip телефонии.
Курите настройки kurento который и является медиасервером в частности про nat.

Answer 2

[RS-qrsk]

В общем, проблему я решил, если кто столкнется с подобным, делал следующее:

Как оказалось, ssl действительно влияет на передачу rtmp трафика во внешку.
1. Создал поддомен om.example.com
2. На сервере отключил apache, дабы полностью освободить 80 порт на время
3. Выпустил сертификат SSL самоподписанный на поддомен
4. в DIR/conf/server.xml изменил 5080 и 5443 на 80 и 443 соответственно
5. Установил turnserver (обязательно!) + бонусом будет также настроить stunserver (в сети много публичных)
6. Перезагрузил tomcat3, kms, mysql, turnserver (что бы постоянно это не прописывать при перезагрузке сервера, сделайте скрипт автозапуска)
Не забываем про ufw или iptables.

Итог: отличный сервер видеоконференций с одновременно работающими клиентами как из внешней сети так и из локальной. Примерная нагрузка на сеть 1-1,5 мбит\с на 1 клиента.