如何可靠的检测摄像仪是否在线（RTSP协议探测方案）

一。背景：

    在视频平台项目中通常需要对接入摄像机的在线状态进行展示和统计。比较常见的摄像仪在线状态检测机制有以下几种：

    1.对摄像仪IP地址周期性的进行ping检测。此种方式只能检测出摄像仪在网络上是否在线，并不能反映出摄像仪是否真正能够播放。

    2.对摄像仪的rtsp流地址周期性的进行ffmpeg截图或者拉流。此种方式本质上是在服务器上对摄像仪进行一次拉流播放尝试，准确性最高，但是弊端也很明显。截图和拉流都需要可能在服务器上进行一次视频解码操作，占用服务器资源。另外摄像仪通常会限制拉流客户端数量，这样的探测会占用一个用户数，容易触发摄像仪拉流用户过多的异常。

    3.使用摄像仪的私有SDK进行周期性的登录尝试。此种方式的弊端是摄像仪厂家SDK各不相同，适配工作量大。并且也会频繁占用登录用户数。

    4.利用RTSP协议进行周期性的探测（本方案）。

 

二。RTSP协议交互流程：

    一次完整的RTSP流视频播放需要经过以下几个协议步骤。

    OPTIONS：查询摄像机的RTSP可用方法。有些NVR在此阶段就要进行密码校验。

    DESCRIBE：查询摄像仪的会话描述。此阶段通常需要进行用户名密码校验，成功后摄像仪返回它的媒体流通道track（视频通道/音频通道）

    SETUP：使能摄像仪的指定媒体通道。此阶段之后摄像仪真正开始进行音视频的编码，视频流准备就绪。

    PLAY：向摄像仪发送播放指令。此阶段之后摄像仪开始将音视频流不断的推送到客户端进行播放。

    TEARDOWN：断开客户端与摄像仪的连接。摄像仪会停止推流，实现编码器资源，断开连接。

 

三。设计思路：

    首先作为TCP客户端连接摄像仪的RTSP服务端（IP:554)，如果能连接上说明网络是通的；向摄像仪发送OPTIONS探测包，如果能够收到摄像仪的正确回复，说明摄像仪的RTSP服务是正常的；向摄像仪发送DESCRIBE探测包，此阶段通常会触发摄像仪的401权限认证，通过使用摄像仪的用户名和密码进行摘要算法计算，如果能够认证成功，说明摄像仪的账号密码是配置正确的，由于不实际拉流，因此对摄像仪返回的媒体通道信息不处理。至此完成了视频RTSP播放的前两步流程，虽未实际拉流，但基本能够探测出摄像仪是在线的，且用户名密码是配置正确的。

    有三个注意项：

            1）有些NVR设备会在OPTIONS阶段就要进行401权限认证。因此需要考虑兼容性。

            2）在频繁探测过程中，如果用户名密码配置错误，很容易被摄像仪拉黑。因此需要进行特殊的密码错误退避机制考虑处理。

            3）此种方式能够较为准确的检测出摄像仪的在线状态。但是如果摄像仪同时拉流的客户端的确过多时，仍可能无法播放视频，是由于摄像仪的并发拉流客户端个数限制造成的。

 

 

四。RTSP协议探测流程设计：

RTSP协议探测支持普通摄像仪和NVR两种设备场景。

采用两步探测法。在OPTIONS阶段检测网络联调性；在DESCRIBE阶段检测具体异常信息，如密码配置错误，流地址拼写错误等异常场景。

RTSP协议探测除了能返回是否在线外，还可以返回具体的异常信息。

 

五。防止密码锁定的探测指数退避机制：

摄像仪设备通常有安全策略：在连续一段时间内，多次接收到错误的账号和密码进行RTSP连接时，会触发摄像仪的密码锁定策略，对客户端IP拉入黑名单。

    因此在执行RTSP协议探测时，需要设计鉴权失败的指数退避机制，规避被摄像仪拉黑的风险。即当探测到摄像仪用户名密码错误时，逐步拉长检测周期。比如最初是10秒探测一次，初步修改为2分钟、5分钟、30分钟、1小时。

    逻辑设计：

 关键代码实现：

 

六。多任务机制：

    作为一个RTSP在线状态检测小工具，需要能够支持外部业务系统很多摄像仪RTSP探测的任务。一个简单的多任务机制设计如下：

将摄像仪RTSP协议探测作为task任务单元，通过manager管理类实现对多个task任务的管理。

1）接收到获取rtsp在线状态指令时，如果是新的地址则创建为task任务对象，添加到任务缓存列表。

2）定时任务(1秒）遍历task对象列表，查看是否达到探测周期条件，如果满足则异步(td::async)执行对应task的探测任务。

3）定时任务同时检测并移除任务缓存列表中长时间(超过1小时）未接收过获取rtsp在线状态的任务，避免无效任务累积。

 

特点优势：

接口简单：对外只暴露一个getRtspOnline请求接口，任务管理在后台完成。

兼顾时效性和准确性：首次接收到RTSP地址探测时立即探测，之后则返回最近一次异步探测的结果，接口无需等待。

自维护任务队列：通过任务过期机制，保证无垃圾任务堆积。

无需数据库持久化：无需将任务持久化到数据库中，通过单一接口和自维护任务队列，保证即使工具重启对用户也无感知。

 

七。HTTP服务接口化封装：

    摄像仪RTSP在线状态检测工具封装为小服务。对外提供HTTP的GET请求接口，便于或其它系统使用。

请求示例：

请求：http://ip:port/api/v1/rtspcheck?rtsp=rtsp://admin:root1234@172.23.62.90/Streaming/Channels/101

返回：{"code":200,"data":1,"msg":"RTSP在线"}

支持的离线异常检测类型：

• 网络超时：用户配错IP地址端口号或服务器与摄像机之间网络不通。
• 用户名密码错误：用户配错用户名或密码，摄像仪回复401的异常。
• RTSP地址错误：用户rtsp地址拼接错误，摄像仪回复404的异常。
• 摄像仪内部错误：摄像仪回复500的异常。
• 未知错误：摄像仪回复400的异常。

八。工具应用场景：

    业务系统新增或修改摄像仪配置时，调用一次检测配置的摄像仪基础信息是否正确。

    业务系统后台统计摄像仪在线、离线数量。用于摄像仪在线率展示。

    业务系统在视频播放之前，可以先看一下摄像仪是否在线。摄像仪无法播放时，其实原因有可能是摄像仪根本就没有在线。