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

79 阅读26分钟

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

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

1. 设备的信息查询

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

1.1 整体流程

sequenceDiagram
SIP服务->>接入设备: 1. Message 设备查询请求命令
接入设备->>SIP服务: 2. 200 OK
接入设备->>SIP服务: 3. Message 设备查询响应命令
SIP服务->>接入设备: 4. 200 OK
  1. SIP服务器向目标设备转发设备查询命令,设备查询命令采用 Message方法携带;

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

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

  4. 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>

image.png

命令类型说明

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>
  1. xml
<?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流程)

  1. 由其他接口调用开始某个点位的点位,触发至SIP服务,SIP服务端选定接入设备,与收流的流媒体一起协商出要收流的IP以及端口,向指定设备发送Invite信令(带有SDP内容),其消息体中描述并告知设备要推送的目的地(IP、端口)、推送方式(UDP/TCP)、要推送的通道(设备具有多个通道的话)、媒体参数(媒体源标识SSRC等)。
  2. 设备收到SIP服务发送的Invite请求后,会对请求进行解析,确认自己能够满足所要求的传输条件,满足协商条件后回复200 OK(带有SDP内容)响应,消息体中描述了要发送媒体流的IP、端口、媒体格式、SSRC字段等内容以保证对接的匹配;不满足条件后会对应告知SIP服务异常码停止当前点播流程。
  3. SIP服务器收到媒体流发送者返回的200OK 响应后,必须发出一个ACK(Acknowledgement)请求作为正式的确认,告知设备侧可以推送视频流。ACK请求是基于先前的Invite200 OK消息,没有额外的SDP内容,它是一个简短的确认信号,确保设备不会在未得到明确指示前就开始发送数据,从而避免资源浪费或不必要的网络拥堵。
  4. 一旦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 重要信令解析
  1. 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版。
  1. Contact: <sip:51000000002000000001@10.18.104.201:5060>
  • Contact: 提供了发送此INVITE请求的设备或用户的联系信息。在这个例子中,发送方的SIP URI是51000000002000000001,位于IP地址10.18.104.2015060端口上。这使得被叫方能够直接回复到正确的地址。
  1. Subject: 62010201001320000108:59682,51000000002000000001:0
  • Subject: 媒体流发送者ID:发送方媒体流序列号,媒体流接收者ID:接收方媒体流序列号。 各字段定义如下:
    • 媒体流发送者ID: 为符合附录E定义的媒体流发送者的编码。
    • 发送方媒体流序列号: 发送方媒体流序列号为不超过20位的字符串;当请求为实时视频时,首位取值为0,对于相同的实时视频取值唯一;当请求的媒体流为历史视频时,首位取值为1,对于每一路历史视频取值唯一。
    • 媒体流接收者ID: 为符合附录E定义的媒体流接收者的ID编码。
    • 接收方媒体流序列号: 为媒体流接收端的标识序列号,在同一时刻该序列号在媒体流接收者端为不重复的字符串。当接收者为客户端时,可以作为窗口的标识符。
  1. Content-Type: Application/SDP
  • Application/SDP:消息头 Content-type字段应表示消息体采用SDP协议格式定义,注:因协议的规定以及历史原因,大小写均会遇到,编写代码时需要注意。
  1. 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内容:

  1. 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 重要信令解析
  1. 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。
  1. CSeq: 330911174 ACK
  • CSeq(Command Sequence Number):是一个序列号,用于唯一标识一个请求及其响应。这里的值330911174是一个递增的计数器,确保每个请求都是唯一的,并且与对应的响应相匹配。后面跟着的ACK表明这个序列号对应的是一个ACK消息。
  1. 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服务主动停止

    1. 当视频流不再需要继续传输时,比如因为主动停止命令的下达或是无人点播等事件的触发,SIP服务会向指定设备发送BYE消息。BYE消息是一种会话控制信令,用来指示对方应该结束当前的媒体会话。
    2. 设备侧收到SIP服务发送的BYE消息后,设备会立即停止正在进行的视频流推送,并向SIP服务回复一个200OK消息。
    3. 一旦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)

  • 设备侧主动停止

    1. 当设备不再需要继续传输时,比如因为设备侧连不到服务侧端口或者设备侧算力不足等原因,设备侧会向SIP服务发送BYE消息。BYE消息是一种会话控制信令,用来指示对方应该结束当前的媒体会话。
    2. SIP服务收到设备侧发送的BYE消息后,向收流媒体告知端口取消监听等资源释放流程,并向设备侧回复一个200OK消息。
    3. 一旦设备侧收到设备返回的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

2.3.4 平台通知流媒体停止收流(对应流程b.3以及c.3)

3. 设备的回放以及下载