Контакты
Подписка
МЕНЮ
Контакты
Подписка

Подводные камни VSaaS

В рубрику "IP-security" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Подводные камни VSaaS

Уже не первую статью посвящаю рассмотрению сервисов облачного видеонаблюдения. Некоторые эксперты довольно скептически относятся к облачным технологиям в видеонаблюдении, но наша компания на собственном опыте убеждается, что спрос на VSaaS растет с каждым месяцем. Операторы связи создают прибыльный сервис, пользователи получают инструмент видеоконтроля за умеренную абонентскую плату
Александр Коробков
Директор по разработкам компании MACROSCOP

Несмотря на то что концепция VSaaS в общем случае звучит как "включи и работай", на деле все не всегда так просто. Существуют подводные камни, которые надо учитывать как создателям, так и пользователям облачных сервисов. Данный материал посвящен обзору не только сложностей, которые могут возникнуть при работе с VSaaS, но и решений этих сложностей. Существует два способа организации VSaaS – две модели получения видео от IP-камеры в облако. В первом случае сервер облачного сервиса подключается к камере, во втором – камера должна самостоятельно подключиться к облаку. Для каждого вида организации сервиса существуют свои особенности, которые необходимо учитывать пользователю при подключении.

Готовы ли IP-камеры к VSaaS?

Не все и не всегда, если речь идет о "классических" IP-камерах.

Модель 1
Если сервис построен по первой модели: сервер связывается с IP-камерой через программное обеспечение, инициализирует соединение и диагностирует состояние подключения; необходимо обратить внимание на то, как построена система пользователя. Когда IP-камеры подключаются к Интернету через роутер, для того чтобы сервер нашел камеру, сле дует выполнить проброс портов. Если пользователь обладает достаточной компетенцией, он может сделать это самостоятельно, настроив правило в FireWall роутера. Или же проброс портов и инициализация соединения могут быть произведены IP-камерой, но та должна поддерживать службу UPNp. При этом необходимо обращать внимание на совместимость используемой модели роутера и реализованной в IP-камере функции UPNp, поскольку разные производители реализуют ее по-разному.


Модель 2
Второй вариант организации сервиса предполагает использование специализированных IP-камер, созданных для использования в облаке производителя данных камер.

Готовы ли провайдеры?

Модель 1
Если подключение осуществляется первым способом - облаком к IP-камере, пользователь должен обладать внешним ("белым") IP-адресом. В масштабе глобальной сети Интернет проблема исчерпания IPv4-адресов стоит очень остро, поэтому провайдеры все чаще предоставляют своим абонентам частные (или "серые") IP-адреса. Эти адреса не используются в сети Интернет, предназначены для применения в локальных сетях, а их распределение никем не контролируется. Так как в рамках глобальной сети Интернет "серых" адресов фактически не существует, облако не сможет подключиться к камерам пользователя, у которого "серый" IP-адрес. Узнать тип IP-адреса пользователь может у провайдера, и в случае, если у него частный адрес, запросить смену на внешний. IP-адрес также должен быть статическим, то есть постоянным, привязанным к подключению. В случае динамического IP-адреса при каждой новой сессии он будет меняться, а значит, при первой же смене своего адреса IP-камера "вылетит" из облака.

Если адрес динамический, поможет сервис привязки IP-адреса к домену, например DynDNS . Пользователь может выбрать IP-камеру или роутер Wi-Fi со встроенным сервисом. DynDNS-клиент постоянно отправляет информацию DNS-серверу сервиса, тем самым сообщая о своем IP-адресе. Сервер службы DynDNS сохраняет последний IP-адрес пользователя и при обращении к пользовательскому доменному имени, полученному при регистрации, перенаправляет запрос на этот IP-адрес.

Если используется роутер Wi-Fi с поддержкой DynDNS для системы с несколькими IP-камерами, "белый" статический IP-адрес получает именно роутер, а камерам раздаются "серые" Чтобы и в этом случае система работала как надо, следует произвести проброс портов на роутере.

Модель 2
Если подключение к облачному серверу осуществляется IP-камерой, ее IP-адрес может быть как "белым", так и "серым", статическим или динамическим.

Готов ли Интернет?

Хотя Интернет и является неотъемлемой частью современной жизни, операторы связи далеко не всегда могут обеспечить своих пользователей высококачественным и высокоскоростным интернет-соединением. Возможны перебои в работе каналов связи между IP-камерой и облаком. В большинстве случаев перебои каналов приводят к потере части видеоданных. Устранение неполадок на линии - процесс небыстрый, поэтому речь, как правило, идет далеко не о нескольких минутах потерянного видео.

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


Серьезным препятствием для широкого распространения облачного видеонаблюдения в России также является ограниченная пропускная способность интернет-каналов. Недостаточная ширина канала серьезно ограничивает объем передаваемой информации, тем самым не только причиняя неудобства пользователю, но и снижая уровень безопасности объекта. Об ограниченности каналов связи я уже писал в статье "Облачное видеонаблюдение: решение проблемы узких каналов связи" ("Системы безопасности", № 4/2013), поэтому на данном вопросе не буду останавливаться очень подробно.

Существует несколько решений проблемы узких интернет-каналов. Большинство из них направлено на уменьшение объема передаваемых видеоданных.
1. Использование встроенной видеоаналитики IP-камер для записи в облако отфильтрованных фрагментов видео с интересующими оператора событиями (запись в облако по детекции движения, пересечению виртуальной линии, проникновению в выбранную зону и т.д.).
2. Выбор оптимального формата сжатия. Основными форматами сжатия видео для систем наблюдения сегодня являются MJPEG, MPEG-4 и H.264. Для решения проблемы узких каналов связи необходимо снизить объем передаваемой информации, и сделать это можно, используя формат сжатия H.264. Заглядывая в будущее, разработчики облачных решений возлагают огромные надежды на формат H.265. Существенное повышение (до 50% по сравнению с H.264) эффективности сжатия видео и более совершенные алгоритмы обработки информации позволяют прогнозировать ощутимое снижение требуемой для передачи данных ширины интернет-канала.
3. Ранжирование видеоданных. Данная технология реализуется поставщиком сервиса и представляет собой выделение интересующих оператора фрагментов видео с помощью функций видеоаналитики и дальнейшую их передачу в порядке очереди приоритетов. Видеоаналитика "обрезает" ненужные части видео, уменьшая объем, а ранжирование регулирует передаваемый поток.
4. Снижение качества видеозаписи. В ряде случаев пользователю не требуется высокое качество картинки. Видеонаблюдение не всегда призвано решать узкие охранные задачи, например распознавать лица или регистрационный номер автомобилей. Так, для наблюдения за территорией объекта иногда достаточно невысокого разрешения видео, а чем ниже качество картинки, тем меньшая ширина канала требуется для передачи видео по сети.
5. Построение гибридной системы. В этом случае предполагается установка пользователем собственного сервера. Видеопоток с камер поступает на сервер, где анализируется при помощи интеллектуальных функций, и в облако передается лишь отфильтрованная часть информации

4 правила комфортного облака

Избежать неприятных сюрпризов при работе с VSaaS можно, зная о них заранее. Решения возникающих сложностей довольно просты, но учитывать их необходимо еще на этапе подбора оборудования и создания своей облачной видеосистемы. Итак, еще раз несколько правил для комфортного использования облака:

1. Если облачная система организована по модели подключения облака к IP-камере, пользователь должен обладать внешним статическим IP-адресом. Если соединение осуществляется через роутер, следует произвести проброс портов. Это можно сделать вручную или выбрав IP-камеру с функцией UPNp.

2. Для системы, в которой подключение к облачному серверу осуществляется IP-камерой, не имеет значения, частный у пользователя IP-адрес или внешний, статический или динамический.

3. Защитить себя от потери видео при обрыве связи с облаком помогут IP-камеры со встроенной картой памяти.

4. Снизить трафик при ограниченной пропускной способности интернет-канала можно с помощью видеоаналитики IP-камер, функции ранжирования видеоданных, снижения качества видеозаписи, выбора формата сжатия H.264 или построения гибридной системы.

Опубликовано: Журнал "Системы безопасности" #5, 2013
Посещений: 9830

  Автор

Александр Коробков

Александр Коробков

Директор по разработкам компании MACROSCOP

Всего статей:  47

В рубрику "IP-security" | К списку рубрик  |  К списку авторов  |  К списку публикаций