ONVIF vs RTSP: в чём разница и что когда использовать

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

Коротко, для тех кто спешит

RTSP — протокол транспорта видеопотока. Он отвечает на один вопрос: «как передать видео от камеры к клиенту». Ничего больше.

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

Немного истории

RTSP (Real-Time Streaming Protocol) — RFC 2326, опубликован в 1998 году Netscape, RealNetworks и Columbia University. Тогда это был универсальный протокол стриминга всего подряд — фильмы, радио, видеоконференции. Сейчас единственная живая ниша, где он массово используется, — видеонаблюдение.

ONVIF (Open Network Video Interface Forum) — стандарт, разработанный Axis, Bosch и Sony в 2008 году. Цель была одна: сделать так, чтобы камера одного вендора могла работать в видеоклиенте другого без плясок с бубном. К 2024 году более 25 000 моделей от 500+ производителей заявили совместимость с ONVIF. Не все из них, надо сказать, её реально реализуют.

Что такое ONVIF Profile

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

Для нашей задачи (подключение к облачному клиенту) минимум — Profile S, оптимум — S + T. Profile M становится обязательным для AI-интеграций — передача найденных объектов вместе с видеопотоком.

Как это выглядит в URL

RTSP-поток обычно доступен по URL вида:

rtsp://login:password@192.168.1.64:554/Streaming/Channels/101

Конкретный путь зависит от вендора:

Hikvision:  rtsp://user:pass@ip:554/Streaming/Channels/101
Dahua:      rtsp://user:pass@ip:554/cam/realmonitor?channel=1&subtype=0
РуКлауд:    rtsp://user:pass@ip:554/stream1
TRASSIR:    rtsp://user:pass@ip:554/live/main

Количество таких диалектов — одна из причин, зачем нужен ONVIF. Клиент, поддерживающий ONVIF, сам спрашивает у камеры: «дай мне список твоих потоков». Камера отвечает структурированным XML с URL каждого потока, параметрами и URI для подписки на события. Интегратор не задумывается, Hikvision это или какой-то Dahua.

Реальный пример: подписка на события

Представьте, что нужно запустить запись в облако только при движении. Через RTSP это в принципе невозможно — он только поток. Либо вы пишете всё 24/7, либо настраиваете детекцию на стороне сервера (а это гигабайты данных, прошедших по сети).

Через ONVIF Profile T клиент подписывается на Events и получает XML уведомления в реальном времени:

<tt:NotificationMessage>
  <tt:Topic>tns1:VideoSource/MotionAlarm</tt:Topic>
  <tt:Message UtcTime="2026-03-04T11:14:27Z">
    <tt:Source>VideoSourceConfigToken_1</tt:Source>
    <tt:Data>
      <tt:SimpleItem Name="State" Value="true"/>
    </tt:Data>
  </tt:Message>
</tt:NotificationMessage>

Получили — запустили запись. Через 30 секунд пришло State=false, остановили запись. Одного потока по сети не течёт, пока никого нет. Это и есть «умная запись» в облаке РуКлауд.

Когда достаточно чистого RTSP

RTSP без ONVIF — нормальный выбор для простой задачи «покажи мне поток с камеры в VLC или в мобильном приложении». Если вы подключаете одну камеру для мониторинга и всё управление, включая запись, делается на стороне сервера (например, ffmpeg + диск) — ONVIF не обязателен.

Также RTSP самодостаточен при трансляциях: ТВ-трансляции рабочих зон на рецепции, подтверждение присутствия в офисе для внутренней системы.

Когда ONVIF необходим

• Интеграция нескольких камер разных вендоров в один клиент.
• Включение событийно-ориентированной записи (motion, tampering, detect objects).
• Удалённое управление PTZ, пресетами, imaging-настройками.
• Работа с локальным архивом камеры (скачивание сегментов, поиск по времени).
• Интеграция с AI-аналитикой и передача bounding boxes.
• Сертификация системы по ГОСТ Р или международным стандартам — там часто требуется именно ONVIF-совместимость.

Подводные камни

Даже камеры с галочкой «ONVIF Profile S» могут не работать в конкретном клиенте. Причины:

• Разные версии ONVIF. 2.40 и 22.12 сильно отличаются в описании событий. Клиент, написанный под старую версию, не распарсит новые сообщения.
• Проприетарные расширения. Производитель добавил своё поверх ONVIF, а при включении этого режима перестают работать стандартные запросы. Всегда смотрите в настройках «ONVIF legacy mode».
• Время камеры. ONVIF использует WS-Security, подпись с временной меткой. Если часы камеры и клиента разойдутся больше чем на 5 минут, авторизация не проходит. Всегда настраивайте NTP.
• Авторизация. Многие старые прошивки Hikvision и Dahua по умолчанию отключают ONVIF-пользователя или требуют явно его создать. Без этого шага камера «видна» по ONVIF discovery, но ни на один запрос не отвечает.

Что в РуКлауд

Наши камеры поддерживают ONVIF Profile S + T + G и совместимы с клиентами TRASSIR, Macroscop, Axxon, VideoNet, RVi-оператор и десятком других. Мы не закрываем ONVIF в пользу своего протокола — всё, что делает мобильное приложение РуКлауд, можно повторить через ONVIF.

При этом для связи камеры с нашим облаком мы используем собственный протокол поверх WebSocket + SRT — он лучше переживает обрывы и плохие каналы связи, чем классический RTSP через TCP. Но снаружи, для интеграций, ONVIF всегда доступен. Если хотите подключить камеру РуКлауд в стороннюю VMS — без проблем.

Простое правило: если вы покупаете камеру, которая должна работать в вашей существующей системе, требуйте ONVIF Profile S как минимум. Если вендор настаивает, что «наши камеры работают только с нашим клиентом» — скорее всего, это плохой знак на долгую перспективу.

Подробнее про то, как мы выстроили связь камер с облаком без белого IP и проброса портов, читайте в статье «P2P без белого IP».