目录
一、定义
国标28181（GB/T 28181-2022）《公共安全视频监控联网系统信息传输、交换、控制技术要求》是一部关于公共安全视频监控联网系统的国家标准，该标准在2022年12月30日发布，并于2023年7月1日正式实施。
在国标GBT28181中，定义了第三方呼叫控制的历史视音频回放流程，指的是一种通过特定的通信协议（如SIP）和接口，由非直接参与媒体流传输的实体（即第三方）来控制和管理“存储在服务器或设备上历史视音频回放”的功能或机制。
整个流程基于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）概述
其中，信令 1~6为 SIP 服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体链接信令过程，信令 7~12 为 SIP 服务器通过三方呼叫控制建立媒体流接收者与媒体服务器之间的媒体链接信令过程，信令 13~14 为回放控制信令过程，信令 15~16 为媒体流发送者回放、下载到文件结束向媒体接收者发送的回放结束通知消息，信令 17~20 为断开媒体流接收者与媒体服务器之间的媒体链接信令过程，信令 21~24 为断开媒体服务器与媒体流发送者之间的媒体链接信令过程。
（2）命令流程描述如下:
a）1:SIP 服务器向媒体服务器发送 Invite 消息，此消息不携带 SDP 消息体；
b）2:媒体服务器收到 SIP 服务器的 Invite 请求后，回复 200 OK 响应，携带 SDP 消息体，消息体中描述了媒体服务器接收媒体流的 IP、端口、媒体格式等内容；
c）3:SIP 服务器收到媒体服务器返回的 200 OK 响应后，向媒体流发送者发送 Invite 请求，请求中携带消息2中媒体服务器回复的 200 OK 响应消息体，s字段为“Playback”代表历史回放，u字段代表回放通道 ID 和回放类型，t字段代表回放时间段，增加y字段描述 SSRC值，f字段描述媒体参数；
d）4:媒体流发送者收到 SIP 服务器的 Invite 请求后，回复 200 OK 响应，携带 SDP 消息体，消息体中描述了媒体流发送者发送媒体流的 IP、端口、媒体格式、SSRC字段等内容；
e）5:SIP 服务器收到媒体流发送者返回的 200 OK 响应后，向媒体服务器发送 ACK 请求，请求中携带消息4中媒体流发送者回复的 200 OK 响应消息体，完成与媒体服务器的 Invite 会话建立过程；
f）6:SIP 服务器收到媒体流发送者返回的 200 OK 响应后，向媒体流发送者发送 ACK 请求，请5)求中不携带消息体，完成与媒体流发送者的Invite 会话建立过程；
g）7:SIP 服务器向媒体流接收者发送 Invite 消息，此消息不携带 SDP 消息体；
h）8)8:媒体流接收者收到 SIP 服务器的 Invite 请求后，回复 200 OK 响应，携带 SDP 消息体，消息h)体中描述了媒体流接收者接收媒体流的P、端口、媒体格式等内容；
i）9:SIP 服务器收到媒体流接收者返回的 200 OK 响应后，向媒体服务器发送 Invite 请求，请求D)中携带消息8中媒体流接收者回复的 200 OK 响应消息体，s字段为“Playback”代表历史回放，增加y字段描述 SSRC 值；
j）10:媒体服务器收到 SIP 服务器的 Invite 请求后，回复 200 OK 响应，携带 SDP 消息体，消息体i)中描述了媒体服务器发送媒体流的 IP、端口、媒体格式、SSRC字段等内容；
k）11:SIP 服务器收到媒体服务器返回的 200 OK 响应后，向媒体流接收者发送 ACK 请求，请求k)中携带消息 10 中媒体服务器回复的 200 OK 响应消息体，完成与媒体流接收者的 Invite 会话建立过程；
l）12:SIP 服务器收到媒体服务器返回的 200 OK 响应后，向媒体服务器发送 ACK请求，请求中不携带消息体，完成与媒体服务器的Invite 会话建立过程；
m）13:在回放过程中，SIP 服务器通过向媒体流发送者发送 Info 消息进行回放控制，包括视频的斩停、播放、定位、快放、慢放等操作，Info 消息体见附录 B；
n）14:媒体流发送者收到 1nfo 消息后回复 200 OK 响应:
o）15:媒体流发送者在文件回放结束后发送会话内 Message 消息,通知 SIP 服务器回放已结束,消息体格式参见 A.2.5媒体通知;
p）16:SIP 服务器收到 Message 消息后回复 200 OK 响应,进行链路断开过程;
q）17:SIP 服务器向媒体流接收者发送 BYE 消息,断开消息 7、8、11 建立的同媒体流接收者的4)Invite 会话:
r）18:媒体流接收者收到 BYE 消息后回复 200 OK 响应,会话断开;
s）19:SIP 服务器向媒体服务器发送 BYE, 消息,断开消息 9、10、12 建立的同媒体服务器的 Invite 会话;
t）20:媒体服务器收到 BYE 消息后回复 200 OK 响应,会话断开;
u）21:SIP 服务器向媒体服务器发送 BYE 消息,断开消息 1、2、5建立的同媒体服务器的 Invite 会话;
v）22:媒体服务器收到 BYE 消息后回复 200 OK 响应,会话断开;
w）23:SIP 服务器向媒体流发送者发送 BYE 消息,断开消息 3、4、6建立的同媒体流发送者的Invite 会话:
x）24:媒体流发送者收到 BYE 消息后回复 200 OK 响应,会话断开。
五、协议接口
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详解：国标GBT28181-2022的客户端主动发起历史视音频回放流程》
国标GB/T28181-2022协议标准中的9.8.2.1描述的客户端主动发起的历史媒体回放流程与9.8.2.2描述的第三方呼叫控制的历史视音频回放流程，在功能、操作方式和作用上存在一定区别。
1、功能定义
（1）客户端主动发起的历史媒体回放流程：该流程允许客户端（如用户或相关机构）主动发起对存储在服务器或设备上的历史音视频数据的回放请求。这一流程提供了数据回顾的便利性，并增强了监控系统的功能性。
（2）第三方呼叫控制的历史视音频回放流程：此流程主要涉及通过第三方呼叫控制的方式实现历史视音频的回放。这一流程可能涉及更复杂的信令交互和会话控制，以实现精细化的操作与控制。
2、操作方式
（1）客户端主动发起的历史媒体回放流程：主要基于客户端的主动操作，如通过用户界面选择回放的时间段、通道等参数，然后向服务器发送回放请求。服务器在接收到请求后，根据请求的参数进行历史音视频数据的检索和回放。
（2）第三方呼叫控制的历史视音频回放流程：可能涉及多个设备之间的信令交互和会话控制。例如，SIP服务器可能需要向媒体服务器发送Invite消息以建立回放会话，然后媒体服务器根据请求的参数进行历史音视频数据的检索和传输。这一过程可能需要更多的协议交互和信令处理。
3、作用与影响
（1）客户端主动发起的历史媒体回放流程：提供了有效的数据回顾机制，增强了监控系统的功能性，并保障了数据传输与存储的可靠性。同时，该流程还支持对音视频数据的精细化操作，如暂停、播放、快进、慢放等，以满足不同场景下的回放需求。
（2）第三方呼叫控制的历史视音频回放流程：除了提供数据回顾和监控系统功能增强的作用外，还可能涉及更复杂的网络拓扑和设备间的交互。这一流程有助于推动监控系统的集成化发展，使不同厂商和系统能够更容易地实现互联互通。
总结来说，9.8.2.1客户端主动发起的历史媒体回放流程更侧重于客户端的主动操作和数据的直接回放，而9.8.2.2描述的第三方呼叫控制的历史视音频回放流程则可能涉及更复杂的网络拓扑和设备间交互，以实现更精细化的操作与控制。两者在功能定义、操作方式和作用上存在一定差异，但都是GB/T28181协议标准中重要的组成部分。
八、参考
《GB/T 28181-2022 公共安全视频监控联网系统信息传输、交换、控制技术要求》
《GB/T 28181-2016 公共安全视频监控联网系统信息传输、交换、控制技术要求》
《AS-V1000视频监控平台产品概要说明》
《国标GB/T 28181详解：国标GBT28181-2022的客户端主动发起历史视音频回放流程》
文章正下方可以看到我的联系方式：鼠标“点击” 下面的 “威迪斯特-就是video system 微信名片”字样，就会出现我的二维码，欢迎沟通探讨。
1131
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
