简介面向移动开发者的公网对讲与国标视频监控融合方案以完整工程形式提供适合需要快速搭建轻量级对讲平台、接入国标视频监控或开展WebRTC语音视频通话二次开发的团队与个人。方案覆盖安卓公网对讲机、平板和嵌入式设备兼容大屏触控与小屏按键机型。压缩包内共1732个文件约79.22MB代码以Java、C、C#为主搭配XML配置、PNG与WEBP界面素材、so动态库及WAV、MP3音频便于按模块拆解对讲协议、国标注册流程和媒体传输逻辑。目前已有155人学习下载具备一定参考热度。资源不仅提供可运行的服务端与多端客户端还附带了WebRTC通话模块和国标平台对接示例目录划分清晰可帮助开发者缩短选型与原型验证周期也有利于在此基础上扩展SIP对讲和警用数字集群融合通讯等后续能力。1. 公网对讲如何绕过传统专网限制直连GB28181平台过去做公网对讲一般只解决语音通道和视频监控完全是两张皮。仓库、工地、应急现场往往既要有对讲机又要装一套NVR两个系统独立运行调度员只能一边听对讲一边盯监控。这个项目要解决的正是这个问题把Android公网对讲机包括大屏触屏、小屏按键、平板和嵌入式终端直接注册到GB28181标准视频监控平台让音频对讲和视频流走同一条国标链路。它轻量能跑在企业局域网、公网甚至基站环境下适合物业调度、铁路巡检、应急演练这类需要语音与视频联动的场景。我拆完这套源码后发现整个系统的核心不是“对讲”本身而是WebRTC与GB28181之间的信令和媒体接入设计。2. WebRTC模块拆解从peer_connection_factory到audio_device_module2.1 PeerConnectionFactory初始化顺序决定连接成功率先看C侧的WebRTC代码。peer_connection_factory.cc是创建整个呼叫链路的入口。在Android端调用时必须先初始化网络线程、信令线程和工作线程再创建PeerConnectionFactory。如果顺序反了就会出现ICE状态一直卡在“new”这类诡异问题。// Java层使用PeerConnectionFactory的典型初始化 PeerConnectionFactory.initialize( initializationContext, new PeerConnectionFactory.Options() .setNetworkIgnoreMask(...) ); PeerConnectionFactory factory PeerConnectionFactory.builder() .setAudioDeviceModule(audioDeviceModule) .setVideoEncoderFactory(defaultVideoEncoderFactory) .createAudioDeviceModule() .createPeerConnectionFactory();setAudioDeviceModule是公网对讲机上最关键的注入点。传统Android手机有扬声器、耳机、蓝牙而按键对讲机只有一颗受话器和一个功放默认的audio_device_module.cc会枚举多个设备导致啸叫。我替换成只暴露“听筒”和“麦克风”两个逻辑设备的实现再用setNetworkIgnoreMask过滤掉不需要的网卡。networkIgnoreMask按位设置0保留默认1忽略Wi-Fi2忽略蜂窝4忽略以太网。对讲机通常只走蜂窝或Wi-Fi我会用setNetworkIgnoreMask(6)同时忽略蜂窝和以太网强制走Wi-Fi避免基站回传时选错网卡。2.2 audio_device_module.cc把系统的音频路由藏起来audio_device_module.cc在这里的作用是提供稳定的PCM数据源。公网对讲机按下PTT时App要立刻打开麦克风采集并编码松开时马上停止。问题在于系统音频焦点和MODE_IN_COMMUNICATION的切换延迟直接调用会使前几十毫秒出现“咔哒”声。我在采集线程里加了一个预开启缓冲在PTT按下前200ms就初始化AudioRecord但不发射数据按下时通过writeIndex偏移让媒体流从中间开始冗余数据直接截断。这个方案的关键是把音频路由控制在App层而不是交给系统。系统路由一旦切到喇叭WebRTC的回声消除模块会以为是免提场景误伤近端语音。对讲机外接手咪时更要把setSpeakerphoneOn(false)写死否则手咪的麦克风收不到远端声音。2.3 android_network_monitor.cc基站回传场景的网卡选择android_network_monitor.cc负责网络类型变化通知。Android公网对讲机插的是物联网卡经常走APN专网。运营商的基站回传环境下IP是内网地址经过NAT才到公网服务器。如果直接用系统默认网络iceCandidate会附带内网IP对端无法连接。我的做法是禁用WebRTC自带的网络监控自己用Socket探测服务器可达性然后强制把网卡绑定到已连通的网络。# 查看当前默认网络路由 ip route show # 禁用某一网络接口上的WebRTC探测 adb shell settings put global captive_portal_mode 0captive_portal_mode改为0只是让系统不检测Wi-Fi的门户认证避免它频繁切换网络。真正要做的还是在代码里监听onNetworkStatusChanged用ConnectivityManager.bindProcessToNetwork绑定到已经通了的蜂窝网络。绑定后WebRTC产生的Socket都会走这条链路ICE的server-reflexive地址才会是正确的公网映射。2.4 video_encoder_wrapper.cc给GB28181复用的H.264出口video_encoder_wrapper.cc有意思的地方是它把WebRTC的VideoFrame转成了H.264裸流。GB28181平台要求的不是普通RTP媒体而是PS封装里的H.264码流。我通过实现一个内部回调把编码器输出的每帧数据直接打入PS封装器省去了二次解码。注意编码参数Profile必须设成Baseline部分国标平台不支持MainProfile关键帧间隔GOP设成2秒或4秒不能像WebRTC默认那样根据带宽动态调否则平台录像会花屏或无法seek。模块文件职责对讲机场景的改动重点peer_connection.ccICE状态机、编解码协商固定STUN服务器关闭mDNS候选android_network_monitor.cc网络类型变化通知基站回传时屏蔽Wi-Fi扫描audio_device_module.cc音频采集/播放抽象替换为单设备实现预开启缓冲video_encoder_wrapper.cc视频编码封装强制Baseline、固定GOP3. Android公网对讲机多形态适配触屏、按键、平板与嵌入式3.1 触屏机型的PTT事件分发从onTouch到KeyEvent大屏触屏对讲机比如7寸以上工业平板操作逻辑与手机类似但有个特殊点用户习惯屏幕上有明显的“按住说话”按钮同时实体侧键也要能触发PTT。在Android里要同时监听OnTouchListener和KeyEvent。override fun dispatchKeyEvent(event: KeyEvent): Boolean { if (event.keyCode KEYCODE_TALK event.action KeyEvent.ACTION_DOWN) { startPushToTalk() return true } if (event.keyCode KEYCODE_TALK event.action KeyEvent.ACTION_UP) { stopPushToTalk() return true } return super.dispatchKeyEvent(event) }KEYCODE_TALK是Android 4.4以后出现的按键码部分对讲机固件不会上报需要从/proc/bus/input/devices里解析自己的按键上报值。我见过最坑的是设备把PTT映射成KEYCODE_F1导致只能在全屏Activity里收到事件弹窗或悬浮窗就失灵。解决办法是注册一个Kiosk模式的DeviceAdminReceiver把输入焦点固定在自己进程上再通过WindowManager.addView做全局PTT浮层。3.2 小屏按键机型的方向键导航与音频路由小屏幕按键机型通常只有2.4寸屏没有触摸。整机运行Android系统但锁定了触摸事件。这类机器要把App的导航方式改成方向键确认键。更重要的是音频手机用扬声器外放对讲机则用内置蜂鸣器或手咪。要在AudioManager里设置setSpeakerphoneOn(false)并设定MODE_IN_COMMUNICATION否则系统会把音频投到喇叭而不是听筒。AudioManager am (AudioManager) getSystemService(Context.AUDIO_SERVICE); am.setMode(AudioManager.MODE_IN_COMMUNICATION); am.setSpeakerphoneOn(false); // 强制走听筒/手咪MODE_IN_COMMUNICATION会让系统启用降噪和回声消除这和WebRTC的音频处理模块有点重叠。如果两边都开着AEC声音会发闷。标准做法是WebRTC里关闭软件AEC只靠硬件DSP。按键机型的麦克风通常灵敏度低还需要在AudioRecord里把bufferSizeInBytes设成双倍分片否则编码线程会被拉长PTT按下后延时感明显。3.3 安卓平板的双摄与多窗口调度安卓平板在项目里是调度台形态屏幕同时显示GB28181视频画面和对讲联系人列表。Android原生Split Screen或PiP会切走Activity造成WebRTC重新negotiation。我的做法是把对讲和视频放同一个Activity的不同Fragment里用WindowInsets控制尺寸变化。摄像头切换要注意GB28181平台一般只支持一路主码流平板前置摄像头用于本地视频通话后置用于监控推流同时工作时要确认硬件编码器是否支持两个实例。平板通常有多个麦克风系统默认拾音会采集到环境噪声。我建议在视频监控推流时关闭语音只做视频语音对讲时再打开音频设备模块里的麦克风。否则扬声器播出的调度指令会被后置麦克风重新采集形成多处回声。处理方式是监听MediaCodec的INFO_OUTPUT_FORMAT_CHANGED在视频流稳定后主动释放音频会话。3.4 嵌入式Linux与裁剪Android的编码器适配嵌入式公网对讲机往往是定制Android主板内存512MB甚至更低没有GPU。视频编码要靠硬核VPU而GB28181推流要求H.264。在这类板子上不要用MediaCodec默认编码器要找厂家提供的libOMX_*.so。同时去掉SurfaceView直接用MediaCodec.createInputSurface()来做编码画面数据从相机直接走不需要渲染。设备形态屏幕主要适配点常见坑大屏触屏7寸以上UI布局、侧键映射弹窗焦点被抢小屏按键2-4寸方向键导航、音频路由按键码不标准安卓平板10寸多窗口模式、双摄切换麦克风阵列回声嵌入式无屏/串口屏VPU编码、内存优化系统裁剪导致硬解不可用嵌入式Linux终端更麻烦需要自己编译WebRTC静态库并处理android_network_monitor.cc里的netlink通知。我一般会先跑一遍项目的gradlew.bat脚本拿到底层so再在external/目录下打补丁。用adb shell dumpsys media.codec能看到硬件编码器列表如果列表为空说明VPU驱动没加载先解决驱动再调应用。4. GB28181注册与音视频推流参数实战4.1 SIP注册与设备ID编码GB28181的注册流程和SIP协议类似。终端要发REGISTER请求Authorization字段用MD5摘要。很多开发者直接用OkHttp发HTTP但GB28181走UDP或TCP的SIP不是HTTP。项目里实现了一个精简的SIP栈只处理REGISTER和MESSAGE。初次注册时用REGISTER sip:platformip:port SIP/2.0。import hashlib def digest(server_realm, nonce, username, password, method, uri): ha1 hashlib.md5(f{username}:{server_realm}:{password}.encode()).hexdigest() ha2 hashlib.md5(f{method}:{uri}.encode()).hexdigest() return hashlib.md5(f{ha1}:{nonce}:{ha2}.encode()).hexdigest()server_realm和nonce来自平台返回的401响应。注意设备ID编码国标要求20位数字编码前10位是行政区划编码后10位是设备类型加序号。如果设备ID不对注册会一直401或200 OK但无后续。我排查过很多次都是因为把设备ID当成随意字符串填进去。一个可行的设备ID示例是34020000001320000001前10位3402000000代表海康默认域后面依次是类型和序号。4.2 音视频编码与PS封装参数GB28181的视频流要在RTP上封装PS流。音频用G.711A或G.711U视频用H.264。下表是我在局域网站点调通的参数组合公网和基站场景会略有调整。参数推荐值说明H.264 ProfileBaseline平台兼容性最好分辨率640x480 / 1280x720公网对讲机码率有限720p足够帧率25fps / 15fps应急场景不需要60fpsGOP2s太大录像seek慢太小码率波动音频编码PCMA 8000Hz 16bit国标标准不要用OPUS传输协议RTP over UDP基站场景优先UDP局域网可用TCP注意音频编码WebRTC默认用OPUS但GB28181平台很多不支持必须转成PCMA。我在audio_device_module.cc里加了重采样和编码器把16kHz的OPUS换成8kHz的PCMA再塞进PS封装。最初转换时不做丢包补偿通话偶发“咔哒”后来加了jitter buffer才稳定。PS封装头里的PTS和DTS也要换算成90kHz时基否则平台录像时间轴会错位。4.3 NAT穿透与保活机制企业局域网内对讲终端到国标平台之间通常可以传TCP丢包少。基站或公网环境运营商NAT会限制UDP映射时间GB28181的RTP流可能断流。我一般会把SIP信令走TCP但RTP走UDP并在Contact头里额外注册一个备用地址。# 查看NAT映射表Linux服务器上 conntrack -L | grep udp对于基站链路要在终端侧设置KeepAlive间隔而不是只靠Expires。国标注册过期时间建议120秒但同时要在会话里每60秒发一个keepalive。如果把keepalive放大了NAT会在5分钟级别断开通话瞬间卡死。保活消息可以是一个空MESSAGE或OPTIONS关键是要触发平台回一个事务响应这样NAT映射会被双方刷新。4.4 局域网/基站部署的抓包验证部署时最容易踩的坑是SIP信令通了但媒体流方向不对。我习惯在平台服务器上抓包tcpdump -i eth0 -s 0 -w gb28181.pcap udp port 5060 or udp port 20000然后打开抓到的文件首先看平台是否回了200 OK然后看是否有INVITE或SUBSCRIBE。如果只有REGISTER后面没有媒体协商说明平台没有找到对应通道。再看RTP的SSRC是否和SIP里的SDP一致。很多平台严格要求SSRC等于设备ID的十进制后四位不一致时直接丢包。5. 向SIP与PDT融合演进架构预留与验证方法这个项目的设计目标并不止于GB28181后续还要支持SIP对讲平台以及和PDT警用数字集群融合通讯。我在代码里看到一层“统一呼叫抽象”把所有呼叫类型都封装成StartSession/EndSession这为扩展留下了清晰的接口。新增SIP协议时只需要实现协议适配器把SIP的INVITE映射到统一接口同样的PDT融合通过窄带网关把语音转成PCM再塞进对讲的音频通道。PDT的语音编解码格式和PCMA差异很大直接接入会产生大量噪声。正确做法是PDT网关侧先做窄带到宽带的转码转成PCMA后进入GB28181音频流。我在项目中预留了一个AudioBridge接口专门处理不同协议的音频互联。如果要做PDT融合建议加一台独立的转码服务器不要让Android终端承担转码负载否则对讲机CPU会飙高、耗电翻倍。验证是否已经为SIP/PDT预留好扩展点可以直接看项目里是否有一个service包和protocol包分离。如果协议实现和业务逻辑混在一起后续加协议必然大改。我一般会做一个最简验证写一个假的SipProtocolAdapter实现统一接口跑一轮对所有频道的呼叫看是否能正常建链和挂断。最后分享一个最直接的验证技巧。推流时在平台侧用ffprobe查看收到的码流封装ffprobe -show_packets -of csv -i capture_ps.stream | head -20看到PCMA或H264表示封装正确。如果看到OPUS说明音频没有转码平台大概率不出声。也可以用ffplay直接播放抓到的RTP流立刻能听出噪声和延迟是不是符合预期。这样不用平台调试界面也能快速定位是信令问题还是媒体问题。本文还有配套的精品资源点击获取