ONVIF 解决的是发现和管理问题
ONVIF 常用于局域网发现摄像头、读取设备信息、获取媒体 Profile、解析 RTSP 地址、控制云台和读取部分配置。它不是浏览器播放协议，也不直接替代 RTSP。很多现场问题看起来像“ONVIF 不支持”，实际原因可能是摄像头关闭了 ONVIF、账号没有权限、设备和服务器不在同一网段、时间不同步、防火墙阻止 UDP 发现，或者摄像头只允许指定认证方式。
排查时应先确认摄像头管理后台是否启用 ONVIF，账号是否具备媒体访问和云台权限。再确认 StreamGate 或 Demo 所在机器和摄像头网络互通，WS-Discovery 所需广播或组播是否被交换机、VLAN 或安全策略拦截。若无法自动发现，可以先手工输入 IP，再读取 Profile 和 RTSP 地址。
获取 RTSP 地址后的验证
ONVIF 能返回 RTSP 地址，并不代表媒体链路已经完成。还需要验证 RTSP 认证、主码流/子码流、H.264 / H.265、分辨率、码率、音频和长时间播放。对需要云台的项目，还要验证方向控制、变倍、预置位和权限边界。
StreamGate 更适合把 ONVIF 搜索、RTSP 取流、通道管理和浏览器播放放在同一套 Web Console 中；StreamCore SDK 则适合在客户自己的软件里完成 ONVIF 搜索和播放地址应用。无论使用哪种方式，都建议用真实摄像头做验收，而不是只用模拟流。
自动发现和手动接入都要保留
ONVIF 自动发现依赖局域网广播或组播环境，现场交换机、VLAN、无线网络、虚拟网卡和防火墙都可能影响搜索结果。因此，一个可靠的网关或 Demo 不应只依赖自动发现，也应支持手动输入 IP、端口、用户名和密码后读取设备能力。
自动发现适合快速找设备、批量确认网段和减少录入工作；手动接入适合跨网段、网络策略严格或已知设备地址的项目。两种方式结合，才能覆盖真实现场。
认证失败通常不等于设备不可用
很多摄像头的 Web 登录账号和 ONVIF 账号并不完全等同，部分设备需要单独启用 ONVIF 用户，或者给用户分配媒体、云台、录像等权限。还有一些设备对摘要认证、时间同步和密码复杂度有要求。遇到认证失败时，应先在摄像头管理后台确认 ONVIF 服务、用户权限和设备时间，而不是直接判断为不兼容。
如果能发现设备但读取 Profile 失败，需要继续看错误码和设备日志。若能读取 Profile 但不能播放 RTSP，则排查重点应转到 RTSP 认证、码流编码、端口和网络访问。
云台和能力读取要分开验证
ONVIF 云台能力不应只看设备是否返回 PTZ 服务地址，还要验证方向、变倍、停止、预置位和权限边界。部分摄像头只对特定 Profile 或特定用户开放云台控制，也可能只支持连续移动或相对移动中的一种。项目上应把“能发现设备”“能取流”“能控制云台”拆成独立验收项。
在网关和 SDK 中的不同使用方式
StreamGate 更适合把 ONVIF 发现、手动接入、通道管理、实时预览和录像回放组织在 Web Console 里，方便现场人员操作。StreamCore SDK 更适合在客户自己的软件中提供设备发现、RTSP 地址获取和播放控制能力。无论哪种方式，最终都要用真实摄像头和目标网络验证。
对项目范围的影响
ONVIF 问题经常影响交付周期、选型风险和维护成本。自动搜索受网络影响，认证受设备配置影响，云台能力受型号和权限影响。项目报价或排期时，应把“设备发现”“取流播放”“云台控制”“录像回放”和“厂商差异”分开确认。这样即使部分设备 ONVIF 表现不完整，也能通过手动 RTSP、厂商 SDK 或限定功能范围继续推进。