视频监控联网系统GB28181协议中历史视音频的回放流程详解以及查询失败常见原因

9.8 历史视音频的回放

9.8.1 基本要求

历史视音频回放满足以下基本要求。
a) 应采用 SIP 协 议(IETF RFC 3261)中 的 INVITE 方法实现会话连接，采用 SIP 扩展协议 (IETF RFC 2976)INFO 方法的消息体携带视音频回放控制命令，采用 RTP/RTCP 协议 (IETF RFC 3550)实现媒体传输。媒体回放控制命令引用 MANSRTSP 协议中的 PLAY、
PAUSE 、TEARDOWN 的请求消息和应答消息，具体见附录 B。
b) 历史媒体回放的信令流程分为客户端主动发起和第三方呼叫控制两种方式，联网系统可选择 其中一种或两种结合的实现方式。第三方呼叫控制的第三方控制者宜采用 B2BUA 实现，有
关第三方呼叫控制见 IETF RFC 3725。
c) 媒体流接收者可为包括 SIP 客户端、SIP 设备(如视频解码器),媒体流发送者可为 SIP 设备、
网关、媒体服务器。
d) 历史视音频的回放应符合附录 K 规定的媒体流保活机制。

9.8.2 命令流程

9.8.2.1 客户端主动发起

客户端主动发起的历史视音频回放流程应与图19相符合。

其中，信令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 请求后，回复200 OK 响应，携带 SDP 消息体，消息体中描述了媒体服务器接收媒体流的 IP、端口、媒体格式等内容。

d) 4:SIP 服务器收到媒体服务器返回的200 OK 响应后，向媒体流发送者发送 Invite 请求，请求 中携带消息3中媒体服务器回复的200 OK 响应消息体，s 字段为“Playback” 代表历史回放，u 字段代表回放通道 ID 和回放类型，t 字段代表回放时间段，增加 y 字段描述 SSRC 值 ，f 字段描述媒体参数。

e) 5:媒体流发送者收到 SIP 服务器的 Invite 请求后，回复200 OK 响应，携带 SDP 消息体，消息
体中描述了媒体流发送者发送媒体流的 IP、端口、媒体格式、SSRC 字段等内容。

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

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

h) 8:完成三方呼叫控制后，SIP 服务器通过B2BUA 代理方式建立媒体流接收者和媒体服务器之
间的媒体连接。在消息1中增加 SSRC 值，转发给媒体服务器。

i) 9:媒体服务器收到 Invite 请求，回复200 OK 响应，携带 SDP 消息体，消息体中描述了媒体服
务器发送媒体流的 IP、端口、媒体格式、SSRC 值等内容。

j) 10:SIP 服务器将消息9转发给媒体流接收者。

k) 11:媒体流接收者收到200 OK 响应后，回复 ACK 消息，完成与 SIP 服务器的 Invite 会话建立
过程。

l) 12:SIP 服务器将消息11转发给媒体服务器，完成与媒体服务器的 Invite 会话建立过程。

m)13: 在回放过程中，媒体流接收者通过向 SIP 服务器发送会话内 Info 消息进行回放控制，包括
视频的暂停、播放、快放、慢放、随机拖放播放等操作，Info 消息体应符合附录 B 的规定。

n) 14:SIP 服务器收到消息13后转发给媒体流发送者。

o) 15:媒体流发送者收到消息14后回复200 OK 响应。

p) 16:SIP 服务器将消息15转发给媒体流接收者。

q) 17:媒体流发送者在文件回放结束后发送会话内 Message 消息，通知 SIP 服务器回放已结
束，消息体格式应符合 A.2.5.4 媒体通知的要求。

r) 18:SIP 服务器收到消息17后转发给媒体流接收者。

s) 19:媒体流接收者收到消息18后回复200 OK 响应，进行链路断开过程。

t) 20:SIP 服务器将消息19转发给媒体流发送者。

u) 21:媒体流接收者向SIP 服务器发送 BYE 消息，断开消息1、10、11建立的同媒体流接收者的
Invite 会话。

v) 22:SIP 服务器收到 BYE 消息后回复200 OK 响应，会话断开。

w) 23:SIP 服务器收到 BYE 消息后向媒体服务器发送 BYE 消息，断开消息8、9、12 建立的同媒
体服务器的 Invite 会话。

x) 24:媒体服务器收到 BYE 消息后回复200 OK 响应，会话断开。

y) 25:SIP 服务器向媒体服务器发送 BYE 消息，断开消息2、3、6建立的同媒体服务器的 Invite
会话。

z) 26:媒体服务器收到 BYE 消息后回复200 OK 响应，会话断开。

aa) 27:SIP 服务器向媒体流发送者发送 BYE 消息，断开消息4、5、7建立的同媒体流发送者的
Invite 会话。

bb) 28:媒体流发送者收到 BYE 消息后回复200 OK 响应，会话断开。

9.8.2.2 第三方呼叫控制

第三方呼叫控制的历史视音频回放流程应与图20相符合。

其中，信令1～6为SIP 服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体链接 信令过程，信令7～12为 SIP 服务器通过三方呼叫控制建立媒体流接收者与媒体服务器之间的媒体链 接信令过程，信令13～14为回放控制信令过程，信令15～16 为媒体流发送者回放、下载到文件结束向 媒体接收者发送回放结束的通知消息过程，信令17～20为断开媒体流接收者与媒体服务器之间的媒体
链接信令过程，信令21～24为断开媒体服务器与媒体流发送者之间的媒体链接信令过程。

命令流程描述如下：
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 请求，请
求中不携带消息体，完成与媒体流发送者的 Invite 会话建立过程；

g) 7:SIP 服务器向媒体流接收者发送 Invite 消息，此消息不携带 SDP 消息体；

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

i) 9:SIP 服务器收到媒体流接收者返回的200 OK 响应后，向媒体服务器发送 Invite 请求，请求 中携带消息8中媒体流接收者回复的200 OK 响应消息体，s 字段为“Playback” 代表历史回
放，增加 y 字段描述 SSRC 值 ；

j) 10: 媒体服务器收到 SIP 服务器的 Invite 请求后，回复200 OK 响应，携带 SDP 消息体，消息体
中描述了媒体服务器发送媒体流的 IP、端口、媒体格式、SSRC 字段等内容；

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

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

m)13: 在回放过程中，SIP 服务器通过向媒体流发送者发送 Info 消息进行回放控制，包括视频的
暂停、播放、定位、快放、慢放等操作，Info 消息体应符合附录B 的规定；

n) 14:媒体流发送者收到 Info 消息后回复200 OK 响应；

o) 15:媒体流发送者在文件回放结束后发送会话内 Message 消息，通知 SIP 服务器回放已结
束，消息体格式应符合 A.2.5.4 媒体通知的要求；

p) 16:SIP 服务器收到 Message 消息后回复200 OK 响应，进行链路断开过程；

q) 17:SIP 服务器向媒体流接收者发送 BYE 消息，断开消息7、8、11建立的同媒体流接收者的
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 响应，会话断开。

9.8.3 协议接口

9.8.3.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 的详细描述见IETF RFC 4566。
e) SDP 文本信息包括：会话名称和意图、会话持续时间、构成会话的媒体、有关接收媒体的信息
(地址等)。 INVITE 请求以时间段方式获取历史图像。
f) 定位历史视音频数据的信息在 SDP 协议格式的消息体中携带，应包含设备名和时间段信
息，规定如下。

1. 媒体流接收者应在 SDP 协议格式的消息体中包括 u 行(见 IETF RFC 4566 的5.5),u 行 应填写产生历史媒体的媒体源(如某个摄像头)的设备 URI, 应符合6.1.2 的规定。设备URI 应包含媒体源设备编码，媒体源设备编码成为检索历史媒体数据的设备名信息。
2. 媒体流接收者应在 SDP 协议格式的消息体中包括 t 行(见 IETF RFC4566 的5.9),t 行的开始时间和结束时间组成检索历史媒体数据的时间段信息。

9.8.3.2 视音频回放控制协议

历史视音频回放控制协议满足以下要求：
a) 视音频回放控制流程是采用SIP 消息 INFO 实现视音频播放、暂停、进/退和停止等视音频回
放控制命令的过程；
b) 视音频回放控制请求消息在 INFO 方法的消息体中携带，回放控制请求消息应符合 MAN-
SRTSP 协议的请求消息的部分定义，包括 PLAY 、PAUSE 、TEARDOWN;
c) 视音频回放控制应答消息可在 INFO 方法的200 OK 响应消息体中携带，回放控制应答消息 应符合 MANSRTSP 协议的应答消息定义，视音频回放控制命令的详细描述应符合附录 B 的
规定；
d) 携带 MANSRTSP 请求和应答命令的 INFO 消息头 Content-type 字段为Content-type:Ap
plication/MANSRTSP。

国标28181中历史视音频的回放失败原因

一、协议交互流程问题

• SIP信令交互失败
  • 原因：INVITE请求中的关键参数错误（如时间范围格式不符、Subject字段未携带会话ID或媒体类型标识）。
  • 排查点：检查SDP报文中的Playback模式参数（a=Playback）是否完整，时间范围是否符合UTC格式（如20250521T095000Z-20250521T100000Z）。
  • 解决方案：使用抓包工具（如Wireshark）分析SIP信令，确认平台与设备是否支持PLAY、TEARDOWN等基本操作。
• 时间参数不匹配
  • 原因：请求的时间段无有效录像（设备未存储该时段数据，或录像文件已损坏/被覆盖）。
  • 排查点：通过设备本地接口或平台日志确认录像存储状态，检查NVR/DVR的存储策略（如循环录制是否开启）。

二、网络与设备配置问题

• 网络传输异常
  • 原因：媒体流传输端口（UDP/TCP）未开放或带宽不足，导致RTP/RTCP流丢包。
  • 排查点：检查防火墙规则、NAT穿透配置（如是否启用TCP Active模式），测试网络延迟和抖动。
• 设备能力不支持
  • 原因：设备未实现历史回放功能（如部分IPC仅支持实时流），或编码格式不兼容（如平台要求H.264而设备仅支持H.265）。
  • 解决方案：查阅设备手册确认GB28181协议版本兼容性，升级固件或调整平台解码策略。

三、媒体流处理问题

• 媒体流解析失败
  • 原因：PS（封装格式）或RTP负载格式不符合标准（如缺少SPS/PPS帧），导致平台无法解码。
  • 排查点：通过媒体分析工具（如VLC或FFmpeg）检查流是否可正常播放，确认SSRC和Payload Type匹配。
• 录像索引缺失
  • 原因：设备未生成或未同步录像索引文件（如MP4的moov头信息损坏）。
  • 解决方案：尝试通过设备本地导出录像，检查文件完整性。

智联视频超融合平台介绍

• 智联视频超融合平台通过GB/T28181-2011/2016/2022、国网B接口、RTSP、RTMP、ONVIF、GB/T35114、GA1400、海康大华SDK/API等方式，接入海康、大华、宇视等各个厂家的摄像机、录像机，接入直播手机，接入下级平台，提供web客户端进行视频预览、录像回放、配置管理和智慧运维。

• 提供标准RESTful格式的HTTP API，提供web播放器demo，满足二次开发需求。同时支持将音视频数据等转发成各种通用标准的流媒体协议，方便第三方客户端调用展示。

• 支持按照GB/T28181-2011/2016/2022、国网B接口、GB/T35114、GA1400等协议对接到上级平台，包括智联视频云平台和第三方平台。支持普通级联，多级级联，混合级联等多种级联方式。
  
  智联视频超融合平台目前已经在电力、公安、交通、教育、医疗、物联网、智慧城市、智慧园区等多个行业得到了广泛应用。在电力行业，智联视频超融合平台已经在全国多个省区二十多个地市部署，在上百个变电站和集控中心接入了十多个厂家的摄像机、无人机、录像机和平台，视频接入总数接近十万路，持续为电力行业贡献力量。在公安行业，已经参与过多个二十万路以上视频的项目，稳定性和安全性都得到了充分的验证。