Крупномасштабные системы видеонаблюдения обычно используют GB28181 для организации камер, NVR и многоуровневых ресурсов мониторинга под централизованной платформой. Однако системы унифицированных коммуникаций и экстренного реагирования чаще строятся на основе стандартного SIP. Хотя GB28181 также использует SIP как часть своей архитектуры сигнализации, он не является прямым аналогом традиционной системы связи SIP. Когда эти две среды должны работать вместе, шлюз GB28181 в SIP обеспечивает практический уровень взаимодействия без необходимости масштабной переработки любой из существующих платформ.

Шлюз может получать ресурсы видеонаблюдения от существующей платформы GB28181, преобразовывать выбранные каналы камер в видеоресурсы, доступные через SIP, адаптировать потоки H.264 и H.265 при необходимости, а также предоставлять дополнительные медиа-выходы, такие как FLV, HLS, WebRTC, RTMP и RTSP. Это позволяет интегрировать стационарные камеры и другие видеоисточники в диспетчерские консоли, приложения экстренного реагирования и другие рабочие процессы связи на основе SIP.

Почему необходим уровень взаимодействия

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

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

Платформы связи на основе SIP используют другую модель обслуживания. SIP-терминал обычно рассматривается как вызываемая конечная точка связи. Когда диспетчер выбирает конечную точку, система ожидает, что процесс SIP-сигнализации установит сеанс. Камера, управляемая платформой видеонаблюдения GB28181, не автоматически представляется системе связи в таком виде.

Это различие становится практической проблемой в проектах экстренного реагирования и конвергентных коммуникаций. Операторы уже могут иметь доступ к телефонам, диспетчерским терминалам и другим пользователям SIP, в то время как живое видео наблюдения остается изолированным внутри отдельной платформы мониторинга. Без механизма взаимодействия переключение между двумя системами добавляет операционные шаги и ограничивает возможность объединения информации о связи и видео в одном рабочем процессе.

Разработка прямого программного интерфейса между двумя системами возможна, но может потребовать значительной адаптации протоколов, обработки медиа и тестирования совместимости. Выделенный шлюз снижает нагрузку по интеграции, обрабатывая различия в протоколах и медиа между средами GB28181 и SIP.

Преобразование ресурсов видеонаблюдения в конечные точки SIP

Преобразование протоколов является центральной функцией решения. Вместо того чтобы требовать от системы унифицированных коммуникаций прямого понимания полной структуры видеонаблюдения GB28181, шлюз интерпретирует видеоресурсы на одной стороне и представляет необходимые каналы среде SIP на другой.

Шлюз может подключаться к существующей платформе GB28181 и получать её структуру видеоресурсов. Это особенно полезно для проектов, где сеть видеонаблюдения уже развернута и содержит большое количество камер. Существующая платформа остается ответственной за организацию наблюдения, в то время как шлюз выбирает и предоставляет ресурсы, которые должны участвовать в системе связи.

Ресурсы камер затем могут быть отображены в форму, которую может использовать SIP-платформа. С точки зрения диспетчерской системы, выбранный канал наблюдения может вести себя скорее как вызываемый видеоконечная точка. Диспетчеру не нужно понимать базовый процесс сигнализации GB28181 каждый раз, когда требуется видео.

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

• Шлюз подключается к существующей видеоплатформе GB28181 и считывает доступные ресурсы наблюдения.

• Необходимые камеры или видеоканалы отображаются для использования средой связи SIP.

• Диспетчерский терминал или другая авторизованная конечная точка SIP инициирует стандартный рабочий процесс связи.

• Шлюз преобразует запрос в сигнализацию, требуемую на стороне наблюдения.

• Соответствующий поток камеры получается и доставляется в приложение связи.

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

Гибкий доступ к существующим видеоресурсам

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

При крупном развертывании предпочтительным методом обычно является подключение к существующей платформе GB28181. Платформа может уже содержать тысячи ресурсов наблюдения и поддерживать собственную иерархию устройств. Вместо подключения каждой камеры по отдельности шлюз может использовать эту существующую структуру в качестве источника видеоресурсов.

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

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

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

• Доступ на уровне платформы: подходит для устоявшихся систем видеонаблюдения GB28181 с централизованными каталогами ресурсов.

• Доступ на уровне NVR: подходит, когда несколько локальных каналов камер уже сконцентрированы в рекордере.

• Доступ на уровне камеры: подходит для выбранных совместимых камер, требующих прямой интеграции.

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

Адаптация кодеков и потоков улучшает совместимость

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

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

Шлюз может обеспечивать транскодирование между H.264 и H.265 при необходимости. Это позволяет камере продолжать использовать режим кодирования, подходящий для сети наблюдения, в то время как принимающая система связи получает поток, который она может декодировать.

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

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

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

Один видеоисточник может обслуживать несколько приложений

Интеграция видео часто выходит за рамки одного SIP-вызова. Центрам экстренного реагирования, браузерным приложениям, системам визуализации на больших экранах и сторонним бизнес-платформам может потребоваться доступ к одному и тому же ресурсу видеонаблюдения.

По этой причине шлюз GB28181 в SIP также может выступать в качестве точки распространения медиа. В дополнение к подключению GB28181 и интеграции, ориентированной на SIP, медиа-уровень может предоставлять распространенные форматы и протоколы потоковой передачи, такие как:

• FLV для совместимых веб- и стриминговых приложений.

• HLS для распространения видео на основе HTTP.

• WebRTC для сценариев связи на основе браузера с низкой задержкой.

• RTMP для рабочих процессов стриминга и публикации.

• RTSP для приложений, требующих традиционного доступа к потокам в реальном времени.

• Восходящий канал GB28181, когда видеоресурсы должны продолжать участвовать в иерархии наблюдения на основе стандартов.

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

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

Интеграция мобильного видео в центр управления

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

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

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

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

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

Проектирование интеграции как полного рабочего процесса

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

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

Следующий шаг — определить, как пользователи будут получать доступ к видео из системы связи. Некоторым проектам нужны только изображения наблюдения, встроенные в диспетчерскую консоль. Другие требуют одновременного SIP-видеозвонка, воспроизведения в браузере, отображения на большом экране и доступа к сторонним приложениям.

Совместимость кодеков также должна быть подтверждена перед развертыванием. Кодирование, используемое камерами наблюдения, следует сравнить с возможностями декодирования диспетчерских терминалов, браузеров и других принимающих приложений. Если эти возможности различаются, транскодирование можно ввести только для потоков, которые в этом нуждаются, вместо изменения каждой камеры.

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

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

Где эта архитектура приносит наибольшую пользу

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

В центре управления экстренными ситуациями видео наблюдения может быть связано с диспетчерскими операциями, чтобы операторы общались, одновременно просматривая место происшествия. На промышленном объекте существующие ресурсы CCTV могут быть введены в консоль связи, используемую для обработки инцидентов и операционной координации.

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

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

Заключение

Шлюз GB28181 в SIP предоставляет практический способ соединения двух систем, которые обе используют IP-видео, но применяют разные модели связи. Он может подключаться к существующей среде видеонаблюдения GB28181, получать ресурсы камер и NVR, преобразовывать выбранные видеоканалы в конечные точки, доступные через SIP, и адаптировать медиа, когда источник и получатель используют разные требования к кодированию.

Помимо базового преобразования протоколов, поддержка транскодирования H.264 и H.265, а также регулировка частоты кадров, битрейта и разрешения помогают решать реальные проблемы совместимости между устройствами видеонаблюдения и приложениями связи. Такие выходы, как FLV, HLS, WebRTC, RTMP, RTSP и GB28181, также позволяют использовать одни и те же видеоресурсы для более широкого круга приложений управления и визуализации.

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

Часто задаваемые вопросы

Требует ли внедрение шлюза замены существующей платформы управления видео?

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

Могут ли права доступа оставаться разными для пользователей наблюдения и связи?

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

Следует ли транскодировать каждый видеопоток?

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

Можно ли использовать шлюз, когда видео должно отображаться в веб-приложении?

Да, если выбранная архитектура шлюза обеспечивает совместимый с вебом медиа-выход, такой как WebRTC, HLS или FLV. Окончательный выбор зависит от задержки, совместимости с браузерами и способа проектирования приложения.

Что следует тестировать перед подключением большого каталога камер?

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