3. ONVIF设备发现机制

在ONVIF接入流程中，"发现"是第一步，也是最容易被忽视却最容易出问题的一步。很多现场工程师习惯直接输入摄像机IP地址添加设备，于是把发现机制当成可有可无的辅助功能。但在智慧矿山场景中，摄像机数量动辄数百台，分布在井口、皮带走廊、变电所、主扇机房、选煤厂等不同区域，靠手工录入IP既不现实也极易出错。理解WS-Discovery的工作方式，才能判断"为什么设备搜不到""为什么搜到了却加不上""为什么跨网段就失效"。

WS-Discovery的基本原理

ONVIF规范把设备发现完全建立在WS-Discovery（Web Services Dynamic Discovery）之上，这是一个基于SOAP-over-UDP的轻量协议。它的核心角色只有两个：客户端（Client，即NVR、视频管理平台或调试工具）和目标服务（Target Service，即支持ONVIF的摄像机或编码器）。发现过程本质上是"客户端广播询问、设备单播应答"的问答机制。

客户端向UDP 3702端口发送一条Probe消息，消息体中携带一个类型过滤条件，例如查找所有NetworkVideoTransmitter类型的设备。这条Probe以组播方式发出，目的地址为239.255.255.250，TTL通常设为1。网段内所有ONVIF设备收到后，判断自身类型是否匹配，匹配者则在随机延迟（0～500ms，用于避免同时应答造成碰撞）后，向Probe的源地址单播回复一条ProbeMatch，其中包含设备的关键信息：Endpoint Reference（EPR，设备唯一标识）、设备服务地址（Device Service URL）、设备类型以及Scopes（作用域，含名称、位置、硬件型号等）。

除Probe外，还有两类消息值得了解：Hello是设备上线时主动向组播地址宣告自己，用于让客户端感知新设备加入；Bye是设备下线时发出的告别消息。二者构成被动发现能力，但依赖组播可达，实际工程中不如主动Probe可靠。

组播发现与单播发现

标准Probe是组播发送的，这决定了它的作用范围：默认只能发现同一广播域（同一VLAN/网段）内的设备。原因在于组播地址239.255.255.250的TTL被设为1，路由器不会转发。这是很多"平台在核心机房、摄像机在井口子网，怎么都搜不到"问题的根源。

解决跨网段发现有三条路径。第一条是网络层放通组播：在三层交换机或路由器上启用组播路由（如PIM-SM），并确保TTL足够大，同时在各网段配置IGMP。这种方式对网络设备要求高，矿山井下环网设备往往不支持或不愿开启，实施成本大。第二条是单播定向Probe：ONVIF客户端支持向指定IP或IP列表直接发送Probe（单播UDP 3702），设备收到后同样单播回复。这是最实用的方案——在平台侧维护一份设备IP清单或IP段，逐一定向探测，绕开组播限制。第三条是静态添加+手动触发发现：先手工录入IP完成接入，再依赖设备服务地址进行后续能力查询，发现仅作为辅助。

需要区分的是：发现成功不等于接入成功。ProbeMatch只返回设备服务地址，后续的GetCapabilities、GetProfiles、GetStreamUri都走HTTP单播。因此即便组播不通，只要知道IP且HTTP可达，设备依然能正常接入——这正是单播定向发现的价值所在。

矿山网络环境适配要点

矿山网络与办公网差异明显，发现机制需要针对性调整。首先是VLAN划分：井上井下、生产与视频常分属不同VLAN，组播被隔离，应优先采用单播定向发现，并在平台配置中把摄像机所在网段全部纳入探测范围。其次是工业交换机特性：井下环网交换机普遍支持ERPS/STP冗余，环网倒换时组播报文可能丢失，Probe超时不宜设得过短，建议单次等待3～5秒、重试2～3次。第三是IGMP Snooping：若必须使用组播，应在交换机上开启IGMP Snooping，避免Probe泛洪到所有端口造成井下带宽浪费；同时确认没有开启"组播过滤"把3702端口拦掉。

第四是防火墙与安全策略：部分矿山部署了工业防火墙，默认只放通TCP业务端口，UDP 3702常被丢弃。排查时应确认客户端到设备方向UDP 3702双向放通。第五是设备侧配置：部分摄像机默认关闭ONVIF或Discovery功能，需在Web界面"网络—ONVIF"中启用，并确认未勾选"仅允许已认证用户发现"之类的限制项。

一个可复用的发现排查清单

掌握上述机制后，面对"设备发现"环节的各类异常，就能从组播域、单播路径、设备配置三个层面快速定位，而不是盲目重启平台或反复插拔网线。