CN115767192A - 基于ssrc管理调度多路视频流的方法及装置 - Google Patents

Abstract

本发明公开了一种基于SSRC管理调度多路视频流的方法及装置，当设备管理服务器(DMS)收到客户端发起的视频流获取请求时，从数据管理模块(DBS)请求一个还没被其他客户端占用的SSRC，并向设备(如摄像头)请求视频流，然后向该客户端返回这路流的SSRC。媒体服务器(MMS)只需要开放一个发流端口和一个收流端口就可以发送和接收所有视频流，用SSRC来区分不同的流，客户端使用携带不同SSRC的URL(视频流获取网络地址)就可以观看不同设备产生的实时视频或录像回放视频，避免了传统方法获取多路视频流因MMS开放过多端口存在的网络信息安全风险。通过有效区分视频流来源，同时可以防止串流现象，避免呼叫发起方接收到错误来源的视频流。

Description

基于SSRC管理调度多路视频流的方法及装置

技术领域

本发明涉及流媒体调度技术领域，具体涉及一种基于SSRC管理调度多路视频流的方法及装置。

背景技术

当前视频平台普遍采用的视频流管理方法为：在媒体服务器所在的主机上，分配一段范围的端口，对每路视频流，开放至少一个收流端口和一个发流端口来传输视频流，通过端口类型来区分不同的视频流。这种做法会消耗大量的端口资源，且平台需要频繁分配和回收端口，当视频流数目比较大时，会将范围内的端口资源消耗殆尽，从而无法开启新的视频流传输任务。并且，服务器开放端口越多，越容易受到网络攻击，不符合当前对网络信息安全的要求。

发明内容

本发明以在多路视频流传输中，减少端口开放，提高数据传输安全性为目的，提供了一种基于SSRC管理调度多路视频流的方法及装置。

为达此目的，本发明采用以下技术方案：

提供一种基于SSRC管理调度多路视频流的方法，包括：

设备管理服务器DMS收到客户端发起的视频流获取请求后，向数据管理模块DBS请求分配SSRC和用于收发流的媒体服务器MMS；

DMS携带分配到的SSRC、MMS信息以及所述视频流获取请求与设备建立呼叫后，所述设备开始发流给MMS，所述设备发出的视频流的RTP包中携带有该SSRC；

中心管理模块CMS根据MMS的发流IP和发流端口和该SSRC生成获取视频流的URL，返回给所述客户端，所述客户端向该URL发起请求，MMS向客户端发流。

作为优选，所述客户端发起的所述视频流获取请求中携带有视频通道ID，DBS完成每次SSRC分配后，DMS生成视频通道ID对应的视频流获取任务加入到视频流获取任务列表中；

CMS在将所述客户端发起的所述视频流获取请求转发给DMS前，首先从所述视频流获取任务列表里查询是否已存在所述视频通道ID对应的所述视频流获取任务，

若是，则直接将事先已生成的所述视频通道ID对应的URL返回给所述客户端；

若否，则将所述视频流获取请求转发给视频通道注册的DMS。

作为优选，DBS分配SSRC的方法为：

从存储在数据库中的SSRC会话表中随机分配一个未启用的SSRC，然后置该SSRC的占用状态为启用；

所述SSRC会话表中以列为单位存储有若干条SSRC会话数据，每条所述SSRC会话数据包括SSRC值、视频通道ID、视频通道注册的DMS的ID、SSRC占用状态、SSRC占用状态变更时间戳。

作为优选，当所述客户端发起的所述视频流获取请求为实时视频流获取请求时，所述视频流获取请求中的数据内容包括发起请求的所述客户端的客户端ID、拟在所述客户端和所述设备之间建立的视频传输通道的视频通道ID、请求时间戳和设备的视频流传输模式；

当所述客户端发起的所述视频流获取请求为前端录像回放请求时，所述视频流获取请求中的数据内容包括发起请求的所述客户端的客户端ID、拟在所述客户端和所述设备之间建立的视频传输通道的视频通道ID、请求时间戳、设备的视频流传输模式、录像回放开始时间和录像回放结束时间。

作为优选，若所述客户端从MMS处获取的所述视频流为所述设备产生的实时视频流，则所述客户端从MMS处获取所述视频流的过程具体包括如下步骤：

DMS接收到CMS对所述客户端转发的所述视频流获取请求后，向DBS请求分配SSRC和用于收发流的MMS；

DMS携带DBS分配的SSRC、MMS的收流IP、收流端口、视频流传输模式向视频传输通道所在的设备发起视频流获取正式请求；

所述设备接收到所述视频流获取正式请求后，返回表示请求已成功的状态响应码给DMS；

DMS接收到所述状态响应码后发送已确认接收的ACK字符给所述设备，并生成携带有SSRC、MMS的ID、MMS的发流IP、发流端口的响应数据返回给CMS；同时所述视频通道在接收到ACK响应后开始发流给MMS；

CMS接收到所述响应数据后根据直播协议和接收到的SSRC和MMS的发流IP、发流端口生成对应的URL返回给所述客户端；

最终所述客户端根据返回的URL中携带的MMS的发流IP和发流端口的路径指引从对应的MMS处获取该SSRC对应的所述视频流。

作为优选，所述的基于SSRC管理调度多路视频流的方法还包括一SSRC回收流程，具体为：

MMS从所述客户端发送的URL中解析出SSRC，然后将该SSRC对应的视频流转码成URL指定的直播协议(常用的网络流媒体传输协议，比如RTSP协议、RTMP协议、HTTP-FLV协议、HLS协议)后从URL指定的发流端口将所述视频流发送给所述客户端；

MMS监听发流状态，并在监听到发流异常时，将发流异常的所述视频流对应的SSRC加入到回收列表中；

MMS将所述回收列表中的各SSRC发送给DBS，并向所述回收列表中的每个SSRC对应的DMS发起停止发流请求；

DMS发送停止发流指令给对应的所述设备，所述设备接收到停止发流指令后停止发送该SSRC对应的所述视频流并返回停止发流成功信号；

DMS接收到所述停止发流成功信号后通知DBS回收停发的所述视频流对应的SSRC。

作为优选，发流异常的类型包括发出的所述视频流格式错误、传输码率异常、转码异常和所述客户端接收所述视频流超时中的任意一种或多种。

作为优选，若所述客户端从MMS处获取的所述视频流为录像回放产生的视频流，则所述客户端从MMS处获取所述视频流的过程具体包括：

DMS接收到CMS对所述客户端转发的所述视频流获取请求后，生成SessionID并记录到DBS中的SSRC会话表中的对应会话数据中，并向DBS请求分配SSRC和用于收发视频流的MMS；

DMS携带DBS分配的SSRC、MMS的收流IP、收流端口以及SessionID、所述客户端发起的所述视频流获取请求中包含的国标传输模式、录像回放起始时间、录像回放结束时间向拟建立视频传输通道的所述设备发起录像回放正式请求；

所述设备接收到所述录像回放正式请求后，返回表示请求已成功的状态响应码给DMS；

DMS收到所述状态响应码后，返回已确认接收的ACK字符给所述设备，并生成携带有视频通道ID、SSRC、SessionID、MMS的ID、MMS的发流IP、发流端口的响应数据返回给CMS；同时所述设备在接收到ACK响应后向MMS的收流IP与收流端口发送携带有SSRC的录像回放视频流；

CMS接收到所述响应数据后根据SSRC、MMS的ID、发流IP、发流端口生成对应的URL连同SessionID、所述视频通道ID返回给所述客户端；

所述客户端保存SessionID，并根据返回的URL中携带的MMS发流IP和发流端口的路径指引从对应的MMS处获取该SSRC对应的所述录像回放视频流。

作为优选，所述客户端停止录像回放的流程包括：

所述客户端向CMS发起携带有客户端ID、SessionID、所述视频通道ID的停止录像回放请求；

CMS在DBS中查找请求中携带的所述视频通道ID对应的视频通道注册的DMS，并向查找到的DMS转发所述停止录像回放请求；

DMS根据请求中携带的SessionID在DBS中查找记载有该SessionID的所述会话数据，

若未查找到，则返回错误信息；

若查找到，则携带所述停止录像回放请求发送INFO指令给对应的所述设备，并发送BYE指令给所述设备，INFO指令为暂停、或恢复播放或、快进、或慢放、或倍速播放指令，BYE指令用于停止录像回放；

所述设备向DMS发送成功接收到所述INFO指令和所述BYE指令的状态响应码，并停止发流；

DMS收到所述状态响应码后，向CMS返回HTTP响应，并携带所述视频通道ID、所述SessionID向DBS请求删除所述SessionID对应的所述会话数据；

CMS向所述客户端返回携带有所述视频通道ID、所述SessionID的响应，以通知录像流已停止回放。

本发明还提供了一种SSRC管理和回收装置，包括数据管理模块DBS、设备管理服务器DMS和媒体服务器MMS，DMS用于为每路视频流请求DBS分配一个SSRC，MMS用于将设备发出的视频流推送给对应的客户端，并负责管理视频流的状态，并在监控到视频流异常时，回收异常视频流对应的SSRC。

本发明具有以下有益效果：

1、当设备管理服务器(DMS)收到客户端发起的视频流获取请求时，从数据管理模块(DBS)请求一个还没被其他客户端占用的SSRC(Synchronization source，RTP协议报文头中一个32位的标识符，用于表示产生媒体流的信源)，并向设备(如摄像头)请求视频流，然后向该客户端返回这路流的SSRC。媒体服务器(MMS)只需要开放一个发流端口和一个收流端口就可以发送和接收所有视频流，用SSRC来区分不同的流，客户端使用携带不同SSRC的URL(视频流获取网络地址)就可以观看不同设备产生的实时视频和录像回放视频，避免了传统方法获取多路视频流因MMS开放过多端口存在的网络信息安全风险。通过有效区分视频流来源，同时可以防止串流现象，避免呼叫发起方接收到错误来源的视频流。

2、通过SSRC来记录并管理平台内所有流的会话状态，如果有异常则及时停止设备发流，并回收SSRC等相关资源，杜绝了死流现象(指设备一直在发视频流的RTP包但没有媒体服务器负责接收并分发，浪费网络资源)。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是客户端请求实时视频流的流程示意图；

图2是客户端请求前端录像回放的流程示意图；

图3是客户端停止前端录像回放的流程示意图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。

其中，附图仅用于示例性说明，表示的仅是示意图，而非实物图，不能理解为对本专利的限制；为了更好地说明本发明的实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；对本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

本发明实施例的附图中相同或相似的标号对应相同或相似的部件；在本发明的描述中，需要理解的是，若出现术语“上”、“下”、“左”、“右”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此附图中描述位置关系的用语仅用于示例性说明，不能理解为对本专利的限制，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。

在本发明的描述中，除非另有明确的规定和限定，若出现术语“连接”等指示部件之间的连接关系，该术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个部件内部的连通或两个部件的相互作用关系。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

本发明提供的基于SSRC管理调度多路视频流的方法，如图1所示，包括如下步骤：

客户端向中心管理模块CMS发起一个请求建立视频通道的呼叫(视频流获取请求)；

CMS将客户端发起的呼叫转发给该视频通道注册的设备管理服务器DMS；

DMS向数据管理模块DBS请求分配视频流对应的SSRC和用于收发流的媒体服务器MMS，然后DMS携带此SSRC、MMS的收流IP、收流端口、视频流传输模式向拟建立视频传输通道的设备建立呼叫；

DMS与设备建立呼叫后，设备开始发流给MMS，设备发出的视频流的RTP包中携带SSRC，MMS通过RTP包中的SSRC来区分不同的视频流，分发给对应的客户端；

CMS根据MMS的发流端口、MMS发流IP、和SSRC，生成获取视频流的URL，返回给客户端，URL格式举例：rtmp://MMS发流IP:MMS发流端口/rtp/SSRC值。

在视频流收发过程中，MMS同时监控视频流收发状态，通过内置模型判断视频流收发是否异常，如果发生异常，则中断该SSRC关联的视频流的收发，并向DMS上报异常，然后DMS向设备发送BYE消息，并通知DBS回收SSRC，DBS回收有异常或停止使用的SSRC，用于下次分配。

其中，DBS分配SSRC的方法为：在数据库中建立一张存储有所有SSRC的SSRC会话表，表中的每个SSRC不相同，表中的每列(column)表示一条SSRC会话数据，每条SSRC会话数据包括SSRC值、视频通道ID、视频通道注册的DMS的ID、SSRC占用状态、SSRC占用状态变更时间戳。SSRC占用状态默认为off(未启用)，如果SSRC被占用，则置该SSRC的状态为on(启用)。分配SSRC时，从表中随机取一个状态为off的SSRC，然后置该SSRC的占用状态为on。

DBS分配SSRC时，考虑到存在实时视频流获取和前端录像回放这两个使用场景，优选使用两张表来存储SSRC会话数据，一张专门用于请求获取实时视频流时分配SSRC，另一张用于请求前端录像回放时分配SSRC，两张表相互独立，互不干扰，不会分配出错。

MMS需要把所有的视频流接收与分发的任务详情存储于数据库中，任务详情包括MMS收发流的IP和端口、请求时间戳、收发流任务开始时间戳(由MMS负责存储到数据库)、MMS发流的IP和端口列表、SSRC、视频流分发任务当前具体的状态(分发到哪些客户端的列表，包括这些客户端的IP和端口，以及分发的码流传输是否正常，由MMS负责存储到数据库)、视频流编码格式(比如MPEG-4视频流/H.265视频流/H.265视频流/SVAC视频流等)、设备端的流传输模式(国标28181协议中规定的三种视音频流传输模式方式，UDP或TCPACTIVE或TCP PASSIVE)、分发给客户端的直播协议(常见的网络流媒体传输协议，比如HLS或HTTP-FLV或RTMP，由MMS负责存储到数据库)、任务类型为实时视频流获取或录像回放、INVITE(向设备获取视频流的请求)的sip头。

客户端发起一个视频通道的实时视频流获取请求时，由CMS检查是否已经为该视频通道分配了一个SSRC，如果是，则直接获取该视频通道对应的URL，将URL返回给客户端，客户端根据返回的URL获取实时视频流；如果未给该视频通道分配SSRC，则CMS将客户端发起的视频流获取请求转发给该视频通道注册的DMS。

客户端发起实时视频流获取请求时，该实时视频流获取请求中的数据内容包括客户端ID(设备通过该客户端ID识别发起请求的为哪个客户端)、视频通道ID(设备通过视频通道ID识别从哪个视频通道返回视频流)、请求时间戳、设备的数据流传输模式(UDP或TCPACTIVE或TCP PASSIVE，后续设备根据从该请求中解析出的数据流传输模式进行视频流传输)。

当客户端发起一个视频通道的前端录像回放请求时，CMS直接将前端录像回放请求发送给该视频通道注册的DMS。

客户端发起前端录像回放请求时，请求中的数据内容包括客户端ID、视频通道ID、当前时间戳、设备的回放流传输模式(UDP或TCP ACTIVE或TCP PASSIVE，后续设备根据从该请求中解析出的数据流传输模式进行视频流传输)、录像回放开始时间、录像回放结束时间，设备按照请求中携带的录像回放开始时间和结束时间进行录像视频的回放。

如图1中所示，DMS接收到CMS转发的视频流获取请求后，向DBS请求一个SSRC和一个用于收发流的MMS；DBS完成SSRC和MMS分配后将分配信息返回给DMS，分配信息包括分配到的SSRC和MMS的收流IP、发流IP、收流端口、发流端口。然后DMS携带客户端发起的视频流获取请求以及分配到的SSRC与MMS的收流IP、收流端口，向作为呼叫对象的设备发送sipINVITE(视频流获取正式请求)；对应设备返回200ok(成功状态响应码，用于指示请求已成功)给DMS，DMS发送ACK(确认字符，表示200ok接收成功)后，携带SSRC和MMS的发流IP、发流端口返回给CMS，CMS接收到DMS的响应后，根据直播协议(常用的网络流媒体传输协议，比如HLS或HTTP-FLV或RTMP)、SSRC和MMS的发流IP、发流端口生成一个URL，返回给客户端，URL格式举例：rtmp://MMS发流IP:MMS发流端口/rtp/SSRC值。最后，客户端根据返回的URL中携带的发流IP和发流端口的路径指引从对应的MMS处获取该SSRC对应的视频流。

本申请中，MMS在一个平台中会部署多个，DBS为DMS分配用于收发流的MMS时，采用的是负载均衡算法。

MMS接收到视频通道发送的视频流的RTP包后，根据RTP报文头中携带的SSRC来区分不同的视频流(SSRC唯一，每个SSRC对应不同的视频流)。

客户端收到CMS返回的URL后，向MMS请求该URL。MMS解析该URL，得到URL中携带的SSRC，从而将解析到的该SSRC对应的RTP流转码成URL指定的直播协议发送给客户端。

在客户端不再接收视频流达到预设间隔时间后，MMS不再将该视频流分发给该客户端。

在SSRC关联的RTP流长时间无客户端接收时，MMS将此流标记为无人观看，加入到回收列表中。

在SSRC关联的RTP流发生异常时，MMS将此流标记为异常，同样加入到回收列表。

MMS将回收列表中的SSRC发送到DBS，获取对应的DMS的ID，MMS向该ID对应的DMS发起停止发流请求，DMS接收到该请求后，发送BYE给与其建立视频通道的设备，该设备停止发送该SSRC对应的RTP流，并且通知DBS回收该SSRC。

其中，RTP流发生异常的类型包括RTP流格式错误、客户端接收RPT包超时、RTP包码率异常、RTP流转码错误。

以下通过两个具体的实施例对本发明提供的基于SSRC管理调度多路视频流的方法的具体实现进行详细说明：

实施例一、多路实时视频流管理调度流程

SSRC的数据结构如下表1所示：

表1

请结合图1，本实施例一管理调度多路视频流的方法，包括如下步骤：

S101，客户端在HTTP POST的body中携带视频通道ID、客户端ID、设备端视频流国标传输模式形成为视频流获取请求发送给CMS，视频流获取请求的json格式举例如下：

其中，DeviceID表示国标设备ID，比如这里DeviceID为“33010100001180000001”；

ClientID表示客户端ID，比如这里ClientID为“client01”；

ChannelID表示视频通道ID，一个国标设备下可能有多个视频通道，表示不同的视频源。比如这里ChannelID为“33010100001320000001”

GBVideoTransMode表示设备端传送视频流的国标传输模式，比如这里GBVideoTransMode为“UDP”。

S102，CMS在DBS中查找ChannelID对应的DMS的ID，以及ChannelID是否已经有分配好的实时视频流使用的SSRC，如果有已经分配好的SSRC，则直接将事先生成的URL返回给客户端，具体返回示例如下：

其中，code表示错误代码，此处中code为“0”表示正常没有错误，否则表示有错误；

Message表示具体错误信息，此处message为“ok”表示正常没有错误，否则表示有错误；

RTMP表示使用RTMP协议从MMS获取视频流时的URL，127.0.0.1是MMS的发流IP,554是MMS的RTMP协议端口，0010000002是SSRC的值。

如果没有分配好的SSRC，则携带视频通道ID、客户端ID、设备端国标传输模式发送HTTP请求到DMS，具体json格式举例如下：

S103，DMS收到CMS发送的HTTP请求后，向DBS请求分配一个可用的MMS和SSRC，然后携带该SSRC、MMS的收流IP、收流端口、国标传输模式，向视频通道发起INVITE；

S104，视频通道收到INVITE后，返回200ok；

S105，DMS收到200ok后，给视频通道发送ACK；

S106，视频通道收到ACK后，向MMS的收流IP与收流端口传输携带了SSRC的RTP流；

S107，DMS向CMS返回HTTP response(HTTP响应)，HTTP response中携带视频通道ID、SSRC、MMS的ID、MMS的发流IP、发流端口，具体json格式举例如下：

其中，MMSID表示MMS的ID，此处的“mms01”表示MMS的ID为01；

SendIP表示MMS的发流IP，此处该发流IP为“127.0.0.1”；

SendPort表示MMS的发流端口，此处的“554”表示MMS的发流端口的端口号。

S108，CMS向客户端返回携带有视频通道ID、URL的HTTP response，具体格式举例如下：

其中，rtmp表示直播协议；

0010000002表示SSRC；

127.0.0.1表示MMS的发流IP；

554表示MMS的发流端口。

S109，客户端根据URL中携带的MMS的发流IP、发流端口的路径指引从对应的MMS的发流端口处拉取URL中携带的SSRC对应的实时视频流。

实施例二、前端录像回放和停止前端录像回放流程

1、前端录像回放流程如图2所示，包括如下步骤：

S201，客户端在HTTP POST的body中携带视频通道ID、客户端ID、设备端国标传输模式、录像回放起始时间和录像回放结束时间，然后发送RTSP SETUP请求到CMS，具体json格式举例如下：

其中，BeginTime表示录像回放的起始时间，此处的“2022-07-15 00:00:00”表示录像回放的起始时间为2022年7月15日零时零分零秒；

EndTime表示录像回放的结束时间，此处的“2022-07-15 04:00:00”表示录像回放的结束时间为2022年7月15凌晨4时零分零秒。

RecordAction表示是录像回放还是录像下载，此处的“0”表示回放，“1”表示下载。

S202，CMS在DBS中查找ChannelID注册的DMS，然后将携带视频通道ID、客户端ID、设备端国标传输模式的HTTP请求转发给查找到的DMS，转发的HTTP请求内容示例如下：

S203，DMS接收到CMS发送的HTTP请求后，生成SessionID(会话ID为会话唯一标识符)，并将SessionID和HTTP请求中携带的视频通道ID、客户端ID以及建立SessionID的当前时间戳形成为一条会话记录保存到DBS中。

DSM向DBS请求分配SSRC和用于收发视频流的MMS；

然后，DMS携带DBS分配的SSRC、MMS的收流IP、收流端口以及SessionID、客户端发起的视频流获取请求中包含的国标传输模式、录像回放起始时间、录像回放结束时间向作为客户端请求对象的设备发起INVITE(此处为录像回放正式请求)，视频通道ID是用于标识媒体源(比如一个网络摄像头)的ID，一般一个设备下可以有1个或多个视频通道。

S204，对应设备接收到录像回放正式请求后，返回表示请求已成功的状态响应码给DMS，例如返回“200ok”的状态响应码给DMS；

S205，DMS收到“200ok”后，返回ACK给对应的该设备；

S206，对应设备接收到ACK后，向MMS的收流IP与收流端口发送携带有SSRC的录像回放视频流；

S207，DMS向CMS返回HTTP response，该HTTP response中携带有视频通道ID、SSRC、SessionID、MMS的ID、MMS的发流IP、发流端口，具体json格式举例如下：

S208，CMS向客户端返回携带有视频通道ID、URL、SessionID的HTTP response，具体格式举例如下：

S209，客户端保存SessionID作为会话唯一标识符，并根据返回的URL中携带的MMS的ID、MMS的发流IP和发流端口的路径指引从对应的MMS处获取该SSRC对应的录像回放视频流。

这里需要说明的是，SessionID是RTSP协议中的唯一会话标识符，在一个会话建立后，暂停/快进/停止等操作发送到设备需要SessionID。获取视频流是从MMS获取的，但是暂停/快进/停止等操作是发到DMS进行的，MMS可以用SSRC来标记流，所以只需要知道SSRC，不需要SessionID来标记。

2、停止前端录像回放流程如图3所示，包括：

S301，客户端发起停止录像回放请求，停止录像回放请求中携带有客户端ID、视频通道ID、SessionID，具体json格式举例如下：

S302，CMS在DBS中查找该视频通道ID注册的DMS，并向该DMS转发该停止录像回放请求；

S303，DMS根据请求中携带的SessionID在DBS中查找会话信息，

若未查找到，则返回错误信息；

若查找到，则转入步骤S304；

S304，DMS携带停止录像回放请求发送INFO给对应设备，同时发送BYE指令给该设备；

S305，设备向DMS发送成功接收到停止录像回放请求的200ok(状态响应码)和成功接收到BYE指令的200ok，并停止发流；

S306，DMS收到INFO的200ok后，向CMS返回HTTP响应，并携带视频通道ID、SessionID向DBS请求删除SessionID对应的会话；

S307，CMS向客户端返回携带有视频ID、SessionID的响应，以通知录像流已停止，返回的该响应具体的json格式举例如下：

本发明还提供了一种SSRC管理和回收装置，包括数据管理模块DBS、设备管理服务器DMS和媒体服务器MMS，DMS用于为每路视频流请求DBS分配一个SSRC，MMS用于将设备发出的视频流推送给对应的客户端，并负责管理视频流的状态，并在监控到视频流异常时，回收该异常视频流对应的SSRC。

数据管理模块DBS中负责保存SSRC会话的表结构如下表2和表3所示：

表2实时视频SSRC会话表结构

表3前端录像回放SSRC会话表结构

DMS携带视频通道ID和自身ID请求DBS分配SSRC，DBS随机返回一个Status为off的SSRC，然后设置该SSRC的Status为on，并设置LastUpdateTime为当前时间戳。

MMS将设备发出的视频流推送给对应的客户端，并负责管理视频流的状态，当监控到视频流长时间无人观看或发生异常(比如视频流格式错误、接收视频流超时、视频流码率异常、转码错误等)，则通知DBS回收该视频流对应的SSRC。

回收SSRC的步骤为：

S401，MMS携带SSRC，向DBS查询该SSRC对应的DMS的ID和DMS的API接口；

S402，MMS携带SSRC和时间戳，向DMS的API接口推送Notify；

S403，DMS接收到Notify，查询到SSRC对应的视频通道ID，向对应设备发起BYE(如果是前端录像回放，还需要同时发送INFO)；

S404，设备返回200ok；

S405，DMS收到200ok，通知DBS回收该SSRC；

S406，DBS将该SSRC对应的ChannelID和DMSID置为NULL，Status置为off，LastUpdateTime置为当前时间戳，如果是前端录像回放，还需要置SessionID为NULL，完成SSRC回收流程。

需要声明的是，上述具体实施方式仅仅为本发明的较佳实施例及所运用技术原理。本领域技术人员应该明白，还可以对本发明做各种修改、等同替换、变化等等。但是，这些变换只要未背离本发明的精神，都应在本发明的保护范围之内。另外，本申请说明书和权利要求书所使用的一些术语并不是限制，仅仅是为了便于描述。

Claims (10)

1.一种基于SSRC管理调度多路视频流的方法，其特征在于，包括：

设备管理服务器DMS收到客户端发起的视频流获取请求后，向数据管理模块DBS请求分配SSRC和用于收发流的媒体服务器MMS；

DMS携带分配到的SSRC、MMS信息以及所述视频流获取请求与设备建立呼叫后，所述设备开始发流给MMS，所述设备发出的视频流的RTP包中携带有该SSRC；

中心管理模块CMS根据MMS的发流端口和该SSRC生成获取视频流的URL，返回给所述客户端，所述客户端向该URL发起请求，MMS向所述客户端发流。

2.根据权利要求1所述的基于SSRC管理调度多路视频流的方法，其特征在于，所述客户端发起的所述视频流获取请求中携带有视频通道的ID，DBS完成每次SSRC分配后，DMS生成视频通道ID对应的视频流获取任务详情加入到视频流获取任务列表中；

CMS在将所述客户端发起的所述视频流获取请求转发给DMS前，首先从所述视频流获取任务列表里查询是否已存在所述视频通道ID对应的所述视频流获取任务，

若是，则直接将事先已生成的所述视频通道ID对应的URL返回给所述客户端；

若否，则将所述视频流获取请求转发给视频通道注册的DMS。

3.根据权利要求1所述的基于SSRC管理调度多路视频流的方法，其特征在于，DBS分配SSRC的方法为：

从存储在数据库中的SSRC会话表中随机分配一个未启用的SSRC，然后置该SSRC的占用状态为启用；

所述SSRC会话表中以列为单位存储有若干条SSRC会话数据，每条所述SSRC会话数据包括SSRC值、视频通道ID、视频通道注册的DMS的ID、SSRC占用状态、SSRC占用状态变更时间戳。

4.根据权利要求1所述的基于SSRC管理调度多路视频流的方法，其特征在于，当所述客户端发起的所述视频流获取请求为实时视频流获取请求时，所述视频流获取请求中的数据内容包括发起请求的所述客户端的客户端ID、拟在所述客户端和所述设备之间建立的视频传输通道的视频通道ID、请求时间戳和设备的视频流传输模式；

当所述客户端发起的所述视频流获取请求为前端录像回放请求时，所述视频流获取请求中的数据内容包括发起请求的所述客户端的客户端ID、拟在所述客户端和所述设备之间建立的视频传输通道的视频通道ID、请求时间戳、设备的视频流传输模式、录像回放开始时间和录像回放结束时间。

5.根据权利要求1所述的基于SSRC管理调度多路视频流的方法，其特征在于，若所述客户端从MMS处获取的所述视频流为所述设备产生的实时视频流，则所述客户端从MMS处获取所述视频流的过程具体包括如下步骤：

DMS接收到CMS对所述客户端转发的所述视频流获取请求后，向DBS请求分配SSRC和用于收发流的MMS；

DMS携带DBS分配的SSRC、MMS的收流IP、收流端口、视频流传输模式向拟建立视频传输通道的所述设备发起视频流获取正式请求；

所述设备接收到所述视频流获取正式请求后，返回表示请求已成功的状态响应码给DMS；

DMS接收到所述状态响应码后发送已确认接收的ACK字符给所述设备，并生成携带有SSRC、MMS的ID、MMS的发流IP、发流端口的响应数据返回给CMS；同时所述设备在接收到ACK响应后开始发流给MMS；

CMS接收到所述响应数据后根据直播协议和接收到的SSRC、MMS的发流IP、发流端口生成对应的URL返回给所述客户端，URL格式举例：rtmp://MMS发流IP:MMS发流端口/rtp/SSRC值；

最终所述客户端根据返回的URL中携带的MMS的发流IP和发流端口的路径指引从对应的MMS处请求该SSRC对应的所述视频流。

6.根据权利要求1-5任意一项所述的基于SSRC管理调度多路视频流的方法，其特征在于，还包括一SSRC回收流程，具体为：

MMS从所述客户端发送的URL中解析出SSRC，然后将该SSRC对应的视频流转码成URL指定的直播协议后从URL指定的发流端口将所述视频流发送给所述客户端；

MMS监听发流状态，并在监听到发流异常时，将发流异常的所述视频流对应的SSRC加入到回收列表中；

MMS将所述回收列表中的各SSRC发送给DBS，并向所述回收列表中的每个SSRC对应的DMS发起停止发流请求；

DMS发送停止发流指令给对应的所述设备，所述设备接收到停止发流指令后停止发送该SSRC对应的所述视频流并返回停止发流成功信号；

DMS接收到所述停止发流成功信号后通知DBS回收停发的所述视频流对应的SSRC。

7.根据权利要求6所述的基于SSRC管理调度多路视频流的方法，其特征在于，发流异常的类型包括发出的所述视频流格式错误、传输码率异常、转码异常和所述客户端接收所述视频流超时中的任意一种或多种。

8.根据权利要求1所述的基于SSRC管理调度多路视频流的方法，其特征在于，若所述客户端从MMS处获取的所述视频流为录像回放产生的视频流，则所述客户端从MMS处获取所述视频流的过程具体包括：

DMS接收到CMS对所述客户端转发的所述视频流获取请求后，生成SessionID并记录到DBS中的SSRC会话表中的对应会话数据中，并向DBS请求分配SSRC和用于收发视频流的MMS；

DMS携带DBS分配的SSRC、MMS的收流IP、收流端口以及SessionID、所述客户端发起的所述视频流获取请求中包含的国标传输模式、录像回放起始时间、录像回放结束时间向拟建立视频传输通道的所述设备发起录像回放正式请求；

所述设备接收到所述录像回放正式请求后，返回表示请求已成功的状态响应码给DMS；

DMS收到所述状态响应码后，返回已确认接收的ACK字符给所述设备，并生成携带有视频通道ID、SSRC、SessionID、MMS的ID、MMS的发流IP、发流端口的响应数据返回给CMS；同时所述设备在接收到ACK响应后向MMS的收流IP与收流端口发送携带有SSRC的录像回放视频流；

CMS接收到所述响应数据后根据SSRC、MMS的ID、发流IP、发流端口生成对应的URL连同SessionID、所述视频通道ID返回给所述客户端；

所述客户端保存SessionID，并根据返回的URL中携带的MMS的发流IP和发流端口的路径指引从对应的MMS处获取该SSRC对应的所述录像回放视频流。

9.根据权利要求8所述的基于SSRC管理调度多路视频流的方法，其特征在于，所述客户端停止录像回放的流程包括：

所述客户端向CMS发起携带有客户端ID、SessionID、所述视频通道ID的停止录像回放请求；

CMS在DBS中查找请求中携带的所述视频通道ID对应的视频通道注册的DMS，并向查找到的DMS转发所述停止录像回放请求；

DMS根据请求中携带的SessionID在DBS中查找记载有该SessionID的所述会话数据，

若未查找到，则返回错误信息；

若查找到，则携带所述停止录像回放请求发送INFO指令给对应的所述设备，并发送BYE指令给所述设备，INFO指令为暂停、或恢复播放、或快进、或慢放或倍速播放指令，BYE指令用于停止录像回放；

所述设备向DMS发送成功接收到所述INFO指令和所述BYE指令的状态响应码，并停止发流；

DMS收到所述状态响应码后，向CMS返回HTTP响应，并携带所述视频通道ID、所述SessionID向DBS请求删除所述SessionID对应的所述会话数据；

CMS向所述客户端返回携带有所述视频通道ID、所述SessionID的响应，以通知录像流已停止回放。

10.一种SSRC管理和回收装置，其特征在于，包括数据管理模块DBS、设备管理服务器DMS和媒体服务器MMS，DMS用于为每路视频流请求DBS分配一个SSRC，MMS用于将设备发出的视频流推送给对应的客户端，并负责管理视频流的状态，并在监控到视频流异常时，回收异常视频流对应的SSRC。

Images