Структура ONVIF-запроса и ответа

В этой части лекции мы рассмотрим, как выглядит реальное сетевое взаимодействие между клиентом и ONVIF-устройством. Цель — не научить разрабатывать SOAP-клиенты, а помочь понимать структуру сообщений, которые проходят по сети. Это особенно важно при диагностике: инженеру часто приходится анализировать логи, перехватывать трафик или читать ответы от камеры, чтобы понять, почему не удаётся получить поток или настроить событие.

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

Логическая структура ONVIF-сообщения

ONVIF использует SOAP (Simple Object Access Protocol) как формат обмена сообщениями. Это означает, что все запросы и ответы — это XML-документы, упакованные в стандартную оболочку. SOAP не является частью ONVIF, а лишь средством передачи данных. Однако понимание его структуры помогает читать и интерпретировать реальный трафик.

SOAP-сообщение состоит из двух основных частей:

Обёртка (Envelope) — корневой элемент, который определяет начало и конец сообщения.
Тело (Body) — содержит непосредственно команду или ответ.

Иногда используется также заголовок (Header), в котором могут передаваться метаданные: аутентификация, идентификаторы сессий, адреса назначения.

Пример упрощённой структуры:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header> ... </soap:Header>
  <soap:Body>
    <GetProfiles xmlns="http://www.onvif.org/vermedia/wsdl"/>
  </soap:Body>
</soap:Envelope>

Каждый элемент в этом XML имеет пространство имён (namespace), которое указывает, к какой спецификации он относится. Например, vermedia — это пространство имён для сервиса управления медиапотоками. Это важно, потому что ONVIF использует множество сервисов, и без чёткой привязки к спецификации нельзя однозначно интерпретировать команду.

Пример: запрос на получение профилей

Рассмотрим реальный сценарий. Допустим, клиент (например, видеорегистратор или утилита диагностики) хочет узнать, какие видеопрофили доступны на камере. Он отправляет запрос к Media Service — одному из ключевых сервисов ONVIF.

Запрос

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
               xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl"
               xmlns:tds="http://www.onvif.org/ver10/device/wsdl"
               xmlns:trt="http://www.onvif.org/ver10/media/wsdl">
  <soap:Header>
    <wsa:Action>http://www.onvif.org/ver10/media/wsdl/GetProfiles</wsa:Action>
    <wsa:To>http://192.168.1.100:80/onvif/media_service</wsa:To>
  </soap:Header>
  <soap:Body>
    <trt:GetProfiles/>
  </soap:Body>
</soap:Envelope>

Разберём ключевые элементы:

wsa:Action — указывает, какую операцию вызывает клиент. В данном случае это GetProfiles, определённая в спецификации Media Service.
wsa:To — адрес сервиса, к которому идёт обращение. Здесь: http://192.168.1.100:80/onvif/media_service. Это URL конечной точки (endpoint), который был получен ранее, например, через запрос GetCapabilities.
trt:GetProfiles — сама команда. Префикс trt указывает на пространство имён Media Service (ver10/media/wsdl).

Обратите внимание: в этом запросе нет параметров. GetProfiles — это простая команда, которая возвращает все доступные профили. Но даже в таком простом случае важно понимать, куда и как идёт запрос.

Пример: ответ от камеры

После получения запроса камера формирует ответ. Вот как он может выглядеть (упрощённо):

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Body>
    <trt:GetProfilesResponse>
      <trt:Profiles token="Profile_1">
        <tt:Name>VideoProfile01</tt:Name>
        <tt:VideoSourceConfiguration token="VideoSrcCfg1">
          <tt:Name>SourceCfg1</tt:Name>
          <tt:UseCount>1</tt:UseCount>
          <tt:SourceToken>VideoSrcToken1</tt:SourceToken>
        </tt:VideoSourceConfiguration>
        <tt:VideoEncoderConfiguration token="VideoEncCfg1">
          <tt:Name>EncoderCfg1</tt:Name>
          <tt:Encoding>H264</tt:Encoding>
          <tt:Resolution>
            <tt:Width>1920</tt:Width>
            <tt:Height>1080</tt:Height>
          </tt:Resolution>
          <tt:RateControl>
            <tt:FrameRateLimit>30</tt:FrameRateLimit>
            <tt:BitrateLimit>4096</tt:BitrateLimit>
          </tt:RateControl>
        </tt:VideoEncoderConfiguration>
        <tt:PTZConfiguration token="PTZToken1"/>
        <tt:StreamSetup>
          <tt:Transport>
            <tt:Protocol>RTSP</tt:Protocol>
          </tt:Transport>
        </tt:StreamSetup>
      </trt:Profiles>
    </trt:GetProfilesResponse>
  </soap:Body>
</soap:Envelope>

Разберём основные компоненты ответа:

1. Токен профиля (`token="Profile_1"`)

Это уникальный идентификатор профиля. Он используется во всех последующих операциях: при получении RTSP-ссылки, настройке кодирования, управлении PTZ.
Пример: Чтобы получить URL потока, клиент должен указать этот токен в запросе GetStreamUri.

2. Конфигурация источника видео (`VideoSourceConfiguration`)

Определяет, с какого сенсора берётся изображение. Содержит:

SourceToken — идентификатор источника (например, основная камера или термокамера).
UseCount — сколько сервисов используют эту конфигурацию.

3. Конфигурация кодировщика (`VideoEncoderConfiguration`)

Описывает параметры видеопотока:

Кодек: H264
Разрешение: 1920×1080
Частота кадров: до 30 fps
Битрейт: до 4096 Кбит/с

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

4. Транспорт (`StreamSetup`)

Указывает, по какому протоколу можно получить поток. В данном случае — RTSP. Это означает, что после получения профиля клиент может запросить URL потока и передать его медиаплееру.

Как инженер читает такие сообщения

При диагностике ONVIF-взаимодействия важно уметь быстро находить ключевые элементы. Вот на что стоит обращать внимание:

Элемент	Значение для диагностики
`wsa:To`	Проверка: правильно ли указан адрес сервиса? Доступен ли он в сети?
`wsa:Action`	Соответствует ли операция ожидаемой? Ошибка здесь может означать неправильный URL или версию спецификации.
`token` в ответе	Уникальный идентификатор для последующих вызовов. Его отсутствие — признак ошибки конфигурации.
`Encoding`, `Resolution`	Подтверждение, что камера поддерживает нужный формат. Если в ответе не то, что ожидается — возможно, профиль настроен неверно.
`Protocol` в `StreamSetup`	Гарантирует, что можно использовать RTSP. Если указан `HTTP`, это может повлиять на производительность.

Визуализация процесса

Представьте, что вы подключаете камеру к системе. Первое, что делает ПО:

Находит камеру в сети (через WS-Discovery).
Получает список сервисов (GetCapabilities).
Обращается к Media Service по его URL.
Запрашивает профили (GetProfiles).
Анализирует ответ: есть ли H.264, 1080p, RTSP?
Использует токен профиля, чтобы получить RTSP-URL (GetStreamUri).

Если на каком-то шаге ответ приходит с ошибкой или содержит неожиданные данные — вы возвращаетесь к логам и смотрите, что именно пришло в XML.

Типичные проблемы и как их видеть в сообщениях

Сервис не найден (404 Not Found)
В заголовке wsa:To указан неверный путь. Например, /onvif/media вместо /onvif/media_service.
→ Проверьте, какой именно endpoint вернула GetCapabilities.
Операция не поддерживается (Action Not Supported)
В wsa:Action указана команда, которой нет в реализации камеры.
→ Убедитесь, что камера поддерживает нужный профиль (например, Profile S).
Пустой ответ или отсутствие профилей
Камера может быть сброшена или повреждена конфигурация.
→ Проверьте, возвращает ли GetServices Media Service.
Нет RTSP в StreamSetup
Камера может быть настроена только на HTTP-потоки.
→ Это ограничение производителя, даже если ONVIF формально поддерживается.

Заключение

Понимание структуры ONVIF-запросов и ответов — это не про программирование, а про инженерную диагностику. Вы не обязаны писать SOAP-клиенты вручную, но должны уметь читать логи, понимать, откуда берётся RTSP-URL, и почему камера может не отвечать.

Ключевые моменты:

ONVIF использует SOAP поверх HTTP — сообщения — это XML.
Каждый запрос указывает что делать (Action) и куда отправлять (To).
Ответ содержит токены, параметры видео и информацию о транспорте.
Эти данные используются на следующих этапах: получение потока, управление PTZ, настройка событий.

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

Вложения

05-02-03.png

Логическая структура ONVIF-сообщения​

Пример: запрос на получение профилей​

Запрос​

Пример: ответ от камеры​

1. Токен профиля (token="Profile_1")​

2. Конфигурация источника видео (VideoSourceConfiguration)​

3. Конфигурация кодировщика (VideoEncoderConfiguration)​

4. Транспорт (StreamSetup)​

Как инженер читает такие сообщения​

Визуализация процесса​

Типичные проблемы и как их видеть в сообщениях​

Заключение​

Вложения​