简介基于Java实现的GB28181国标平台面向安防监控与视频接入领域的开发者帮助解决设备注册、目录查询、实时视频流TCP被动/UDP等常见协议接入问题。压缩包内含49个文件以43个Java源文件为项目核心另有XML、properties、yml等配置文件及Markdown说明文档整体体积仅64KB结构紧凑、便于快速下载与本地部署。目前已有4240人学习下载适合需要参考国标协议实现或希望搭建轻量级视频接入平台的Java工程师。使用方式很简单修改config.properties中的配置后编译运行即可体验完整流程。借助精炼的代码组织可以清晰看到设备注册、目录查询、实时视频流等关键模块的调用关系为后续二次开发和协议扩展提供扎实基础。 做了几年视频接入和安防平台相关的工作中间有段时间一直在折腾GB28181的东西。一开始是拿开源C项目改后来项目要上Java技术栈干脆自己用Java撸了一个完整的GB28181平台就是JGB28181。这个项目解决的核心问题很简单把不同品牌、不同协议的摄像头和NVR统一接入到一个平台里用国标方式完成注册、直播、回放、云台控制和语音对讲。如果你正在做安防平台开发、视频接入网关或者想搞懂GB28181协议到底是怎么跑通的这篇东西应该能给你省不少时间。1. 为什么用Java写GB28181平台项目背景与选型逻辑1.1 视频接入的痛点比想象中多得多做视频接入的人应该深有体会海康、大华、宇视这些厂家的SDK各不相同每接一个新的设备型号就要重新适配。ONVIF虽然能做设备发现和媒体协商但在大规模组网、跨地域互联、平台级联这些场景下还是不够用。GB28181作为国内视频监控联网的国家标准通过SIP协议进行信令交互用RTP传输媒体流从设计上就是为了解决异构设备之间的互联互通问题。但现实是网上能找到的GB28181实现大多是C写的比如live555、osip、eXosip这些想要集成到Java后端里还得写JNI维护成本非常高。更麻烦的是C项目里对SIP信令的处理往往和媒体流处理耦合在一起想单独把信令模块抽出来做二次开发代码读起来相当痛苦。我当时的判断是如果团队本身就是Java栈用一个Java原生实现反而能少踩很多坑。1.2 选型对比别被老思路困住我评估过几种路线简单说下结论直接用eXosip/libeXosip封装的Java接口底层还是C库编译环境折腾人跨平台部署时经常遇到so库不兼容的问题。基于JAIN-SIP做二次开发JAIN-SIP只处理SIP协议栈GB28181里的SDP字段解析、设备目录查询、录像检索这些应用层逻辑还得自己写工作量不小。参考wvp-GB28181的设计思路用Java全栈实现代码可控性最强信令和流媒体分开处理后续扩展比如加WebRTC网关、加AI分析都会方便很多。JGB28181最终走了第三条路。SIP协议栈用Java原生的方式实现自己解析、自己组包媒体转发和PS流解复用也用Java搞定。这样整个项目打成一个Jar包就能跑不需要额外装任何C依赖。1.3 JGB28181的总体架构先看下项目的主要模块SIP信令服务负责设备注册、心跳、目录查询、云台控制、报警通知等信令交互。媒体服务负责RTP接收、PS流解复用、H264/H265裸流提取再把裸流转发到流媒体服务或直接推给播放器。设备管理维护设备列表、通道列表、在线状态支持级联场景下的目录推送。流媒体网关把内部媒体流以RTSP、RTMP、HLS或WebRTC方式分发出去前端播放器只需要按标准协议拉流。平台管理接口对外提供REST API方便上层业务系统调用。我们以SIP服务为例注册流程大致是设备端发送REGISTER请求SIP服务校验设备ID和密码校验通过后返回401鉴权挑战设备再次带鉴权信息注册注册成功后在内存和数据库里同时记录设备状态并启动一个定时器等待设备心跳。这个流程看起来简单但涉及的协议细节特别多下面逐个拆开说。2. 核心细节解析与实操要点2.1 设备ID和设备编码规则一开始就要约定好GB28181里每个设备、通道、平台都有20位数字编码。前8位是行政区划编码中间4位是行业编码再后面2位是类型编码最后6位是序号。比如一台摄像头的编码可能是14070000001310000001其中140700是地区0000是行业13是类型1300代表摄像机1310代表NVR后面是序号。自己搭平台时一定要把这个编码规范做成配置不要把编码逻辑写死在代码里。我在项目里遇到过一个很尴尬的情况测试设备是海康的默认编码是14070000001320000001但平台里配置的行政区划是110000结果设备注册时校验地区码不匹配直接拒绝了。后来把编码校验改成可配置的规则按实际项目情况松紧控制才解决了问题。2.2 SIP信令交互细节最容易翻车的地方GB28181的信令流程和标准RFC 3261是有区别的很多刚接触的人会按SIP标准协议去解析结果一头雾水。几个关键差异没有标准的注册成功后200 OK就完事设备端还会周期性发送MESSAGE心跳Notify平台需要响应200 OK否则设备会反复重连。目录查询用的是MESSAGE消息body里是XML格式的Query请求响应是XML格式的DeviceList响应注意SIP头的User-Agent、Content-Type、Content-Length一个都不能少。实时视频点播的INVITE请求里SDP的y字段存储的是媒体流的SSRC这个值在GB28181里是十六进制或十进制表示的字符串不少设备会在这个字段里直接写0解析时要注意兼容。历史录像回放中SDP里还带有DownloadSpeed字段控制的是回放倍速如果设备不支持加速回放这个字段传了也没用。这些细节在协议文档里都有但排错时第一反应往往是看网络抓包而不是看文档。我的建议是开发调试阶段每处理一个信令方法就录一段报文留档后面排查问题效率会高很多。2.3 媒体流格式化H264/H265私有扩展要特别留意摄像机推上来的RTP流一般都是PS封装的。PS流的头部里包含了系统头、节目流映射PSM、PES包我们需要从PES包里剥离出H264或H265的NALU再以标准格式输出给播放器。难点在于国标设备在封装PS时会有差异有些设备把SPS、PPS作为PES包的私有数据带上来有些则放在RTP负载的第一个字节里解析必须足够健壮。流的开始往往会有多个PS头如果在起始的几百个字节里解析不到PSM就需要等待下一个关键帧重新同步。H265的话NALU类型在RTP头里可能带了2字节的PayloadHdr不能套用H264的单一NAL模式直接解析需要判断单位类型是NALU还是AP。我试过几款低端IPC设备有的码流里的PSM头就没有按标准更新播放器一直黑屏做了兼容处理后才正常出画面。这种兼容性工作没有捷径只能靠多测设备、多积累报文样本。3. 实操过程与核心环节实现3.1 环境准备与基础配置建议的Java运行环境是JDK 1.8以上推荐JDK 11。音频和视频编解码这块会用到FFmpeg做辅助转码但信令和媒体核心处理都在Java层不需要装额外的SIP库。启动前先修改配置文件本机IP和SIP服务端口默认5060建议自定义要保证设备能访问到这条IP和端口。媒体服务端口范围比如10000-20000这些端口需要在防火墙上放行否则媒体流进不来。数据库、Redis等中间件连接信息。设备接入的鉴权密码模式支持MD5和SHA-256两种摘要算法。对于IP地址的配置千万注意要设成对设备可见的IP。我遇到过一个案例部署环境是双网卡SIP服务绑定到了内网IP可设备在外网向映射的公网IP注册结果SIP信令能通后续的INVITE时的SDP内容里带的还是内网IP设备回传媒体流直接发到了内网导致一直看不到画面。后来改成SDP生成时动态替换成公网映射IP问题就解决了。3.2 添加一个真实的摄像头设备下面用一个海康DS-2CD3T56摄像头举例。在平台后台添加设备时填写设备的国标编号、名称、密码、所属区域。然后在设备端配置平台接入在摄像头网页后台找到平台接入或GB28181配置页填上SIP服务器ID、SIP服务器地址和端口、SIP用户ID、密码。设备保存后会立即向平台发送注册消息。平台的SIP服务收到消息后校验设备ID和密码。这里有一个容易忽略的坑很多设备的密码默认是12345而平台配置的密码也是12345但设备端做摘要鉴权时用的是H(DN)也就是把密码做MD5后再参与算法如果平台端直接拿明文密码比较永远通过不了。正确处理是拿到设备发来的Authorization头按MD5(username:realm:password)方式校验摘要值不要存明文密码比对。注册成功后平台向设备发送一条MESSAGE目录查询请求设备返回XML格式的通道列表。平台解析后把通道数据和设备关联存储可以看到在线状态变绿通道画面可以拉流预览。3.3 实时视频点播的完整流程点播流程从用户点击播放按钮开始。前端向后端请求播放后端收到请求后找到对应通道的设备和SIP信令信息组装一个INVITE请求SDP里带上本平台的媒体接收端口和SSRC发送到设备端。设备端收到INVITE后如果确认可以转发码流会回复200 OK携带设备端的SDP信息然后主动向平台发送RTP流。平台媒体服务收到RTP流后解析SSRC和PayloadType按设备编码、通道编码建立会话把PS流解封装成裸流。之后通过流媒体网关将裸流转发成RTSP流前端直接用播放器播放。整体时延在500毫秒以内画面还没有出现明显卡顿。调试这个流程时我用Wireshark同时抓SIP和RTP包。关键抓包节点有三个抓SIP信令包看INVITE请求和200 OK响应里的SDP内容是否正常。抓RTP包看设备是否在收到200 OK后向SDP里声明的IP和端口发流。看RTP包的SSRC是否和SDP里y字段一致。第2、3两点最容易出问题。有些设备无论SDP怎么写都按照自己配置的编码发流平台端要用SSRC而不是端口号来关联会话否则多条会话会串流。3.4 一次信令交互的报文分析以一个实际的注册报文为例。设备发送的REGISTER请求简化后REGISTER sip:192.168.1.100:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branchz9hG4bK34791 From: sip:14070000001320000001192.168.1.100;tag10001 To: sip:14070000001320000001192.168.1.100 Call-ID: 4520135621192.168.1.64 CSeq: 1 REGISTER Contact: sip:14070000001320000001192.168.1.64:5060 Authorization: Digest username14070000001320000001, realm192.168.1.100, nonce6e769c13, urisip:192.168.1.100:5060, response8d2f84ffbec4e36d2adc7f0a9f95d18c Content-Length: 0关注几点From和To都是设备国标编号Contact是设备实际IP和端口Authorization是摘要鉴权的核心。平台返回401后携带WWW-Authenticate头给设备一个nonce设备再用同样格式重新发一次REGISTER重试才算认证通过。我在开发调试时会把这类报文的关键信息提取出来做成日志方便对比。在JGB28181里就加了一个调试开关打开后每个SIP消息可以按time|method|from|to|status的格式打印到日志文件里排查问题时能快速锁定是哪一步异常。3.5 语音对讲的实现路径GB28181的语音对讲流程是平台向设备发送INVITESDP里带上音频编码一般是PCMA/PCMU采样率8000然后平台向设备发送音频RTP流设备解码后通过扬声器播放。这里必须注意的是早期摄像机对讲功能没有那么标准需要判断设备支持的是双向语音还是单向语音。有的设备支持双向有的只支持平台上行即只能接收平台的音频不能把设备端麦克风音频传上来。我实现时会把对讲流单独建会话不能和视频流混用音频格式统一用PCMA因为G711A的封包简单、兼容性最高很多设备走PCMU反而对讲不出声。另一个小技巧设备端对讲口的音量增益一般没有做自动处理平台推音频流的时候建议在服务端先做一次音量归一化避免推上去声音忽大忽小。4. 常见问题与排查技巧实录4.1 设备注册一直401怎么办设备总是返回401不代表失败。正确的注册流程本来就包含401挑战响应。要想验证是否成功必须看第二次REGISTER是否返回200 OK。如果第二次REGISTER也没通过先看平台日志里计算出的摘要值和设备发来的response是否一致。如果两端MD5结果始终对不上通常是密码问题。排查时可以用tcpdump抓包把Authorization头里的摘要值提取出来和平台端单独跑一次MD5计算做对比。经常被忽略的一点是设备端配置的SIP服务器ID必须和平台生成的SIP服务器ID一致。有的设备默认是34020000002000000001如果平台配置的是34020000002000000002设备侧会认为认证失败反复注册。4.2 能注册但看不了实时视频出现这个现象优先级最高的排查顺序是看设备是否收到了平台发来的INVITE请求。如果没收到检查APN和NAT映射确认信令端口在网关上的映射关系是否配好。看设备是否在回复200 OK。如果回复了看SDP里的IP和端口和平台实际等待的IP和端口是否一致。看RTP流是否真的到了平台媒体服务打开的UDP端口上。如果到了但画面黑屏重点检查PS解复用是否异常看日志里有没有PS header not found之类的报错。如果画面卡顿但能出图多半是设备码率设置过高或者RTP的JitterBuffer不够大可以把缓冲从100ms提高到300ms试一下。还有一个之前在双网卡服务器上遇到的坑很多服务会自动绑定主机名对应的IP造成SIP信令和媒体流不在同一网卡导致信令通但媒体不通。这种情况要把配置里的IP显式指定别依赖自动绑定的行为。4.3 多设备并发接入时性能瓶颈在哪里并发量最大的瓶颈通常不在SIP信令而在媒体服务的RTP接收和转发环节。SIP本身就是轻量协议即使设备数量上万信令对CPU的占用依然不高。真正吃性能的是每路视频流都要做解复用、转封装、再分发。实测下来一台4核8G的服务器纯转发不做转码的情况下能稳定跑大约50路720P码流如果做转封装加转码性能会降到20路以内。所以生产环境的设计原则是转码尽量下沉到GPU或专用流媒体服务器JGB28181负责信令和流分发。为了降低性能开销我在实现时做了两件事一是对相同码流的多个订阅者做了合并转发也就是一路设备码流同时推给多个前端播放器平台只解一次PS二是把RTP接收、PS解析、流分发做成独立线程池避免因为一路卡顿阻塞所有流。4.4 自动化测试的落地经验测试GB28181平台如果全靠真机效率太低。我的做法是用SIPp或自己写一个模拟的GB28181设备端脚本模拟注册、心跳、目录上报、录像检索、推流等行为。比如目录上报脚本可以按周期发送MESSAGE消息携带固定的XML设备树平台端就能持续收到设备信息验证数据库写入是否正常。推流测试则更简单用FFmpeg读取本地视频文件封装成PS流再按国标协议通过RTP发送到平台。自己写脚本时有两个点需要注意一是平台对SIP事务的超时时间一般设得很短比如2秒模拟设备如果回复太慢会频繁触发事务超时二是模拟脚本要把完整流程走到不能只发一个INVITE然后就不再回其他消息否则平台端会话状态会一直挂在未确认状态。JGB28181里我做了一套基于Java的设备模拟器配置好设备编号和服务器地址后可以一键启动方便联调。4.5 几个实战经验小结最后再分享几个经验不要在业务代码里处理SIP原始报文。JGB28181的信令解析和组装是独立封装的业务层只关心设备上下线、点播请求、云台控制这些语义化事件。这样改协议细节不会影响业务逻辑业务逻辑也不会干扰协议实现。所有SIP管理接口要支持批量操作。比如批量添加设备、批量发起录像检索这在对接大型项目时特别重要。我之前在线下项目里一次性添加了三千多路通道如果一条条调用后台接口能把运维同事逼疯。日志和监控一定要做细。平台跑的越久越能体会日志的重要性。每个SIP事务、每条媒体流会话都要有traceId通过一个id能把信令请求、响应、媒体流、播放日志串起来。排查问题的时间能从小时级降到分钟级。JGB28181目前还在持续维护中我后续计划补上级联功能和WebRTC接入的优化方便更多场景直接落地。如果你也在搞GB28181或者正在调研Java技术栈的视频接入方案希望这篇能给你一个相对完整的参考。有问题可以一起交流这几年的坑我基本都踩过了。本文还有配套的精品资源点击获取
基于Java的GB28181视频接入平台实现与核心细节解析
简介基于Java实现的GB28181国标平台面向安防监控与视频接入领域的开发者帮助解决设备注册、目录查询、实时视频流TCP被动/UDP等常见协议接入问题。压缩包内含49个文件以43个Java源文件为项目核心另有XML、properties、yml等配置文件及Markdown说明文档整体体积仅64KB结构紧凑、便于快速下载与本地部署。目前已有4240人学习下载适合需要参考国标协议实现或希望搭建轻量级视频接入平台的Java工程师。使用方式很简单修改config.properties中的配置后编译运行即可体验完整流程。借助精炼的代码组织可以清晰看到设备注册、目录查询、实时视频流等关键模块的调用关系为后续二次开发和协议扩展提供扎实基础。 做了几年视频接入和安防平台相关的工作中间有段时间一直在折腾GB28181的东西。一开始是拿开源C项目改后来项目要上Java技术栈干脆自己用Java撸了一个完整的GB28181平台就是JGB28181。这个项目解决的核心问题很简单把不同品牌、不同协议的摄像头和NVR统一接入到一个平台里用国标方式完成注册、直播、回放、云台控制和语音对讲。如果你正在做安防平台开发、视频接入网关或者想搞懂GB28181协议到底是怎么跑通的这篇东西应该能给你省不少时间。1. 为什么用Java写GB28181平台项目背景与选型逻辑1.1 视频接入的痛点比想象中多得多做视频接入的人应该深有体会海康、大华、宇视这些厂家的SDK各不相同每接一个新的设备型号就要重新适配。ONVIF虽然能做设备发现和媒体协商但在大规模组网、跨地域互联、平台级联这些场景下还是不够用。GB28181作为国内视频监控联网的国家标准通过SIP协议进行信令交互用RTP传输媒体流从设计上就是为了解决异构设备之间的互联互通问题。但现实是网上能找到的GB28181实现大多是C写的比如live555、osip、eXosip这些想要集成到Java后端里还得写JNI维护成本非常高。更麻烦的是C项目里对SIP信令的处理往往和媒体流处理耦合在一起想单独把信令模块抽出来做二次开发代码读起来相当痛苦。我当时的判断是如果团队本身就是Java栈用一个Java原生实现反而能少踩很多坑。1.2 选型对比别被老思路困住我评估过几种路线简单说下结论直接用eXosip/libeXosip封装的Java接口底层还是C库编译环境折腾人跨平台部署时经常遇到so库不兼容的问题。基于JAIN-SIP做二次开发JAIN-SIP只处理SIP协议栈GB28181里的SDP字段解析、设备目录查询、录像检索这些应用层逻辑还得自己写工作量不小。参考wvp-GB28181的设计思路用Java全栈实现代码可控性最强信令和流媒体分开处理后续扩展比如加WebRTC网关、加AI分析都会方便很多。JGB28181最终走了第三条路。SIP协议栈用Java原生的方式实现自己解析、自己组包媒体转发和PS流解复用也用Java搞定。这样整个项目打成一个Jar包就能跑不需要额外装任何C依赖。1.3 JGB28181的总体架构先看下项目的主要模块SIP信令服务负责设备注册、心跳、目录查询、云台控制、报警通知等信令交互。媒体服务负责RTP接收、PS流解复用、H264/H265裸流提取再把裸流转发到流媒体服务或直接推给播放器。设备管理维护设备列表、通道列表、在线状态支持级联场景下的目录推送。流媒体网关把内部媒体流以RTSP、RTMP、HLS或WebRTC方式分发出去前端播放器只需要按标准协议拉流。平台管理接口对外提供REST API方便上层业务系统调用。我们以SIP服务为例注册流程大致是设备端发送REGISTER请求SIP服务校验设备ID和密码校验通过后返回401鉴权挑战设备再次带鉴权信息注册注册成功后在内存和数据库里同时记录设备状态并启动一个定时器等待设备心跳。这个流程看起来简单但涉及的协议细节特别多下面逐个拆开说。2. 核心细节解析与实操要点2.1 设备ID和设备编码规则一开始就要约定好GB28181里每个设备、通道、平台都有20位数字编码。前8位是行政区划编码中间4位是行业编码再后面2位是类型编码最后6位是序号。比如一台摄像头的编码可能是14070000001310000001其中140700是地区0000是行业13是类型1300代表摄像机1310代表NVR后面是序号。自己搭平台时一定要把这个编码规范做成配置不要把编码逻辑写死在代码里。我在项目里遇到过一个很尴尬的情况测试设备是海康的默认编码是14070000001320000001但平台里配置的行政区划是110000结果设备注册时校验地区码不匹配直接拒绝了。后来把编码校验改成可配置的规则按实际项目情况松紧控制才解决了问题。2.2 SIP信令交互细节最容易翻车的地方GB28181的信令流程和标准RFC 3261是有区别的很多刚接触的人会按SIP标准协议去解析结果一头雾水。几个关键差异没有标准的注册成功后200 OK就完事设备端还会周期性发送MESSAGE心跳Notify平台需要响应200 OK否则设备会反复重连。目录查询用的是MESSAGE消息body里是XML格式的Query请求响应是XML格式的DeviceList响应注意SIP头的User-Agent、Content-Type、Content-Length一个都不能少。实时视频点播的INVITE请求里SDP的y字段存储的是媒体流的SSRC这个值在GB28181里是十六进制或十进制表示的字符串不少设备会在这个字段里直接写0解析时要注意兼容。历史录像回放中SDP里还带有DownloadSpeed字段控制的是回放倍速如果设备不支持加速回放这个字段传了也没用。这些细节在协议文档里都有但排错时第一反应往往是看网络抓包而不是看文档。我的建议是开发调试阶段每处理一个信令方法就录一段报文留档后面排查问题效率会高很多。2.3 媒体流格式化H264/H265私有扩展要特别留意摄像机推上来的RTP流一般都是PS封装的。PS流的头部里包含了系统头、节目流映射PSM、PES包我们需要从PES包里剥离出H264或H265的NALU再以标准格式输出给播放器。难点在于国标设备在封装PS时会有差异有些设备把SPS、PPS作为PES包的私有数据带上来有些则放在RTP负载的第一个字节里解析必须足够健壮。流的开始往往会有多个PS头如果在起始的几百个字节里解析不到PSM就需要等待下一个关键帧重新同步。H265的话NALU类型在RTP头里可能带了2字节的PayloadHdr不能套用H264的单一NAL模式直接解析需要判断单位类型是NALU还是AP。我试过几款低端IPC设备有的码流里的PSM头就没有按标准更新播放器一直黑屏做了兼容处理后才正常出画面。这种兼容性工作没有捷径只能靠多测设备、多积累报文样本。3. 实操过程与核心环节实现3.1 环境准备与基础配置建议的Java运行环境是JDK 1.8以上推荐JDK 11。音频和视频编解码这块会用到FFmpeg做辅助转码但信令和媒体核心处理都在Java层不需要装额外的SIP库。启动前先修改配置文件本机IP和SIP服务端口默认5060建议自定义要保证设备能访问到这条IP和端口。媒体服务端口范围比如10000-20000这些端口需要在防火墙上放行否则媒体流进不来。数据库、Redis等中间件连接信息。设备接入的鉴权密码模式支持MD5和SHA-256两种摘要算法。对于IP地址的配置千万注意要设成对设备可见的IP。我遇到过一个案例部署环境是双网卡SIP服务绑定到了内网IP可设备在外网向映射的公网IP注册结果SIP信令能通后续的INVITE时的SDP内容里带的还是内网IP设备回传媒体流直接发到了内网导致一直看不到画面。后来改成SDP生成时动态替换成公网映射IP问题就解决了。3.2 添加一个真实的摄像头设备下面用一个海康DS-2CD3T56摄像头举例。在平台后台添加设备时填写设备的国标编号、名称、密码、所属区域。然后在设备端配置平台接入在摄像头网页后台找到平台接入或GB28181配置页填上SIP服务器ID、SIP服务器地址和端口、SIP用户ID、密码。设备保存后会立即向平台发送注册消息。平台的SIP服务收到消息后校验设备ID和密码。这里有一个容易忽略的坑很多设备的密码默认是12345而平台配置的密码也是12345但设备端做摘要鉴权时用的是H(DN)也就是把密码做MD5后再参与算法如果平台端直接拿明文密码比较永远通过不了。正确处理是拿到设备发来的Authorization头按MD5(username:realm:password)方式校验摘要值不要存明文密码比对。注册成功后平台向设备发送一条MESSAGE目录查询请求设备返回XML格式的通道列表。平台解析后把通道数据和设备关联存储可以看到在线状态变绿通道画面可以拉流预览。3.3 实时视频点播的完整流程点播流程从用户点击播放按钮开始。前端向后端请求播放后端收到请求后找到对应通道的设备和SIP信令信息组装一个INVITE请求SDP里带上本平台的媒体接收端口和SSRC发送到设备端。设备端收到INVITE后如果确认可以转发码流会回复200 OK携带设备端的SDP信息然后主动向平台发送RTP流。平台媒体服务收到RTP流后解析SSRC和PayloadType按设备编码、通道编码建立会话把PS流解封装成裸流。之后通过流媒体网关将裸流转发成RTSP流前端直接用播放器播放。整体时延在500毫秒以内画面还没有出现明显卡顿。调试这个流程时我用Wireshark同时抓SIP和RTP包。关键抓包节点有三个抓SIP信令包看INVITE请求和200 OK响应里的SDP内容是否正常。抓RTP包看设备是否在收到200 OK后向SDP里声明的IP和端口发流。看RTP包的SSRC是否和SDP里y字段一致。第2、3两点最容易出问题。有些设备无论SDP怎么写都按照自己配置的编码发流平台端要用SSRC而不是端口号来关联会话否则多条会话会串流。3.4 一次信令交互的报文分析以一个实际的注册报文为例。设备发送的REGISTER请求简化后REGISTER sip:192.168.1.100:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branchz9hG4bK34791 From: sip:14070000001320000001192.168.1.100;tag10001 To: sip:14070000001320000001192.168.1.100 Call-ID: 4520135621192.168.1.64 CSeq: 1 REGISTER Contact: sip:14070000001320000001192.168.1.64:5060 Authorization: Digest username14070000001320000001, realm192.168.1.100, nonce6e769c13, urisip:192.168.1.100:5060, response8d2f84ffbec4e36d2adc7f0a9f95d18c Content-Length: 0关注几点From和To都是设备国标编号Contact是设备实际IP和端口Authorization是摘要鉴权的核心。平台返回401后携带WWW-Authenticate头给设备一个nonce设备再用同样格式重新发一次REGISTER重试才算认证通过。我在开发调试时会把这类报文的关键信息提取出来做成日志方便对比。在JGB28181里就加了一个调试开关打开后每个SIP消息可以按time|method|from|to|status的格式打印到日志文件里排查问题时能快速锁定是哪一步异常。3.5 语音对讲的实现路径GB28181的语音对讲流程是平台向设备发送INVITESDP里带上音频编码一般是PCMA/PCMU采样率8000然后平台向设备发送音频RTP流设备解码后通过扬声器播放。这里必须注意的是早期摄像机对讲功能没有那么标准需要判断设备支持的是双向语音还是单向语音。有的设备支持双向有的只支持平台上行即只能接收平台的音频不能把设备端麦克风音频传上来。我实现时会把对讲流单独建会话不能和视频流混用音频格式统一用PCMA因为G711A的封包简单、兼容性最高很多设备走PCMU反而对讲不出声。另一个小技巧设备端对讲口的音量增益一般没有做自动处理平台推音频流的时候建议在服务端先做一次音量归一化避免推上去声音忽大忽小。4. 常见问题与排查技巧实录4.1 设备注册一直401怎么办设备总是返回401不代表失败。正确的注册流程本来就包含401挑战响应。要想验证是否成功必须看第二次REGISTER是否返回200 OK。如果第二次REGISTER也没通过先看平台日志里计算出的摘要值和设备发来的response是否一致。如果两端MD5结果始终对不上通常是密码问题。排查时可以用tcpdump抓包把Authorization头里的摘要值提取出来和平台端单独跑一次MD5计算做对比。经常被忽略的一点是设备端配置的SIP服务器ID必须和平台生成的SIP服务器ID一致。有的设备默认是34020000002000000001如果平台配置的是34020000002000000002设备侧会认为认证失败反复注册。4.2 能注册但看不了实时视频出现这个现象优先级最高的排查顺序是看设备是否收到了平台发来的INVITE请求。如果没收到检查APN和NAT映射确认信令端口在网关上的映射关系是否配好。看设备是否在回复200 OK。如果回复了看SDP里的IP和端口和平台实际等待的IP和端口是否一致。看RTP流是否真的到了平台媒体服务打开的UDP端口上。如果到了但画面黑屏重点检查PS解复用是否异常看日志里有没有PS header not found之类的报错。如果画面卡顿但能出图多半是设备码率设置过高或者RTP的JitterBuffer不够大可以把缓冲从100ms提高到300ms试一下。还有一个之前在双网卡服务器上遇到的坑很多服务会自动绑定主机名对应的IP造成SIP信令和媒体流不在同一网卡导致信令通但媒体不通。这种情况要把配置里的IP显式指定别依赖自动绑定的行为。4.3 多设备并发接入时性能瓶颈在哪里并发量最大的瓶颈通常不在SIP信令而在媒体服务的RTP接收和转发环节。SIP本身就是轻量协议即使设备数量上万信令对CPU的占用依然不高。真正吃性能的是每路视频流都要做解复用、转封装、再分发。实测下来一台4核8G的服务器纯转发不做转码的情况下能稳定跑大约50路720P码流如果做转封装加转码性能会降到20路以内。所以生产环境的设计原则是转码尽量下沉到GPU或专用流媒体服务器JGB28181负责信令和流分发。为了降低性能开销我在实现时做了两件事一是对相同码流的多个订阅者做了合并转发也就是一路设备码流同时推给多个前端播放器平台只解一次PS二是把RTP接收、PS解析、流分发做成独立线程池避免因为一路卡顿阻塞所有流。4.4 自动化测试的落地经验测试GB28181平台如果全靠真机效率太低。我的做法是用SIPp或自己写一个模拟的GB28181设备端脚本模拟注册、心跳、目录上报、录像检索、推流等行为。比如目录上报脚本可以按周期发送MESSAGE消息携带固定的XML设备树平台端就能持续收到设备信息验证数据库写入是否正常。推流测试则更简单用FFmpeg读取本地视频文件封装成PS流再按国标协议通过RTP发送到平台。自己写脚本时有两个点需要注意一是平台对SIP事务的超时时间一般设得很短比如2秒模拟设备如果回复太慢会频繁触发事务超时二是模拟脚本要把完整流程走到不能只发一个INVITE然后就不再回其他消息否则平台端会话状态会一直挂在未确认状态。JGB28181里我做了一套基于Java的设备模拟器配置好设备编号和服务器地址后可以一键启动方便联调。4.5 几个实战经验小结最后再分享几个经验不要在业务代码里处理SIP原始报文。JGB28181的信令解析和组装是独立封装的业务层只关心设备上下线、点播请求、云台控制这些语义化事件。这样改协议细节不会影响业务逻辑业务逻辑也不会干扰协议实现。所有SIP管理接口要支持批量操作。比如批量添加设备、批量发起录像检索这在对接大型项目时特别重要。我之前在线下项目里一次性添加了三千多路通道如果一条条调用后台接口能把运维同事逼疯。日志和监控一定要做细。平台跑的越久越能体会日志的重要性。每个SIP事务、每条媒体流会话都要有traceId通过一个id能把信令请求、响应、媒体流、播放日志串起来。排查问题的时间能从小时级降到分钟级。JGB28181目前还在持续维护中我后续计划补上级联功能和WebRTC接入的优化方便更多场景直接落地。如果你也在搞GB28181或者正在调研Java技术栈的视频接入方案希望这篇能给你一个相对完整的参考。有问题可以一起交流这几年的坑我基本都踩过了。本文还有配套的精品资源点击获取
