CN112261336B - 一种融合gb28181协议实现手机视频通信的方法 - Google Patents

Abstract

本申请公开了一种融合GB28181协议实现手机视频通信的方法，实现多协议环境下的视频通信需求。方法包括：接收第一设备向注册中心发起基于GB28181协议的注册请求，在第一设备注册成功后，基于注册中心的请求，向注册中心发送第一设备的具体信息；基于第一设备向注册中心发送的呼叫其他设备的呼叫请求，查询其他设备的具体信息，通过SIP代理服务器向其他设备发送INVITE请求；接收其他设备收到INVITE请求后做出的回应，向其他设备发送一个基于第一设备的具体信息做出的响应，响应包括第一设备能够接受的视频流协议与流媒体服务器地址以及各式与端口；根据响应，经由SIP代理服务器与注册中心，向第一设备返回视频流，建立视频通信通道。

Description

一种融合GB28181协议实现手机视频通信的方法

技术领域

本申请涉及计算机系统流媒体传输领域，尤其涉及一种融合GB28181协议实现手机视频通信的方法。

背景技术

近年来，计算机系统流媒体传输领域发展迅速。适用于不同视频流协议环境下视频通信的需求越来越多。

不同类型的播放端对视频流的格式要求不同，目前视频直播方案是基于既定的视频协议，从视频流发送到服务器，再到播放端都是使用同一套网络协议，不适用于多协议环境下的视频通信需求。

发明内容

本申请实施例提供了一种融合GB28181协议实现手机视频通信的方法，用以解决直播方案中基于既定的视频协议，从视频流发送到服务器，再到播放端都是使用同一套网络协议，不适用于多协议环境下的视频通信的问题。

本申请实施例提供一种融合GB28181协议实现手机视频通信的方法，包括：

接收第一设备向注册中心发起基于GB28181协议的注册请求，在所述第一设备注册成功后，基于所述注册中心的请求，向所述注册中心发送所述第一设备的具体信息；

基于所述第一设备向所述注册中心发送的呼叫其他设备的呼叫请求，查询所述其他设备的具体信息，通过SIP代理服务器向所述其他设备发送INVITE请求；

接收所述其他设备收到INVITE请求后做出的回应，向所述其他设备发送一个基于所述第一设备的具体信息做出的响应，所述响应包括所述第一设备能够接受的视频流协议与流媒体服务器地址以及格式与端口；

根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道。

本申请实施例通过在第一设备注册成功后向注册中心发送自身的具体信息，在呼叫其他设备时，其他设备应答，可根据第一设备能够接受的视频流协议或流媒体服务器地址，返回给第一设备相应的视频流，适应于多环境协议下的视频通信。

可选地，所述接收第一设备向注册中心发起基于GB28181协议的注册请求，在所述第一设备注册成功后，基于所述注册中心的请求，向所述注册中心发送所述第一设备的具体信息，具体包括：

接收所述第一设备不携带授权的注册信息的注册请求，在获得所述注册中心对所述不携带授权的注册信息的注册请求的响应之后，接收所述第一设备携带授权的注册信息的注册请求；

验证所述授权的注册信息，通过后，向所述第一设备发送注册成功的响应。

接收不携带授权的注册信息的注册请求后，收到注册中心的响应之后，再次发送携带授权的注册信息的注册请求，保证注册时的安全性。

可选地，所述第一设备的具体信息具体包括：

采用MANSCDP协议格式定义的包括设备编码、设备名称、查询结果标志、厂商信息、设备型号、固件版本、最大支持摄像机个数、可接受的视频流协议、格式和端口的应答命令。

可选地，在所述向所述第一设备发送注册成功的响应之后，还包括：

建立心跳机制，保持所述第一设备与所述注册中心的连接，并根据心跳失败的规则，判断所述第一设备与所述注册中心的连接状态。

可选地，在所述向所述第一设备发送注册成功的响应之后，还包括：

预设注册事件的有效期，在所述有效期之后，所述第一设备与所述注册中心断开连接。

避免占用过多的网络资源。

可选地，在所述注册事件的有效期到临之前，向所述第一设备发送注册到期提醒。

可选地，所述根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立实时通信通道，具体包括：

接收所述其他设备返回的视频流，检查所述其他设备返回的视频流协议与流媒体服务器地址是否与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致；

若所述其他设备返回的视频流协议与流媒体服务器地址与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致，根据所述注册中心收到的所述第一设备的具体信息，定位进行呼叫的所述第一设备，将所述视频流返回所述第一设备。

实现了多协议环境下的视频通信需求。

可选地，在所述第一设备向所述注册中心发送呼叫其他设备的呼叫请求之前，还包括：

检查是否已存在所述第一设备与所述其他设备的视频通信通道，若存在，返回所述视频通信通道的链接。

可选地，所述根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道之后，还包括：

设置无人观看事件；

若触发无人观看事件，执行所述视频通信通道资源注销流程。

无人观看事件触发后，执行资源注销流程，以节省并无用户使用的资源开销。

可选地，若所述第一设备为WEB播放器，则将所述其他设备推送的视频流的格式根据所述WEB播放器的品牌、版本转换成符合所述WEB播放器的视频流格式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法的过程示意图。

图2为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法的整体流程示意图。

图3为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法中基本注册流程示意图。

图4为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法中第三方呼叫控制的实时视音频点播流程示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本身请具体实施例以及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本身请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本身请保护的范围。

针对背景技术中的问题，本申请提出了一种融合GB28181协议实现手机视频通信的方法，实现了多协议环境下的视频需求。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请实施例提供的一种融合GB28181协议实现手机视频通信的方法的过程示意图，可以包括以下步骤：

S101：接收第一设备向注册中心发起基于GB28181协议的注册请求，在所述第一设备注册成功后，基于所述注册中心的请求，向所述注册中心发送所述第一设备的具体信息；

S102:基于所述第一设备向所述注册中心发送的呼叫其他设备的呼叫请求，查询所述其他设备的具体信息，通过SIP代理服务器向所述其他设备发送INVITE请求；

S103：接收所述其他设备收到INVITE请求后做出的回应，向所述其他设备发送一个基于所述第一设备的具体信息做出的响应，所述响应包括所述第一设备能够接受的视频流协议与流媒体服务器地址以及格式与端口；

S104:根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道

步骤S101具体包括：接收所述第一设备不携带授权的注册信息的注册请求，在获得所述注册中心对所述不携带授权的注册信息的注册请求的响应之后，接收所述第一设备携带授权的注册信息的注册请求；验证所述授权的注册信息，通过后，向所述第一设备发送注册成功的响应。

图3为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法中基本注册流程示意图。其过程如下：

1.第一设备向注册中心发送Register请求，此时的Register请求不包含授权信息；

2.注册中心向第一设备发送响应401，并在响应的消息头字段中给出合适第一设备的认证体制和参数；

3.第一设备重新向注册中心发送Register请求，在请求的字段给出信任书，包含认证信息，也就是发送携带授权的注册信息的注册请求；

4.注册中心对请求进行验证，如果检查出第一设备身份合法，向第一设备发送成功响应200ok，若身份不合法则发送拒绝应答。

需要说明的是，图3所提供的一种融合GB28181协议实现手机视频通信的方法中基本注册流程示意图的注册过程并不局限于第一设备，此文件只是以第一设备为视角对注册过程进行了说明。

其中，第一设备的具体信息具体包括：

采用MANSCDP协议格式定义的包括设备编码、设备名称、查询结果标志、厂商信息、设备型号、固件版本、最大支持摄像机个数、可接受的视频流协议、格式和端口的应答命令。

在向第一设备发送注册成功的响应之后，建立心跳机制，保持第一设备与注册中心的连接，并根据心跳失败的规则，判断第一设备与注册中心的连接状态。

在本申请的一个实施例中，当第一设备的整个注册流程成功结束后，为与注册中心保持持续的连接，建立心跳机制，第一设备需要进行周期性的“心跳”行为，开启一个定时任务，周期性地向注册中心发送一个ALIVE请求，并根据超时时间，次数限制每次心跳的失败重试规则，如果超过限定的超时时间或次数，就认为第一设备与注册中心断开连接。例如，设置第一设备向注册中心每一分钟发送一个包含两次心跳的ALIVE请求，注册中心会有相应的回应，保持持续的连接，若注册中心在一分钟之内没有收到第一设备发送的包含两次心跳的ALIVE请求，则认为第一设备与注册中心断开连接。

在本申请的另一个实施例中，心跳规则可以设置为第一设备每两分钟向注册中心发送一个包含四次心跳的ALIVE请求，若注册中心在两分钟内没有收到第一设备发送的包含四次心跳的ALIVE请求，认为第一设备与注册中心断开连接。

本申请文件中的心跳规则可以根据具体情况具体设置，在此不做具体限定。

在向第一设备发送注册成功的响应之后，预设注册事件的有效期，在有效期之后，第一设备与注册中心断开连接。

在注册事件的有效期到临之前，向第一设备发送注册到期提醒。

预先设置第一设备在注册成功后的有效期，在有效期内第一设备与注册中心保持连接，在有效期结束之后，注册中心就会认为第一设备离线，此时设备发送心跳不会得到正确回应。若要实现第一设备与注册中心的重新连接，第一设备需要重新向注册中心发送一个注册请求。

若第一设备要保持与注册中心的连接，应该在注册事件的有效期结束之前向注册中心进行刷新注册，遵循IETFRFC3261对刷新注册的规定。若注册失败，第一设备应该间隔一定时间后继续发起注册过程，与上一次注册时间间隔可调，一般情况下不应该短于60秒。其中，注册事件的有效期可根据实际应用过程中具体设置，默认值为86400秒，同时注册过期时间不短于3600秒，除此之外，注册事件的有效期时间具体不做限制。

在第一设备注册事件有效期到临之前，注册中心向第一设备发送刷新注册消息，提醒第一设备注册事件的有效期的截止时间，为第一设备预留适当刷新注册处理时间，给第一设备预留考虑注册事件有效期到临之后直接断开连接，或者再次重新刷新注册保持与注册中心的连接的时间，预留时间可以为300秒、600秒，或者其他时间，在此不做具体的限制。当第一设备注册成功则认为注册中心为在线状态，注册失败则认为注册中心为离线状态；注册中心在第一设备注册成功后认为其为在线状态，第一设备注册过期则认为其为离线状态。第一设备在注册过程中，每次收到注册中心的查询请求，都应该先响应OK，再发送查询结果。

根据响应，经由SIP代理服务器与注册中心，向第一设备返回视频流，建立实时通信通道，具体包括：

接收所述其他设备返回的视频流，检查所述其他设备返回的视频流协议与流媒体服务器地址是否与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致；

若所述其他设备返回的视频流协议与流媒体服务器地址与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致，根据所述注册中心收到的所述第一设备的具体信息，定位进行呼叫的所述第一设备，将所述视频流返回所述第一设备。

SIP代理服务器接收到其他设备返回的视频流，检查收到的视频流协议和流媒体服务器地址是否和注册中心向其他设备发送的响应包含的视频流协议和流媒体服务器地址一致，若一致，SIP代理服务器通过注册中心查询第一设备的具体信息，查询到第一设备的具体信息之后，将收到的视频流转发给第一设备，进而建立一个实时视频通信通道。

在第一设备向注册中心发送呼叫其他设备的请求之前，检查是否已存在第一设备与其他设备的视频通信通道，若存在，返回视频通信通道的链接。

若不存在，则需要先向其他设备发起呼叫请求，等待其他设备响应视频流并注册后，建立视频通信通道。

根据响应，经由SIP代理服务器与注册中心，向第一设备返回视频流，建立视频通信通道之后，设置无人观看事件；若触发无人观看事件，执行所述视频通信通道资源注销流程。

设置无认观看事件，设置一个特定的时间，例如3600秒，在这一段时间内若没有人观看视频流，则会触发无人观看事件，事件触发后执行资源注销流程，以节省并无用户使用的资源开销。在本申请实施例中，无人观看事件的触发还包括通信双方某一方的挂断等情况。

若所述第一设备为WEB播放器，则将所述其他设备推送的视频流的格式根据所述WEB播放器的品牌、版本转换成符合所述WEB播放器的视频流格式。

对于WEB播放器来说，现代浏览器可以基于HTML5直接播放基于websocket的视频流。考虑不同品牌、版本浏览器的兼容性，如果想在web浏览器上实现视频播放，还需要对设备推送过来的视频流进行格式转换：老版IE浏览器(IE8-IE10)需要借助兼容性较好的flash播放器进行在线播放，视频协议为http下的flv视频流；新版的IE浏览器(IE11)与谷歌、火狐浏览器支持html5下的视频播放，应用层上可以使用websocket与http进行传输；苹果生态下的Safari浏览器默认支持hls协议下的视频播放，不过值得注意的是，hls协议实现的视频流默认就带有很高的延时，不适用于对实时性要求较高的场景，其延时普遍在10秒以上；另外现代浏览器还支持web-rtc协议的流媒体传输，可以借助注册中心，建立点对点的稳定视频通讯。

图2为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法的整体流程示意图。如图所示：

1.访问后台服务，请求某设备直播。此时可以为第一设备向注册中心注册成功之后，请求其他设备直播。

2.后台服务向设备发起呼叫请求。后台服务包括注册中心和SIP代理服务器，由SIP代理服务器转发第一设备的呼叫请求。

3.其他设备收到呼叫请求后接听或者挂断。

4.若其他设备点击接听，将视频流推送给SIP代理服务器，由SIP代理服务器经注册中心定位视频请求发起方也就是第一设备，将视频流响应到视频请求发起方。

图4为本申请实施例中提供的一种融合GB28181协议实现手机视频通信的方法中第三方呼叫控制的实时视音频点播流程示意图。如图所示，在本实施例中，媒体流接收者相当于第一设备，SIP服务器相当于注册中心，媒体服务器相当于SIP代理服务器，媒体流发送者相当于其他设备。第三方呼叫控制的实时视音频点播流程如下：

1.SIP服务器向媒体服务器发送Invite消息；

2.媒体服务器收到SIP服务器的Invite请求后,回复200OK响应,消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容；

3.SIP服务器收到媒体服务器返回的200OK响应后,向媒体流发送者发送Invite请求,请求中携带消息2中媒体服务器回复的200OK响应消息体；

4.媒体流发送者收到SIP服务器的Invite请求后,回复200OK响应,消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式等内容；

5.SIP服务器收到媒体流发送者返回的200OK响应后,向媒体服务器发送ACK请求,请求中携带消息4中媒体流发送者回复的200OK响应消息体,完成与媒体服务器的Invite会话建立过程；

6.SIP服务器收到媒体流发送者返回的200OK响应后,向媒体流发送者发送ACK请求,请求中不携带消息体,完成与媒体流发送者的Invite会话建立过程；

7.SIP服务器向媒体流接收者发送Invite消息；

8.媒体流接收者收到SIP服务器的Invite请求后,回复200OK响应,消息体中描述了媒体流接收者接收媒体流的IP、端口、媒体格式等内容；

9.SIP服务器收到媒体流接收者返回的200OK响应后,向媒体服务器发送Invite请求,请求中携带消息8中媒体流接收者回复的200OK响应消息体；

10.媒体服务器收到SIP服务器的Invite请求后,回复200OK响应,消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式等内容；

11.SIP服务器收到媒体服务器返回的200OK响应后,向媒体流接收者发送ACK请求,请求中携带消息10中媒体服务器回复的200OK响应消息体,完成与媒体流接收者的Invite会话建立过程；

12.SIP服务器收到媒体服务器返回的200OK响应后,向媒体服务器发送ACK请求,请求中不携带消息体,完成与媒体服务器的Invite会话建立过程；

13.SIP服务器向媒体流接收者发送BYE消息,断开消息7、8、11建立的同媒体流接收者的Invite会话；

14.媒体流接收者收到BYE消息后回复200OK响应,会话断开；

15.SIP服务器向媒体服务器发送BYE消息,断开消息9、10、12建立的同媒体服务器的Invite会话；

16.媒体服务器收到BYE消息后回复200OK响应,会话断开；

17.SIP服务器向媒体服务器发送BYE消息,断开消息1、2、5建立的同媒体服务器的Invite会话；

18.媒体服务器收到BYE消息后回复200OK响应,会话断开；

19.SIP服务器向媒体流发送者发送BYE消息,断开消息3、4、6建立的同媒体流发送者的Invite会话；

20.媒体流发送者收到BYE消息后回复200OK响应,会话断开；

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (8)

1.一种融合GB28181协议实现手机视频通信的方法，其特征在于，包括：

接收第一设备向注册中心发起基于GB28181协议的注册请求，在所述第一设备注册成功后，基于所述注册中心的请求，向所述注册中心发送所述第一设备的具体信息；基于所述第一设备向所述注册中心发送的呼叫其他设备的呼叫请求，查询所述其他设备的具体信息，通过SIP代理服务器向所述其他设备发送INVITE请求；

接收所述其他设备收到INVITE请求后做出的回应，向所述其他设备发送一个基于所述第一设备的具体信息做出的响应，所述响应包括所述第一设备能够接受的视频流协议与流媒体服务器地址以及格式与端口；

根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道；其中，所述在所述第一设备向所述注册中心发送呼叫其他设备的呼叫请求之前，方法还包括：

检查是否已存在所述第一设备与所述其他设备的视频通信通道，若存在，返回所述视频通信通道的链接；

若不存在，则需要先向其他设备发起呼叫请求，等待其他设备响应视频流并注册后，建立视频通信通道；

所述根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道，具体包括：

接收所述其他设备返回的视频流，检查所述其他设备返回的视频流协议与流媒体服务器地址是否与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致；

若所述其他设备返回的视频流协议与流媒体服务器地址与所述响应包括的所述第一设备能够接受的视频流协议与流媒体服务器地址一致，根据所述注册中心收到的所述第一设备的具体信息，定位进行呼叫的所述第一设备，将所述视频流返回所述第一设备。

2.根据权利要求1所述的方法，其特征在于，所述接收第一设备向注册中心发起基于GB28181协议的注册请求，在所述第一设备注册成功后，基于所述注册中心的请求，向所述注册中心发送所述第一设备的具体信息，具体包括：

接收所述第一设备不携带授权的注册信息的注册请求，在获得所述注册中心对所述不携带授权的注册信息的注册请求的响应之后，接收所述第一设备携带授权的注册信息的注册请求；

验证所述授权的注册信息，通过后，向所述第一设备发送注册成功的响应。

3.根据权利要求1所述的方法，其特征在于，所述第一设备的具体信息具体包括：

采用MANSCDP协议格式定义的包括设备编码、设备名称、查询结果标志、厂商信息、设备型号、固件版本、最大支持摄像机个数、可接受的视频流协议、格式和端口的应答命令。

4.根据权利要求2所述的方法，其特征在于，在所述向所述第一设备发送注册成功的响应之后，所述方法还包括：

建立心跳机制，保持所述第一设备与所述注册中心的连接，并根据心跳失败的规则，判断所述第一设备与所述注册中心的连接状态。

5.根据权利要求2所述的方法，其特征在于，在所述向所述第一设备发送注册成功的响应之后，所述方法还包括：

预设注册事件的有效期，在所述有效期之后，所述第一设备与所述注册中心断开连接。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在所述注册事件的有效期到临之前，向所述第一设备发送注册到期提醒。

7.根据权利要求1所述的方法，其特征在于，所述根据所述响应，经由所述SIP代理服务器与所述注册中心，向所述第一设备返回视频流，建立视频通信通道之后，所述方法还包括：

设置无人观看事件；

若触发无人观看事件，执行所述视频通信通道资源注销流程。

8.根据权利要求1所述的方法，其特征在于，若所述第一设备为WEB播放器，则将所述其他设备推送的视频流的格式根据所述WEB播放器的品牌、版本转换成符合所述WEB播放器的视频流格式。

Images