Интеграция в существующую систему
В этой статье описан типовой сценарий внедрения Flussonic Watcher с контролируемой продажей камер по подписке и учетом абонентов и их услуг в сторонней системе. Далее будут использоваться термины:
- клиент — клиент компании Эрливидео, владелец сервиса
- абонент — абонент у клиента, пользователь сервиса
- биллинг — система внешняя к Watcher, в ней ведется тарификация услуг клиента абонентам и взимание денег
Сценарий следующий:
- На партию камер заливается модифицированная прошивка с Flussonic Agent
- В этой прошивке зашита информация о том, к какому Flussonic Watcher надо привязать эту камеру
- Камеру с серийником клиент заносит в систему инвентаризации биллинга, пока она ещё лежит на складе
- При продаже абонентусотрудник клиента связывает в биллинге серийный номер камеры с идентификатором абонента
- При первом включении камера от нашего сервера активации получает данные для авторизации в Flussonic Watcher. Эти данные никак не связаны с идентификатором абонента, это авторизация камеры
- Активированная камера немедленно начинает попытки соединения с Flussonic Watcher
- Сервер активации посылает данные о камере напрямую в Watcher или в биллинг
- Биллинг получает информацию о свежесозданной камере, добавляет к ней идентификатор абонента, занесенный ранее в систему инвентаризации
- Биллинг отправляет информацию о свежесозданной камере в Watcher и камера там заводится. Этот и предыдущий пункты необходимо реализовать в рамках интеграции на стороне клиента
- Теперь камера может подключиться к Watcher и начать отдавать видео на Flussonic
Важно то, что при такой организации процесса не требуется никакой настройки роутеров, камер и прочих сетевых устройств у абонента. После включения камеры в сеть она автоматически появится в личном кабинете.
Агент и модификация прошивки не являются обязательным требованием, всё может работать и со стандартными, неизмененными камерами, ниже будут описаны детали.
Подробнее об агенте в подробной статье.
API биллинга
Со стороны клиента надо реализовать в биллинге API для приема данных о свежесозданных камерах и отправку этих данных в Watcher. Такая схема с проксированием данных нужна для добавления информации о владельце камеры и услугах, которые доступны на этой камере.
Вся концепция подобного использования биллинга подразумевает, что именно он является центральным местом хранения данных в системе, а не Flussonic Watcher. Такая практика является стандартной и позволяет централизованно управлять услугами в разных системах, связывая, например, умный дом и видеонаблюдение в едином проекте.
Сервер активации, обслуживаемый Эрливидео, присылает запрос на сконфигурированный урл (по вопросу конфигурации необходимо обратиться к техподдержке) с CSV или списком JSON объектов.
Все данные, которые присылает сервер активации надо переслать в Flussonic Watcher без изменений, если только нет задачи по какой-либо причине их поменять. Так, например, может прийти флаг ptz=1, его можно выставить в 0, если не хочется вообще управлять этой камерой в Watcher.
Поля, передаваемые от сервера активации (Эрливидео) в биллинг:
- 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 (строка) — служебное поле
- ptz (0 или 1) — вкл/выкл PTZ
Пришедшая от сервера активации информация должна создавать в биллинге новые записи для камер, либо «склеивать» эту информацию с уже существующими в биллинге или другой системе учета камер, камеры по параметру agent_serial (серийный номер камеры). Важно понимать, что agent_id может поменяться в случае, если камеру сбросили или передали другому абоненту. Серийный номер у камеры меняться не должен.
Т.е. если в биллинге существует система инвентаризации в которой камера привязывается к абоненту до первого включения, то новая запись появляться не будет, вместо этого надо заполнить пропущенные поля в существующей строчке в БД.
На стороне биллинга можно быть реализована возможность дозаполнять атрибуты к камерам, например привязка к владельцу или детали по управлению услугами для формирования тарифных планов.
Управление камерами в Watcher
Биллинг может управлять камерами, которые существуют в Watcher. В частности при получении данных от сервера активации он может дополнить данные своими полями и отправить информацию о камерах в Watcher.
Атрибуты заполняемые на стороне биллинга:
- owner — (логин привязанного абонента).
- dvr_depth (целое число в днях) - кол-во дней записи архива для камеры. 0 — отключает архив.
- enabled (0 или 1) - вкл/выкл камеры.
- access (private/public) - видимость камеры, публичная она будет (для всех абонентов) или приватная (только для owner'а камеры).
Разработка механизма создания тарифных планов и логики, которая будет влиять на доступ, глубину архива и прочие настройки, находится на стороне клиента.
После добавления полей индивидуальной настройки (owner, dvr_depth, enabled, access) необходимо отправить расширенный список камер в формате CSV в Watcher, по ссылке: http(s)://URL_ВАШЕГО_ВОТЧЕРА/vsaas/api/v2/cameras/import.
curl -v http://localhost:8080/vsaas/api/v2/cameras/import \ -d \ '[{ "name":"cam1","stream_url":"fake://clock","access":"private", "enabled":true,"dvr_depth":3,"agent_id":"123098456","agent_serial":"mJ0ODnktZFc", "agent_key":"salt:secretkey","owner":"alex@smith.com","dvr_path":"movies" }]' \ -H "X-Vsaas-Api-Key: 7ab056b1-5bb1-4501-b528-d69538392842" \ -H "Content-Type: application/json" .... { "deleted": 0, "updated": 0, "errors": {}, "created": 1 }
Здесь X-Vsaas-Api-Key: 7ab056b1-5bb1-4501-b528-d69538392842 это API key из настроек Watcher.
В случае если биллинг отправляет в Watcher камеру с идентификатором несуществующего пользователя (поле owner
),
Watcher создает нового пользователя. Его пароль при этом не передается. Мы подразумеваем,
что клиент не хранит пароли абонентов в открытом виде и никак не может передать. Для того, что бы абонент
мог залогиниться в Watcher, необходимо настроить внешний авторизационный бекенд в Watcher.
Управление пользователями (абонентами)
Параллельно с информацией по камерам можно отправлять в Watcher информацию об абонентах.
Вызов http(s)://URL_ВАШЕГО_ВОТЧЕРА/vsaas/api/v1/users
Пример:
curl -v http://localhost:8080/vsaas/api/v2/users \ -d \ '[{ "login":"user@domain.com","dvr_allowed":true,"external_id":"12346780" }]' \ -H "X-Vsaas-Api-Key: 7ab056b1-5bb1-4501-b528-d69538392842" \ -H "Content-Type: application/json" ... [ { "authorized_ip": null, "enabled": null, "id": null, "note": null, "is_admin": null, "dvr_allowed": true, "notification_email": null, "external_id": "12346780", "login": "user@domain.com" } ]
Полный список полей, которые можно отправлять по ссылке на полную документацию