目录
一、定义
二、作用
1、提供有效的数据回顾机制
2、增强监控系统的功能性
3、保障数据传输与存储的可靠性
4、实现精细化的操作与控制
5、促进监控系统的集成与发展
三、历史视音频回放的基本要求
四、命令流程
1、流程图
2、流程描述
五、协议接口
1、会话控制协议
2、历史视音频回放控制协议
六、产品说明
七、参考
一、定义
在国标GBT28181中,定义了客户端主动发起历史视音频回放流程,它允许客户端主动发起对存储在服务器或设备上的历史音视频数据的回放请求。整个流程基于SIP、SDP和RTP/RTCP等网络通信协议,确保了数据的稳定传输和精确控制。
二、作用
在国标GB/T28181-2022中,定义的历史视音频回放流程,有如下几个方面的作用:
1、提供有效的数据回顾机制
历史音视频回放流程允许用户或相关机构回顾和分析过去的监控录像。这对于事件调查、安全管理以及后续的决策制定都具有重要意义。例如,在发生安全事件后,可以通过回放录像来查找线索或证据。
2、增强监控系统的功能性
回放功能是现代监控系统不可或缺的一部分。通过定义标准化的回放流程,GB/T28181确保了不同系统之间的兼容性和互操作性,从而提高了监控系统的整体功能性。
3、保障数据传输与存储的可靠性
流程中明确规定了数据的传输和存储方式,这有助于确保历史音视频数据的完整性和可靠性。标准化的流程还降低了数据损坏或丢失的风险。
4、实现精细化的操作与控制
该流程支持对音视频数据的精细化操作,如暂停、播放、快进、慢放等。这为用户提供了灵活且便捷的控制方式,以满足不同场景下的回放需求。
5、促进监控系统的集成与发展
作为国家标准,GB/T28181的定义有助于推动监控系统的标准化和集成化。统一的回放流程标准使得不同厂商和系统能够更容易地实现互联互通,从而促进了整个监控行业的发展。
三、历史视音频回放的基本要求
根据《GB/T28181-2022》第9章关于历史视音频回放的描述,GB28181的历史视音频视频回放应满足以下基本要求:
- 应采用SIP协议(IETFRFC3261)中的INVITE方法实现会话连接,采用SIP扩展协议(IETFRFC2976) INFO方法的消息体携带视音频回放控制命令,采用RTP/RTCP协议(IETFRFC3550)实现媒体传输。媒体回放控制命令引用MANSRTSP协议中的PLAYPAUSE、TEARDOWN的请求消息和应消息,具体见附录B。
- 历史媒体回放的信令流程分为客户端主动发起和第三方呼叫控制两种方式,联网系统可选择其中一种或两种结合的实现方式。第三方呼叫控制的第三方控制者宜采用B2BUA实现,有关第三方呼叫控制见IETFRFC3725。
- 媒体流接收者可为包括SIP客户端、SIP设备(如视频解码器),媒体流发送者可为SIP设备网关、媒体服务器。
- 历史视音频的回放应符合附录K规定的媒体流保活机制。
四、命令流程
1、流程图
客户端主动发起的历史媒体回放流程符合如下流程图:
2、流程描述
其中,信令1、8、9、10、11、12为SIP服务器接收到客户端的呼叫请求后通过 B2BUA 代理方式建立 媒体流接受者与媒体服务器之间的媒体链接信令过程,信令2~7为SIP服务器通过三方呼叫控制建立 媒体服务器与媒体流之间的媒体链接信令过程,信令13~16为媒体流接收者进行回放控制信令过程,信令17~20为媒体流发送者回放、下载到文件结束向媒体接收者发送通知消息过程,信令21~24为断 开媒体流接收者与媒体服务器之间的媒体链接信令过程,信令25~28为SIP服务器断开媒体服务器与 媒体流发送者之间的媒体链接信令过程。
命令流程描述如下:
a) 1:媒体流接收者向SIP服务器发送Invite消息,消息头域中携带Subject字段,表明点播的视频源 ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号标识等参数,SDP消息体中s字 段为“Playback”代表历史回放,u字段代表回放通道ID和回放类型,t字段代表回放时间段。
b) 2:SIP服务器收到Invite请求后,通过三方呼叫控制建立媒体服务器和媒体流发送者之间的 媒体连接。向媒体服务器发送Invite消息,此消息不携带SDP消息体。
c) 3:媒体服务器收到SIP服务器的Invite请求后,回复200OK 响应,携带 SDP消息体,消息体 中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容。
d) 4:SIP服务器收到媒体服务器返回的200OK 响应后,向媒体流发送者发送Invite请求,请求 中携带消息3中媒体服务器回复的200OK 响应消息体,s字段为“Playback”代表历史回放,u 字段代表回放通道ID和回放类型,t字段代表回放时间段,增加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服务器发送会话内Info消息进行回放控制,包括 视频的暂停、播放、快放、慢放、随机拖放播放等操作,Info消息体见附录 B。
n) 14:SIP服务器收到消息13后转发给媒体流发送者。
o) 15:媒体流发送者收到消息14后回复200OK 响应。
p) 16:SIP服务器将消息15转发给媒体流接收者。
q) 17:媒体流发送者在文件回放结束后发送会话内 Message消息,通知SIP服务器回放已结束, 消息体格式参见 A.2.5媒体通知。
r) 18:SIP服务器收到消息17后转发给媒体流接收者。
s) 19:媒体流接收者收到消息18后回复200OK 响应,进行链路断开过程。
t) 20:SIP服务器将消息19转发给媒体流发送者。
u) 21:媒体流接收者向SIP服务器发送 BYE消息,断开消息1、10、11建立的同媒体流接收者的 Invite会话。
v) 22:SIP服务器收到 BYE消息后回复200OK 响应,会话断开。
w)23:SIP服务器收到 BYE 消息后向媒体服务器发送 BYE 消息,断开消息8、9、12建立的同媒体服务器的Invite会话。
x) 24:媒体服务器收到 BYE消息后回复200OK 响应,会话断开。
y) 25:SIP服务器向媒体服务器发送BYE消息,断开消息2、3、6建立的同媒体服务器的Invite会话。
z) 26:媒体服务器收到 BYE消息后回复200OK 响应,会话断开。
aa) 27:SIP服务器向媒体流发送者发送 BYE 消息,断开消息4、5、7建立的同媒体流发送者的 Invite会话。
bb) 28:媒体流发送者收到 BYE消息后回复200OK 响应,会话断开。
五、协议接口
1、会话控制协议
a)SIP消息头域(如 TO、FROM、Cseq、Call-ID、Max-Forwards和 Via等)的详细定义符合相关 SIP 消息的 RFC文档的规定。
b)消息头域 Allow 字段应支持Invite、ACK、Info、CANCEL、BYE、OPTIONS和 Message方法,不排 除支持其他SIP和SIP扩展方法。
c)消息头 Content-type字段为 Content-type:application/sdp。
d)历史视音频回放流程中携带消息体的请求和响应的消息体应采用 SDP协议格式定义。有关 SDP 的详细描述见IETFRFC4566。
e)SDP文本信息包括:会话名称和意图、会话持续时间、构成会话的媒体和有关接收媒体的信息(地 址等)。Invite请求以时间段方式获取历史图像。
f) 定位历史视音频数据的信息在SDP协议格式的消息体中携带,应包含设备名和时间段信息,规定 如下:
1)媒体流接收者应在 SDP协议格式的消息体中包括 u行(见IETFRFC4566—2006的5.5), u行应填写产生历史媒体的媒体源(如某个摄像头)的设备 URI,应符合6.1.2的规定。设备 URI应包含媒体源设备编码,媒体源设备编码成为检索历史媒体数据的设备名信息。
2)媒体流接收者应在 SDP协议格式的消息体中包括t行(见IETFRFC4566—2006的5.9), t行的开始时间和结束时间组成检索历史媒体数据的时间段信息。
2、历史视音频回放控制协议
历史视音频回放控制协议满足以下要求:
a) 视音频回放控制流程是采用SIP消息INFO实现视音频播放、暂停、进/退和停止等视音频回放控制命令的过程;
b) 视音频回放控制请求消息在INFO方法的消息体中携带,回放控制请求消息应符合MANSRTSP协议的请求消息的部分定义,包括PLAY、PAUSE、TEARDOWN;
c) 视音频回放控制应答消息可在INFO方法的200OK响应消息体中携带,回放控制应答消息应符合MANSRTSP协议的应答消息定义,视音频回放控制命令的详细描述应符合附录B的规定;
d) 携带MANSRTSP请求和应答命令的INFO消息头Content-type字段为Content-type:Apd)plication/MANSRTSP。
六、产品说明
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 微信名片”字样,就会出现我的二维码,欢迎沟通探讨。