1.引言

　　国家标准GB/T 28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》已于2022年12月30日发布，将于2023年7月1日实施。该标准规定了视频联网系统的联网结构、信令流程、协议接口以及相关安全性要求，适用于公共安全视频联网系统的方案设计、系统检测、验收以及与之相关的设备研发、生产。

　　标准定位于视频资源联网共享，2011年首次发布，并很快得到了广泛应用落地，2016年发布了更新版。随着业务实践的深入和新场景、新应用的需求驱动，2022年再次进行更新。下面介绍一下标准的基本框架和2022版主要技术改进点。

　　2.基本框架

　　标准从设计之初就充分考虑了全国统一大规模联网的需求，制定了一套全局统一的资源编码规范，对联网系统里面的设备、客户端、服务器、用户等实体进行统一编码。编码结构中包含省、市、区等行政区划信息，以及行业编码、类型编码等，因此能够做到各自独立编码且全局唯一不冲突，同时通过编码本身也能直接获取到对应实体的所属区域和类型等基本信息。

　　早期的视频联网系统往往是从各自独立且小规模进行建设，然后慢慢扩容升级，正是有了这样前瞻性的全局统一的编码规范，使得后面这些独立系统能够顺利进行大规模联网。

　　标准中对设备进行了简化抽象，摒弃了通道概念的复杂性，将通道本身看作一个子设备，同样有唯一的设备编码。为了更好的进行大规模联网时资源的描述，标准中定义了统一的目录结构，将系统、设备、子设备等实体按照行政区划目录项、系统目录项、业务分组目录项、虚拟组织目录项等进行层次划分，形成树状结构的目录树，通过联网系统之间的目录推送进行视频汇聚。

　　2.2.联网方式

　　联网系统的信息传输、交换、控制方面的SIP监控域联网结构如图1所示。

图1：SIP监控域联网结构

　　在SIP监控域中，SIP客户端和SIP设备接入到中心信令控制服务器，通过中心信令控制服务器进行信令交互，通过流媒体服务器进行媒体交互。SIP监控域之间业务交互，通过不同监控域的中心信令控制服务器进行信令中转，以及流媒体服务器之间的媒体中转来完成。由于涉及到外部的IP传输网络，因此在中心信令控制服务器与外部IP传输网络的出口处，分别都增加信令安全路由网关来进行安全传输。

　　SIP监控域可以通过网关和非SIP监控域进行联网，SIP监控域之间也可以进行级联联网，下级SIP监控域将自己下级的SIP监控域的目录资源和自身的目录资源进行整合，统一往上级进行汇聚。级联方式联网时，信令流逐级转发，媒体流推荐逐级转发，也可以跨媒体服务器传输。经过多级的级联汇聚和互联，最终可以形成全国大规模联网系统。

　　2.3.协议结构

　　联网系统进行视频、音频、数据等信息传输交换控制基于TCP/IP协议，通信协议结构分为会话通道和媒体流通道，如图2所示。

图2：通信协议结构

　　会话通道基于SIP协议进行信令传输，在其上面承载的是SDP、MANSCDP和MANSRTSP等业务命令协议，其中SDP和MANSRTSP主要用于媒体播放操作，MANSCDP用于设备控制、设备查询、订阅通知等信令控制操作。

　　媒体流通道基于RTP/RTCP协议进行数据传输，在其上面承载的是H.265、H.264、G.711等格式的媒体数据，支持PS OVER RTP和ES OVER RTP封装格式，传输过程中可以通过MANSRTSP协议来进行播放控制。

　　在进行数据交互时，首先建立会话通道，并进行注册认证。一般是设备向平台注册、下级平台向上级平台注册，注册成功后才可以进行后续业务命令。当需要访问媒体数据时，先通过会话通道协商建立媒体流通道，并交换媒体的格式说明，然后通过媒体流通道进行媒体数据的传输。

　　标准中提供了基于口令的数字摘要方式对设备进行身份认证和SIP信令认证，没有定义业务数据加密、数据完整性等相关具体内容，并通过引用方式，描述了在高安全级别情况下，设备身份认证、数据加密、SIP信令认证、数据完整性保护、访问控制等应符合GB 35114的规定。

　　2.4.信令控制

　　设备控制、查询等通过MANSCDP来实现。MANSCDP基于SIP，对SIP的From、To头域的URI进行了定义，SIP命令字使用MESSAGE，Body使用XML描述，Control、Query、Notify等元素描述了不同业务功能。

　　MANSCDP业务应答并不是直接通过SIP的200 OK回复来承载，而是通过一个新的SIP命令来发送，业务应答的SIP命令字同样是MESSAGE，Body是一个XML，内部通过Response元素来描述不同的业务应答。协议中部分命令是没有应答的，但命令接收方还是要回复一个SIP 200 OK。而对于有应答的命令，命令发送方除了接收到SIP 200 OK回复外，还会接收到一个业务应答的命令，此时命令发送方需要回复一个SIP 200 OK回复进行确认收到业务应答。

　　MANSCDP的请求和应答中都有一个通用的SN子元素，取值为命令序列号，不同请求必须唯一，实现时一般是递增的，应答的SN的值必须和请求保持相同，命令请求方接收到应答时，可以通过SN的值将应答和请求关联起来。

　　2.4.1.设备控制

　　设备控制命令包括云台控制、远程控制、录像控制、报警布撤防等。命令消息体Body的XML元素是Control，子元素CmdType固定取值为DeviceControl，然后通过PTZCmd、Teleboot、GuardCmd等不同的子元素表示不同的功能。

　　根据命令的不同含义，设备控制命令有应答和无应答两类。如果控制命令有应答，那么应答命令消息体Body的XML元素是Response，子元素CmdType固定取值为DeviceControl，通过Result字段来描述命令的执行结果。

　　例如录像控制命令的XML body例子如下：

　　录像控制命令的应答的XML body例子如下：

　　2.4.2.设备查询

　　设备查询命令包括设备目录查询、设备信息查询、设备状态查询等。命令消息体Body的XML元素是Query，通过子元素CmdType的取值Catalog、DeviceInfo、DeviceStatus等来描述不同的查询内容。设备查询命令都有应答，应答Body的XML元素是Response，通过子元素CmdType的取值Catalog、DeviceInfo、DeviceStatus等来描述不同的查询结果应答，与查询命令一一对应。

　　2.4.3.设备配置

　　设备配置命令包括基本参数配置、SVAC编解码配置等。命令消息体Body的XML元素是Control，而子元素CmdType固定取值为DeviceConfig，然后通过不同的子元素来描述具体的配置，例如基本参数配置通过BasicParam元素描述。设备配置的设置都是有应答的，应答Body的XML元素是Response，子元素CmdType的取值DeviceConfig，通过Result元素描述设备配置的设置结果。

　　设备配置的查询命令Body的XML元素是Query，子元素CmdType固定取值为ConfigDownload，然后通过ConfigType子元素的值来描述具体需要读取的配置内容，例如基本参数配置通过取值BasicParam来指定。设备配置的读取都是有应答的，应答Body的XML元素是Response，子元素CmdType的取值ConfigDownload，然后通过不同的子元素来描述具体的配置，例如基本参数配置通过BasicParam子元素来指定。

　　2.4.4.订阅通知

　　订阅和通知命令是平台对设备进行事件或者目录进行订阅，当设备产生相应事件或者目录变化时，将相应的事件或者目录的数据通过通知命令的方式向平台进行推送，其中事件主要包括报警事件、移动设备位置通知事件等。

　　订阅命令通过SIP命令SUBSCRIBE进行，通过命令Body中的Query元素的子元素CmdType描述具体的订阅内容。通知命令通过SIP的NOTIFY命令进行，通过命令Body中的Notify元素的子元素CmdType描述具体的通知内容。

　　另外，设备中产生重要报警或者异常时，应主动上报报警或者状态，此时不需要订阅，而是设备通过SIP的MESSAGE命令直接发送，命令Body中同样是Notify元素，通过子元素CmdType描述具体的报警或者状态等通知内容。

　　媒体传输命令包括实时视音频点播、历史视音频回放/下载、语音广播、语音对讲等功能。媒体传输功能需要通过会话通道和媒体流通道配合来完成，首先通过会话通道发送SIP的INVITE命令来创建媒体会话，命令的Body体是SDP文本，里面描述了媒体数据的基本信息、媒体编码格式和传输方式等。然后根据SDP中描述的传输方式建立媒体流通道，在媒体流通道上通过基于RTP的ES或者基于RTP的PS等封装方式传输媒体数据。

　　对于历史视音频回放，可以通过MANSRTSP协议进行播放、暂停、快进快退、随机定位等播放控制操作。MANSRTSP协议并不是直接使用标准的RTSP命令，而是复用了会话通道，使用基于SIP的协议，SIP命令是INFO命令，命令的Body体中承载的是RTSP命令，通过RTSP的PLAY、PAUSE、TEARDOWN等命令以及相应的Header参数来描述具体的控制操作要求。

　　语音对讲并不是一个独立的命令，而是通过组合实时音视频播放和语音广播的方式来进行的。例如中心用户要和前端设备用户进行语音对讲，需要中心用户向前端设备发起实时视音频点播，这样中心用户就能听到前端设备用户的声音。同时中心用户向前端设备发起语音广播请求，将本地语音传输到前端设备用户，这样前端设备用户就能听到中心用户的声音，从而完成语音对讲的过程。业务上是单一的，但底层的两个方向的媒体传输是通过不同的命令实现的，而且命令之前是相互独立，互不影响的。

　　3.主要改进

　　随着联网系统的规模化建设，单一的SIP信令服务器在应对海量设备命令交互时容易成为性能瓶颈，需要增加多个SIP信令服务器，若不支持注册重定向，只能通过人工绑定的方式对设备在平台的SIP信令服务分布式集群节点间进行负载均衡，并为每个设备配置不同的注册接入节点IP和端口，绑定和配置过程复杂繁琐且工作量大。除此之外，当设备接入的SIP信令服务节点发生故障时，因为设备不支持注册重定向，总是尝试向故障节点发起重新注册，无法实现自动故障转移，需要人工发现并重新进行配置，耗时较长，在此过程中平台业务会中断，数据会丢失，对用户的业务应用会造成较大影响。

　　为了解决这个问题，2022版增加了注册重定向功能，对注册信令的应答格式进行扩展，增加了重定向应答，同时也增加了重定向方式的注册流程的交互过程说明。有了注册重定向之后，设备向平台的SIP信令服务注册流程更加灵活，设备注册的相关配置可以大大简化。平台系统中增加一个全局SIP注册服务，由于此服务只进行重定向，不处理具体的业务信令，因此其负载很轻，也不需要维护设备连接状态，容易实现高可用。维护人员可以对所有设备都统一配置同一个全局SIP注册服务IP和端口。设备首先向全局SIP注册服务发起注册，由全局SIP注册服务根据平台的各个SIP信令服务的负载情况，按照一定的负载均衡策略对设备进行负载均衡调度，将设备调度到合适的SIP信令服务节点，并向设备回复注册请求响应302，在响应消息中携带对应的SIP信令服务节点的地址和端口。设备收到302重定向响应后，向重定向的SIP信令服务节点发起注册并完成重定向注册流程。

　　当设备注册重定向后，与具体的SIP信令服务节点通信时，如果按照心跳要求判定SIP信令服务节点离线，设备会重新执行注册重定向流程，向全局SIP注册服务发起新的注册请求，全局SIP注册服务会对设备重新进行负载均衡调度，将设备重定向到正常的SIP信令服务节点，实现了SIP信令服务节点的故障转移，保证了业务连续可用，提升了用户使用体验。

　　3.2.图像抓拍

　　2022版增加了图像抓拍功能，通过设备配置的方式来实现，消息体Body的XML元素是Control元素，而子元素CmdType固定取值为DeviceConfig，通过SnapShotConfig元素描述具体的抓拍请求。当设备完成抓拍后，需要发送一个通知命令，消息体Body的XML元素是Notify，子元素CmdType取值UploadSnapShotFinished，通知中包含抓拍到的图像的唯一标识。

　　图像抓拍虽然是通过配置命令来实现，但实际上不像一个持久的配置，反而更像是一个命令，设备收到配置命令后，应该马上按照配置内容进行抓图，完成后发送通知，之后配置就相当于失效了。当需要再次进行抓图时，即使参数相同，也需要再次下发图像抓拍配置的命令。

　　标准规范了抓图的张数、每张图之间的间隔时间、抓图上传的URL和SessionID，并没有对如何上传图片进行细化。在实际项目应用中，需要进行细化规范，一般抓图上传的URL是一个Http的URL，通过HTTP协议进行上传，URL中一般都应该带token或者其他字段来进行鉴权认证，同时一般也要求在上传每个图片时，在URL上附加上SessionID和图像唯一标识SnapShotFileID，方便图像服务器进行存储和索引，在后续下载时进行关联。

　　下面是一个参考实现，下发图像抓拍配置的SIP命令的Body如下：

　　然后设备抓拍到一张图片后，通过Http协议进行图片上传，Http命令报文如下：

　　设备图像抓拍完成后，发送抓拍完成通知，相应SIP命令的Body如下：

　　硬件处理能力和网络传输带宽的提升以及编解码技术的发展，为高清音视频的应用提供了可能性，而业务应用的需求，特别是人工智能分析处理对音视频媒体的分辨率、采样率等的更高要求，使得高清音视频成为迫切需求。

　　2022版增加H.265和AAC的支持，对编解码的具体要求包括的档次和水平的要求、支持的编解码选项和工具的要求、码流语法的要求等。在码流封装传输时，H.265的PSM流类型取值0x24，RTP包负载类型（Payload Type）建议取值100。AAC的PSM流类型取值0x0F，RTP包负载类型建议取值102。

　　2022版中也对SDP描述进行了扩展，支持对高清媒体情况及其他信息的描述。在f字段中，扩展分辨率的表示方式，在原有的QCIF、CIF基础上，增加了WxH的通用表示方式，其中W表示宽度，H表示高度，例如1920x1080。音频的码率和采样率也增加了高清音频所需的定义。另外新增"a=streamnumber:码流编号"的字段来描述码流标号，例如0表示主码流，1表示子码流1，以此类推。

　　3.4.存储卡管理

　　在视频监控前端设备中，很多时候需要使用存储卡进行数据存储且远程对SD卡进行管理，因此在2022版增加了对存储卡的查询和格式化等功能。

　　查询存储卡通过会话通道进行，消息Body的XML元素是Query，子元素CmdType固定取值为SDCardStatus，设备收到命令后，在应答中返回设备的SD卡列表，以及每个SD卡的总空间和剩余可用空间等信息。

　　如果存储卡数据异常，或者更换新的存储卡之后，需要对存储卡进行格式化，消息Body的XML元素是Control，子元素CmdType固定取值为DeviceControl，然后通过子元素FormatSDCard来描述具体的格式化SD卡的信息。格式化的进度可以通过前面提到的查询存储卡的命令进行查询。

　　3.5.配置管理增强

　　2022版进一步完善了配置管理，将各个配置信息的具体数据都独立抽取出来作为公共数据结构进行描述，确保了读取和写入配置信息的一致性，同时也在原有的基本参数配置、SVAC编解码配置的基础上，增加了一些业务应用配置。

　　新增视频相关配置，视频参数属性配置通过VideoParamAttribute元素描述，用于对编解码格式、分辨率、帧率、码率等进行配置。视频画面遮挡配置通过PictureMask元素描述，用于对视频中多个特定区域进行画面遮挡。在一些涉及隐私的应用中，可以对部分敏感信息区域进行遮挡。画面翻转配置通过FrameMirror元素描述，用于对画面的上下翻转、左右翻转、中心镜像等翻转方式的配置，项目实施过程中，由于现场环境的限制，有时候只能以某个方向某种角度进行设备安装，通过画面翻转配置，将画面翻转成适合观看的正常角度，方便观看。前端OSD配置通过OSDConfig元素描述，用于对画面上的OSD信息进行配置，包括OSD的位置、时间显示方式、文字内容和显示方式等。

　　新增录像相关配置，录像计划配置通过VideoRecordPlan元素描述，用于对录像计划的时间段、码流类型等进行配置。报警录像配置通过VideoAlarmRecord元素描述，用于对控制报警录像是否启用，启用时对录像延时、预录、码流类型等进行配置。

　　新增报警相关配置，报警上报开关配置通过AlarmReport元素描述，用于对移动侦测事件、区域入侵事件等不同的事件进行是否上报的配置，通过控制不同的报警上报，能够减少不必要的报警信息，聚焦于重要的报警。

　　3.6.云台控制增强

　　早期版本的云台控制，提供了上下左右、变倍变焦、拉框放大、看守位、预置点、巡航等功能，部分功能是通过单独命令进行，还有部分功能是通过PTZCmd命令进行，这个命令采用二进制数据格式描述具体的操作，使用不方便，2022版中对云台的控制命令更加完善，不再对PTZCmd命令进行增补，而是通过单独命令的方式进行，并且对控制、查询、数据通知等也进行了规范。

　　看守位信息查询命令Query元素的CmdType固定取值HomePositionQuery，返回各个看守位是否启用、预置位编号、自动归位时间间隔等。巡航轨迹列表和巡航轨迹查询命令Query元素的CmdType固定取值CruiseTrackListQuery和CruiseTrackQuery，返回巡航轨迹的列表，以及每个巡航轨迹的编号、名称、各个预置点的编号、预置点停留时间、云台速度等信息。

　　PTZ精准控制命令通过子元素PTZPreciseCtrl来描述具体的精准控制参数，包括云台水平角度、垂直角度、变焦倍数等。PTZ精准状态查询命令通过CmdType子元素取值PTZPosition来进行查询，返回设备PTZ的水平角度、垂直角度、变倍倍数、水平视场角、垂直视场角、可视距离等信息。PTZ精准状态也可以通过订阅的方式进行查询，订阅后，设备会将PTZ精准位置变化的信息通过事件通知的方式进行推送。

　　目标跟踪控制命令通过子元素TargetTrack来描述具体的目标跟踪方式，例如自动跟踪、手动跟踪等。这个命令主要用于全景摄像机和球机进行目标跟踪配合，当在全景摄像机中指定具体位置时，联动球机跟踪展示该区域的特写图像。

　　3.7.多路径级联

　　在视频联网平台发展过程中，由于业务流程和网络拓扑越来越复杂，联网结构逐渐从树状结构发展成网状结构，下级平台可能会有多个上级平台或者互联平台，同一目录可能会被推送到多个不同的平台，而这些平台又可能再往上推送到同一个更上级的平台，从而形成了多个路径。一个多路径的例子如图3所示，这种联网结构中，上级域访问下级域接入的目标设备，存在多种访问路径的可能性。图中平台A访问设备M，则存在C→E、B→C→E、B→D→E三种路径。

图3 摄像机及平台推送示例

　　基于全局统一的资源编码规范，多个不同路径汇聚的目录结构，可以通过全局唯一编码来识别出相同的设备。为了能获取到多路径中每个路径的具体情况，通过指定使用具体路径的方式来访问设备，并且当某个路径出现故障时，切换使用其他路径的方式进行设备访问，减轻局部故障的影响，提高系统的可靠性。

　　在目录推送的过程中，在设备目录项和平台目录项的XML格式的数据中加入ParentID元素，表示此目录项的父节点信息，对于多个下级节点推送上来的目录项，通过全局统一编码将相同的目录项匹配出来。如果他们的ParentID元素的值不一致，则进行值的合并。这样在上级平台中，可以通过设备目录项和平台目录项的ParentID元素，从设备开始逐级往上查找到最高节点，形成完整的路径。如果中间某个节点的ParentID因为合并有多个值，也就是有多个上级节点，就会形成多个路径。

　　在对设备进行命令控制过程中，上级平台与设备之间存在多条路径时，应支持自动路径选择，默认选择的是在线的且最短路径的下级平台或设备，下级平台或设备在返回成功或失败 SIP 响应时，消息头部应扩展 X-RoutePath 字段，用于记录命令过程中经过的平台路径情况。响应消息从下级逐层转发到上级平台时，转发消息的平台应将本平台编码添加至 X-RoutePath字段的最前面，用"-"分隔）。这样上级平台就可以得到信令执行过程中默认的自动路径情况。

　　当由于中间平台出现异常等原因，上级平台希望换一个路径向设备发送命令时，可以通过添加 X-PreferredPath 头部字段的方式，指定期望的命令请求经过的各级平台路径。平台在命令请求时，如果存在 X-PreferredPath 头字段，且本平台在路径之内，则应将本平台编号从X-PreferredPath中删除，然后转发请求到X-PreferredPath中指定的下一个平台，从而实现指定路径方式的访问。

　　3.8.设备软件升级

　　新版标准发布后，一方面新的设备和平台采用新标准进行开发需要时间，另一方面已有的设备和平台在进行升级前可能还将在一段较长时间内维持使用，而且未来还可能有新版标准发布，因此多版本标准并存将成为常态。为了使不同协议版本的设备、平台之间兼容，2022版增加了协议版本号的说明，通过在SIP协议中增加X-GB-Ver头部来描述具体的版本号，1.0表示2011版，2.0表示2016版，3.0表示2022版。通讯双方可以通过消息头部来了解对方支持的协议版本，然后根据协议版本要求进行通信。一般来说，设备只需要支持一种协议版本即可，由于平台往往需要同时接入多种协议版本的设备，因此需要支持多种协议版本，由平台来适配设备。

　　在实际项目中经常遇到需要设备升级的场景，之前由于没有定义的设备升级指令，都需要单独登陆到设备上进行逐个升级，费事费力。2022版增加了设备升级的指令，可以很好的解决设备批量升级的问题。

　　由于不同的厂家的升级包格式与升级方式都有差别，因此2022版只定义了升级命令的下发和升级结果的通知过程，对于升级包本身只通过一个FileUrl字段来说明，不做过多的限制。设备升级命令通过会话通道进行，消息Body的XML元素是Control，子元素CmdType固定取值为DeviceControl，通过DeviceUpgrade元素描述升级包路径、升级SessionID等信息，设备收到命令后，获取升级包进行升级，升级成功后发送升级结果通知，消息Body的XML元素是Notify，子元素CmdType固定取值DeviceUpgradeResult，通过SessionID、UpgradeResult等子元素描述升级结果。

　　实际实现时，一般是采用Http协议的FileURL，将设备升级软件包按照厂商、型号、版本等信息进行分类索引，放在升级软件包仓库管理系统中进行管理，提供Http方式的下载服务。当需要对设备进行升级时，先通过设备信息查询命令获取设备的厂商、型号、版本信息等，然后在升级软件包仓库中按照厂商、型号、版本等信息搜索合适的高版本的升级软件包下发给设备进行升级。在升级过程中需记录升级的结果，检验升级后的版本是否和需要升级的版本一致。

　　4.结语与思考

　　从标准的历次迭代更新，我们可以看到标准和应用之间的相互促进，有效解决了异构视频联网系统的互联互通，将不同领域新技术进行多维度、多层次集成创新应用，实现跨区域、跨部门、跨层级的视频资源超大规模联网共享。

　　GB/T28181标准在公共安全、社会治理、智慧交通等多个领域中广泛使用，并逐步延伸到非视频的物联设备联网应用。2022版修订也深入讨论了门禁、出入口控制器、停车道闸等相关提案，最终由于种种原因没有完全采纳。

　　随着AIoT融合创新应用的不断发展，越来越多的物联设备加入到大联网中，必然会对标准提出更多新需求，同时也给标准制定带来新挑战。如何统筹兼顾大数据量频繁交互的智能视频应用和超低功耗的物联应用对协议框架的不同要求，也许是标准未来再次更新时要思考的问题。技术路线经过产业实践得到了广泛认可的内容迟早会成为标准，但根据场景应用等需求，将来是在此标准中增补，还是以独立标准的形式发布更合适仍然有待深入研究。