Интеграция в существующую систему биллинга¶

В этой статье описаны типовые сценарии внедрения Flussonic Watcher с контролируемой продажей камер по подписке и учетом абонентов и их услуг в сторонней системе. API для интеграции доступен по ссылке.

Далее будут использоваться термины:

• оператор связи — клиент компании Эрливидео, владелец сервиса
• абонент — абонент у оператора связи, пользователь сервиса
• биллинг — система внешняя к Watcher, в ней ведется тарификация услуг оператора связи абонентам и взимание денег

Концепция использования биллинга подразумевает, что именно он является центральным местом хранения данных в системе, а не Flussonic Watcher. Такая практика является стандартной и позволяет централизованно управлять услугами в разных системах, связывая, например, умный дом и видеонаблюдение в едином проекте.

Перед добавлением абонентской камеры в любом случае необходимо создать в Watcher соответствующую структуру организаций и пресетов, назначить абоненту те или иные права. Это можно сделать как из интерфейса Watcher, так и с помощью соответствующих запросов API для управления организациями, папками, пользователями. Механизм сопоставления тарифных планов биллинга и пресетов Watcher, а также логика, которая будет влиять на доступ, глубину архива и прочие настройки, находится на стороне биллинга.

Сценарии интеграции при использовании камер с агентом и без него отличаются. Они описаны ниже отдельно.

Также на странице приведены примеры запросов, позволяющих приостановить пользование услугами в Watcher для абонента.

Создание пресетов¶

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

Как правило при интеграции с биллингом абоненты не должны менять задаваемые пресетом настройки на камере. Для выполнения этого требования достаточно сделать пресет ненастраиваемым. Тогда, даже если у абонента будут права владельца Организации с возможностью редактирования настроек камер, он не сможет изменить заданные пресетом настройки. Они будут видны ему, но недоступны для редактирования.

Владельцы Организаций не могут создавать, редактировать и удалять пресеты: такие права есть только у Администратора Watcher. Если к Организации привязано несколько пресетов, то владелец Организации сможет поменять один пресет на другой в настройках камеры.

Пресеты можно создавать из биллинга с помощью следующего API-запроса:

POST /watcher/admin-api/presets

Обязательный параметр title — название пресета.

Также доступны запросы GET/PUT/DELETE для получения/изменения/удаления пресета с заданным идентификатором.

Камеры с агентом¶

Сценарий работы интеграции при использовании камер с агентом:

1. На партию камер устанавливается модифицированная прошивка с Flussonic Agent. В этой прошивке содержится информация о том, к какому Flussonic Watcher надо привязать эту камеру
2. Камеру с серийным номером оператор связи заносит в систему инвентаризации биллинга, пока она ещё лежит на складе
3. При продаже абоненту сотрудник оператора связи в биллинге ставит в соответствие серийному номеру камеры идентификатор абонента
4. При подключении к сети камера получает данные для авторизации от сервера активации. Эти данные никак не связаны с идентификатором абонента, это авторизация камеры.
5. Активированная камера немедленно начинает попытки соединения с Flussonic Watcher

6. Сервер активации посылает данные о камере в биллинг

   Note

   Сервер активации может отправлять данные о камере напрямую в Watcher, если при активации камеры с агентом уже известна информация о ее владельце (например, если камера IRIS активирована из приложения). Это зависит от типа агента и требований к интеграции. Для настройки сервера активации обратитесь в техническую поддержку Flussonic Watcher.

7. Биллинг получает информацию о свежесозданной камере, добавляет к ней информацию о пресете (тарифе) и организации.

8. Биллинг отправляет информацию о свежесозданной камере в Watcher. Этот и предыдущий пункты необходимо реализовать в рамках интеграции на стороне биллинга.
9. Теперь камера может подключиться к Watcher и начать отдавать поток

При такой организации процесса не требуется никакой настройки роутеров, камер и прочих сетевых устройств у абонента. После включения камеры в сеть она автоматически появится в личном кабинете, при условии что в биллинге реализован API для приема данных о свежесозданных камерах и отправки этих данных в Watcher. Такая схема с проксированием данных нужна для добавления информации о владельце камеры и услугах, которые доступны на этой камере.

Сервер активации, обслуживаемый Эрливидео, присылает запрос с CSV или списком JSON объектов на сконфигурированный url. Чтобы сервер активации присылал данные на url биллинга, обратитесь в техподдержку Flussonic Watcher.

Все данные о камере, которые присылает сервер активации, надо переслать в Flussonic Watcher без изменений, если только нет задачи по какой-либо причине их поменять. Например, может прийти флаг can_ptz=1, его можно выставить в 0, если абоненту нужно запретить управлять поворотной камерой в Watcher.

Поля, передаваемые от сервера активации (Эрливидео) в биллинг (в формате CSV или JSON):

• agent_model (строка) — модель камеры
• agent_serial (строка) — серийный номер камеры
• agent_id (строка) — уникальный номер агента на камере
• agent_key (строка) — специальное поле, используемое для авторизации камеры Watcher’ом
• stream_url (строка) — основной RTSP-URL потока
• substream_url (строка) — вторичный RTSP-URL потока
• thumbnails (строка) — URL снепшотов с камеры
• onvif_url (строка) — URL по которому камера будет отвечать по onvif протоколу
• onvif_profile (строка) — служебное поле
• can_ptz (0 или 1) — вкл/выкл PTZ
• abonent_sign (целое число) — зашифрованная информация об организации и пользователе-владельце камеры. Присутствует только для соответствующего типа агента, когда абонент вручную добавляет камеру в свою организацию через мобильное приложение или веб-интерфейс Watcher. Если это поле заполнено, добавление информации о владельце камеры не требуется.

Пришедшая от сервера активации информация должна «склеиваться» с уже существующими в биллинге или другой системе учета данными о камере по параметру agent_serial (серийный номер камеры). Важно понимать, что agent_id может поменяться в случае, если камеру сбросили или передали другому абоненту. Серийный номер у камеры меняться не должен.

На стороне биллинга должна быть реализована возможность дозаполнять атрибуты камер, такие как привязка к организации или детали по управлению услугами для формирования тарифных планов.

После добавления полей индивидуальной настройки (preset_id, enabled, organization_id) необходимо отправить информацию о камере в формате CSV или JSON в Watcher, используя один из следующих запросов:

/watcher/admin-api/streams для добавления одной камеры.

Пример запроса для добавления нескольких камер приведен ниже. Обратите внимание, что параметр X-Vsaas-Api-Key необходимо заменить на тот, который указан в настройках Watcher.

import link

Если не указать в запросе идентификатор пресета и организации, то камера будет добавлена в организацию по умолчанию с пресетом по умолчанию.

Камера без агента¶

Сценарий интеграции для камер без агента (например, RTSP, ONVIF) обычно следующий:

1. Камера подключается к внутренней сети оператора связи
2. Абонент оставляет оператору связи запрос на подключение к камере.
3. Запрос на добавление камеры абоненту или выдачу абоненту прав на камеру поступает от оператора связи в биллинг.

4. Если подключается новая личная камера абонента, например, в систему умного дома:

   • Предполагается, что в Watcher уже создан пользователь и организация для абонента. Если их нет, нужно их создать из интерфейса или с помощью соответствующих запросов API из биллинга.

   • Биллинг заполняет необходимые атрибуты камеры в соответствии с тарифом.

   • Биллинг отправляет в Watcher запрос на добавление камеры абоненту (см. пример ниже).

5. Если абонент хочет подключиться к общей камере, например, к домофону или к системе "Безопасный город":

   • Предполагается, что в Watcher уже создана соответствующая камера и организация. Если их нет, нужно их создать из интерфейса или с помощью соответствующих запросов API из биллинга.

   • Биллинг заполняет необходимые атрибуты пользователя (абонента) для добавления в организацию, в которую добавлена необходимая камера.

   • Биллинг отправляет в Watcher запрос на создание или обновление пользователя (абонента) (см. пример ниже).

Добавление камеры¶

/watcher/admin-api/streams для добавления одной камеры.

В запросе на добавление камеры обязательно должны быть указаны следующие параметры:

• preset_id (целое число) — идентификатор пресета Watcher, соответствующего тарифу в биллинге.
• organization_id (целое число) — идентификатор организации. Организация должна быть уже создана в Watcher, вместе с пользователем.

Добавление пользователя¶

POST /watcher/admin-api/users

Альтернатива добавлению пользователей - внешний авторизационный бекенд.

Отключение камеры абоненту по инициативе биллинга¶

В случае, если абонент по какой-то причине не должен больше пользоваться камерой (например, отключил услугу или не внес оплату вовремя), биллинг должен отправить в Watcher соответствующий запрос.

Самый простой вариант — отключить пользователя. Это можно сделать запросом вида

PUT /watcher/admin-api/users/{id}

задав параметру disabled значение true.

Также есть следующие основные варианты ограничения прав без отключения пользователя: Или отключение камемы абонента, которой никто не пользуется, кроме него, и абонент не имеет прав на редактирование камеры:

PUT /watcher/admin-api/streams/{id}

задав параметру disabled значение true.