全网最全GB/T 28181剖析3️⃣设备的信息查询以及点播本章将继续深入对28181协议中点播信令的剖析，与大家一起了

本章将继续深入对28181协议中点播信令的剖析，与大家一起了解下。

本章以及后续章节描述的协议内容将主要参考GB/T 28181最新在行的2022版本，在描述中将会标注出是否是2022版本特有，且核心协议基本是向下兼容的，大家可以放心食用。

1. 设备的信息查询

当我们将设备成功注册到平台后，平台将要下发信令用来获取视频通道的视频流，这时就需要知道设备配置有哪些视频通道可以推送视频，于是先要询问设备的视频通道的列表，为点播做准备。

1.1 整体流程

sequenceDiagram
SIP服务->>接入设备: 1. Message 设备查询请求命令
接入设备->>SIP服务: 2. 200 OK
接入设备->>SIP服务: 3. Message 设备查询响应命令
SIP服务->>接入设备: 4. 200 OK

SIP服务器向目标设备转发设备查询命令,设备查询命令采用 Message方法携带;

目标设备收到命令后返回200OK;

目标设备向SIP服务器发送设备查询响应命令,设备查询响应命令采用 Message方法携带;

SIP服务器收到命令后返回200OK;

1.2 信令解析

1.2.1 设备查询

MESSAGE sip:62010201001320000393@10.18.44.86:5060 SIP/2.0
To: <sip:62010201001320000393@10.18.44.86:5060>
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=90650094
Call-ID: 11ec6335-eaec-4c71-b631-f08d114abae40
CSeq: 1332667738 MESSAGE
Max-Forwards: 70
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7fab61e50400385148953;rport
User-Agent: zdww sip server
Content-Type: Application/MANSCDP+xml
Content-Length: 139

<?xml version="1.0" encoding="GB2312"?>
<Query>
<CmdType>Catalog</CmdType>
<SN>1708</SN>
<DeviceID>62010201001320000393</DeviceID>
</Query>

Content-Type: Application/MANSCDP+xml

Message消息头 Content-type头域为 Content-type:Application/MANSCDP+xml。设备目录查询命令采用 MANSCDP协议格式定义,设备目录信息查询请求。设备目录查询请求命令应包括命令类型(CmdType)、命令序列号(SN)、设备/区域/系统编码/业务分组/虚拟组织(DeviceID)等,采用IETFRFC3428的 Message方法的消息体携带。

xml

<?xml version="1.0" encoding="GB2312"?>
<Query>
    <! -- 命令类型:设备信息查询(必选)-->
    <CmdType>Catalog</CmdType>
    <! -- 命令序列号(必选)，消息中的SN值用于与请求命令的匹配处理,响应命令中的SN值应使用请求命令中的SN值。--> 
    <SN>1708</SN>
    <! -- 目标设备的设备编码(必选)-->
    <DeviceID>62010201001320000393</DeviceID>
</Query>

命令类型说明

1.2.2 响应查询

MESSAGE sip:51000000002000000001@5100000000 SIP/2.0
Via: SIP/2.0/UDP 10.18.44.86:5060;rport;branch=z9hG4bK897441835
From: <sip:62010201001320000393@5100000000>;tag=1617705135
To: <sip:51000000002000000001@5100000000>
Call-ID: 17524357
CSeq: 20 MESSAGE
Content-Type: Application/MANSCDP+xml
Max-Forwards: 70
User-Agent: IP Camera
Content-Length:   586

<?xml version="1.0" encoding="GB2312"?>
<Response>
<CmdType>Catalog</CmdType>
<SN>1708</SN>
<DeviceID>62010201001320000393</DeviceID>
<SumNum>1</SumNum>
<DeviceList Num="1">
<Item>
<DeviceID>62010201001320000393</DeviceID>
<Name>Camera 01</Name>
<Manufacturer>Hikvision</Manufacturer>
<Model>IP Camera</Model>
<Owner>Owner</Owner>
<CivilCode>5100000000</CivilCode>
<Address>Address</Address>
<Parental>0</Parental>
<ParentID>51000000002000000001</ParentID>
<SafetyWay>0</SafetyWay>
<RegisterWay>1</RegisterWay>
<Secrecy>0</Secrecy>
<Status>ON</Status>
</Item>
</DeviceList>
</Response>

<?xml version="1.0" encoding="GB2312"?>
<Response>
    <! -- 命令类型:设备目录查询(必选)-->
    <CmdType>Catalog</CmdType>
    <SN>1708</SN>
    <! -- 目标设备/区域/系统的编码,取值与目录查询请求相同(必选)-->
    <DeviceID>62010201001320000393</DeviceID>
    <! -- 查询结果总数(必选)-->
    <SumNum>1</SumNum>
    <! -- 设备目录项列表,Num 表示目录项个数，注意双引号-->
    <DeviceList Num="1">
        <Item>
            <! -- 设备/区域/系统编码(必选)-->
            <DeviceID>62010201001320000393</DeviceID>
            <! -- 设备/区域/系统名称(必选)-->
            <Name>Camera 01</Name>
            <! -- 当为设备时,设备厂商(必选)-->
            <Manufacturer>Hikvision</Manufacturer>
            <! -- 当为设备时,设备型号(必选)-->
            <Model>IP Camera</Model>
            <! -- 当为设备时,设备归属(必选)-->
            <Owner>Owner</Owner>
            <! -- 行政区域(必选)-->
            <CivilCode>5100000000</CivilCode>
            <! -- 当为设备时,安装地址(必选)-->
            <Address>Address</Address>
            <! -- 当为设备时,是否有子设备(必选)1有,0没有-->
            <Parental>0</Parental>
            <! -- 父设备/区域/系统ID(必选)-->
            <ParentID>51000000002000000001</ParentID>
            <! -- 信令安全模式(可选)缺省为0; 0:不采用;2:S/MIME 签名方式;3:S/ MIME加密签名同时采用方式;4:数字摘要方式-->
            <SafetyWay>0</SafetyWay>
            <! -- 注册方式(必选)缺省为1;1:符合IETFRFC3261标准的认证注册模 式;2:基于口令的双向认证注册模式;3:基于数字证书的双向认证注册模式-->
            <RegisterWay>1</RegisterWay>
            <! -- 保密属性(必选)缺省为0;0:不涉密,1:涉密-->
            <Secrecy>0</Secrecy>
            <! -- 设备状态(必选)-->
            <Status>ON</Status>
            ... 其他请参考协议文档
        </Item>
    </DeviceList>
</Response>

2. 设备的点播

2.1 点播整体流程

sequenceDiagram
SIP服务->>接入设备: a.1 Invite(携带SDP)
接入设备->>SIP服务: a.2 200 OK(携带SDP)
SIP服务->>收流媒体: a.3 通知开始收流事件（通知方式按照系统架构来定）
SIP服务->>接入设备: a.4 ACK
接入设备-->>收流媒体: a.5 实时媒体流



SIP服务->>接入设备: b.1 BYE
接入设备->>SIP服务: b.2 200 OK
SIP服务->>收流媒体: b.3 通知停止收流事件（通知方式按照系统架构来定）



接入设备->>SIP服务: c.1 BYE
SIP服务->>接入设备: c.2 200 OK
SIP服务->>收流媒体: c.3 通知停止收流事件（通知方式按照系统架构来定）

点播整体流程如下

2.1.1 点播流程（a流程）

由其他接口调用开始某个点位的点位，触发至SIP服务，SIP服务端选定接入设备，与收流的流媒体一起协商出要收流的IP以及端口，向指定设备发送Invite信令（带有SDP内容），其消息体中描述并告知设备要推送的目的地（IP、端口）、推送方式（UDP/TCP）、要推送的通道（设备具有多个通道的话）、媒体参数（媒体源标识SSRC等）。
设备收到SIP服务发送的Invite请求后，会对请求进行解析，确认自己能够满足所要求的传输条件,满足协商条件后回复200 OK（带有SDP内容）响应，消息体中描述了要发送媒体流的IP、端口、媒体格式、SSRC字段等内容以保证对接的匹配；不满足条件后会对应告知SIP服务异常码停止当前点播流程。
SIP服务器收到媒体流发送者返回的200OK 响应后，必须发出一个ACK（Acknowledgement）请求作为正式的确认，告知设备侧可以推送视频流。ACK请求是基于先前的Invite和200 OK消息，没有额外的SDP内容，它是一个简短的确认信号，确保设备不会在未得到明确指示前就开始发送数据，从而避免资源浪费或不必要的网络拥堵。
一旦SIP服务通过ACK确认了视频流的启动，设备便依据之前协商的规则开始推送音视频流到指定的IP地址和端口。接收端的流媒体服务器或客户端接收到流后，会根据流的特性进行解码处理，并维持这一连接，确保视频流畅、不间断地传输。

2.1.2 停止点播（b、c流程）

SIP服务主动停止
1. 当视频流不再需要继续传输时，比如因为主动停止命令的下达或是无人点播等事件的触发，SIP服务会向指定设备发送BYE消息。BYE消息是一种会话控制信令，用来指示对方应该结束当前的媒体会话。
2. 设备侧收到SIP服务发送的BYE消息后，设备会立即停止正在进行的视频流推送，并向SIP服务回复一个200OK消息。
3. 一旦SIP服务收到设备返回的200OK响应，确认推流已经成功停止，向收流媒体告知端口取消监听等资源释放流程。
设备侧主动停止
1. 当设备不再需要继续传输时，比如因为设备侧连不到服务侧端口或者设备侧算力不足等原因，设备侧会向SIP服务发送BYE消息。BYE消息是一种会话控制信令，用来指示对方应该结束当前的媒体会话。
2. SIP服务收到设备侧发送的BYE消息后，向收流媒体告知端口取消监听等资源释放流程，并向设备侧回复一个200OK消息。
3. 一旦设备侧收到设备返回的200OK响应，设备会立即停止正在进行的视频流推送（此流程也可在第一步操作）。

2.2 直播点播

2.2.1 平台发起点播（对应流程a.1）

由其他接口调用开始某个点位的点位，触发至SIP服务，SIP服务端选定接入设备，与收流的流媒体一起协商出要收流的IP以及端口，向指定设备发送Invite信令（带有SDP内容），其消息体中描述并告知设备要推送的目的地（IP、端口）、推送方式（UDP/TCP）、要推送的通道（设备具有多个通道的话）、媒体参数（媒体源标识SSRC等）。

2.2.1.1 信令总览

INVITE sip:62010201001320000108@10.18.34.1:5060 SIP/2.0
To: <sip:62010201001320000108@10.18.34.1:5060>
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=957224978
Call-ID: cfc3d61c-20b5-4bdb-8e33-ff9f8cde911b0
CSeq: 199946311 INVITE
Max-Forwards: 70
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7f1bcc056800753269171;rport
Contact: <sip:51000000002000000001@10.18.104.201:5060>
User-Agent: zdww sip server
Subject: 62010201001320000108:59682,51000000002000000001:0
Content-Type: Application/SDP
Content-Length: 294

v=0
o=62010201001320000108 0 0 IN IP4 10.18.104.201
s=Play
c=IN IP4 10.18.104.201
t=0 0
m=video 43001 TCP/RTP/AVP 96 98 97
a=recvonly
a=setup:passive
a=connection:new
a=rtpmap:96 PS/90000
a=rtpmap:98 H264/90000
a=rtpmap:97 MPEG4/90000
a=stream:main
a=streamnumber:0
y=0000059682

2.2.1.2 重要信令解析

INVITE sip:62010201001320000108@10.18.34.1:5060 SIP/2.0

INVITE: 表示这是一个邀请请求，用于初始化一个新的会话或加入现有会话。
sip:62010201001320000108@10.18.34.1:5060: 指定了被邀请方的SIP统一资源定位符（URI），其中包括用户名（62010201001320000108）、SIP服务器的IP地址（10.18.34.1）和端口号（5060），这是设备或用户接收呼叫的位置。
SIP/2.0: 表明使用的是SIP协议的第2版。

Contact: <sip:51000000002000000001@10.18.104.201:5060>

Contact: 提供了发送此INVITE请求的设备或用户的联系信息。在这个例子中，发送方的SIP URI是51000000002000000001，位于IP地址10.18.104.201的5060端口上。这使得被叫方能够直接回复到正确的地址。

Subject: 62010201001320000108:59682,51000000002000000001:0

Subject: 媒体流发送者ID:发送方媒体流序列号,媒体流接收者ID:接收方媒体流序列号。各字段定义如下:
- 媒体流发送者ID: 为符合附录E定义的媒体流发送者的编码。
- 发送方媒体流序列号: 发送方媒体流序列号为不超过20位的字符串;当请求为实时视频时,首位取值为0,对于相同的实时视频取值唯一;当请求的媒体流为历史视频时,首位取值为1,对于每一路历史视频取值唯一。
- 媒体流接收者ID: 为符合附录E定义的媒体流接收者的ID编码。
- 接收方媒体流序列号: 为媒体流接收端的标识序列号,在同一时刻该序列号在媒体流接收者端为不重复的字符串。当接收者为客户端时,可以作为窗口的标识符。

Content-Type: Application/SDP

Application/SDP：消息头 Content-type字段应表示消息体采用SDP协议格式定义，注：因协议的规定以及历史原因，大小写均会遇到，编写代码时需要注意。

v=0 
o=62010201001320000108 0 0 IN IP4 10.18.104.201 
s=Play 
c=IN IP4 10.18.104.201 
t=0 0  
m=video 43001 TCP/RTP/AVP 96 98 97 
a=recvonly 
a=setup:passive 
a=connection:new 
a=rtpmap:96 PS/90000 
a=rtpmap:98 H264/90000 
a=rtpmap:97 MPEG4/90000 
a=stream:main 
a=streamnumber:0 
y=0000059682

v=0

o=62010201001320000108 0 0 IN IP4 10.18.104.201

o字段：标识了会话的发起者和会话的唯一标识。

62010201001320000108：表示该会话会话发起者的SIP ID。

0：这是会话的地址类型（Address Type），在这里也是0，同样表示IN（Internet）。

0：这表示地址（Address）字段的优先级或者状态标记，在很多情况下这个值并不携带特定意义，保持为默认的0。

IN：这是网络类型的文本表示，与前面的数字0对应，表明这是一个基于IP的网络。

IP4：表示使用的IP协议版本，这里是IPv4。

10.18.104.201：这是会话发起者的IP地址，在这个例子中是一个IPv4地址。

s=Play

会话名称: 在向SIP服务器和媒体流接收者/媒体流发送者之间的SIP消息中，使用s字段标识请求媒体流的操作类型。Play代表实时点播，Playback代表历史回放，Download代表文件下载，Talk 代表语音对讲。

c=IN IP4 10.18.104.201

指定了会话的网络类型（IN，即Internet）、IP版本（IP4）以及会话发起者的IP地址（10.18.104.201）。

t=0 0

第一参数为视频开始时间第二个参数为结束时间 t = 0 0表示实时视音频点播

m=video 43001 TCP/RTP/AVP 96 98 97

m字段描述媒体的媒体类型、端口、传输层协议、负载类型等内容。

传输端口采用43001;

媒体类型采用“video”标识传输视频或视音频混合内容,采用“audio”标识传输音频内容;

传输方式采用“RTP/AVP”标识传输层协议为 RTPoverUDP，采用“TCP/RTP/AVP”标识传输层协议为 RTPoverTCP。

负载类型: 96 97 98支持码流格式，由媒体决定

a=recvonly

recvonly 只接受（收流端）只用于媒体，不用于控制协议, sendonly 只发送（发流端）只用于媒体，不用于控制协议

a=setup:passive

setup：TCP连接方式(表示本SDP发送者在RTP over TCP连接建立时是主动还是被动发起TCP连接，"active”为主动，"passive”为被动)，此处假如由服务端发起，那么此时为服务端发起TCP被动模式，设备需要连接到服务端提供的Ip、端口进行TCP连接。

a=connection:new

表示采用RTP over TCP传输时新建或重用原来的TCP连接,可固定采用新建TCP连接的方式

a=rtpmap:96 PS/90000

a=rtpmap:98 H264/90000

a=rtpmap:97 MPEG4/90000

96 是一个payload type（负载类型），是一个标识符，用于在RTP数据包中区分不同的媒体编码格式。

PS 表示该媒体流使用的编码是PS（Packetized Elementary Stream，分组基本流），通常用于携带MPEG-1视频或音频的数据。

90000 指的是时钟频率或者说时间戳单位，表示该编码每秒使用90000个时间戳单位。这意味着媒体流中的时间戳增量应按照此频率进行计算。

a=stream:main

a=streamnumber:0

主辅码流的定义，生产中2022版本有说明，其他版本为厂商私有定义

y=0000059682

为十进制整数字符串,表示SSRC值。格式如下:dddddddddd。其中,第1位为历史或实时媒体流的标识位,0为实时,1为历史;第2位至第6位取20位SIP监控域ID之中的4到8位作为域标识，例如“13010000002000000001”中取数字“10000”;第7位至第10位作为域内媒体流标识,是一个与当前域内产生的媒体流SSRC值后4位不重复的四位十进制整数。

f=xxx

f= v/编码格式/分辨率/帧率/码率类型/码率大小a/编码格式/码率大小/采样率

UDP

这个是普遍的传输方式。GB28181流媒体服务器监听单个UDP端口，然后发送一个SIP信令(INVITE)，其携带的SDP中包含了接收媒体的端口设备端收到信令后，解析该端口，然后设备主动通过UDP向流媒体服务端监听的那个端口上发送视频流

TCP

有两种，一种是主动模式，一种是被动模式

对于主动：设备端告知服务端自己的媒体流tcp端口，服务端主动去连接设备端的该端口，获取数据。。这种场景应用较少，可以忽略

对于被动：流媒体服务器监听单个TCP端口，然后通过SIP信令(INVITE)告诉设备端口，设备主动向当前流媒体服务端发送视频流，基本等同于UDP流。

2.2.2 设备/平台返回200OK（对应流程a.2）

设备收到SIP服务发送的Invite请求后，会对请求进行解析，确认自己能够满足所要求的传输条件,满足协商条件后回复200OK（带有SDP内容）响应，消息体中描述了要发送媒体流的IP、端口、媒体格式、SSRC字段等内容以保证对接的匹配；不满足条件后会对应告知SIP服务异常码停止当前点播流程

2.2.2.1 信令总览

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7f1bcc056800753269171;rport=5060
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=957224978
To: <sip:62010201001320000108@10.18.34.1:5060>;tag=540380936
Call-ID: cfc3d61c-20b5-4bdb-8e33-ff9f8cde911b0
CSeq: 199946311 INVITE
Contact: <sip:62010201001320000108@10.18.34.1:5060>
Content-Type: application/SDP
User-Agent: Embedded Net DVR/NVR/DVS
Content-Length:   272

v=0
o=62010001001187000003 0 0 IN IP4 10.18.34.1
s=Network Video Recorder
c=IN IP4 10.18.34.1
t=0 0
m=video 63014 TCP/RTP/AVP 96
a=sendonly
a=rtpmap:96 PS/90000
a=username:62010001001187000003
a=password:Zdww@2021
a=filesize:0
a=setup:active
y=0000059682
f=

2.2.2.2 重要信令解析

其他与Invite字段说明类似，我们着重分析下sdp内容：

v=0
o=62010001001187000003 0 0 IN IP4 10.18.34.1
s=Network Video Recorder
c=IN IP4 10.18.34.1
t=0 0
m=video 63014 TCP/RTP/AVP 96
a=sendonly // 对应服务端的recvonly，设备为sendonly
a=rtpmap:96 PS/90000
a=username:62010001001187000003  // 私有数据
a=password:Zdww@2021  // 私有数据
a=filesize:0
a=setup:active  // 对应着服务端的passive，设备为active，意味着设备主动连接服务端进行推流
y=0000059682  // ssrc取自服务端提供，当然也会有被点播着自定义ssrc的情况，服务端需要做处理使用200ok返回ssrc
f=

2.2.3 平台通知流媒体准备收流（对应流程a.3）

在a.1流程，我们知道在发送Invite信令中，消息体中带有需要设备连接的流媒体服务器的收流IP以及端口，用来推送视频流数据，实际使用中，因为流媒体可能存在多个，需要引入一个预先协商的步骤，旨在动态确定最合适的流媒体接收资源，协商出需要收流的最佳流媒体的IP以及端口。而在此流程处，需要信令服务通知协调好的流媒体开放协商好的端口，开始准备接受设备推送的视频流。

在实现服务间通信时，多样化的方法并存以适应不同场景的需求。GB/T 28181协议框架内，明确指定了信令服务器与媒体服务器间采用SIP协议进行标准化交互，以此确保视频监控网络的兼容性和互操作性。然而，在实际部署与应用过程中，考虑到技术生态的多样性及特定项目的实际要求，服务间通讯方式展现出了高度的灵活性与可定制性。

具体而言，除了遵循标准的SIP协议之外，根据技术框架的特性和实际需求，开发者可以灵活选用其他高效通讯手段，如采用HTTP/HTTPS协议通过RESTful API进行简便、直观的数据交换，或是借助于RPC（如gRPC）实现高效、低延迟的远程过程调用，这些选择均有助于优化系统集成、提高通讯效率并促进服务间的无缝协同。总之，通讯协议的选取应基于对系统性能、扩展性、安全性等多维度的综合考量，以达到最佳的通讯策略配置。

2.2.4 平台通知设备/平台可以推流（对应流程a.4）

SIP服务器收到媒体流发送者返回的200OK 响应后，必须发出一个ACK（Acknowledgement）请求作为正式的确认，告知设备侧可以推送视频流。ACK请求是基于先前的Invite和200 OK消息，没有额外的SDP内容，它是一个简短的确认信号，确保设备不会在未得到明确指示前就开始发送数据，从而避免资源浪费或不必要的网络拥堵。

2.2.4.1 信令总览

ACK sip:62010201001320000277@10.18.34.1:5060 SIP/2.0
To: <sip:62010201001320000277@10.18.34.1:5060>;tag=334986858
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=957224979
Call-ID: e484c728-dfe5-4a4d-8b2f-2561fb7578ca0
CSeq: 330911174 ACK
Max-Forwards: 70
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7f1bcc057c00266821219;rport
User-Agent: zdww sip server
Content-Length: 0

2.2.4.2 重要信令解析

ACK sip:62010201001320000277@10.18.34.1:5060 SIP/2.0

ACK：表示这是一个确认消息，用于回应之前接收到的INVITE的消息。
sip:62010201001320000277@10.18.34.1:5060：这是目标用户或会话的地址，其中62010201001320000277是用户的标识（可能是电话号码或者其他唯一标识符），10.18.34.1:5060指定了接收方的IP地址（10.18.34.1）和端口号（5060），SIP通信通常使用5060端口。
SIP/2.0：表示使用的SIP协议版本是2.0。

CSeq: 330911174 ACK

CSeq（Command Sequence Number）：是一个序列号，用于唯一标识一个请求及其响应。这里的值330911174是一个递增的计数器，确保每个请求都是唯一的，并且与对应的响应相匹配。后面跟着的ACK表明这个序列号对应的是一个ACK消息。

Call-ID: e484c728-dfe5-4a4d-8b2f-2561fb7578ca0

Call-ID：是一个全局唯一的标识符，用于标识一次特定的会话或通话。即使有多个相同From和To标签的对话，Call-ID也会不同，确保每个对话都能被唯一识别。这里e484c728-dfe5-4a4d-8b2f-2561fb7578ca0是一个示例的Call-ID值，通常由随机生成的字符串组成。

2.2.5 接收媒体流（对应流程a.5）

一旦SIP服务通过ACK确认了视频流的启动，设备便依据之前协商的规则开始推送音视频流到指定的IP地址和端口。接收端的流媒体服务器或客户端接收到流后，会根据流的特性进行解码处理，并维持这一连接，确保视频流畅、不间断地传输。

RTP流接收与解封装：平台的流媒体服务器接收到从设备发送过来的RTP数据包后，首先会对这些数据包进行解封装。RTP包头包含时间戳、序列号等信息，用于同步和重组分片的数据。解封装过程会依据SDP中声明的编解码类型（如H.264、H.265视频编码或G.711、AAC音频编码），对RTP负载进行正确的解析。
媒体解码：解封装后的原始媒体数据（如H.264的NAL单元）被送入相应的解码器进行解码。解码器将压缩的媒体数据转换为未压缩的音视频帧，这些帧可以直接用于显示或进一步处理。
实时播放：
- 缓冲与同步：为了保证流畅播放，平台会将解码后的音视频帧放入缓冲区，进行时钟同步和抖动平滑处理，确保播放的连续性和稳定性。
- 渲染输出：同步后的音视频帧被送至渲染引擎，按照正确的时序在监视终端或网页上实时展示，用户即可观看监控画面。

具体的关于视频流的讲解将在其他章节详细说明

2.3 停止点播

2.3.1 平台发起停止点播（对应流程b.1）

SIP服务主动停止

当视频流不再需要继续传输时，比如因为主动停止命令的下达或是无人点播等事件的触发，SIP服务会向指定设备发送BYE消息。BYE消息是一种会话控制信令，用来指示对方应该结束当前的媒体会话。

设备侧收到SIP服务发送的BYE消息后，设备会立即停止正在进行的视频流推送，并向SIP服务回复一个200OK消息。

一旦SIP服务收到设备返回的200OK响应，确认推流已经成功停止，向收流媒体告知端口取消监听等资源释放流程。

2.3.1.1 信令总览

BYE sip:62010201001320000277@10.18.34.1:5060 SIP/2.0
To: <sip:62010201001320000277@10.18.34.1:5060>;tag=334986858
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=957224979
Call-ID: e484c728-dfe5-4a4d-8b2f-2561fb7578ca0
CSeq: 330911175 BYE
Max-Forwards: 70
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7f1bcc059000450632814;rport
User-Agent: zdww sip server
Content-Length: 0

2.3.1.2 重要信令解析

BYE sip:62010201001320000277@10.18.34.1:5060 SIP/2.0：
- BYE 表示这是一个结束会话的请求。
- sip:62010201001320000277@10.18.34.1:5060 是目标URI（Uniform Resource Identifier），指定了要终止通信会话的接收方。其中，62010201001320000277 是用户的标识，10.18.34.1:5060 是接收方的IP地址和端口号（5060是SIP协议的标准端口）。
- SIP/2.0 指明使用的是SIP协议的第2版。
CSeq: 330911175 BYE：
- CSeq 是Command Sequence Number的缩写，用于唯一标识发送的每个请求，并跟踪请求的顺序。这里的值是330911175，意味着这是该会话中的第330911175个命令序列，且这个命令是一个BYE请求。

2.3.2 设备/平台发起停止点播（对应流程c.1）

设备侧主动停止

当设备不再需要继续传输时，比如因为设备侧连不到服务侧端口或者设备侧算力不足等原因，设备侧会向SIP服务发送BYE消息。BYE消息是一种会话控制信令，用来指示对方应该结束当前的媒体会话。

SIP服务收到设备侧发送的BYE消息后，向收流媒体告知端口取消监听等资源释放流程，并向设备侧回复一个200OK消息。

一旦设备侧收到设备返回的200OK响应，设备会立即停止正在进行的视频流推送（此流程也可在第一步操作）。

2.3.3 平台，设备/平台返回200OK（对应流程b.2以及c.2）

2.3.3.1 信令总览

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.104.201:5060;branch=z9hG4bK0x7f1bcc059000450632814;rport=5060
From: <sip:51000000002000000001@10.18.104.201:5060>;tag=957224979
To: <sip:62010201001320000277@10.18.34.1:5060>;tag=334986858
Call-ID: e484c728-dfe5-4a4d-8b2f-2561fb7578ca0
CSeq: 330911175 BYE
User-Agent: Embedded Net DVR/NVR/DVS
Content-Length: 0

全网最全GB/T 28181剖析3️⃣设备的信息查询以及点播