GBT 28181-2022解读2：主要改进

admin

3.1.注册重定向

　　随着联网系统的规模化建设，单一的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如下：

3.3.高清编码传输

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

　　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方式的下载服务。当需要对设备进行升级时，先通过设备信息查询命令获取设备的厂商、型号、版本信息等，然后在升级软件包仓库中按照厂商、型号、版本等信息搜索合适的高版本的升级软件包下发给设备进行升级。在升级过程中需记录升级的结果，检验升级后的版本是否和需要升级的版本一致。