Что такое ONVIF? Протокол для инженеров

Кратко (TL;DR)

ONVIF – это открытый стандарт, благодаря которому камеры и софт записи от разных производителей понимают друг друга, причём на обычной веб-технологии: XML-сообщения в формате SOAP идут по сети, а машиночитаемые WSDL-файлы описывают, что устройство умеет. Он решает три конкретные задачи: даёт софту найти камеру (обнаружение), даёт софту управлять и забирать поток с камеры (сервисы) и упаковывает всё это в именованные профили – фиксированный список функций, которые обещают поддерживать и совместимая камера, и совместимый клиент, так что клиент Profile T гарантированно работает с устройством Profile T. Главный факт, который экономит больше всего денег и нервов: ONVIF гарантирует базис, а не каждую функцию – продвинутая аналитика, фирменные настройки и свежие параметры ИИ обычно всё равно требуют SDK производителя, и сам стандарт говорит об этом, называя такие возможности «условными… в том числе любым проприетарным способом». Эта статья объясняет, что ONVIF стандартизирует на самом деле, что он намеренно оставляет за бортом и как читать профиль, чтобы заложить мультивендорную систему без неприятных сюрпризов.

Почему это важно

Если вы проектируете или закупаете систему видеонаблюдения, фраза «это ONVIF, значит совместимо» звучит как конец разговора о совместимости – а на самом деле это его начало. Слово «ONVIF» в спецификации говорит, что камера говорит на общем языке, но не на каком диалекте, с какими функциями и проходит ли по этому языку та единственная возможность, на которой держится ваш проект. Ошибётесь – и уже после закупки выяснится, что камера подключается и стримит, но её аналитика подсчёта людей невидима вашему софту, или что «поддержка ONVIF» означала частичную реализацию, которая теряет половину событий. Понимание системы профилей, рукопожатия обнаружения и границы стандарта позволяет написать спецификацию, из которой вендор не вывернется, задать три вопроса, которые важны до покупки, и заранее знать, где понадобится фирменный SDK. Писать код не придётся; вы получите ментальную модель, которая удерживает мультивендорный парк камер от превращения в мультивендорную головную боль.

Что такое ONVIF на самом деле

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

ONVIF – Open Network Video Interface Forum – это и организация, и открытый стандарт, который даёт тот самый общий язык. Форум основали в 2008 году три тяжеловеса отрасли: Axis Communications, Bosch Security Systems и Sony. Заявленная миссия – «предоставлять и продвигать стандартизированные интерфейсы для эффективной интероперабельности IP-продуктов и сервисов физической безопасности» (ONVIF, Our Mission). Простыми словами – способ для камеры одного бренда и софта другого понять друг друга без ручного переводчика. Сегодня в форуме больше 500 компаний-участников на шести континентах, а их продукты в сумме дают более 33 000 профиль-совместимых наименований – поэтому «а ONVIF поддерживается?» – это первый вопрос о совместимости, который задаёт любой (ONVIF, Our Mission).

Два термина, прежде чем двигаться дальше, – на них держится остальная статья. Камера в словаре ONVIF – это устройство (device): то, что производит видео и отвечает на вопросы о себе. Система видеоменеджмента (VMS) – софт, который находит, настраивает, пишет и показывает много камер сразу – это клиент: тот, кто задаёт вопросы и отдаёт команды. (Если VMS, NVR и DVR всё ещё сливаются, наш разбор VMS, NVR и DVR их разводит.) Почти всё, что делает ONVIF, – это диалог клиента и устройства, и почти вся путаница вокруг ONVIF идёт от того, что забывают: свою часть диалога должны держать оба конца.

Полезная аналогия – разговорный язык. Английский не гарантирует, что два человека во всём согласятся; он гарантирует, что они смогут обмениваться мыслями вообще и что третий говорящий по-английски присоединится позже без личного репетитора. ONVIF – это то же для устройств безопасности. Он не делает все камеры одинаковыми и не делает любую функцию доступной везде. Он гарантирует, что совместимая камера и совместимый клиент разделяют достаточно общего словаря, чтобы найти друг друга, настроить видеопоток и обмениваться событиями, – и что позже можно подставить четвёртого вендора, не переписывая интеграцию с нуля.

Как ONVIF устроен внутри: веб-сервисы, а не магия

Вот часть, которую большинство обзоров пропускает, – а именно она демистифицирует всё остальное. ONVIF не изобрёл новую сетевую технологию. Он переиспользовал скучную, давно понятную механику веб-сервисов – то же семейство технологий, на котором бизнес-софт общается через интернет. Организация ONVIF говорит об этом прямо: «спецификации ONVIF основаны на веб-сервисах и используют открытые стандарты – XML, SOAP и WSDL – для описания обмена между двумя электронными устройствами по IP-сети» (ONVIF, Our Mission). Разберём эти три аббревиатуры простым языком, потому что это и есть весь движок.

XML – это способ записи структурированного текста, читаемого и человеком, и машиной: подписи вокруг значений, как форма с именованными полями. SOAP (Simple Object Access Protocol) – согласованный конверт, в который кладут XML-запрос, отправляют и получают XML-ответ; думайте о нём как о стандартном формате письма с «кому», «от кого» и телом, чтобы любая почта могла его доставить. WSDL (Web Services Description Language) – машиночитаемое меню: файл, который камера публикует и в котором перечислено, на какие вопросы она умеет отвечать и какой формы будут ответы. VMS читает меню WSDL, а затем шлёт SOAP-письма в XML, размещая заказы.

Нажмите, чтобы увеличить

Камера выставляет возможности как набор именованных сервисов – каждый это группа связанных команд. Управляющие интерфейсы стандарта ONVIF «описаны как веб-сервисы» с полными XML-схемой и WSDL-определениями (ONVIF Core Specification). Те, что важны для видеосистемы, легко назвать простыми словами:

• Device – это ресепшен: отвечает «кто ты, какая прошивка, что умеешь, выставь часы, управляй пользователями».
• Media выдаёт адрес потока – VMS просит «дай URI твоего главного видеопотока», и камера возвращает RTSP-адрес для подключения.
• PTZ двигает поворотную камеру; Imaging регулирует яркость, фокус и баланс белого.
• Events – способ камеры поднять руку («движение в зоне 2», «меня саботировали»), а VMS подписывается, чтобы это слышать.
• Analytics несёт структурированные описания того, что увидела бортовая аналитика, а Recording / Search / Replay позволяют клиенту управлять и забирать видео, записанное на самой камере.

Заметьте, что идёт по SOAP, а что – нет. Управляющий диалог – найти, описать, настроить, подписаться – это SOAP/XML. Само видео – нет. Когда сервис Media отдаёт адрес потока, VMS подключается к нему по RTSP (Real-Time Streaming Protocol, IETF RFC 2326) и получает сжатое видео по RTP. ONVIF – переговорщик, который устанавливает звонок; стриминговые протоколы несут сам звонок. Механика этой передачи – обнаружение, рукопожатие RTSP и кодек в канале – тема статьи-спутника как поток камеры попадает в VMS; здесь же важно одно: ONVIF организует поток, но не является потоком.

Обнаружение: как VMS находит камеру

Первое, что должен сделать общий язык, – представления. Прежде чем VMS отправит хоть одну SOAP-команду, она должна знать, что камера существует и где её достать. ONVIF решает это открытым протоколом WS-Discovery (Web Services Dynamic Discovery), и механизм – это один общий канал, который слышат все устройства локальной сети.

Конкретно: устройства говорят по одному известному адресу – шлют небольшие сообщения в multicast-группу 239.255.255.250 на UDP-порт 3702, где multicast значит одно сообщение, которое получают сразу все устройства сегмента, как объявление по громкой связи в комнате, а не личный звонок (OASIS, WS-Discovery 1.1). Камера, входя в сеть, объявляет о себе через Hello. VMS, ищущая камеры, кричит Probe – «есть тут ONVIF-устройства?». Каждая подходящая камера отвечает ProbeMatch, который несёт то, что VMS нужно дальше: адрес сервиса (ONVIF называет его XAddrs), где пойдёт настоящий SOAP-диалог.

Нажмите, чтобы увеличить

Эта граница – самый частый сюрприз больших развёртываний, поэтому скажем прямо: multicast-обнаружение локально (link-local). Оно достаёт устройства того же сегмента сети, а не за роутерами или отдельными VLAN, если только сеть специально не настроена их ретранслировать. Скан, который находит все камеры на плоском тестовом стенде, может найти ни одной, когда камеры живут в выделенном VLAN для камер – а это обычная практика. Это не отказ ONVIF; это multicast, ведущий себя как задумано. За этой границей VMS добавляет камеры вторым способом – вручную, по IP-адресу или сканированием диапазона IP, – и именно так подключают любой серьёзный парк. Операционное искусство подключения сотен камер – отдельная тема, разобранная в обнаружении и подключении камер в масштабе.

Ещё одно, чем обнаружение не является: обнаружение – это не доступ. Найти камеру значит узнать, что она есть; это не вход в неё. ONVIF аутентифицирует SOAP-диалог механизмом WS-UsernameToken, где клиент шлёт имя пользователя плюс одноразовое число и хэшированный (не открытый) дайджест пароля, вычисленный по спецификации (ONVIF Core Specification). Камера с заводским паролем по умолчанию – это задокументированная дыра в безопасности, а не удобство, и поскольку ONVIF явно оставляет реализацию безопасности производителю и интегратору, дефолтные учётные данные – ровно та брешь, которую стандарт за вас не закрывает.

Конкретный запрос: как выглядит обмен SOAP

Теория становится очевидной на одном примере. Допустим, VMS нашла камеру и хочет адрес её видеопотока. Она шлёт SOAP-запрос сервису Media – GetStreamUri – и камера отвечает RTSP-адресом для подключения. В сухом остатке обмен выглядит так:

<!-- VMS → камера: «дай адрес потока» (SOAP, упрощённо) -->
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetStreamUri xmlns="http://www.onvif.org/ver10/media/wsdl">
      <ProfileToken>MainStreamProfile</ProfileToken>
    </GetStreamUri>
  </s:Body>
</s:Envelope>

<!-- камера → VMS: «вот он» -->
<GetStreamUriResponse>
  <MediaUri>
    <Uri>rtsp://192.0.2.10:554/onvif/media/stream1</Uri>
  </MediaUri>
</GetStreamUriResponse>

Это весь паттерн, повторяемый для каждой возможности: VMS называет, что хочет, в XML-конверте, камера отвечает тем же. (Заметьте: слово «Profile» появляется здесь во втором, узком смысле – медиа-профиль (media profile) это собственный набор настроек потока камеры, не то же, что профили соответствия ONVIF, которым посвящена статья. Одно слово, два значения; держите их раздельно.) Вернувшийся адрес – это RTSP-URI, и это шов, где ONVIF передаёт эстафету стриминговому слою. Этот XML вам никогда не писать руками – это делает VMS, – но увидеть его полезно: ONVIF – это структурированные вопросы и структурированные ответы, ничего загадочнее.

Система профилей: как на самом деле работает соответствие

Если сервисы – это словарь, то профили – согласованные разговорники, и они сердце ONVIF, потому что превращают «поддерживает ONVIF» из расплывчатого заявления в проверяемое обещание. Профиль ONVIF, словами самой организации, – это «фиксированный набор функций, которые должны поддерживать совместимые устройство и клиент», устроенный так, что «клиент, соответствующий Profile T, будет работать с устройством, которое тоже соответствует Profile T» (ONVIF, Profiles). Перечитайте дважды – в этом прячутся две идеи.

Во-первых, профиль – это фиксированный чек-лист, а не размытый значок. Если камера заявляет Profile T, должны присутствовать все обязательные функции Profile T – не «большинство», не «те, до которых дошли руки». Во-вторых, соответствие – это двустороннее обещание: устройство соответствует, и клиент соответствует, и гарантия существует только там, где эти двое пересекаются. Камера Profile T в паре с клиентом, поддерживающим только Profile S, даёт базис Profile S, а не Profile T. Продукт – это совпадение, а не каждая половина по отдельности. ONVIF говорит о следствии прямо: «соответствие профилям – единственный способ обеспечить совместимость между ONVIF-совместимыми продуктами», и только продукты, зарегистрированные в списке совместимых продуктов ONVIF, вообще считаются совместимыми (ONVIF, Profiles).

В 2026 году активны семь профилей, и они чётко делятся на видео и контроль доступа. Устройство или клиент может держать больше одного – «сетевая камера с локальным хранилищем может соответствовать и Profile T, и Profile G» (ONVIF, Profiles), – так что думайте о них как о меню, которое комбинируют, а не как об одной ступени лестницы.

Таблица 1. Семь активных профилей ONVIF (2026). Профили – это меню, а не лестница: современной IP-видео VMS обычно нужна связка S/T + G + M, а A/C/D добавляют, только если в задаче есть контроль доступа. Profile Q выведен в 2022 году.

Для современной видеосистемы рабочий ответ короток. Берите Profile T для стрима (с Profile S как запасным для старого железа примерно 2016 года), добавляйте Profile G, если нужно управлять записями на камере, и Profile M, если метаданные аналитики должны доходить до вашего софта. Это и есть системная связка. Подробное, по-функциональное решение, какой именно профиль нужен вашему продукту – с разбором обязательных и условных функций и пути миграции стрима – это отдельный гид, и мы так к нему и относимся: Профили ONVIF S, G, T и M – какой профиль нужен вашему продукту. Для коммерческого обзора системы профилей «с высоты птичьего полёта» собственный гид Фора Софт по профилям ONVIF в системах безопасности – спутник к этому инженерному разбору.

Нажмите, чтобы увеличить

Одно замечание про текущий момент, которое стоит унести с собой: Profile S, первый профиль стрима 2012 года, выводят из обращения. ONVIF держит его в формальной депрекации: последняя дата подачи заявок на соответствие новых продуктов – 31 марта 2027 года, и в качестве преемника указан Profile T (ONVIF, Profile S). Устройства Profile S, уже стоящие в поле, продолжают работать; меняется то, что центр тяжести отрасли для стрима сместился на Profile T – поэтому спецификация 2026 года должна называть Profile T первым.

Что ONVIF *не* стандартизирует

Это раздел, который пропускают листиклы, и именно он спасает от дорогих ошибок. ONVIF – это базис, а не потолок, и знание, где потолок, держит проект честным.

Он не стандартизирует качество аналитики. Profile M стандартизирует интерфейс аналитики: как камера описывает «человек пересёк линию» или «появился номер» и как эти метаданные доходят до вашего софта (ONVIF, Profile M). Он ничего не говорит о том, насколько точно это распознавание. Две камеры Profile M могут обе корректно говорить на языке метаданных, при этом одна надёжно детектирует людей, а другая теряет половину в темноте. Соответствие – про водопровод результата, никогда про его истинность; и поскольку ни один аналитик не идеально точен, судите о точности по измеренным precision и recall в вашей сцене, а не по значку ONVIF. Внутреннее устройство этих детекций – как на самом деле работают детекция объектов, трекинг и распознавание – живёт в нашем разделе ИИ для видеоинженерии; ONVIF лишь переносит вердикт.

Он не стандартизирует каждую функцию камеры. Это суть, и стандарт говорит это сам. Кроме обязательных функций, профили определяют условные – функции, которые «должны быть реализованы ONVIF-устройством или ONVIF-клиентом, если он поддерживает эту функцию хоть как-то, в том числе любым проприетарным способом» (ONVIF, Profiles). На практике производители выставляют свои свежие и самые отличительные возможности – продвинутые зоны движения, корридорный режим, специфичные для камеры параметры ИИ, фирменную аналитику – через собственные SDK, а не через ONVIF. Axis публикует VAPIX, Hikvision – ISAPI, Dahua поставляет SDK, и они открывают более глубокий набор функций, чем достают профили ONVIF (Camera Authority). Правило для запоминания: ONVIF-совместимый – не то же, что полнофункциональный по ONVIF. Базис идёт по стандарту; фронтир обычно требует собственного набора вендора – компромисс, который мы разбираем в проприетарных SDK камер: когда ONVIF недостаточно.

Он не гарантирует полноту реализации. «Поддержка ONVIF» на коробке может означать частичную реализацию – некоторые вендоры реализуют лишь подмножество функций профиля, что даёт частичную совместимость, которая выглядит нормально, пока недостающим куском не окажется тот, что вам был нужен (Camera Authority). Единственная реальная гарантия – реестр совместимых продуктов ONVIF плюс ваш собственный тест, а не маркетинговая строка.

Он не стандартизирует регуляторный комплаенс или уровень безопасности. ONVIF здесь прям: «соответствие нормам… вне области ONVIF», и производители, архитекторы и интеграторы остаются «ответственными за проверку регуляторных и иных локальных требований… и за внедрение надлежащего уровня безопасности под сценарий» (ONVIF, Profiles). ONVIF ссылается на современные стандарты кибербезопасности, но соответствие не закаляет вашу систему за вас и уж точно не делает развёртывание распознавания лиц законным. Слой приватности и права – отдельная дисциплина целиком.

Нажмите, чтобы увеличить

Математика интеграции: зачем нужен стандарт

Справедливо спросить, стоит ли общий язык того ограничения, которое он накладывает. Арифметика отвечает чисто. Представьте интегратора, который поддерживает 8 производителей камер и 5 платформ записи, и допустим, общего стандарта нет. Каждому производителю камер понадобилась бы ручная интеграция под каждую платформу, так что число интеграций, которые надо строить и держать, – это произведение двух чисел:

интеграции без стандарта = производители камер × платформы = 8 × 5 = 40 ручных интеграций

Теперь добавьте ещё одного производителя камер. Без стандарта вы добавляете не одну интеграцию, а пять – по одной на платформу, потому что новую камеру нужно «научить» каждой платформе отдельно. Стоимость растёт умножением, и каждая интеграция – это то, что ломается, когда обновляется любой из концов.

С ONVIF каждая сторона реализует один стандарт один раз. Производитель камер соответствует ONVIF; платформа соответствует ONVIF; они встречаются посередине. Число реализаций теперь сумма, а не произведение:

реализации со стандартом = производители камер + платформы = 8 + 5 = 13 реализаций

Добавить девятого производителя теперь стоит ровно одну новую реализацию, а не пять. Сорок падает до тринадцати, а темп роста – с умножения до сложения. Этот обвал – с N×M до N+M – и есть весь экономический аргумент за ONVIF, и именно поэтому стандарт, который «всего лишь» гарантирует базис, остаётся одним из самых результативных решений в проекте наблюдения.

Нажмите, чтобы увеличить

Частая ошибка, которой стоит избегать

Самый дорогой паттерн в закупке наблюдения – считать логотип ONVIF гарантией, что всё «просто заработает», и у него три лица. Первое – считать, что соответствие покрывает именно ту функцию, что вам важна: оно покрывает чек-лист профиля, так что если проект живёт или умирает на конкретной аналитике или настройке камеры, убедитесь, что эта возможность идёт по ONVIF, – или заложите путь через SDK вендора до покупки, а не после. Второе – доверять «поддержке ONVIF» без проверки реестра и теста: частичная реализация может устроить продавца и провалить вашу интеграцию, так что проверьте устройство в списке совместимых продуктов ONVIF и проведите реальный тест подключения с вашей настоящей VMS. Третье – считать, что оба конца равны: соответствие двустороннее, и полностью совместимая камера в паре с клиентом, реализующим лишь более старый профиль, даёт меньший общий знаменатель. Ни одно из этого не экзотично; всё три предсказуемы, и все три гораздо дешевле заложить в проект, чем обнаружить в продакшене.

Где здесь Фора Софт

Фора Софт строит софт реального времени для видео, стриминга и компьютерного зрения с 2005 года, на счету 250+ выпущенных проектов, и ONVIF – это место, где мультивендорные продукты наблюдения тихо выживают или проваливаются. Сложное – никогда не одна совместимая камера на стенде; это пара сотен камер от нескольких производителей, часть образцово совместима, а часть требует обойти вендорскую особенность, и все они должны обнаружиться, авторизоваться, отдать поток и вынести свои события в одну платформу – и продолжать это делать после того, как обновление прошивки меняет поведение камеры. Мы строим этот слой: обнаружение и подключение по ONVIF, чистый откат на RTSP, когда ONVIF-путь медиа у устройства неполон, и параллельный путь через SDK (VAPIX, ISAPI и другие) для продвинутых функций, до которых стандарт не достаёт. Мы ведём с того, как интеграция ведёт себя в плохой день – частичная реализация, регресс прошивки, – а потом уже список функций, потому что слой интероперабельности, переживающий несовместимую камеру, лучше того, что красиво демонстрируется на идеальной. Forasoft.com занимает первое место по запросу «onvif camera», и это место держится на том, что мы делаем эту работу, а не просто читаем спецификацию.

Ключевые выводы

• ONVIF – это стандарт на веб-сервисах (XML, SOAP, WSDL) для интероперабельности мультивендорных камер и софта.
• Он делает три вещи: находит устройства, управляет и стримит их, упаковывает функции в именованные профили.
• Профиль – это фиксированный чек-лист функций, которому должны соответствовать и устройство, и клиент.
• Profile T – базис стрима 2026; Profile S выводится (последние заявки 2027-03-31).
• ONVIF гарантирует базис – продвинутые и фирменные функции обычно требуют SDK вендора.
• «Соответствие ONVIF» никогда не значит полноту функций, законность или измеренную точность аналитики.

Что почитать дальше

• Профили ONVIF S, G, T и M – какой профиль нужен вашему продукту
• Как поток камеры попадает в VMS: обнаружение, RTSP и кодеки
• Проприетарные SDK камер: когда ONVIF недостаточно