ONVIF

What you can build

• Find out a camera is down before the night shift does

  Pull tns1:Monitoring/LinkStatus and tns1:Device/HardwareFailure events from every camera, compare against the expected device list, and propose a ticket with the last GetSystemLog entries.

  With Camera Health

• Attach the clip to the door alarm

  When a controller reports DoorOpenTooLong through tns1:Door/State/DoorAlarm, run FindRecordings on the camera covering that door and propose an incident record with the recording window.

  With Door Held Open, Incident Draft

• Review a tailgate with the video already found

  Match an access event to FindEvents results on the entrance camera and propose a review packet with the snapshot and the recording span.

  With Tailgate Review, Access Anomaly

• Lock down on a duress signal

  On a duress event, propose LockDownDoor on the affected doors and a PTZ GotoPreset toward the entrance, for approval before anything moves.

  With Duress Response

Requirements

• Devices registered as ONVIF conformant to the profiles you need: S or T for video, G for recordings, C for doors
• A device user at the Operator level or above, since PTZ moves and door commands are ACTUATE operations and GetDoorState is READ_SYSTEM_SENSITIVE
• Network reach to each device; WS-Discovery finds devices through multicast Hello and Probe messages on the local network
• A Door Control service (doorcontrol.wsdl) on the access control unit for door state and commands

Authentication

Device credentials over HTTP digest authentication as the Core Specification requires, with WS-UsernameToken for legacy devices and JWT over HTTPS where a device supports it; ONVIF recommends configuring devices for TLS.

Limits

• Feature coverage varies by device. A profile marks each feature mandatory or conditional, so read the device's conformance details before relying on one
• By default a pull point stays alive only while the client keeps calling PullMessages; a lapsed subscription drops events until it is recreated
• Digest authentication and WS-Security give what the Core Specification calls a rudimentary level of security. Plan on TLS
• Live video moves over RTP/RTSP per the Streaming Specification. This listing reads events and stream addresses; a video connector takes the stream itself

Questions and answers

How does an ONVIF device deliver events?

Through the event service in the Core Specification, built on WS-BaseNotification and WS-Topics. A client calls CreatePullPointSubscription, then PullMessages to fetch notifications, which works through a firewall. Topics are namespaced tns1:, for example tns1:Device/HardwareFailure/FanFailure.

Which profiles matter for this connector?

Video systems can make use of Profiles D, G, M, S, and T; access control systems can make use of A, C, D, and M. Profile S covers video streaming and PTZ, T adds H.264/H.265 and motion and tampering events, G covers recording and retrieval, C covers door control and event management.

How does a client authenticate to a device?

The Core Specification requires HTTP digest authentication (RFC 2617), with exceptions for legacy WS-UsernameToken, TLS client authorization, and JWT over HTTPS. Each user has one level: Administrator, Operator, User, Extended, or Anonymous. ONVIF recommends configuring devices for TLS.