简介这是一份面向视频监控联网平台开发与运维人员的接口对接参考文档聚焦28181协议下下级平台与上级平台之间的通信机制重点讲解平台注册、SIP信令交互、鉴权校验与心跳保活等核心环节。文档通过具体REGISTER信令示例完整演示了从发起注册、收到401 Unauthorized、携带鉴权信息重发到最终200 OK的对接流程并顺带说明了SIP、UDP、HTTP认证及MD5算法在其中的作用便于读者按图索骥完成联调。资源包内含1个doc文档大小约85KB内容结构紧凑可直接用于系统设计、代码实现与问题排查。目前已有291人学习适合具备一定网络基础、正在接入或维护GB/T28181平台的开发者和维护者参考。1. 28181平台对接接口视频联网项目为什么总卡在这份文档上一个视频联网项目里最容易拖进度的不是摄像头安装而是平台对接。上级平台丢给你一份《28181平台对接接口详解.doc》说照着接就行可真到联调时设备注册不上、目录刷不出来、预览窗口黑屏全是这类问题。28181平台对接接口解决的从来不是某个厂商的私有协议而是国标GB/T 28181所定义的跨厂商视频平台互联规则平台与平台怎么注册、目录怎么上报、实时流怎么拉取。适合集成商、平台研发和运维人员在把下级设备或下级平台接入上级域时照着这套规则把信令和媒体流真正打通。别指望一份doc能替代协议本身决定接通率的是你如何把里面的字段填进自己的配置并抓包验证每一步。2. 28181接口骨架拆解SIP管信令、RTP管媒体、XML管目录2.1 协议栈为什么国标选SIP而不是私有SDK先给结论28181对外表现为基于SIP的会话控制码流用RTP承载会话描述用SDP目录、报警、设备信息这类业务数据则通过SIP的MESSAGE方法在消息体里塞入XML来传递。整条链路被严格切成信令面和媒体面各司其职。信令面使用SIP协议常见默认端口是5060/UDP处理注册、心跳、点播、云台控制这些控制动作。媒体面使用RTP承载摄像头编码后的H.264或H.265码流并按PS封装后送到平台指定的地址端口。业务数据面则复用SIP的MESSAGE或INFO方法比如目录查询的响应就是一段Catalog类型的XML。理解这个三层关系所有排错就有了主线先看信令通没通再看媒体流到没到最后才去怀疑封装和编码。国标28181标准协议文档之所以写得厚是因为它要覆盖的厂太多、场景太杂既有摄像头直连平台也有平台级联平台。SIP作为RFC标准协议报文是文本的在Wireshark里可以直接展开看状态码和头域不像私有SDK那样是个黑匣子。这一点对做对接的人特别关键跨厂商排障时双方都能看同一份抓包各自主张就少了。2.2 平台级联模型上级平台和下级平台各自扮演什么角色在28181的联网架构里设备不是直接裸接到中心而是按“设备-平台”和“平台-平台”两层关系组织。下级平台既要向下面对摄像头又要作为SIP客户端向上级平台注册上级平台则作为SIP服务端接收多个下级域接入。这个“既是服务端又是客户端”的双角色是新手理解上最容易绕晕的地方。所谓对接实际常见就两种。一种是国标摄像头直接注册到平台叫设备接入另一种是把已经建好的下级平台整体上送到上级平台叫级联接入。两者信令行为类似差异主要在目录规模级联接入时下级平台上报的通道数量可能几千路目录查询往往要做多层分页一条Catalog响应装不下需要按序号逐段返回。平台对接接口文档里如果出现“逐条查询”“分页目录”这些字眼多半就是级联场景。另一个容易忽略的点是SIP监控域标识。每个接入域需要规划好自己的域编号它体现在注册URI里。上下级平台要提前协商的正是这个域标识、鉴权密码和编码前缀。如果没约定好上级平台不知道你是哪个域的注册请求会直接被拒掉。我一般拿到对接文档后第一件事就是找“SIP服务地址、域编号、密码”这三项而不是先翻报文示例。2.3 注册与心跳的关键报文REGISTER、401挑战与Keepalive对接的第一个动作是注册。设备或下级平台启动后按配置的服务器地址发送REGISTER用From和To分别指明自己的国标ID和上级平台SIP服务器ID。平台开启鉴权时会先回401并带挑战参数客户端用密码做MD5摘要后重发REGISTER平台校验通过回200 OK。下面是一段常见注册报文的缩略形式REGISTER sip:340200000020000000013402000000 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10:5060;rport;branchz9hG4bK123456 From: sip:340200000013200000013402000000;tagabcdef To: sip:340200000020000000013402000000 Call-ID: 2024010112000010.0.0.10 CSeq: 1 REGISTER Expires: 3600 User-Agent: GB28181Client Content-Length: 0这段报文里From中的34020000001320000001是本端设备的20位国标IDTo中的34020000002000000001是上级平台分配给本域的SIP服务器国标IDExpires是注册有效期。注册成功后设备要周期上报心跳常见实现是发送MESSAGE方法消息体嵌一段Keepalive的XMLMESSAGE sip:340200000020000000013402000000 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10:5060;rport;branchz9hG4bK777888 From: sip:340200000013200000013402000000;tagheartbeat001 To: sip:340200000020000000013402000000 Call-ID: 2024010112001010.0.0.10 CSeq: 20 MESSAGE Content-Type: Application/MANSCDPxml Content-Length: 178 ?xml version1.0 encodingUTF-8? Notify CmdTypeKeepalive/CmdType SN101/SN DeviceID34020000001320000001/DeviceID StatusOK/Status /Notify心跳报文里两个字段最关键。CmdType告诉平台这是何种业务消息Keepalive是心跳、Catalog是目录、DeviceInfo是设备信息SN是流水号设备发送时自增平台回响应时会把相同的SN原样带回用来对齐请求和结果。心跳周期一般设置60秒注册有效期多数平台建议3600秒至少要保证心跳间隔小于注册有效期的三分之一否则网络稍有抖动平台就会判定设备离线。提示注册成功后不要急着点播放。先观察几轮Keepalive是否按固定周期到达很多平台显示“在线”又频繁掉线问题都出在心跳周期和Expires配置颠倒上。3. 对接前的参数表怎么抠国标编码、SIP端口、传输协议一个都不能错3.1 一份最小对接配置样例与字段含义拿到一份《28181平台对接接口详解.doc》这类资料我一般只把它当参数词典用核心价值是把对方的SIP服务地址、域编号、鉴权密码和媒体端口段告诉你。联调之前建议把参数集中成一张表而不是散落在设备网页和群里聊天记录里。这里最容易犯的错是把“对方提供”和“本端规划”混成一团。典型的配置块长这样我习惯写成可读的配置文件[sip] local_id 34020000001320000001 # 本端设备或下级域国标ID20位 domain 3402000000 # 上级平台的SIP域标识 server_addr 10.10.1.20 # 上级平台SIP服务器地址 server_port 5060 # 上级平台SIP服务器端口 password 12345678 # 注册鉴权密码非平台登录密码 transport udp # 信令传输协议可选udp或tcp expires 3600 # 注册有效期单位秒 heartbeat_interval 60 # 心跳间隔单位秒 [media] local_ip 10.10.1.50 # 本端媒体网卡地址必填 start_port 60000 end_port 60010 # 媒体端口范围按并发路数放大 video_pt 96 # RTP负载类型28181常见96 rtp_payload_type PS # 码流封装PS或H264裸流字段里最容易被忽略的是local_ip。很多软平台会按路由自动选源网卡但有多个网卡时SIP信令里携带的媒体地址可能落到错误的网卡导致对端把RTP流发到不通的地址。我一般在对接前强制绑定媒体IP让程序不要猜。server_addr、server_port、password都是对方给的local_id是本端的必须和注册报文From字段里的编码完全一致。密码这块特别提醒28181的鉴权密码和平台后台的用户登录密码是两回事。很多摄像头出厂默认密码为空或固定值对接文档里如果不写联调时会反复401失败而且不容易想到是密码问题。3.2 传输协议TCP与UDP怎么选媒体端口段怎么规划28181信令支持UDP和TCP两种传输方式。大多数平台默认UDP因为视频设备数量大、心跳频繁UDP在局域网开销小。但跨专网、跨运营商链路的项目里UDP长时间丢包会带来大量“假离线”告警所以有的平台会明确要求信令走TCP。TCP信令的服务端通常仍监听5060端口客户端源端口不固定防火墙上除了放行到5060的入站还要允许返回流量。媒体传输协议的坑比信令更多。28181-2016支持UDP媒体和TCP媒体其中TCP媒体又分主动和被动模式被动模式是平台侧监听媒体端口设备主动连入主动模式是设备监听端口平台侧主动去连。对接前一定要把“信令传输协议”和“媒体传输协议”分开确认。信令走UDP不代表媒体也自动走UDPSDP协商里会写明本端媒体地址、端口和传输方式对端按这个来建RTP通道。多数拉流失败都翻车在这里一边按UDP推流另一边在等TCP连接信令全是200 OK画面却始终黑屏。媒体端口段规划也有讲究。常见平台默认从60000或10000起配一段连续端口每路视频占一个端口。端口段长度要按“并发预览路数录像回放路数30%余量”算不要只开五六个端口然后抱怨“有的路通有的路不通”。通道多的大平台我一般建议至少预留100个以上端口段并且把这段端口从防火墙策略里独立放通。注意如果平台侧明确说“媒体走TCP被动模式”意味着平台的媒体地址和端口必须能被设备访问到。两边防火墙只放通了SIP端口媒体依然连不上这是网络策略问题不是协议问题。3.3 20位国标编码怎么拆设备编码和通道编码怎么对应对接文档第一页通常放一段编码规则说明但具体填的时候不少人把设备编码和平台编码填反。标准做法是平台SIP服务器ID由中心编码加类型编号构成设备ID和通道ID则是20位数字前8位是中心编码对应行政区划和扩展编号后12位在不同厂商文档里拆分习惯不太一样有的把其中两位当行业编码、两位当类型编码有的直接把整体叫“设备编码”。这里我给不出放之四海皆准的每一位公式因为不同平台确实存在差异最靠谱的做法是严格按对接文档里的编码表填。能给出的共性经验是在同一个平台下设备ID和通道ID的前12位通常完全一致后8位区分设通道序号。如果目录正常显示但点视频黑屏优先核对通道ID是否正确——有些厂商的通道ID是在设备ID基础上前移或变更一位编号而不是简单地加1。编码这块还有个小习惯把上级平台分配的SIP域标识、本端每台设备的国标ID、每个通道的国标ID单独做成Excel联调时是谁的问题就查谁的ID避免在多个20位数字之间找不同找到眼花。这种事情看着笨实际排查速度比翻聊天记录快得多。4. 从注册到拉流的完整对接流程报文时序与每一步的验证动作4.1 先把注册和心跳跑成稳定状态再谈下一步拿到对接环境后我建议不要急着点视频预览按“注册-心跳-目录-拉流”的次序逐项验证。第一步确认注册状态在平台侧看设备是否在线同时在本端抓包确认REGISTER请求和200 OK在双向流动。抓包命令用系统自带的工具就可以tcpdump -i eth0 -s 0 -w gb28181.pcap udp port 5060 or tcp port 5060抓包网卡必须与实际业务网卡一致。如果平台在专网段而抓包口在管理网段抓到的是连不上的数据等于白抓。抓包时先触发一次设备注册重启方便在pcap里定位第一条REGISTER。一个稳定的对接第一步不是“偶尔在线”而是连续半小时不出现REGISTER重传和401失败。注册成功后改看心跳行为。28181心跳是设备周期向上级平台发送MESSAGECmdType为Keepalive。抓包时关注CSeq是否递增、两个心跳间隔是否稳定。间隔忽长忽短说明设备端负载高或链路抖动平台判定离线往往是多个心跳超时累积的结果单看一条报文看不出问题。4.2 目录查询让平台“看见”你的通道注册和心跳稳定后上级平台会下发目录查询请求设备或下级平台要返回一条Catalog响应把所有通道以XML形式上报。这里最常出问题的不是XML格式而是通道状态字段。一段典型的Catalog响应如下?xml version1.0 encodingUTF-8? Response CmdTypeCatalog/CmdType SN305/SN DeviceID34020000001320000001/DeviceID SumNum2/SumNum DeviceList Item DeviceID34020000001320000002/DeviceID Name东门枪机/Name StatusON/Status /Item Item DeviceID34020000001320000003/DeviceID Name西门球机/Name StatusON/Status /Item /DeviceList /Response这份XML里SumNum是通道总数DeviceList里每个Item是一个通道Status为ON代表在线OFF代表该通道不可用。平台一般按这个字段判断前端点位是否在网如果Status一直为OFF要回到设备端确认通道是否被禁用或者设备本身是否离线。另外设备回响应时SN必须等于请求里的SN否则平台会把这条Catalog丢弃现象就是目录一直刷不出来。4.3 INVITE点播与SDP协商决定拉流成败的细节全在这里通道目录正常后才进入拉流环节。平台向设备发送INVITE请求某一路通道的实时流消息体里的SDP描述了平台期望的媒体格式和接收端口。设备侧必须用相同的负载类型回200 OK然后开始往SDP声明的地址推RTP流。下面这段INVITE消息体是常见请求格式v0 o34020000002000000001 0 0 IN IP4 10.10.1.20 sPlay cIN IP4 10.10.1.20 t0 0 mvideo 60000 RTP/AVP 96 arecvonly artpmap:96 PS/90000 asetup:passive y34020000001320000002逐行拆开说。c行里的IP是平台侧媒体接收地址m后面的60000是平台媒体接收端口artpmap:96 PS/90000约定负载类型96、封装PS、时钟90000asetup:passive表示平台侧采用TCP被动模式接收媒体。最后一行y是28181自定义的SDP扩展字段告诉设备这一路请求对应哪个通道必须填对否则设备不知道该推哪路画面。设备端回200 OK时SDP里的媒体地址要写设备侧能发流的IP不能回环地址或内网管理地址。关于主码流和子码流28181通过SDP的sPlay和sPlaySub区分sPlay一般指主码流sPlaySub指子码流。平台默认发Play需要子码流时显式带PlaySub。对接时如果预览分辨率过高导致带宽吃紧可以在平台侧调整请求类型。注意播放黑屏时先用Wireshark过滤rtp看包有没有到达再谈解封装和编码。如果RTP包根本没有问题在SDP协商或网络路由如果包有但花屏才需要查PS封装和负载类型参数。5. 平台对接避坑指南注册失败、目录不出、视频黑屏的排查路径5.1 平台始终显示离线先查REGISTER的401挑战应答现象设备侧日志显示注册成功平台侧列表里设备仍然离线。原因最常见是本端国标ID与平台白名单不一致或鉴权密码没对上。28181的注册流程里第一次REGISTER会收到401第二次要带Authorization字段里面是对用户名、密码、nonce的MD5摘要。这个用户名不是随便填的一般就是设备国标ID本身。有些设备网页上填的密码和平台侧实际配置不一致摘要自然算不对。解决抓包看401之后的第二条REGISTER确认Authorization字段存在且有值把设备ID复制到平台侧核对注意别把空格带进去。再用平台侧提供的密码算一版摘要重点确认HA1里的用户名确实是设备ID。还有一类容易被忽略的是设备时钟偏差过大某些平台会在nonce里带时间戳设备时间差太多会导致鉴权响应无效这种情况把设备NTP和平台对齐通常能解决。5.2 目录能查到但预览黑屏SDP里的封装格式和实际码流对不上现象平台已经能看到通道点预览黑屏信令全是200 OK抓包发现有RTP包但播放器不解码。原因设备回INVITE的200响应时SDP里的artpmap与设备实际推流封装不一致。比如设备实际推的是H.264裸流却在SDP里声明PS/90000或者设备推PS流但负载类型不是96。平台按SDP里的描述解封装和实际码流对不上自然出不了画面。解决抓包对比INVITE请求和200响应的rtpmap是否一致不一致时优先改设备。平台要求PS封装设备必须按PS封装推流如果设备确实只能推裸流就让平台侧把通道类型改为裸流对接或者加一台转码网关把码流转封成PS再上送。黑屏排障时Wireshark过滤条件建议写成rtp udp.srcport 60000 udp.srcport 60010能够迅速确认媒体包是否到达以及到达的端口分布。这类问题排查到最后往往成了玄学因为配置界面里封装类型不叫“PS”而是叫“国标码流”“GB封装”之类对着文档看就觉得对上了实际要逐个检查。5.3 信令通了媒体不通TCP媒体模式与防火墙端口段没对齐现象注册、目录、INVITE全部成功媒体端口却始终收不到RTP或者有些路数能通有些不能毫无规律。原因信令端口5060放行了但媒体端口段没有放行。媒体走TCP被动模式时平台侧监听的媒体端口必须是设备侧能主动连入的走UDP时设备源端口可能落在配置端口段内只放通单个端口会造成断断续续。解决先看SDP协商里平台声明的媒体接收地址和端口再到平台侧用ss或netstat确认监听端口真的在听。跨网段对接时要保证媒体地址可路由别拿管理网IP填SDP的c字段。防火墙和交换机ACL要把整段媒体端口都放通而不是只开一个端口测试。血泪经验是现场网络人员听说“只对接一个平台”就只放通了5060端口结果调了三天黑屏最后发现媒体端口全被拦。5.4 心跳正常但设备被判定离线注册有效期和心跳超时互为瓶颈现象设备配置心跳60秒平台却每隔几分钟掉线一次抓包看不出任何信令错误。原因注册有效期Expires被设得很短比如300秒而设备或平台在到期前没有重新发起REGISTER或者平台侧配置的心跳超时阈值比设备心跳间隔还小网络一抖动就超时。注册是长周期事件心跳是短周期事件两者配置不匹配时平台会误判离线。解决把注册有效期设置成心跳间隔的数倍以上常见组合是心跳60秒、Expires 3600秒平台侧心跳超时阈值至少按3个心跳周期算也就是180秒。改完两端都要重启服务然后连续观察半小时以上看REGISTER重传间隔和Keepalive周期是否稳定。如果心跳间隔本身有波动可以适当加大平台侧容错次数而不是把心跳调到10秒硬扛。6. 把验收做成固定动作用模拟工具和抓包器确认每个对接阶段做对接多了之后我养成了一个固定习惯先环境验证再动生产配置。环境验证就是本地起一个支持28181接入的开源视频平台或模拟客户端先把注册、目录、点播三个流程对模拟设备跑一遍把抓包存成pcap作为基线。之后所有现场排障都拿基线对比一眼就能看出是配置差异还是环境差异。三个阶段的验收动作基本固定。第一阶段抓信令Wireshark过滤条件直接写sip确认REGISTER、Keepalive、Catalog、INVITE按顺序出现每类消息都有回应第二阶段抓媒体过滤条件写rtp确认媒体包持续到达且端口落在规划段内第三阶段验证码流把抓包里的RTP载荷导出成PS文件用VLC播放确认画面正常。三步走完对接才算真的通过而不是平台界面上显示个“在线”就算完。每次调通后我会把最终生效的传输协议、心跳间隔、媒体端口段、SDP里用的负载类型回填到最初那张参数表作为项目验收附件。下次新对接直接复制这份配置省掉大量重复联调时间。我见过太多项目倒在“协议都对、配置没对上”这一类问题上与其反复催厂商不如自己把关键字段和抓包基线握在手里。希望帮到你。本文还有配套的精品资源点击获取