目录
一、定义
在国标GB28181中,客户端主动发起的实时视音频点播流程是一个复杂但有序的过程,它主要依赖于SIP(Session Initiation Protocol,会话初始协议)、SDP(Session Description Protocol,会话描述协议)和RTP/RTCP(Real-time Transport Protocol/Real-time Transport Control Protocol,实时传输协议/实时传输控制协议)等网络通信协议来实现数据的稳定传输和精确控制。
实时视音频点播的SIP消息应通过本域或其他域的SIP服务器进行路由、转发,目标设备的实时视音频流宜通过本域的媒体服务器进行转发。
整个流程大致可以分为以下几个阶段:客户端发送邀请请求、SIP服务器处理并转发请求、媒体服务器与媒体流发送者建立连接、媒体流接收者与媒体服务器建立连接、以及会话的断开。
二、作用
国标GB28181中客户端主动发起的实时视音频点播流程的作用主要体现在以下几个方面:
1、提供实时监控功能
实时视音频点播允许用户或相关机构实时查看监控录像,这对于安全监控、远程管理以及紧急事件响应等场景至关重要。通过实时点播,用户可以迅速获取现场情况,做出及时决策。
2、增强监控系统的功能性
通过定义标准化的实时点播流程,GB/T28181确保了不同系统之间的兼容性和互操作性,从而提高了监控系统的整体功能性。这使得监控系统能够更加灵活地应用于各种场景,满足不同用户的需求。
3、保障数据传输与接收的可靠性
实时视音频点播流程中明确规定了数据的传输和接收方式,这有助于确保音视频数据的完整性和可靠性。通过采用先进的网络通信协议(如SIP、SDP、RTP/RTCP等),实现了数据的稳定传输和精确控制,降低了数据丢失或损坏的风险。
4、实现精细化的操作与控制
实时点播流程支持用户对音视频数据的精细化操作,如播放、暂停、快进、慢放等。这为用户提供了灵活且便捷的控制方式,使得用户能够根据不同场景下的需求进行个性化的操作。
三、基本要求
根据《GB/T28181-2022》第9章关于实时视音频点播的描述,GB28181的实时视音频点播应满足以下基本要求::
a)实时视音频点播的SIP消息应通过本域或其他域的SIP服务器进行路由、转发,目标设备的实时视音频流宜通过本域内的媒体服务器进行转发。
b)实时视音频点播采用SIP协议(IETFRFC3261)中的Invite方法实现会话连接,采用RTP/RTCP协议(IETFRFC3550)实现媒体传输。
c)实时视音频点播的信令流程分为客户端主动发起和第三方呼叫控制两种方式,联网系统可选择其中一种或两种结合的实现方式。第三方呼叫控制的第三方控制者宜采用背靠背用户代理实现,有关第三方呼叫控制见IETFRFC3725。
d)实时视音频点播宜支持附录K 规定的媒体流保活机制。
四、命令流程
1、流程图
客户端主动发起的实时视音频点播流程符合如下流程图:
2、流程描述
(1)概述
在流程中,信令1、8、9、10、11、12为SIP服务器接收到客户端的呼叫请求后通过B2BUA 代理方式建立媒体流接收者与媒体服务器之间的媒体流信令过程,信令2~7为SIP服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体流信令过程,信令13~16为媒体流接收者断开与媒体服务器之间的媒体流信令过程,信令17~20为SIP服务器断开媒体服务器与媒体流发送者之间的媒体流信令过程。
(2)命令流程描述如下:
a) 1:媒体流接收者向SIP服务器发送Invite消息,消息头域中携带Subject字段,表明点播的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数,SDP消息体中s字段为“Play”代表实时点播。
b) 2:SIP服务器收到Invite请求后,通过三方呼叫控制建立媒体服务器和媒体流发送者之间的媒体连接。向媒体服务器发送Invite消息,此消息不携带SDP消息体。
c) 3:媒体服务器收到SIP服务器的Invite请求后,回复200OK 响应,携带SDP消息体,消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容。
d) 4:SIP服务器收到媒体服务器返回的200OK 响应后,向媒体流发送者发送Invite请求,请求中携带消息3中媒体服务器回复的200OK 响应消息体,s字段为“Play”代表实时点播,增加y字段描述SSRC值,f字段描述媒体参数。
e) 5:媒体流发送者收到SIP服务器的Invite请求后,回复200OK 响应,携带SDP消息体,消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式、SSRC字段等内容。
f) 6:SIP服务器收到媒体流发送者返回的200OK 响应后,向媒体服务器发送ACK 请求,请求中携带消息5中媒体流发送者回复的200OK 响应消息体,完成与媒体服务器的Invite会话建立过程。
g) 7:SIP服务器收到媒体流发送者返回的200OK 响应后,向媒体流发送者发送ACK 请求,请求中不携带消息体,完成与媒体流发送者的Invite会话建立过程。
h) 8:完成三方呼叫控制后,SIP服务器通过B2BUA 代理方式建立媒体流接收者和媒体服务器之间的媒体连接。在消息1中增加SSRC值,转发给媒体服务器。
i) 9:媒体服务器收到Invite请求,回复200OK 响应,携带SDP消息体,消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式、SSRC值等内容。
j) 10:SIP服务器将消息9转发给媒体流接收者。
k) 11:媒体流接收者收到200OK响应后,回复ACK消息,完成与SIP服务器的Invite会话建立过程。
l) 12:SIP服务器将消息11转发给媒体服务器,完成与媒体服务器的Invite会话建立过程。
m) 13:媒体流接收者向SIP服务器发送BYE消息,断开消息1、10、11建立的同媒体流接收者的Invite会话。
n) 14:SIP服务器收到BYE消息后回复200OK响应,会话断开。
o)15:SIP服务器收到BYE消息后向媒体服务器发送BYE消息,断开消息8、9、12建立的同媒体服务器的Invite会话。
p) 16:媒体服务器收到BYE消息后回复200OK响应,会话断开。
q) 17:SIP服务器向媒体服务器发送BYE消息,断开消息2、3、6建立的同媒体服务器的Invite会话。
r) 18:媒体服务器收到BYE消息后回复200OK响应,会话断开。
s) 19:SIP服务器向媒体流发送者发送BYE 消息,断开消息4、5、7建立的同媒体流发送者的Invite会话。
t) 20:媒体流发送者收到BYE消息后回复200OK响应,会话断开。
五、协议接口
协议接口满足以下要求,
a)SIP 消息头域(如 TO、FROM、Cseq、Call-ID,Max-Forwards、Via等)的详细定义符合相关 SIP消息的RFC文档的规定。
b)消息头域 Allow字段应支持INVITE、ACK、INFO,CANCEL BYE、OPTIONS、MESSAGE方法。
c)发送给媒体服务器的消息的消息头应包括Subiject字段,系统应支持该字段,详细定义应符合附录1的规定。实时视频图像点播流程中携带的请求和应答消息体采用SDP协议格式定义有关SDP的详细描述见IETF RFC4566.
d)消息头 Content-type字段应表示消息体采用SDP协议格式定义,即Content-type:application/sdp.
e)SDP文本信息包括会话名称和意图、会话持续时间、构成会话的媒体,有关接收媒体的信息 (地址等)。
f)源设备应在SDP协议格式的消息体中包括t行(见IETFRFC4566的5.9),t行的开始时间和结束时间均设置成0,表示实时视音频点播。
g)SDP协议格式消息体应包括0行(见IETFRFC4566的5.2),o行中的username应为本设备的设备编码,设备编码应符合6.1.1的规定;c行中应包括设备或系统IP地址;m行中应包括媒体接收端口号。
六、产品说明
AS-V1000视频监控平台能够多种方式接入国内和国际主流品牌的视频监控平台、视频相关设备、外围设备等;支持国际和国内的一些标准对接协议,包括RTSP协议、Onvif协议、GB/T28181协议、ehome协议、大华主动注册协议等等。
AS-V1000视频监控平台能够完美支持GB/T28181,通过公安一所的GB/T28181全项检测。既可以作为GB/T28181的上级,也可以作为GB/T28181的下级,还能够进行GB/T28181的互联(同时作为上级,又可以作为下级);能够通过GB/T28181进行多达8级的级联。目前AS-V1000视频监控平台也已经完全支持最新的GB/T28181-2022版本。
可以通过通信协议,接入IPC、DVR、DVS、NVR、编码器、解码器等硬件设备、以及一些大型的软件或者硬件形式的视频监控平台,包括海康威视、浙江大华、苏州科达、杭州宇视等主流品牌;对于有些特定品牌的平台,也能够通过SDK接口、私有协议等方式接入进入本系统平台;反过来,本平台也提供开放接口,能够接入到其他标准或者非标准的平台。
七、参考
《GB/T 28181-2022 公共安全视频监控联网系统信息传输、交换、控制技术要求》
《GB/T 28181-2016 公共安全视频监控联网系统信息传输、交换、控制技术要求》
《AS-V1000视频监控平台产品概要说明》
文章正下方可以看到我的联系方式:鼠标“点击” 下面的 “威迪斯特-就是video system 微信名片”字样,就会出现我的二维码,欢迎沟通探讨。