刚从项目现场回来，通讯调试还在我脑子里转。这次聊一个不少做安防、物联网、视讯联运的团队都会碰到的硬骨头：在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的通信架构分信令和媒体两层，这两层必须分开理解。
信令层基于SIP（Session Initiation Protocol，会话初始协议）。设备接入GB28181平台，本质就是一台SIP用户代理（UA）向SIP服务器完成注册、保持在线、响应查询、接收邀请。SIP是个文本协议，开发时抓包能直接看到内容，比起二进制协议友好太多。但GB28181对SIP的用法做了很多裁剪和扩展，比如用MESSAGE方法承载XML格式的控制命令，用INFO方法上报事件，这和开源的SIP协议栈默认行为有很大差异，直接拿通用UA的例子是跑不通的。
媒体层走的是RTP/RTCP，传输PS（Program 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里直接用请求行里的完整地址，但如果平台注册地址带传输参数（比如;transport=udp），摘要计算时uri必须剔除传输参数。SmartGBD源码里专门做了规范化处理，先用正则从uri中剥离分号后面的参数，再做哈希。这一步错了就是诡异的401反复。
注册成功后会收到200 OK，响应里通常带Expires字段或Contact字段上的过期时间。SmartGBD会取这个值存下来，注册刷新定时器按该时间的1/2进行刷新，而不是死等默认3600秒。这样能适应不同平台的不同会话超时策略。
3.2 心跳保活与注册有效期管理
心跳保活用的不是SIP OPTIONS，而是GB28181规定的MESSAGE方法，消息头部和注册类似，但body是一个XML。比较有代表性的XML格式如下：
<?xml version="1.0"?> <Notify> <CmdType>Keepalive</CmdType> <SN>1</SN> <DeviceID>34020000002000000001</DeviceID> <Status>OK</Status> </Notify>CmdType必须严格命名为Keepalive，大小写敏感；SN是一次会话内递增的序号；DeviceID是设备编码。平台返回的响应也是MESSAGE，Response里的CmdType同样为Keepalive，但XML结构和通知不同。SmartGBD对这部分的判断逻辑是：只要收到带相同SN的响应，就认为本次心跳成功。
注册有效期的管理直接影响在线状态。SmartGBD注册会话模块维护了两个定时器：一个是注册刷新定时器，按平台返回的Expires的一半时间触发重注册；另一个是心跳发送定时器，按心跳周期触发。比较关键的一个场景是，平台重启后可能已经完全丢失设备状态，设备侧如果不主动重注册，就会一直处于“平台看不到但设备认为自己在线”的假在线状态。因此SmartGBD的心跳模块有个巧妙的机制：连续3次心跳无响应后，自动把注册状态机拉回“未注册”，并立即触发重新注册流程。
Android系统的休眠机制也会坑到心跳。屏幕熄屏后CPU可能进入深度睡眠，Handler定时器不再准时触发，导致心跳延迟。SmartGBD在工程上开了部分类型的WakeLock，维持信令线程运行；同时建议在应用层配置时把心跳周期适当调短（比如30秒），双保险。
3.3 目录信息查询与上报
平台查询设备目录时，发送的是一条MESSAGE请求，body里是<Query><CmdType>DeviceList</CmdType></Query>。SmartGBD收到后，需要从设备配置里读取通道列表，拼装XML响应：
<?xml version="1.0"?> <Response> <CmdType>DeviceList</CmdType> <SN>7</SN> <DeviceID>34020000002000000001</DeviceID> <DeviceList Num="2"> <Item> <DeviceID>34020000002000000001</DeviceID> <Name>主通道</Name> <Manufacturer>SmartGBD</Manufacturer> <Model>AndroidCam</Model> <Owner>Self</Owner> <CivilCode>340200</CivilCode> <Address>Room 101</Address> <Status>ON</Status> <Longitude>0.0</Longitude> <Latitude>0.0</Latitude> </Item> </DeviceList> </Response>这里有个容易忽略的细节：目录查询里的SN必须和请求一致，否则平台会丢弃该响应。而且如果设备是级联场景，响应里的DeviceList Num要和实际Item数量完全匹配。SmartGBD源码里有个校验函数，专门在发送前重新统计XML中Item节点数，防止因为通道动态增减导致Num字段漂移。
目录上报还有两种方式，一种是响应平台主动查询，另一种是设备主动上报。主动上报通常在设备启动注册完成后触发，或者在通道信息变化时触发。主动上报的XML同样以Response为根节点，但CmdType为Catalog，Sn随机生成。SmartGBD同时支持这两种路径，代码里共用同一个XML构造器，只是调用时机不同。
4. 实时音视频推流的媒体链路实现
信令通了，真正的考验才刚开始。Android端实时推流涉及采集、编码、封装、发送四个环节，任何一个环节卡顿都会直接体现在画面延迟或花屏上。SmartGBD的媒体链路是纯自研实现，没有依赖WebRTC或者FFmpeg的重封装库，因此在码流字节层面的控制力很强。
4.1 SDP协商：从INVITE到媒体参数确定
平台发起实时点播时，发送的INVITE请求会在SDP里声明它期望的媒体描述。一个典型的GB28181 SDP大概这样：
v=0 o=34020000002000000001 0 0 IN IP4 192.168.1.100 s=Play c=IN IP4 192.168.1.100 t=0 0 m=video 6000 RTP/AVP 96 98 97 a=recvonly a=rtpmap:96 PS/90000 a=rtpmap:98 H264/90000 a=rtpmap:97 MPEG4/90000 y=1000000000m=video 6000表示平台希望设备把RTP流发送到IP地址192.168.1.100的6000端口。a=rtpmap声明了支持的编码类型，PS、H264、MPEG4都是允许的，但GB28181推流时实际用的几乎都是PS封装。y=字段是ssrc，规范里它是一个10位字符串，设备端在回200 OK时需要原样带上。
SmartGBD解析SDP后，会综合平台能力、本地编码能力和用户配置，确定最终的推流参数。比如平台声明支持96/98/97三个动态payload类型，设备侧优先选96（PS），但如果本地编码器只输出了H.264裸流而没有封装PS的能力，就需要降级到98。这种协商逻辑在代码里是一个按优先级遍历的决策函数。
设备端回复200 OK时，同样带SDP，但a=sendonly，并且在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 BB，PSM的起始码00 00 01 BC，PES包的起始码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包通常比较大（一帧视频可能几十KB），SmartGBD做了RTP分片。做法是把PS包按MTU（比如1400字节）切割，每个分片放进一个RTP包的载荷里，RTP头中的Marker位用于标记最后一个分片，时间戳字段填该帧的90kHz PTS。平台侧收到后先缓存分片，按Marker位组装完整PS包再送解码。
4.3 Android端采集编码链路的工程实现
采集编码链路的选择直接影响推流质量和延迟。
SmartGBD视频采集使用Camera2的CameraCaptureSession+ImageReader，分辨率默认取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类型为7（SPS）和8（PPS）的数据块。
音频链路相对简单，AAC编码器输出的是ADTS格式或原始AAC格式，PS封装时只需要一个AAC音频PES。GB28181规定音频编码优先G.711和AAC，SmartGBD做了双兼容，本地配置选哪种就封装哪种。
推流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默认写成1280000（bps），如果平台侧报错说PS头无效，可以先检查这个字段是否被自己改动过。还有RTP的SSRC，GB28181规定用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连贯性。这套方法用熟了，排查速度比看日志快一个数量级。
