ONVIF

ONVIF is the IP physical-security interoperability framework used by cameras, encoders, `VMS` / `NVR` platforms, analytics services, access-control devices, and some AV/security crossover control platforms. It is not one media protocol. In practical designs, ONVIF normally provides discovery, device/service description, configuration/control, profile/add-on conformance, PTZ/event/metadata/recording interfaces, and stream URI negotiation. The live media path usually still resolves to `RTSP/RTP` or another ONVIF-defined streaming mode, with codec and security behavior decided by the profile, firmware, and client implementation. **Sources:** ONVIF mission / governance <https://www.onvif.org/about/mission/>; ONVIF profiles overview <https://www.onvif.org/profiles/>; ONVIF network interface specifications <https://www.onvif.org/profiles-specifications-new/>; ONVIF specification history <https://www.onvif.org/profiles/specifications/specification-history/>; ONVIF conformance process <https://www.onvif.org/profiles/conformance/>; ONVIF conformance FAQ <https://www.onvif.org/conformance-faq/>; ONVIF Profile `T` <https://www.onvif.org/profiles/profile-t/>; ONVIF Profile `G` <https://www.onvif.org/profiles/profile-g/>; ONVIF Profile `M` <https://www.onvif.org/profiles/profile-m/>; ONVIF Profile `S` deprecation Q&A <https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/>; ONVIF Profile `D` <https://www.onvif.org/profiles/profile-d/>; ONVIF Profile `Q` <https://www.onvif.org/profiles/profile-q/>; ONVIF TLS Configuration Add-on <https://www.onvif.org/profiles/add-on/tls-configuration-add-on/>; OASIS `WS-Discovery 1.1` <https://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html>; IANA service-name registry <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>; ONVIF Streaming Specification v25.12 <https://www.onvif.org/specs/2512/ONVIF-Streaming-Spec-v2512.pdf> — accessed 2026-05-11 **Infra context:** Treat `ONVIF` as a management/control/discovery layer plus a pointer into separate media services, not as a single firewall exception. For a camera/VMS path, schedule `WS-Discovery` only if automatic discovery is required, schedule the actual device service endpoint over `HTTP` or `HTTPS`, schedule `RTSP` / secure streaming according to the selected profile and camera configuration, and then schedule the negotiated `RTP` / `RTCP` media behavior. For routed enterprise networks, manual camera enrollment is often cleaner than trying to make multicast discovery cross VLANs. | Port / Range | Protocol | Direction | Purpose | Configurable | |---|---|---|---|---| | UDP 3702 to multicast `239.255.255.250` / `ff02::c` | UDP multicast | B on local segment | `WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually. | No | | TCP 80 / 8080 / vendor-specific service port | TCP | B | ONVIF device/client web-services endpoint over `HTTP`, typically SOAP/XML using ONVIF WSDL-defined services. Used for device information, capabilities, media profiles, stream URI retrieval, PTZ/configuration functions, events, user/access functions, and profile/add-on features as implemented. Exact path and port are product/firmware configurable in many cameras. | Usually | | TCP 443 / vendor-specific secure service port | TCP | B | ONVIF web-services endpoint over `HTTPS` where supported. Required by some security-conscious deployments and relevant to `Profile T` / secure-streaming designs, but `HTTPS` alone does not prove the device exposes certificate lifecycle controls or the `TLS Configuration Add-on`. | Usually | | TCP 554 | TCP | B | `RTSP` session/control channel commonly returned by ONVIF media services for live stream setup. IANA registers both `TCP` and `UDP 554` for `RTSP`; in deployed camera work, `TCP 554` and vendor alternate ports such as `8554` are common. | Usually | | TCP 8554 or other configured `RTSP` alternate | TCP | B | Alternate `RTSP` listener where the camera/vendor/VMS does not use `554`, or where multiple services share an appliance. Do not open this by default; verify the selected device/client configuration. | User-configurable | | UDP dynamic `RTP` / `RTCP` ports | UDP | Usually O from camera to client / recorder for media, with control/statistics return as negotiated | Live media payload after `RTSP` setup when `RTP/UDP` is used. There is no universal ONVIF port number; the session description and transport setup decide the client/server ports. | Dynamic / negotiated | | `RTSP` interleaved over TCP 554 / 8554 / configured port | TCP | B | Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss. | Depends on client/device | | `RTSP` over `HTTP` / `HTTPS` or `WebSocket` modes | TCP | B | ONVIF streaming specifications define additional traversal/secure modes, including secure `RTSPS` and `SRTP` carriage. These are not universal camera defaults; schedule only when the selected profile/firmware/client actually supports and is configured for them. | Depends on client/device | **IT notes:** - `ONVIF` is governed by `ONVIF, Inc.`, a non-profit member forum founded in `2008` by Axis Communications, Bosch Security Systems, and Sony Corporation. Its mission is standardized interfaces for IP-based physical security products and services, not general-purpose AV distribution. - The protocol family is web-services based: `XML`, `SOAP`, and `WSDL` define the control/configuration interfaces. That is why "ONVIF API" usually means SOAP/XML service calls rather than a modern JSON/REST API. - `WS-Discovery` is local multicast. OASIS assigns `UDP 3702`, IPv4 multicast `239.255.255.250`, and IPv6 link-local multicast `ff02::c`. Discovery failure across VLANs does not prove ONVIF is broken; it often only proves multicast discovery is not routed or proxied. - Manual enrollment by IP/FQDN and ONVIF service path is a valid enterprise design. It is often preferable for camera VLANs, secured networks, and large estates where discovery broadcast/multicast should not leak widely. - Do not collapse `ONVIF` with `RTSP`. ONVIF may tell the client what media profiles exist and return stream URIs; `RTSP/RTP`, codec support, keyframe cadence, transport mode, and client decoder behavior still decide whether the picture is usable. - `Profile T` is the new-design video target for advanced streaming. ONVIF states it supports `H.264` / `H.265`, imaging settings, motion/tampering events, metadata streaming, `HTTPS` streaming support, PTZ configuration, and conditional bidirectional audio/digital I/O/relay features. - `Profile S` is being deprecated for security reasons. ONVIF says support for new Profile S conformance submissions ends on `2027-03-31` because its username-token authentication requirement no longer aligns with current cybersecurity recommendations. Keep legacy `Profile S` systems contained; do not specify it as the preferred new-design target. - `Profile G` is the edge-recording/storage profile. If the brief requires local camera recording, failover recording, or standards-based retrieval/playback from device storage, `Profile T` alone is incomplete. - `Profile M` is the analytics metadata/events profile. If people counting, object classification, license plate recognition, face/body metadata, analytics eventing, or MQTT-facing IoT handoff matters, name `Profile M` explicitly and verify client support. - Access-control scope is not automatically covered by a camera/video profile. `Profile A`, `Profile C`, and `Profile D` are the access-control side of the ONVIF family; `Profile D` is for access-control peripherals and is not itself an access-control unit. Schedule the actual door controller, reader/peripheral, lock/relay, event, credential, video, and management paths rather than writing one generic ONVIF line. - Do not use deprecated `Profile Q` as a security or commissioning baseline. ONVIF says Profile Q was deprecated on `2022-04-01` because factory-default setup required anonymous access to all ONVIF commands. - Add-ons are separate conformance claims layered on top of profiles. A device being `Profile T` conformant does not mean it supports the `TLS Configuration Add-on`, and the current TLS add-on v1.0 conformance submission path is itself in deprecation with version `2.0` scheduled for early `2027`. - ONVIF conformance is profile-specific, feature-level, and tied to an exact firmware/software version. ONVIF says only products registered in its Conformant Products database are considered conformant, and membership or marketing language alone is not enough. - ONVIF conformance is a member self-declaration scheme using ONVIF test tools and submitted conformance documents. That is useful, but it is not a substitute for bench-testing the actual required workflows: discovery/manual enrollment, authentication, stream profile selection, PTZ, presets, backchannel audio, event subscription, metadata, recording retrieval, and TLS/certificate behavior. - The current public conformance-process page points to `ONVIF Conformance Process Specification` version `5.7` from April `2026`; in infrastructure terms, that reinforces the same rule: ask for the product's ONVIF database record, claimed profile(s), firmware/software version, feature list, and interface guide, not just a logo on a datasheet. - Security responsibility does not end at the ONVIF logo. Segment camera networks, restrict ONVIF/RTSP access to the VMS/control hosts that need it, disable unused insecure services, prefer `HTTPS`/secure profiles where supported, and coordinate firmware/security-hardening ownership with the security integrator or IT team. - ONVIF is good for cross-vendor surveillance interoperability and AV/security crossover camera integration. It is poor for deterministic AV-over-IP distribution, live production switching, IMAG, low-latency operator camera contribution, or as a generic room-AV PTZ command language when `VISCA over IP` or a vendor API is the cleaner supported path.

Network Ports & Requirements

Port(s)	Transport	Direction	Purpose	DSCP	Multicast	Config.
3702	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
239	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
255	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
255	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
250	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
2	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
—	TCP	Both	ONVIF device/client web-services endpoint over `HTTP`, typically SOAP/XML using ONVIF WSDL-defined services. Used for device information, capabilities, media profiles, stream URI retrieval, PTZ/configuration functions, events, user/access functions, and profile/add-on features as implemented. Exact path and port are product/firmware configurable in many cameras.	—	—	No
443	TCP	Both	ONVIF web-services endpoint over `HTTPS` where supported. Required by some security-conscious deployments and relevant to `Profile T` / secure-streaming designs, but `HTTPS` alone does not prove the device exposes certificate lifecycle controls or the `TLS Configuration Add-on`.	—	—	No
554	TCP	Both	`RTSP` session/control channel commonly returned by ONVIF media services for live stream setup. IANA registers both `TCP` and `UDP 554` for `RTSP`; in deployed camera work, `TCP 554` and vendor alternate ports such as `8554` are common.	—	—	No
8554	TCP	Both	Alternate `RTSP` listener where the camera/vendor/VMS does not use `554`, or where multiple services share an appliance. Do not open this by default; verify the selected device/client configuration.	—	—	Yes
—	UDP	Both	Live media payload after `RTSP` setup when `RTP/UDP` is used. There is no universal ONVIF port number; the session description and transport setup decide the client/server ports.	—	—	No
554	TCP	Both	Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss.	—	—	No
8554	TCP	Both	Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss.	—	—	No
—	TCP	Both	ONVIF streaming specifications define additional traversal/secure modes, including secure `RTSPS` and `SRTP` carriage. These are not universal camera defaults; schedule only when the selected profile/firmware/client actually supports and is configured for them.	—	—	No

AV500.io