Организация облачного видеонаблюдения — это множество технических нюансов, которые требуется решать сразу же: видимость камер из-за NAT, активация и идентификация камер, шифрование и автоматический провижининг. Камера при подключении должна автоматически стать частью IT-инфраструктуры оператора. Плюс должна обеспечиваться связь с абонентом. Flussonic Agent решает эти проблемы.

image

В предыдущей статье мы рассказали об одной из сфер применения Flussonic Watcher и кратко о том, зачем нужен Flussonic Agent. А ещё раньше о том, как агент может решить проблемы безопасности при передаче видеопотока. И везде мы отвечали на вопросы «Зачем?», но очень кратко касались вопроса «Как?».
Как мы уже писали, основная проблемой при запуске большой сети видеонаблюдения — настройка видимости камеры из интернета. Для ее решения есть три классические схемы:

  1. Установка проксирующих серверов OpenVPN.
  2. Ручной проброс портов.
  3. Назначение белых IP-адресов для каждой камеры.

OpenVPN


Распространенный и наиболее простой способ — это организация OpenVPN туннеля. Его выбирают прежде всего потому, что для большинства дешевых камер прошивка собирается с помощью buildroot, а в нем уже есть OpenVPN и он легко включается.

На камере прописывается сертификат подключения и адрес OpenVPN сервера. Затем стриминговый сервер в облаке видит камеру через OpenVPN сервер и забирает с нее видео. Однако, OpenVPN требует наличия еще одного сервера рядом, удваивая ваши серверные затраты.

Управление сервером, на который придет камера, находится на самом устройстве Быстро добавить новый сервер вместо сгоревшего и отправить камеру на него не получится — надо менять DNS. А на пути между вашим DNS-сервером и камерой обязательно появится удобный кеширующий на сутки чужой DNS-сервер, который будет заботливо подставлять старый адрес OpenVPN сервера.

Ко всему прочему, OpenVPN требует больше ресурсов из-за того, что он делает больше, чем нужно для этой задачи. Организуется полноценный туннель, который пропускает трафик через ядро linux. В случае с Flussonic Agent и Flussonic Media Server этого не происходит — весь трафик приходит и остается в одном процессе, При гигабите входящего видео это очень ощутимо.

Ручной проброс портов


Port Forwarding — перенаправление портов или ручной проброс портов — позволяет обращаться из интернета к IP-камере, которая находится во внутренней сети за маршрутизатором, использующим NAT. Доступ осуществляется перенаправлением трафика определенных портов с внешнего адреса маршрутизатора на адрес выбранного устройства в локальной сети. Минусы ручного проброса портов это:

  1. Настройка каждого роутера и каждой камеры очень сложна и занимает непозволительно много времени.
  2. По открытому порту может зайти кто угодно. То есть на лицо явное дыра в безопасности.
  3. Вся нагрузка по трафику ложится на раздающую камеру и раздающий канал, а они упадут уже на третьем клиенте.
  4. По RTSP камера будет отдавать рассыпающуюся картинку.

Назначение белых IP-адресов


Покупка «белых» IP-адресов для каждой IP-камеры решает проблему доступа из-за NAT, но может быть адекватным решением только, если у вас не очень большое количество камер. В противном случае организация видеонаблюдения станет просто невыгодным предприятием.

Flussonic Agent


Каждая из этих схем обладает достоинствами и недостатками. Объединяет их два фактора: применимость лишь к небольшой сети видеонаблюдения и невозможность организовать режим Plug-n-play для абонента и автоматизацию процесса для администраторов сервиса. Flussonic Agent как раз и закрывает эти проблемы, позволяя нашим клиентам упростить запуск сервиса. Программа устанавливается на все камеры, передает нужную информацию для активации и связи камеры с пользователем в биллинг или напрямую в Flussonic Watcher и начинает отдавать видео на стриминговый сервер оператора.

Также, как и с OpenVPN сервером, в агенте существует привязка к DNS, но всё-таки обеспечить failover небольшой виртуалки, на которой запущен только веб-интерфейс и управляющий сервер гораздо проще, чем failover высоконагруженного сервера с толстым каналом.

С какими камерами работает Flussonic Agent


Мы можем запустить Flussonic Agent почти всех камерах, работающие под Linux. Важный момент — нам нужна оригинальная прошивка устройства. На данный момент отработана установка агента на уличных камерах на базе HiSilicon, TI DaVinchi и MIPS роутерах на базе dd-wrt.

Как работает Flussonic Agent


Самое интересное. Подготовленная нами прошивка с агентом устанавливается вендором на заводе или прошивается сами оператором. После того, как камера с установленной прошивкой попадёт к клиенту и будет в первый раз запущена, реализуется следующая схема работы:

1. При включении камеры в сеть и подключении к интернету запускается Flussonic Agent.

2. Агент подключается к серверу с Flussonic Media Server, на котором устанавливается Flussonic Watcher, и сообщает о том, что он готов к передаче видео. Этот сервер является управляющим и называется в терминологии агента: endpoint. Здесь камера получает контрольную информацию, авторизуется и переходит через connection upgrade в наш собственный протокол.

3. Если Flussonic Watcher узнал агента (происходит взаимная проверка пароля), то он передает агенту информацию об одном из запущенных серверов Flussonic Media Server на который как раз и пойдет передача видеотрафика. Такой Flussonic Media Server в терминологии агента называется streampoint. Также endpoint может передать команду быстро переключиться на другой streampoint для того, чтобы отработать ситуацию с выходом из одного из стримеров в кластере Flussonic Media Server.

4. После подключения к Flussonic Media Server агент ожидает команду на открытие соединения. Оно похоже на SSH туннель. Когда Flussonic Media Server решает забрать видео с камеры, он обращается к агенту с просьбой организовать TCP-туннель. По этому туннелю может передаваться как видео с RTSP, так и скриншоты с камеры.

В Flussonic Agent также реализована возможность переключатся между основным и резерным управляющим сервером (endpoint) и стриминговыми серверами Flussonic Media Server.

Безопасность доставки видео


Помимо основной задачи нам было важно защитить камеры от взлома и видеопоток от перехвата. Большинство китайских устройств очень слабо защищены даже от простейших бэкдоров. Flussonic Agent умеет шифровать видеопоток с помощью TLS шифрования, исключая любые проникновения третьих лиц в процесс передачи данных.

Кейс внедрения Flussonic Agent в Тайланде


Чтобы понять принципы работы Flussonic Agent и плюсы его внедрения, стоит рассмотреть пример внедрения. К нам обратился клиент, который покупал Flussonic Media Server для того, чтобы пользователи могли из офиса смотреть на солнечные пляжи Тайланда, впечатляться, а затем бежать покупать путевки. Развитие работы с камерами привело его к оказанию услуги OTT VSaaS. Это означает, что клиент забирает видео с камер, которые устанавливаются в ресторанах, кафе и других публичных местах Тайланда, и даёт доступ к видео как в записи, так и в прямой трансляции.

Но в Тайланде есть две глобальные проблемы с интернетом:

  1. Дорогой внешний интернет: от $80 в месяц за мегабит. Если видео с камер выходит за границу Тайланда, то это автоматически может добавить очень много денег к ежемесячному чеку.
  2. Качество интернета. Ещё в 2011-м году по Тайланду висели объявления «high speed 1 mbit». Сейчас ситуация получше, но всё равно 4-х мегабитный поток с камеры из ресторана ставит под вопрос предоставление Wi-Fi посетителям, что в этой стране очень актуально.

Конечно, видеонаблюдение в ресторанах можно оказать и с помощью обычного китайского регистратора с приложением p2p cloud, но у такого подхода есть множество минусов:

  1. Регистратор требует внешнего IP адреса. В Тайланде такая услуга стоит от $30 до $60 в месяц.
  2. Регистратор отдает наружу видео столько раз, сколько придет клиентов. С учётом вышеописанных проблем с интернетом отдать видео более чем паре клиентов уже проблема
  3. Регистратор скорее всего потребует настройку проброса портов на роутере, а в свете Mirai возможно ещё и общения с провайдером по поводу разблокировки нужных портов.
  4. Если забирать видео по RTSP с китайского оборудования, то почти гарантированно столкнешься с багом которого нет.

Наш клиент и предлагает услугу, которая решает эти проблемы. В Тайланде на арендованном сервере был установлен Flussonic Watcher, а экземпляр программного комплекса зарегистрирован у нас, чтобы можно было войти через мобильное приложение. Для решения вышеуказанных проблем на камеры устанавливается наш агент, с которым камера превращается в полный Plug And Play: принесли, повесили, включили — видео на сайте.

Чтобы обеспечить такой уровень сервиса мы много работали с клиентом, вплоть до советов какие камеры покупать и у каких производителей. Также нам было важно, чтобы все камеры были фирмы «XM». Это очень часто встречающийся noname-бренд, который делает устройства достаточно приличного качества и при этом очень недорогие. Hikvision, конечно, лучше XM, но и дороже.

Производители камер прислали немного другие устройства, но мы были к этому готовы и подготовили несколько прошивок. Они были разработаны таким образом, чтобы камеры сразу шли к нужному экземпляры Flussonic Media Server. Клиент самостоятельно установил прошивки на камеры и запустил услугу. Ещё пару моментов нам пришлось исправлять уже удаленно на установленных камерах из-за проблем, вызванных совсем уж специфичным интернетом в Таиланде, но они были легко устранены.

Итог


Как вы видите, Flussonic Agent может значительно упростить запуск видеонаблюдения, обходя как внутренние технические проблемы, так и внешние, связанные с особенностями интернета в данном географическом регионе. В следующих статьях мы расскажем о том, как происходит интеграция Flussonic Watcher с биллингом оператора.

Комментарии (16)


  1. vrangel
    19.01.2018 22:45

    Основной недостаток такого подхода — зависимость от чужой инфраструктуры, ведь endpoint сервер всегда остается в вашей зоне ответственности. И установить у себя его нельзя по вашей политике.
    А в целом продукт интересен.


    1. erlyvideo
      19.01.2018 23:06

      как раз не так. endpoint здесь — это экземпляр флюссоника, который стоит у вас. Его адрес пишется в конфиг при первом запуске агента и потом агент ходит уже к нему, т.е. к серверу у вас.


      1. vrangel
        20.01.2018 02:11

        Спасибо за ответ. Тогда разрешите более общий вопрос: Все ли элементы системы могут находиться у владельца сервиса? Если да, то мы с менеджерами Erlyvideo не поняли друг-друга.


        1. erlyvideo
          20.01.2018 09:09

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

          Этот момент мы менять не будем, потому что зашивать в прошивку адрес клиента мы не будем. За все годы работы ни разу не было ситуации, что бы клиент с первого раза выбрал себе домен для камер раз и навсегда. Мы всем говорим, что надо выбрать и потом не менять, все говорят ага и меняют.


  1. rt3879439
    20.01.2018 13:34

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


    1. ZigFisher
      21.01.2018 18:40

      Вы не сообщили производителя, модель и SoC камеры. Напишите, попробуем вместе.
      От этого зависит и метод распаковки. Некоторые примеры были тут и на GT.


    1. CherryPah
      22.01.2018 10:17

      если походить по ссылкам из статьи можно найти историю как разбирали и чинили прошивку на камере
      habrahabr.ru/post/219537


  1. ZigFisher
    21.01.2018 18:46

    Спасибо за статью, было достаточно интересно.
    Сообщите пожалуйста, какого размера исполняемых файлов и библиотек вам удалось достичь?
    Ведь не секрет, что в некоторых камерах места, ну как кот наплакал.
    Свои задачи я решил путём интеграции в прошивки к камерам XM небольшой утилитки VTUNd, которая строит L2/L3 туннель на мой сервер, а китайское облако отключил. Ну и скриптов и утилиток еще докинул до кучи в прошивку.


    1. erlyvideo
      21.01.2018 23:09

      не занимаясь сжатием получается порядка 350 килобайт.


      1. ZigFisher
        22.01.2018 00:01

        Туннель + шифрация + какие-то свои алгоритмы = 350k
        Достаточно хороший результат. Мои искренние поздравления!


        1. ZigFisher
          22.01.2018 11:41
          +1

          Минусующих заело что-ли, что разговор пошел в техническую сторону? Повторюсь — указанный выше результат вполне хорош. Любой туннель с более-менее адекватной шифрацией для Embedded систем будет занимать не менее 160-220 килобайт.
          Занимаюсь сейчас моддингом прошивок к камерам XM на базе SoC HI3518E, с интеграцией в камеры низшей ценовой категории, которые с флешкой 8 Mb, дополнительных возможностей в виде поддержки USB WiFi/Flash/3Gmodem, туннелей для создания своего «облака» (повторить сможет каждый на роутере/сервере с одним белым IP), подключения датчиков и исполнительных устройств. Так что немного «в теме» как достаточно непросто происходит там борьба за каждые свободные 50-10 килобайт.


          1. erlyvideo
            23.01.2018 09:04

            на каких камерах экспериментируете с датчиками?


        1. erlyvideo
          23.01.2018 09:04

          я не знаю, за что минусуют, если честно.

          Очень легко написать минимальнейший кусок кода, который работает на стенде, но мы поддерживаем большое разнообразие окружений (т.е. свой libevent, свой ssl), плюс к этому на некоторых камерах нам приходится добавлять юзера, ведь сейчас начали борьбу с мираи, поэтому надо тащить ещё обвязку к этому.


  1. Rewire_getz
    22.01.2018 12:15

    Почему при ручном пробросе портов камера по RTSP будет отдавать рассыпающуюся картинку?


    1. ZigFisher
      22.01.2018 19:20
      +1

      Не принимайте это утверждение дословно.
      Просто при пробросе портов камера может отдавать картинку, которая будет рассыпаться. Дело в том, что во многих камерах бинарник, который является RTSP сервером еще выполняет кучу дополнительных функций и старые прошивки, особенно, работают на грани фола. И каждый «чих», в данном случае трансляция адресов, пусть и не на самой камере, вносит некий дисбаланс в эту хрупкую конструкцию. Выше давали ссылки на статью, там всё достаточно хорошо и подробно объясняется.


    1. erlyvideo
      23.01.2018 09:07

      да, есть статья про баг, которого нет.

      Если вкратце, то ситуация такая: китайские программисты обнаружили что если слать видео по TCP, то сокет начинает блокироваться и возникают дропы фреймов на захвате. А потом они обнаружили, что если перевести сокет в неблокирующий режим, то блокировки и дропа fps не будет. Но при этом не сделали всю ту обвязку, которая нужна вокруг неблокирующих сокетов.

      Поэтому если хоть чуток проседает сеть (а это бывает в 99,9999999% случаев), то большие кадры (кейфреймы т.е.) при моментальной отправке в сеть частично теряются юзерлендом на камере. Бороться с этим чрезвычайно сложно.