При локальном подключении мы всё равно используем WebRTC для видео, при этом локальный контроллер выступает в роли брокера вместо облака. На это есть несколько причин, но главная — сохранить как можно более схожие пути выполнения кода, что значительно упрощает поддержку и отладку.

Пока нет. Мы будем следить за обновлениями Safari, но пока они очень медленно внедряют новые функции. До недавнего времени у них вообще не было WebRTC.

Я понимаю, что оригинального автора раздражает ситуация, но, мне кажется, ему стоит понять, что в целом Ubnt значительно опережает конкурентов в этом вопросе. Большая часть традиционного софта для CCTV/IP камер до сих пор устарела и ужасна в плане интерфейса, даже когда была новой.

Перед тем как выбрать UniFi Protect, я смотрел несколько «коммерческих» NVR-систем, которые стоят больше 1000 долларов за базовую модель, и не только они не поддерживали браузер Safari, но и для работы с клиентом нужно было устанавливать их фирменные расширения. Последней каплей стало то, что даже при использовании их проприетарного софта он чаще всего не работал или был таким медленным и глючным, что оставался совершенно неприемлемым.

Хотя я тоже хотел бы полноценной поддержки Safari, наличие надежной альтернативы в виде браузера Chrome — вполне приемлемое решение. Меня гораздо больше волнует отсутствие важных функций, которые не доступны вообще ни при каком интерфейсе или клиенте.

Это куда более серьезное ограничение, чем необходимость «задержать дыхание» и иногда запустить Chrome, если не получается использовать мобильное приложение или другие платформы. Очевидно, что виноват неполноценный WebRTC у Apple. Я думаю, что автор изначального поста не сталкивался с «радостями» общения с Apple в роли разработчика. Я сталкивался и могу понять UniFi в этом плане.

Apple известна тем, что ставит односторонние барьеры — они говорят, что хотят, а остальное игнорируют. Разработчики регулярно пытаются привлечь внимание Apple, но в ответ — тишина. Это полностью непрозрачные отношения: Apple свяжется с тобой только если сама по своему усмотрению решит, что хочет решить проблему или узнать о ней больше.

Я не оправдываю UniFi за другие вещи, например, отсутствие поддержки iPad в родном разрешении, но в данном случае они демонстрируют вполне разумный подход, который применяют почти все остальные разработчики.

Я никогда не занимался анализом протоколов, но, возможно, стоит этим заняться. На моём офисном компьютере для доступа в интернет нужно использовать прокси-сервер. И кроме этого, для моего компьютера нет никаких правил входящего или исходящего трафика. Я использую Chrome, чтобы зайти на protect.ubnt.com и смотреть поток с камеры. В домашней сети для моего Protect NVR нет никаких правил входящего трафика, и ограничений на исходящий трафик тоже нет. Я не понимаю, как Protect NVR устанавливает сессию с моим компьютером при входе из офиса. Я точно знаю, что офисный файрвол не пропускает никакой UDP-трафик. Есть ли какие-нибудь схемы потока данных и того, как устанавливаются сессии?

Термин «за файрволом» очень общий и не относится к конкретным правилам. Если слишком придираться к деталям правил файрвола, то, да, это не сработает. Если у клиента есть свободный исходящий доступ и он инициирует соединение через файрвол, то файрвол пропустит входящий ответ. Облачный портал работает как посредник P2P, похожий на другие P2P-приложения. Если у вас есть правила, запрещающие P2P, эти правила могут также блокировать Protect.

Итак, как происходит передача данных? UBNT Cloud приказывает моему Protect NVR установить исходящее соединение с моим Protect клиентом? Значит, если мой Protect клиент за файрволом, это не сработает? Не думаю, что это так.

Вся суть облачного сервиса — не открывать входящие порты. С Protect входящие порты в любом случае не статичны. Коди говорил о том, что ограничения на исходящий трафик могут помешать.

@fg1921,

protect.ubnt.com занимается только аутентификацией и загрузкой ресурсов для интерфейса (в Chrome). Затем он использует WebRTC для установления прямого соединения между NVR и клиентом (браузером Chrome или телефоном) — можно представить это как согласование IP-адресов и портов для общения. После этого всё видео передаётся зашифрованным напрямую между NVR и клиентом.

Один из первых тестов, который я бы посоветовал — попробовать подключиться из удалённой сети через Chrome. Если получится, значит проблема скорее всего в мобильном устройстве. Если нет — скорее всего, дело в сетевом подключении самого NVR. В обоих случаях ваша сеть не должна явно блокировать исходящие подключения или WebRTC, поэтому часто пользователям, которые в своём шлюзе прописывают белый список исходящих портов, приходится использовать VPN.

Если проблемы не исчезнут, создайте новую тему, и мы поможем с мобильным подключением.

Я думал, что @UBNT-TomS ясно объяснил, что Safari не полностью поддерживает WebRTC, а Protect требует браузер с полной поддержкой WebRTC. Мне тоже хотелось бы пользоваться Safari, но позиция, похоже, такова: либо используйте браузер с полной поддержкой WebRTC, либо не пользуйтесь Protect. Не думаю, что это катастрофа — использовать Chrome или другой браузер.