SIP 协议在嵌入式设备里落地最容易被低估的不是协议本身而是“把一套为通用计算平台设计的协议栈塞进只有几百 KB RAM、没有 MMU、网络环境还时好时坏的 MCU 里”。我前后在 STM32H7 和几款 Cortex-M 平台上做过基于 pjsip 的语音终端从最早的“能编译过就谢天谢地”到后来能稳定跑通注册、呼叫、双向语音中间踩的坑足够写满一个笔记本。这篇就把 pjsip 在嵌入式系统尤其是 FreeRTOS STM32H7 这类组合上的集成过程完整拆一遍重点讲清楚每个设计选择背后的原因以及那些文档里不会写、但实际调试时一定会遇到的细节。如果你手上正好有一块 H7 的板子、一个能跑通的以太网 PHY又想做一个能真正打电话的嵌入式终端那这篇内容基本可以当作一份可复现的路线图来用。我不会只给你一堆 API 名字而是把“为什么这么配”“哪里最容易翻车”“怎么验证”都讲透。1. 先想清楚为什么嵌入式端要用 pjsip而不是自己撸一套 SIP很多人第一反应是SIP 协议不就是几行文本的请求响应吗自己拼字符串发 UDP 不就行了我一开始也这么想直到真正去实现一个能用的终端才发现这个想法有多天真。1.1 SIP 远不止“发个 INVITE”SIP 表面上是一个基于文本的信令协议但一个能实际通话的终端要处理的东西包括注册与鉴权Digest 认证的 nonce、realm、qop 计算、事务状态机INVITE 事务和非 INVITE 事务的超时重传逻辑完全不同、对话Dialog管理、SDP 协商编解码、媒体端口、方向属性、以及和 RTP/RTCP 的联动。你自己拼字符串等于要把 RFC 3261 里那一大套状态机重新实现一遍而且还要保证在各种异常响应401、407、486、603下行为正确。pjsip 的价值就在于它把这些都封装好了而且它是一个分层清晰的栈pjsip是高层 SIP 用户代理层pjsip-simple处理事件订阅pjmedia负责媒体和 SDPpjlib是最底层的可移植层线程、锁、时间、socket 抽象。这个分层对嵌入式特别友好因为你可以按需裁剪——不用视频就砍掉视频相关模块不用 TLS 就关掉 OpenSSL 依赖。1.2 嵌入式场景下 pjsip 的真实优势在 MCU 上pjsip 有几个别的手段替代不了的特性。第一是它的内存池pool机制pjlib 里的pj_pool_t让所有临时对象可以一次性释放避免了碎片化——这在没有 MMU、堆只有几十 KB 的环境里是救命的。第二是它的可移植层设计pjlib把线程、互斥锁、信号量都抽象成了统一接口你只要实现或适配到 FreeRTOS 的对应原语上上层代码几乎不用改。第三是它对低功耗和弱网的容忍度事务重传、超时策略都可以通过配置调整。当然代价也很明显pjsip 默认假设你有比较充裕的内存和完整的 BSD socket。在 H7 上你需要认真做裁剪和配置否则光是静态内存占用就能把 1MB 的 RAM 吃掉一大半。1.3 什么情况下反而不该用 pjsip说句实在话如果你的需求只是“设备上报个状态、偶尔收个指令”那用 MQTT 或者简单的 HTTP 就够了硬上 SIP 是自找麻烦。pjsip 适合的是真正需要实时语音/视频会话的场景比如 IP 话机、对讲终端、门禁可视对讲、工业调度台。判断标准很简单你的设备需不需要和标准 SIP 服务器如 Asterisk、FreeSWITCH互通、需不需要处理呼叫建立/保持/转接这些完整流程。如果答案是肯定的那 pjsip 值得你花时间如果只是点对点传个音频流自己用 RTP 加个简单信令可能更省事。2. 把 pjsip 搬进 STM32H7 FreeRTOS 的工程骨架这一部分是整个集成的地基地基没打好后面调媒体一定出问题。我见过太多人卡在“编译过了但一跑就 HardFault”根因基本都在这一层。2.1 工具链与目录结构的组织方式我用的工具链是arm-none-eabi-gcc配合 Makefile 或者 CMake 管理构建。pjsip 官方支持 autoconf但交叉编译到裸机 MCU 时autoconf 那套探测基本用不上我建议直接手动组织源码目录把需要的模块挑出来编译。典型的目录结构是这样third_party/pjproject/ pjlib/ # 基础层内存池、线程、socket 抽象 pjlib-util/ # 工具DNS、STUN、XML、扫描器 pjmedia/ # 媒体SDP、RTP、编解码、音频设备抽象 pjsip/ # SIP 核心事务、对话、UA 层 pjsip-simple/ # 事件订阅可选 pjnath/ # ICE/STUN/TURN可选NAT 穿透用裁剪原则是先全带上跑通后再逐个砍。一开始就想着精简很容易因为缺了某个依赖而编译报一堆莫名其妙的错反而更费时间。等基础通话跑通再根据 map 文件里的符号占用把没用到的模块去掉。2.2 pjlib 到 FreeRTOS 的适配要点pjsip 的pjlib里有一套 OS 抽象你需要提供pj_thread、pj_mutex、pj_sem、pj_atomic等的实现。pjproject 其实自带了一个os_core_unix.c和os_core_win32.c但没有现成的 FreeRTOS 版本需要自己写一个os_core_freertos.c。核心映射关系如下pjlib 抽象FreeRTOS 对应注意事项pj_thread_createxTaskCreate栈深度要按 pjsip 需求给足建议 ≥4KBpj_mutexxSemaphoreCreateMutex注意优先级继承避免优先级反转pj_semxSemaphoreCreateCounting计数信号量用于事件等待pj_atomictaskENTER_CRITICAL或__atomicCortex-M7 可用 LDREX/STREXpj_gettimeofdayxTaskGetTickCount换算精度直接影响 RTP 时间戳这里有个特别容易踩的坑pjsip 内部大量使用“带超时的等待”比如pj_mutex_lock带 timeout 参数。FreeRTOS 的xSemaphoreTake支持超时但单位是 tick而 pjsip 传进来的是毫秒。你必须做单位换算而且要考虑 tick 频率。如果configTICK_RATE_HZ是 1000那 1 tick 1ms换算简单如果是 100那 1ms 可能不足 1 tick需要向上取整否则会出现“明明设了 100ms 超时结果 10ms 就返回”的诡异现象。2.3 内存配置pjsip 的 pool 与 FreeRTOS heap 如何共存这是嵌入式集成里最需要动脑子的一块。pjsip 有两套内存来源一是它自己的pj_pool_t从pjlib的缓存分配器拿内存二是直接pj_malloc最终走malloc/free。在 FreeRTOS 上我建议把 pjlib 的底层分配直接接到 FreeRTOS 的 heap 上也就是实现pj_malloc/pj_free时调用pvPortMalloc/vPortFree。但要注意pjsip 的 pool 会一次性申请比较大的块比如一个 pool 初始 4KB如果 FreeRTOS 的 heap 用heap_4.c碎片化风险会随运行时间上升。我的做法是给 pjsip 单独划一块静态内存区用一个简单的块分配器管理和 FreeRTOS 的系统 heap 隔离。这样即使 pjsip 那边分配出问题也不会把整个系统的堆搞崩。具体可以在pjlib的pj_pool_factory初始化时传入自定义的pj_pool_factory_policy把block_alloc和block_free指向自己的实现。配置参数上PJ_IOQUEUE_MAX_HANDLES、PJ_HAS_SSL_SOCK、PJMEDIA_HAS_VIDEO这些宏在config_site.h里定义。我常用的最小配置是关掉视频、关掉 TLS、关掉视频编解码只保留 G.711 和 G.722。这样静态占用能压到 200KB 以内不含音频缓冲。3. SIP 信令与 RTP 媒体到底怎么配合一次完整呼叫的时序拆解这是热词里被问得最多的问题——“SIP 协议和 RTP 协议怎样配合使用”。我用一次真实的 INVITE 呼叫把信令和媒体的配合关系讲清楚。3.1 从 REGISTER 到 INVITE信令阶段做了什么设备上电后第一件事是向 SIP 服务器注册。pjsip 里对应的是pjsua_acc_add加上注册标志底层会发 REGISTER服务器回 401 带 noncepjsip 自动算 Digest 响应再发一次 REGISTER收到 200 OK 后注册成功。这一步的关键是鉴权信息的正确性用户名、密码、realm、域必须和服务器配置完全一致否则会一直 401。注册成功后发起呼叫pjsip 会构造 INVITE里面带一个 SDP body。这个 SDP 就是信令和媒体的“合同”它声明了本端支持的编解码比如 PCMU/8000、媒体类型audio、传输地址IP 和端口、以及方向sendrecv。服务器把这个 INVITE 转发给被叫被叫回 200 OK 时也带自己的 SDP双方通过 offer/answer 模型协商出最终使用的编解码和地址。3.2 SDP 协商完成后RTP 才真正开始这里有个很多人搞混的点RTP 不是在 INVITE 一发出去就开始的。媒体流要等到被叫回 200 OK、主叫发 ACK 之后才建立。pjsip 在收到 200 OK 并解析完对端 SDP 后会创建媒体会话pjmedia_session启动 RTP 收发。此时on_call_media_state回调会被触发状态变成PJSUA_CALL_MEDIA_ACTIVE你才能开始往音频设备读写数据。RTP 和 SIP 的关系可以这样理解SIP 是“打电话前的沟通”负责找到对方、谈好用什么语言编解码、在哪个房间IP 端口聊RTP 是“真正开口说话”负责把声音一包一包传过去。两者用不同的端口SIP 通常 5060RTP 是动态协商的偶数端口走不同的传输层逻辑但通过 SDP 这个“合同”绑定在一起。3.3 一个容易忽略的细节RTP 时间戳与抖动缓冲RTP 包头里有序列号sequence number和时间戳timestamp。序列号用于检测丢包和乱序时间戳用于播放端做抖动缓冲jitter buffer。在嵌入式端如果你的音频采集是 20ms 一帧那时间戳每次应该增加采样率 × 0.02比如 8kHz 采样就是 160。这个值如果算错对端听到的声音会变速或者断续。pjsip 的pjmedia里自带抖动缓冲但默认参数偏保守。在局域网环境可以把PJMEDIA_JBUF_...相关参数调小降低延迟在弱网环境则要调大牺牲延迟换流畅度。我实测在 Wi-Fi 环境下把 jitter buffer 的max设成 200ms 左右比较平衡。4. 音频通路从麦克风到 RTP 包中间要过几道关信令通了、RTP 也建立了但如果音频通路没打通你听到的就是一片寂静或者刺耳噪音。这一块是嵌入式语音终端最考验功力的地方。4.1 pjmedia 的音频设备抽象与自定义实现pjsip 的pjmedia定义了一套音频设备接口pjmedia_aud_dev_factory包括open、close、start、stop、get_frame、put_frame等方法。在 PC 上它对接的是 PortAudio 或 ALSA在 MCU 上你需要自己实现一个 factory对接你的 I2S/SAI 外设和 DMA。以 STM32H7 为例音频采集通常用 SAI 或 I2S 配合 DMA 双缓冲。我的实现思路是DMA 半满和全满中断各触发一次把对应半区的 PCM 数据拷贝到一个环形缓冲区然后 pjmedia 的get_frame从环形缓冲区取数据。播放方向反过来put_frame把数据写进另一个环形缓冲区DMA 从中读取发送。这里环形缓冲区的大小和 DMA 缓冲区的匹配很关键如果 pjmedia 取数据的速度和 DMA 填充速度不匹配就会 underrun播放断音或 overrun采集丢数据。4.2 采样率、帧长与编解码的匹配G.711 的采样率是 8kHz帧长通常 20ms也就是每帧 160 个采样点。如果你的硬件采集是 16kHz 或 48kHz就需要做重采样。pjsip 自带pjmedia_resample但重采样会引入额外延迟和 CPU 开销。我的建议是尽量让硬件采集率直接匹配编解码率比如用 8kHz 或 16kHz 采集避免不必要的转换。帧长也要注意。有些音频 codec 要求特定帧长比如 G.722 常用 20msOpus 支持 2.5ms 到 60ms。帧长不一致会导致 pjsip 内部做帧重组增加延迟。统一用 20ms 是最省心的选择。4.3 回声消除与增益控制要不要开在免提场景下回声消除AEC几乎是必须的否则对方会听到自己的声音绕回来。pjsip 自带pjmedia_echo模块但它在 MCU 上的 CPU 开销不小。STM32H7 有硬件 FPU 和足够的算力跑一个轻量 AEC 是可行的但要控制滤波器长度。我一般把 AEC 的 tail length 设成 100ms 左右再长就吃不消了。增益控制AGC则要看具体硬件。如果麦克风灵敏度固定、扬声器音量固定可以不开 AGC用固定增益更稳定。如果使用环境音量变化大再考虑开。注意 AGC 和 AEC 同时开时可能互相干扰需要仔细调参。5. 调试与排错那些让我熬夜的典型问题这一节是我最想分享的部分因为这些问题在官方文档里基本找不到但实际做项目时几乎一定会遇到。5.1 注册失败从 401 到超时的排查链路注册失败是最常见的入门问题。排查顺序我总结成一条链路先看能不能 ping 通服务器确认网络层没问题再用抓包工具看 REGISTER 有没有发出去、服务器有没有回如果回了 401 但第二次 REGISTER 还是 401那就是鉴权算错了重点检查用户名密码和 realm如果压根没收到响应可能是 NAT 或防火墙挡了需要检查端口和传输协议UDP/TCP。我遇到过一个特别隐蔽的问题服务器返回的 401 里 realm 带了特殊字符而我的配置里 realm 写的是简化版导致 Digest 计算结果不匹配。这种问题只能靠抓包对比看服务器给的 challenge 和你实际用的参数是否一致。5.2 单通与双通媒体方向问题的定位方法“能打通但只有一方能听到”是媒体层的经典问题。定位方法很简单在两端分别抓 RTP 包看包有没有发出去、有没有收到。如果一端发了但另一端没收到那是网络或端口问题如果收到了但没声音那是编解码或音频设备问题。我遇到过一次单通最后发现是 SDP 里的方向属性写成了sendonly导致对端以为这边只发不收。这种问题看 SDP 原文就能发现所以养成看 SDP 的习惯很重要别只看信令是否成功。5.3 内存耗尽与 HardFault 的关联分析嵌入式端最怕的就是跑着跑着 HardFault。pjsip 在内存不足时行为可能不是优雅返回错误而是直接断言失败或者访问空指针。我的经验是先把 FreeRTOS 的configCHECK_FOR_STACK_OVERFLOW和configUSE_MALLOC_FAILED_HOOK打开让栈溢出和分配失败能被捕获。然后给 pjsip 的内存池加统计定期打印剩余量观察是否有泄漏。有一次我遇到通话几分钟后必崩最后定位到是某个回调里创建了 pool 但没有释放每次收到 RTP 包都泄漏一点累积到一定程度就耗尽。这类问题只能靠内存统计加代码审查解决。6. 性能与稳定性优化让终端能长时间跑下去跑通一次通话和稳定运行一整天中间隔着大量的优化工作。这一节讲几个我实际用过的优化手段。6.1 线程优先级与栈深度的合理分配pjsip 在 FreeRTOS 上通常会创建几个线程一个处理 SIP 信令一个处理媒体可能还有定时器线程。优先级分配的原则是媒体线程优先级要高于信令线程因为音频对实时性要求更高信令稍微延迟一点没关系。但媒体线程也不能高到把系统其他任务饿死需要留出余量给网络协议栈和看门狗。栈深度方面pjsip 的线程栈需求比一般任务大。我实测信令线程给 4KB、媒体线程给 6KB 比较稳妥。如果开了 TLS 或视频还要再加。栈不够的典型表现是随机 HardFault而且位置飘忽很难查。6.2 网络抖动下的重传与超时策略SIP 事务有标准的重传机制T1 默认 500ms超时后翻倍。在嵌入式弱网环境下可以适当调大 T1 和最大重传次数提高呼叫成功率。但也不能太大否则呼叫建立时间会很长。我的经验是 T1 设 500ms、最大重传 7 次在大多数网络下够用。RTP 层面没有重传UDP 本身不保证靠的是抖动缓冲和丢包隐藏。pjsip 的pjmedia支持简单的丢包隐藏PLC在丢包率不高时能明显改善听感。6.3 长时间运行的资源回收检查清单要让设备稳定跑几天甚至几周必须确保所有资源都能正确回收。我整理了一份检查清单每次通话结束后call 对象是否释放、媒体会话是否关闭、音频设备是否 stop、pool 是否释放、socket 是否关闭。这些在 pjsua 高层 API 里大部分是自动的但如果你用了底层 API就要自己管。另外定时器、信号量这些内核对象也要检查有没有泄漏。FreeRTOS 可以用uxTaskGetNumberOfTasks和xPortGetFreeHeapSize定期打印观察趋势。如果任务数或堆用量持续上升那一定有泄漏。7. 从能用到好用几个提升体验的进阶方向基础通话稳定之后可以考虑一些进阶功能让终端更接近商用产品。7.1 编解码选择G.711 之外的选项G.711 胜在简单、兼容性好但带宽占用高64kbps。如果带宽紧张可以考虑 G.729 或 Opus。G.729 压缩率高但专利问题要注意Opus 开源且质量好但对 CPU 要求高一些。STM32H7 跑 Opus 是可行的但要注意内存占用和实时性。我的建议是默认用 G.711 保证兼容网络条件允许时再协商更高效的编解码。7.2 与 FreeRTOS 生态的协同队列、信号量的使用pjsip 的回调是在它自己的线程上下文里执行的如果你要在回调里操作应用层的 FreeRTOS 队列或信号量要注意线程安全。我的做法是回调里只做最轻量的操作比如往队列里投递一个事件真正的处理放到应用任务里做。这样既避免了在 pjsip 线程里做耗时操作也避免了跨线程访问共享资源的竞态。7.3 固件升级与配置持久化的考虑商用终端还需要考虑配置的持久化和固件升级。SIP 账号、服务器地址这些配置通常存在 Flash 里启动时读取。升级方面可以预留一个 bootloader 分区通过服务器下发新固件。这些虽然和 pjsip 本身关系不大但在做产品时是绕不开的。我个人在实际项目里的体会是pjsip 在嵌入式端的集成难点从来不在“会不会调 API”而在于对内存、线程、实时性的整体把控。把 pjlib 的适配做扎实、把内存池管好、把音频通路的缓冲匹配好后面的事情就顺了。反过来如果这几块偷懒后面会花几倍的时间去填坑。最后分享一个小技巧在开发阶段把 pjsip 的日志级别开到PJ_LOG_LEVEL_DEBUG虽然串口会刷得很快但几乎所有问题都能从日志里找到线索比盲目抓包高效得多。等稳定后再把日志级别降下来避免影响实时性。