刚从项目现场回来通讯调试还在我脑子里转。这次聊一个不少做安防、物联网、视讯联运的团队都会碰到的硬骨头在Android设备上实现GB28181协议接入把手机、板子、盒子变成能注册到监控平台的“前端设备”。国民级安防标准GB/T 28181在国内视频监控联网里几乎绕不开而市面上多数开源方案偏重服务端或Windows平台Android端能直接落地、还敢开源出来的项目不多SmartGBD算是一个比较完整的参考实现。SmartGBD这个模块本质就是一套跑在Android上的GB28181设备接入SDK。它解决的核心问题有三个一是让Android设备能向GB28181平台完成SIP注册与心跳保活二是能响应平台的目录查询、实时音视频点播、录像回放等信令交互三是把Android摄像头采集的画面和音频数据按照规范封装成PS流并通过RTP推送到流媒体服务器。对做安防终端、单兵设备、移动执法仪、布控球这类产品的开发者来说这个模块的源码和思路是非常值得从头到尾啃一遍的。本文直接从规范出发沿着“设备接入流程 → 模块架构 → 信令源码 → 媒体链路 → 实战排障”这条线走一遍把SmartGBD从规范到源码的关键环节拆开来讲。适合正在做GB28181接入、想搞懂协议细节、或者准备自己写Android端接入模块的开发者参考读完你会对设备接入侧要处理的所有脏活累活有个清晰的全局认识。1. 读懂GB28181接入流程先看设备侧要干哪些活很多人在Android上做GB28181接入上来就翻SIP协议栈代码结果越看越懵。其实问题不在SIP本身而是没把GB28181在整个视频监控联网体系里到底扮演什么角色搞清楚。规范的全名是《公共安全视频监控联网系统信息传输、交换、控制技术要求》说白了就是一套让不同厂家的监控设备、平台之间能互相通信的国家标准2016版是目前最常用的基线版本。1.1 接入协议的前置认知SIP与媒体流两部分GB28181的通信架构分信令和媒体两层这两层必须分开理解。信令层基于SIPSession Initiation Protocol会话初始协议。设备接入GB28181平台本质就是一台SIP用户代理UA向SIP服务器完成注册、保持在线、响应查询、接收邀请。SIP是个文本协议开发时抓包能直接看到内容比起二进制协议友好太多。但GB28181对SIP的用法做了很多裁剪和扩展比如用MESSAGE方法承载XML格式的控制命令用INFO方法上报事件这和开源的SIP协议栈默认行为有很大差异直接拿通用UA的例子是跑不通的。媒体层走的是RTP/RTCP传输PSProgram Stream节目流封装后的视音频数据。PS流是MPEG-2标准里的容器格式GB28181规定H.264/H.265裸流必须先封装成PS流再切成一个个RTP包发送。规范里对PS头、系统头、节目流映射PSM、PES包的字段都有明确要求平台侧解复用时会按这些字节结构硬解析一个字段错位都可能导致画面黑屏。所以SmartGBD的代码里你会看到它有两套完全独立的技术栈在跑信令侧是SIP消息解析、XML报文处理、摘要认证媒体侧是H.264/H.265码流解析、PS封装、RTP组包。这两套栈通过“会话管理”粘合在一起比如收到INVITE请求后信令层解析出媒体参数和端口媒体层开始采集编码推流两侧协同工作。1.2 设备接入的核心交互链路把SmartGBD的运行流程走一遍基本就是国标设备接入的标准时序设备启动后构造SIP REGISTER请求发往平台服务器完成注册鉴权。注册成功后周期性发送MESSAGE消息实现心跳保活默认60秒一次。平台下发目录查询请求设备返回自身编码、名称、通道列表等XML信息。平台发起INVITE请求携带SDP媒体参数邀请设备推流。设备回复200 OK然后立即开始采集编码、封装PS流、通过RTP推送到平台指定地址和端口。平台发送BYE请求设备停止推流并释放资源。这串流程里隐藏了很多细节Android端尤其容易踩坑。比如注册鉴权时平台返回401后要求带Authorization头摘要算法用的用户名和密码怎么拼接规范里有严格规定比如心跳消息里虽然允许为空但很多平台侧要求带设备ID才算合法再比如收到INVITE后回复200 OK的SDP里必须包含ssrc、sps/pps等信息且要和后续推流的实际编码参数完全一致否则平台解码器会起不来。SmartGBD的代码把这套交互流程做成了明确的状态机未注册、注册中、已注册、会话中。每个状态下能接收哪些SIP消息、应该回复什么都有对应处理分支。我读源码时一个很深的体会是这个状态机不仅是为了代码清晰更是为了处理实践中的异常场景——比如注册失效后平台突然发来INVITE设备必须能正确拒绝或者先重新注册再响应。2. SmartGBD模块架构一个Android工程里如何组织这么多功能GB28181设备接入模块涉及的子功能非常多如果一股脑堆在Activity或Service里代码很快会腐烂。SmartGBD在架构上的处理思路值得学习它把整个模块拆成了多个独立层次每一层只做一件事层与层之间通过接口通信。2.1 模块分层思路从整体上看SmartGBD分成了四层协议层负责SIP消息的编解码、XML报文的组装与解析、SDP媒体的解析与生成。这一层不依赖Android系统API上层可以直接用Unit Test跑用例。服务层核心调度逻辑所在。管理注册状态机、维护心跳定时器、接收平台请求并分发到对应处理器、维护媒体会话生命周期。媒体层负责摄像头/麦克风采集、编码器配置、码流读取、PS封装、RTP打包发送。这层使用Android的Camera2、AudioRecord、MediaCodec以及Socket接口。接口层向外暴露像register()、unregister()、startPushStream()、stopPushStream()这类简单的方法。分层带来的直接好处是协议层可以独立验证。比如SIP消息解析这段逻辑在手机端调试时要抓日志看raw报文在PC上可以直接写个小程序解析同一段文本。服务层不关心底层是Wi-Fi还是4G只关心有没有可用网络。媒体层替换编码器配置时也不影响信令逻辑。SmartGBD服务层用的是单线程消息队列模型所有信令消息注册响应、平台请求、心跳超时都通过Handler投递到同一个Looper线程按序处理。这样设计避免了多线程并发修改状态机的竞态问题代价是消息吞吐量有上限但对设备接入这类低频信令场景来说完全够用。2.2 核心子模块拆解服务层内部其实还可以再往细拆几个关键子模块各有各的职责。注册会话模块维护当前注册状态、保存服务器分配的callId和鉴权参数处理REGISTER的2xx/4xx响应计划下一次注册刷新。心跳模块独立定时器触发心跳发送发送后等待平台响应或超时重发多次超时则判定离线并触发重新注册。心跳周期是从平台下发或本地配置读取的默认60秒。目录模块维护本地设备树的数据结构设备ID、名称、厂商、通道号等处理平台发来的目录查询命令在指定SN序列号下返回对应XML。媒体协商模块解析INVITE请求里的SDP提取平台期望的编码类型、分辨率、码率、SSRC、接收IP与端口然后驱动媒体层启动推流。设备信息管理模块把设备ID、密码、网络参数、编码参数等配置项封装成配置对象供各个子模块读取。每个子模块都暴露出“状态 动作”的接口例如注册模块对外暴露onRegisterResponse(),onRegisterTimeout(),isRegistered()。这样做单元测试时就能通过模拟回调来验证复杂逻辑不需要真的连一个平台。2.3 与Android系统能力的衔接Android端接入模块的另一个关键点是怎么把系统能力嫁接到协议栈上。SmartGBD里有一个比较典型的设计独立媒体线程。摄像头采集和编码是耗时操作如果放在主线程Anr风险极大如果放在信令线程又可能阻塞后续信令处理。解决办法是专门起一条媒体线程循环从MediaCodec的输出缓冲区读取编码后的码流做封装打包信令线程只负责启动、停止这条媒体线程。音频采集也一样SmartGBD在推流时默认开启AAC编码的音频通道通过AudioRecord读取PCM数据交给MediaCodec的AAC编码器输出AAC帧。音频和视频编码器各自独立工作在PS封装时由封装线程统一带上时间戳和PTS。这个设计最需要注意的是音视频同步问题SmartGBD的处理是以视频帧的PTS为基准音频帧PTS向视频对齐尽量保证唇音同步。Android系统对麦克风和摄像头权限有严格要求SmartGBD的接口层在启动推流前会先检查权限状态权限未授予时不能启动媒体线程。另外Android前台服务也需要在长推流场景下开启通知否则系统会在后台限制采集能力。这些虽然不属于GB28181规范范畴但在实际产品化时都是绕不开的工程问题。3. 关键源码实现从注册到心跳的信令细节信令是设备接入的第一关。SmartGBD的SIP实现没有引入重量级框架而是自己维护了一套轻量级SIP栈。这套栈核心数据结构是SipMessage每个消息对应一个请求行/状态行、若干头部字段和可选的body。文本解析基于String操作Android环境里性能压力不大胜在逻辑可控。3.1 SIP注册请求的构造与平台校验逻辑以注册为例看一段精简的请求构造代码片段SipMessage registerRequest new SipMessage(REGISTER, sipServerUri); registerRequest.addHeader(From, sip: deviceId localIp ); registerRequest.addHeader(To, sip: deviceId localIp ); registerRequest.addHeader(Contact, sip: deviceId localIp : localSipPort ); registerRequest.addHeader(Call-ID, callId); registerRequest.addHeader(CSeq, String.valueOf(cSeq) REGISTER); registerRequest.addHeader(Expires, String.valueOf(registerExpires)); registerRequest.addHeader(User-Agent, SmartGBD/1.0);这段代码里有几个字段需要特别留意。From和To的URI必须填设备的20位国标编码比如34020000002000000001这个编码是设备在平台侧的唯一身份标识广播域内不能重复。Contact里要带上设备本地SIP端口平台后续下发控制命令时会回复到这个地址端口。平台收到REGISTER后如果配置了鉴权通常会返回401响应头部带WWW-Authenticate字段其中包含realm和nonce。SmartGBD收到401后需要构造Authorization头核心逻辑是String username deviceId; String realm challenge.getRealm(); String nonce challenge.getNonce(); String uri sip: sipServerIp : sipServerPort; String ha1 md5(username : realm : password); String ha2 md5(REGISTER: uri); String response md5(ha1 : nonce : ha2);这里最容易出错的是uri的构造。很多人在Android里直接用请求行里的完整地址但如果平台注册地址带传输参数比如;transportudp摘要计算时uri必须剔除传输参数。SmartGBD源码里专门做了规范化处理先用正则从uri中剥离分号后面的参数再做哈希。这一步错了就是诡异的401反复。注册成功后会收到200 OK响应里通常带Expires字段或Contact字段上的过期时间。SmartGBD会取这个值存下来注册刷新定时器按该时间的1/2进行刷新而不是死等默认3600秒。这样能适应不同平台的不同会话超时策略。3.2 心跳保活与注册有效期管理心跳保活用的不是SIP OPTIONS而是GB28181规定的MESSAGE方法消息头部和注册类似但body是一个XML。比较有代表性的XML格式如下?xml version1.0? Notify CmdTypeKeepalive/CmdType SN1/SN DeviceID34020000002000000001/DeviceID StatusOK/Status /NotifyCmdType必须严格命名为Keepalive大小写敏感SN是一次会话内递增的序号DeviceID是设备编码。平台返回的响应也是MESSAGEResponse里的CmdType同样为Keepalive但XML结构和通知不同。SmartGBD对这部分的判断逻辑是只要收到带相同SN的响应就认为本次心跳成功。注册有效期的管理直接影响在线状态。SmartGBD注册会话模块维护了两个定时器一个是注册刷新定时器按平台返回的Expires的一半时间触发重注册另一个是心跳发送定时器按心跳周期触发。比较关键的一个场景是平台重启后可能已经完全丢失设备状态设备侧如果不主动重注册就会一直处于“平台看不到但设备认为自己在线”的假在线状态。因此SmartGBD的心跳模块有个巧妙的机制连续3次心跳无响应后自动把注册状态机拉回“未注册”并立即触发重新注册流程。Android系统的休眠机制也会坑到心跳。屏幕熄屏后CPU可能进入深度睡眠Handler定时器不再准时触发导致心跳延迟。SmartGBD在工程上开了部分类型的WakeLock维持信令线程运行同时建议在应用层配置时把心跳周期适当调短比如30秒双保险。3.3 目录信息查询与上报平台查询设备目录时发送的是一条MESSAGE请求body里是QueryCmdTypeDeviceList/CmdType/Query。SmartGBD收到后需要从设备配置里读取通道列表拼装XML响应?xml version1.0? Response CmdTypeDeviceList/CmdType SN7/SN DeviceID34020000002000000001/DeviceID DeviceList Num2 Item DeviceID34020000002000000001/DeviceID Name主通道/Name ManufacturerSmartGBD/Manufacturer ModelAndroidCam/Model OwnerSelf/Owner CivilCode340200/CivilCode AddressRoom 101/Address StatusON/Status Longitude0.0/Longitude Latitude0.0/Latitude /Item /DeviceList /Response这里有个容易忽略的细节目录查询里的SN必须和请求一致否则平台会丢弃该响应。而且如果设备是级联场景响应里的DeviceList Num要和实际Item数量完全匹配。SmartGBD源码里有个校验函数专门在发送前重新统计XML中Item节点数防止因为通道动态增减导致Num字段漂移。目录上报还有两种方式一种是响应平台主动查询另一种是设备主动上报。主动上报通常在设备启动注册完成后触发或者在通道信息变化时触发。主动上报的XML同样以Response为根节点但CmdType为CatalogSn随机生成。SmartGBD同时支持这两种路径代码里共用同一个XML构造器只是调用时机不同。4. 实时音视频推流的媒体链路实现信令通了真正的考验才刚开始。Android端实时推流涉及采集、编码、封装、发送四个环节任何一个环节卡顿都会直接体现在画面延迟或花屏上。SmartGBD的媒体链路是纯自研实现没有依赖WebRTC或者FFmpeg的重封装库因此在码流字节层面的控制力很强。4.1 SDP协商从INVITE到媒体参数确定平台发起实时点播时发送的INVITE请求会在SDP里声明它期望的媒体描述。一个典型的GB28181 SDP大概这样v0 o34020000002000000001 0 0 IN IP4 192.168.1.100 sPlay cIN IP4 192.168.1.100 t0 0 mvideo 6000 RTP/AVP 96 98 97 arecvonly artpmap:96 PS/90000 artpmap:98 H264/90000 artpmap:97 MPEG4/90000 y1000000000mvideo 6000表示平台希望设备把RTP流发送到IP地址192.168.1.100的6000端口。artpmap声明了支持的编码类型PS、H264、MPEG4都是允许的但GB28181推流时实际用的几乎都是PS封装。y字段是ssrc规范里它是一个10位字符串设备端在回200 OK时需要原样带上。SmartGBD解析SDP后会综合平台能力、本地编码能力和用户配置确定最终的推流参数。比如平台声明支持96/98/97三个动态payload类型设备侧优先选96PS但如果本地编码器只输出了H.264裸流而没有封装PS的能力就需要降级到98。这种协商逻辑在代码里是一个按优先级遍历的决策函数。设备端回复200 OK时同样带SDP但asendonly并且在SDP里额外补上编码细节。H.264场景要在SDP里加上sprop-parameter-sets字段携带SPS和PPS的Base64编码这个字段平台侧解析后用来初始化解码器。如果这里不填或者填错平台解码器会起不来出现“有流无画面”的现象。4.2 PS流封装与RTP打包GB28181的媒体链路可以理解为H.264裸流 → PS流 → RTP包。PS流封装是其中最核心的一块。PS流的基本结构是若干个PS包每个PS包由PS头、可选系统头/PSM、PES包构成。PS头包含起始码00 00 01 BA系统头起始码00 00 01 BBPSM的起始码00 00 01 BCPES包的起始码00 00 01 E0。SmartGBD里对应的封装逻辑是每次收到编码器输出的一帧数据关键帧或非关键帧就构建一个完整PS包包内音频和视频PES按时间戳交错排列。H.264裸流进PES前必须转换格式。Android MediaCodec输出的是Annex-B格式带00 00 00 01起始码可以直接打包。如果是AVCC格式长度前缀就需要先转换成Annex-B。PES头里要填PTS和DTS单位是90kHz时钟。SmartGBD计算时间戳的做法是记录编码器输出的bufferInfo.presentationTimeUs这是微秒单位转换成90kHz单位时乘以9即pts90k presentationTimeUs * 9。25fps视频每帧的PTS间隔正好是3600个90kHz单位这个数字会在RTP时间戳里同样使用。RTP打包时因为PS包通常比较大一帧视频可能几十KBSmartGBD做了RTP分片。做法是把PS包按MTU比如1400字节切割每个分片放进一个RTP包的载荷里RTP头中的Marker位用于标记最后一个分片时间戳字段填该帧的90kHz PTS。平台侧收到后先缓存分片按Marker位组装完整PS包再送解码。4.3 Android端采集编码链路的工程实现采集编码链路的选择直接影响推流质量和延迟。SmartGBD视频采集使用Camera2的CameraCaptureSessionImageReader分辨率默认取1280x720这个分辨率和码率配置在低端手机上也能有不错的表现。摄像头输出的YUV数据直接通过Surface提供给MediaCodec的输入避免了一次YUV拷贝的开销。编码器选择video/avc码率控制用VBR模式关键是帧率基线25fps关键帧间隔设置为2秒——GB28181平台录像检索依赖关键帧如果间隔太长平台回放起播会变慢。MediaCodec编码器输出的H.264码流里SPS和PPS不是每帧都带的只在关键帧前后出现。而GB28181媒体协商要求的SDP参数需要SPS/PPS所以SmartGBD有个绑定操作在编码器启动后读取第一个关键帧的bufferInfo用MediaFormat的KEY_LEVEL和KEY_PROFILE配合码流数据解析出SPS和PPS字节做Base64编码后在SDP回复中携带。这个解析逻辑不能只靠MediaFormat因为MediaFormat返回的是解码后Level/Profile的数值而不是原始字节。实际做法是从输出码流里抓取起始码位置解析NALU类型为7SPS和8PPS的数据块。音频链路相对简单AAC编码器输出的是ADTS格式或原始AAC格式PS封装时只需要一个AAC音频PES。GB28181规定音频编码优先G.711和AACSmartGBD做了双兼容本地配置选哪种就封装哪种。推流Socket用的是UDP。SmartGBD在发送时维护了一个简单拥塞控制发送成功后记录当前时间戳如果发现最近1秒内发送的数据量超过链路带宽估算值就主动丢帧优先丢非关键帧避免在弱网下同时丢掉关键帧导致平台解码器长时间黑屏。这个策略虽然不符合实时传输的严谨模型但在工程上非常实用大大提升了弱网环境下的可用性。5. 实操中的常见问题与排查经验读源码和自己动手跑中间隔着无数个坑。拿SmartGBD在几款手机和平板上实测的经验来看信令问题、媒体问题、平台兼容问题三类最突出。下面把这几年踩过、也帮别人排查过的问题整理出一份可用的排障速查。5.1 注册与信令常见问题问题现象可能原因快速排查手段注册一直返回401密码错误/摘要uri带参数/时区导致nonce过期抓包看WWW-Authenticate核对密码和computeNonce逻辑注册成功但平台收不到心跳心跳XML格式错误/ID不匹配/平台要求带扩展字段用PC端SIP抓包对比平台解析日志注册成功后很快掉线注册有效期处理不当/没有按时刷新看设备侧有没有发新的REGISTER服务器侧检查会话超时时间Android息屏后信令停止CPU休眠Handler不准时检查WakeLock策略长推流需绑定前台服务最常见也最坑的是摘要认证计算。很多平台返回401时nonce里会带时间戳信息设备侧必须用同一个nonce在规定时间窗口内完成响应。SmartGBD在遇到401时会立即把平台返回的realm、nonce暂存并在下一次请求的Authorization头里使用。如果代码里把nonce当成固定值写死在不同平台间切换一定会出问题。另外部分平台要求Authorization里的username必须是设备ID前8位或完整20位需要按平台文档灵活处理。5.2 推流与媒体常见问题问题现象可能原因快速排查手段平台显示“正在请求视频”但不出画SDP里sprop-parameter-sets缺失/错误抓设备侧SDP报文用Base64在线解码校验SPS画面花屏或绿屏PS封装字段错位/RTP分片被丢弃在PC端用Wireshark解析RTP载荷检查PS头结构延迟越来越大发送端码率控制失效/缓冲积压检查UDP socket发送缓冲区和丢帧策略是否生效音频无声或杂音AAC采样率与PS里声明的不同步核对AudioRecord采样率和MediaCodec配置一致平台接收不到RTP流端口防火墙/SDP里的接收地址填错用nc或Wireshark在服务器侧监听UDP端口这里要特意强调一下PS头的program_mux_rate字段。有些平台对这个字段做了严格的范围检查SmartGBD默认写成1280000bps如果平台侧报错说PS头无效可以先检查这个字段是否被自己改动过。还有RTP的SSRCGB28181规定用SDP里y字段的值但部分老平台对SSRC的变化很敏感如果端侧中途因为重协商改了SSRC平台可能一直不出画面。5.3 工程化落地建议基于对SmartGBD源码的梳理和实际项目改造经验给计划把GB28181接入模块放到正式产品里的团队几个建议。第一个建议是把配置项全部集中化。设备ID、服务器地址、端口、密码、心跳周期、注册有效期、音视频编码参数、推流分辨率、码率上限都要做成可配置项最好能走远端下发。实际连过几十套平台后会发现不同平台的默认参数兼容性很差比如有的平台要求心跳60秒、有的要求30秒有的平台视频码率不能超过2Mbps否则不予收流。把参数集中管理能减少大量现场调试成本。第二个建议是信令和媒体链路加日志审计。SmartGBD源码里已经有了关键节点的log输出但实际产品还要再加强每次SIP消息收发都记录完整报文每次推流启动记录协商参数每次异常断开记录状态机跳转路径。很多线上问题靠现象根本看不出原因完整的日志回溯是排查效率最高的手段。第三个建议是做好网络切换处理。移动设备在Wi-Fi和4G/5G之间切换时IP地址会变化SIP的Contact字段里携带的旧IP会失效。SmartGBD处理这个问题的思路是监听网络变化广播如果发现注册链路使用的网络已断开立刻触发重新注册并更新本地IP。这套逻辑也要配合心跳失败快速重试机制否则平台侧会长时间显示设备离线。第四个建议是注意编解码器兼容性。Android碎片化带来一个普遍问题不同芯片平台高通、联发科、海思等的硬编H.264码流在SPS细节上有微小差异。有的平台对SPS的某些扩展字段敏感可能会出现只有特定手机能推流成功的情况。建议在SDK内部做一次SPS/PPS的标准化重写——把SPS里冗余的extend字段清理掉只保留核心参数可以显著提升平台兼容性。结尾我自己的实践体会是GB28181设备接入模块的难度不在单个技术点而在把协议规范翻译成能应对真实网络环境、真实平台差异的工程代码。SmartGBD最值得学习的不是某一行的算法而是它把规范中的“必须”、“宜”、“不应”变成一个个可测试、可观测、可退避处理的代码分支。看一遍源码之后建议你找一台海康或大华的模拟平台把注册、推流、录像回放全流程跑一遍很多源码里读不懂的设计到抓包那一刻就全通了。最后再分享一个小技巧调试GB28181接入时准备一台PC装Wireshark过滤条件直接写sip || rtcp || rtp分类看报文时间戳。信令问题只看SIP媒体问题重点看RTP的seq与ts连贯性。这套方法用熟了排查速度比看日志快一个数量级。