Flussonic Agent — прошивка для камер

    Организация облачного видеонаблюдения — это множество технических нюансов, которые требуется решать сразу же: видимость камер из-за 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 с биллингом оператора.
    Эрливидео 38,13
    Современный видеостриминговый сервер
    Поделиться публикацией
    Похожие публикации
    Комментарии 23
    • 0
      Основной недостаток такого подхода — зависимость от чужой инфраструктуры, ведь endpoint сервер всегда остается в вашей зоне ответственности. И установить у себя его нельзя по вашей политике.
      А в целом продукт интересен.
      • 0
        как раз не так. endpoint здесь — это экземпляр флюссоника, который стоит у вас. Его адрес пишется в конфиг при первом запуске агента и потом агент ходит уже к нему, т.е. к серверу у вас.
        • 0
          Спасибо за ответ. Тогда разрешите более общий вопрос: Все ли элементы системы могут находиться у владельца сервиса? Если да, то мы с менеджерами Erlyvideo не поняли друг-друга.
          • +1
            на самом старте камера один раз идет к нам, что бы выяснить, куда идти дальше. Потом она уже общается только с вашими серверами.

            Этот момент мы менять не будем, потому что зашивать в прошивку адрес клиента мы не будем. За все годы работы ни разу не было ситуации, что бы клиент с первого раза выбрал себе домен для камер раз и навсегда. Мы всем говорим, что надо выбрать и потом не менять, все говорят ага и меняют.
      • 0
        Можете написать статью о том, как потрошить прошивки? Я пробовал разобраться с прошивкой одной глючной камеры, но ни с какими утилитами я не получил положительного результата.
        • 0
          Вы не сообщили производителя, модель и SoC камеры. Напишите, попробуем вместе.
          От этого зависит и метод распаковки. Некоторые примеры были тут и на GT.
          • 0
            если походить по ссылкам из статьи можно найти историю как разбирали и чинили прошивку на камере
            habrahabr.ru/post/219537
            • 0
              Вот еще прекрасный образец — https://justpaste.it/1g3o2
            • 0
              Спасибо за статью, было достаточно интересно.
              Сообщите пожалуйста, какого размера исполняемых файлов и библиотек вам удалось достичь?
              Ведь не секрет, что в некоторых камерах места, ну как кот наплакал.
              Свои задачи я решил путём интеграции в прошивки к камерам XM небольшой утилитки VTUNd, которая строит L2/L3 туннель на мой сервер, а китайское облако отключил. Ну и скриптов и утилиток еще докинул до кучи в прошивку.
              • +1
                не занимаясь сжатием получается порядка 350 килобайт.
                • 0
                  Туннель + шифрация + какие-то свои алгоритмы = 350k
                  Достаточно хороший результат. Мои искренние поздравления!
                  • +1
                    Минусующих заело что-ли, что разговор пошел в техническую сторону? Повторюсь — указанный выше результат вполне хорош. Любой туннель с более-менее адекватной шифрацией для Embedded систем будет занимать не менее 160-220 килобайт.
                    Занимаюсь сейчас моддингом прошивок к камерам XM на базе SoC HI3518E, с интеграцией в камеры низшей ценовой категории, которые с флешкой 8 Mb, дополнительных возможностей в виде поддержки USB WiFi/Flash/3Gmodem, туннелей для создания своего «облака» (повторить сможет каждый на роутере/сервере с одним белым IP), подключения датчиков и исполнительных устройств. Так что немного «в теме» как достаточно непросто происходит там борьба за каждые свободные 50-10 килобайт.
                    • 0
                      на каких камерах экспериментируете с датчиками?
                      • +1
                        XM с SoC HI3518E v1 и v2
                        XM с SoC HI3516C
                        XM с SoC IPC 510A1
                        XM с SoC GM8135S

                        На данный момент вот такой моддинг пилю. Планирую метод сделать универсальным, под разные PCB. За основу взял специально самую дешевую и массовую плату, ну и относительно старую уже, конечно.
                        • 0
                          это перекликается с нашим Flussonic Iris. Он развивается не так быстро, как хотелось бы, но дело движется.

                          Мы полностью выкинули всё с камеры.
                          • 0
                            Оставили только модули ядра для матриц ;)?
                            Или Hisilicon поделился таки с вашей компанией исходниками под NDA?
                            • 0
                              не, исходниками не делятся даже на таобао =)

                              Модули конечно штатные, равно как и ещё несколько утилит, без которых оно не взлетит
                              • 0
                                Под процессор IPC XM510 находили что-нибудь из документации?
                                Хочется камерам на их базе скриншоты научиться делать, но информации полный ноль. Может это просто какой-то перемаркированный чип?
                                Если кому интересно, поделки свои выкладываю тут
                  • 0
                    я не знаю, за что минусуют, если честно.

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

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

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

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое