企业官网建设流程全解析

1. 项目缘起与整体设计思路

1.1 为什么要在嵌入式系统里跑SIP协议栈

做过VoIP终端产品的朋友应该都有体会，选协议栈这件事本身就挺让人头疼。市面上开源的SIP协议栈不少，但真正能在资源受限的MCU上跑得稳、跑得久的，掰着手指头数也就那么几个。pjsip算是其中一个比较能打的选择——它把SIP、SDP、RTP、甚至音频处理都打包好了，模块化程度高，移植起来虽然有点工作量，但一旦跑通，后续维护成本会低很多。

我这次的项目背景是这样的：需要在STM32H7平台上做一个SIP语音终端，要求能注册到SIP服务器、能发起和接听呼叫、能正常收发RTP音频流。系统跑的是FreeRTOS，网络部分用的是LwIP。选STM32H7的原因很简单，主频够高（480MHz），RAM够大（1MB SRAM + 外扩SDRAM），跑pjsip这种带音频缓冲的协议栈不会太吃力。如果换成F103那种级别的芯片，光内存就够呛。

pjsip在嵌入式场景下的核心价值在于：它把SIP信令和RTP媒体传输的复杂度封装得比较好，你不需要自己去解析SIP消息头、管理事务状态机、处理SDP协商。但代价是它的代码量不小，编译出来的库大概在300KB到500KB之间（取决于裁剪配置），对Flash和RAM都有一定要求。所以整体设计思路就是：在保证功能完整的前提下，尽可能裁剪掉用不到的特性，把资源占用压到最低。

1.2 整体架构与模块划分

整个系统的架构可以分成四层来看。最底层是STM32H7的硬件层，包括以太网MAC、DMA、音频编解码器接口（SAI/I2S）。往上是FreeRTOS和LwIP，负责任务调度和TCP/IP协议栈。再往上是pjsip的核心库，包括SIP事务层、传输层、媒体层。最上面是应用层，处理业务逻辑，比如按键触发呼叫、状态灯显示等。

pjsip本身是高度可配置的，它有一个config_site.h文件，你可以通过宏定义来开关各种特性。比如PJ_HAS_VIDEO可以关掉视频支持，PJMEDIA_HAS_SPEEX_CODEC可以关掉Speex编解码器。我的建议是：先把所有能关的都关掉，然后按需逐个打开，这样能最快定位到哪些模块是必须的。

在FreeRTOS环境下，pjsip需要适配几个关键接口：线程创建、互斥锁、信号量、时间获取。pjsip自带了一个pjlib的OS抽象层，里面有针对不同操作系统的移植文件。FreeRTOS的移植文件在pjlib/src/pj/os_core_freertos.c（不同版本路径可能略有差异），你需要根据自己用的FreeRTOS版本做适配。我用的FreeRTOS是V10.4.3，pjsip是2.13版本，适配过程中改了不少地方，后面会详细说。

1.3 方案选型中的几个关键取舍

第一个取舍是用pjsip自带的传输层还是自己实现。pjsip支持UDP、TCP、TLS等多种传输方式。在嵌入式场景下，UDP是最常用的，因为延迟低、开销小。但UDP有个问题是不保证可靠传输，SIP消息可能会丢。pjsip内部有重传机制，但需要你配置好定时器。我最终选择用UDP，因为SIP协议本身设计就是基于UDP的，TCP反而会引入额外的连接管理开销。

第二个取舍是音频编解码器的选择。pjsip默认支持G.711、G.722、iLBC、Speex等多种编解码器。G.711是最简单的，每个采样点8位，8kHz采样率，码率64kbps。它的优点是计算量极小，几乎不占CPU；缺点是音质一般。G.722是16kHz采样率，音质好很多，但计算量稍大。考虑到STM32H7的算力足够，我最终选了G.722作为主要编解码器，同时保留G.711作为备选。

第三个取舍是内存分配策略。pjsip有自己的内存池机制（pool），可以一次性分配一大块内存然后从中切分，避免频繁的malloc/free。在嵌入式系统里，我强烈建议用pjsip的内存池，而不是直接用FreeRTOS的pvPortMalloc。因为pjsip内部很多地方假设内存分配是快速的，如果用RTOS的堆分配，可能会因为碎片化导致问题。我一般会预分配一个512KB的内存池给pjsip用，具体大小根据实际需求调整。

2. 核心细节解析与移植实操要点

2.1 编译环境搭建与裁剪配置

先说编译环境。我用的工具链是arm-none-eabi-gcc，版本10.3。pjsip的编译系统是基于configure脚本的，但嵌入式交叉编译需要自己写一个config.site文件。这个文件里要指定交叉编译器前缀、目标架构、以及各种编译选项。

# config.site 示例 export CC=arm-none-eabi-gcc export AR=arm-none-eabi-ar export RANLIB=arm-none-eabi-ranlib export CFLAGS="-mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -ffunction-sections -fdata-sections" export LDFLAGS="-mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -Wl,--gc-sections"

这里有几个关键点。-mcpu=cortex-m7指定了CPU架构，-mfpu=fpv5-d16启用了双精度浮点单元，-mfloat-abi=hard表示用硬件浮点。STM32H7的FPU是双精度的，所以这些选项都能用上。-ffunction-sections和-fdata-sections配合--gc-sections可以在链接时去掉未使用的函数和数据，对减小固件体积很有帮助。

然后是config_site.h的配置。这个文件决定了pjsip编译时包含哪些特性。我的配置大概是这样：

#define PJ_HAS_SSL_SOCK 0 #define PJ_HAS_VIDEO 0 #define PJMEDIA_HAS_SPEEX_CODEC 0 #define PJMEDIA_HAS_ILBC_CODEC 0 #define PJMEDIA_HAS_G722_CODEC 1 #define PJMEDIA_HAS_G711_CODEC 1 #define PJMEDIA_HAS_OPENCORE_AMR 0 #define PJ_HAS_TCP 1 #define PJ_MAX_HOSTNAME 64 #define PJ_IOQUEUE_MAX_HANDLES 16 #define PJ_LOG_MAX_LEVEL 3

PJ_HAS_SSL_SOCK关掉SSL，因为嵌入式场景下一般不需要TLS。PJ_HAS_VIDEO关掉视频。PJMEDIA_HAS_SPEEX_CODEC和PJMEDIA_HAS_ILBC_CODEC关掉，只保留G.722和G.711。PJ_IOQUEUE_MAX_HANDLES设成16，这个值决定了同时能打开的socket数量，设太大浪费内存，设太小不够用。PJ_LOG_MAX_LEVEL设成3，只保留错误和警告日志，减少串口输出。

注意：PJ_IOQUEUE_MAX_HANDLES这个值一定要根据实际需求设置。我一开始设了32，结果发现内存占用比预期多了不少。后来改成16，完全够用。

2.2 FreeRTOS适配层的实现细节

pjsip的OS抽象层需要你实现几个关键函数。在os_core_freertos.c里，主要涉及线程、互斥锁、信号量、时间这几个部分。

线程创建这块，pjsip的pj_thread_create需要映射到FreeRTOS的xTaskCreate。但有个坑：pjsip的线程函数签名是void (*)(void*)，而FreeRTOS的是void (*)(void*)，看起来一样，但pjsip的线程函数返回后需要调用pj_thread_exit来清理资源。我的做法是在线程函数里包一层：

static void thread_wrapper(void *arg) { pj_thread_t *thread = (pj_thread_t *)arg; thread->func(thread->arg); pj_thread_exit(thread); vTaskDelete(NULL); }

互斥锁这块，pjsip的pj_mutex_create需要映射到FreeRTOS的xSemaphoreCreateMutex。但要注意，pjsip的互斥锁是可重入的，而FreeRTOS的互斥锁默认也是可重入的（通过xSemaphoreTakeRecursive），所以直接用就行。不过FreeRTOS的互斥锁有优先级继承机制，这个对实时性有帮助。

信号量这块，pjsip的pj_sem_create需要映射到FreeRTOS的xSemaphoreCreateCounting。pjsip的信号量是计数型的，初始值可以大于1。FreeRTOS的计数信号量正好满足需求。

时间这块，pjsip需要获取当前时间（pj_gettimeofday）和系统tick（pj_get_tick_count）。pj_gettimeofday可以用FreeRTOS的xTaskGetTickCount来换算，但要注意tick频率。我用的FreeRTOS tick是1000Hz，所以每个tick是1ms。pj_get_tick_count直接返回xTaskGetTickCount就行。

实操心得：FreeRTOS的tick频率建议设成1000Hz。如果设成100Hz，pjsip的定时器精度会不够，SIP重传可能会出问题。我试过100Hz，结果呼叫建立的成功率明显下降。

2.3 内存池配置与优化

pjsip的内存池机制是它的核心特性之一。每个SIP会话、每个事务、每个媒体流都有自己的内存池。内存池的好处是分配快、释放快、不会碎片化。但坏处是如果池子设小了，会分配失败；设大了，浪费内存。

我的做法是：先给pjsip一个大的全局内存池，然后在创建会话时从全局池里切分。全局池的大小我设的是512KB，具体分配如下：

这个分配不是固定的，你可以根据实际并发数调整。比如如果只需要支持2路通话，媒体流池可以减到64KB。

内存池的创建代码大概是这样：

pj_caching_pool cp; pj_caching_pool_init(&cp, &pj_pool_factory_default_policy, 512*1024); pj_pool_t *pool = pj_pool_create(&cp.factory, "global", 4096, 4096, NULL);

pj_caching_pool是pjsip提供的一种内存池缓存机制，它可以缓存之前释放的池子，避免频繁向系统申请内存。pj_pool_create创建了一个初始大小为4KB、最大可增长到4KB的池子。实际使用中，pjsip会根据需要自动扩展。

注意：pj_caching_pool_init的第三个参数是池子的最大容量。如果你设成512KB，但实际只用了256KB，剩下的256KB也不会被浪费，因为它是按需分配的。但如果你设成256KB，实际需要300KB，就会分配失败。所以建议留一定的余量。

3. 完整实操流程与核心环节实现

3.1 从零开始：pjsip在STM32H7上的编译与链接

第一步是获取pjsip源码。我用的版本是2.13，从官网下载tar.gz包。解压后进入目录，先运行configure脚本生成Makefile。但嵌入式交叉编译不能直接用默认的configure，需要指定--host参数：

./configure --host=arm-none-eabi --disable-video --disable-ssl --disable-speex --disable-ilbc

这个命令会生成一个针对arm-none-eabi的Makefile。然后运行make dep && make开始编译。编译过程中可能会报一些错，常见的是缺少头文件或者某些函数未定义。这时候需要根据错误信息调整config_site.h。

编译完成后，你会得到几个静态库：libpjlib.a、libpjlib-util.a、libpjnath.a、libpjmedia.a、libpjsip.a、libpjsip-simple.a、libpjsip-ua.a、libpjsua.a。这些库需要按顺序链接到你的工程里。链接顺序很重要，因为静态库的依赖关系是单向的。正确的顺序是：

libpjsua.a libpjsip-ua.a libpjsip-simple.a libpjsip.a libpjmedia.a libpjnath.a libpjlib-util.a libpjlib.a

如果顺序错了，会出现“undefined reference”错误。我一开始就踩过这个坑，调了半天才发现是链接顺序的问题。

实操心得：链接时加上-Wl,--start-group和-Wl,--end-group可以解决循环依赖问题。虽然会增加链接时间，但能避免很多麻烦。

3.2 SIP注册与呼叫流程的代码实现

pjsip的高层API叫pjsua，它把SIP注册、呼叫、媒体处理都封装好了。用pjsua可以大大简化开发工作量。下面是一个典型的注册和呼叫流程。

首先是初始化pjsua：

pjsua_config cfg; pjsua_logging_config log_cfg; pjsua_media_config media_cfg; pjsua_config_default(&cfg); cfg.cb.on_incoming_call = &on_incoming_call; cfg.cb.on_call_state = &on_call_state; cfg.cb.on_call_media_state = &on_call_media_state; pjsua_logging_config_default(&log_cfg); log_cfg.console_level = 3; pjsua_media_config_default(&media_cfg); media_cfg.clock_rate = 16000; media_cfg.snd_clock_rate = 16000; media_cfg.ec_tail_len = 0; pjsua_init(&cfg, &log_cfg, &media_cfg);

pjsua_config里设置了回调函数，当有来电、呼叫状态变化、媒体状态变化时会触发。pjsua_media_config里设置了采样率16kHz（对应G.722），关掉了回声消除（ec_tail_len = 0），因为嵌入式设备上回声消除计算量太大。

然后是创建传输层：

pjsua_transport_config trans_cfg; pjsua_transport_config_default(&trans_cfg); trans_cfg.port = 5060; pjsua_transport_create(PJSIP_TRANSPORT_UDP, &trans_cfg, NULL);

这里创建了一个UDP传输层，监听5060端口。SIP默认端口就是5060。

接着是注册到SIP服务器：

pjsua_acc_config acc_cfg; pjsua_acc_config_default(&acc_cfg); acc_cfg.id = pj_str("sip:1001@192.168.1.100"); acc_cfg.reg_uri = pj_str("sip:192.168.1.100"); acc_cfg.cred_count = 1; acc_cfg.cred_info[0].realm = pj_str("*"); acc_cfg.cred_info[0].scheme = pj_str("digest"); acc_cfg.cred_info[0].username = pj_str("1001"); acc_cfg.cred_info[0].data_type = PJSIP_CRED_DATA_PLAIN_PASSWD; acc_cfg.cred_info[0].data = pj_str("password"); pjsua_acc_add(&acc_cfg, PJ_TRUE, NULL);

acc_cfg.id是你的SIP URI，reg_uri是服务器地址，cred_info里填认证信息。PJ_TRUE表示立即注册。

发起呼叫的代码：

pj_str_t uri = pj_str("sip:1002@192.168.1.100"); pjsua_call_id call_id; pjsua_call_make_call(acc_id, &uri, 0, NULL, NULL, &call_id);

接听来电的代码：

pjsua_call_answer(call_id, 200, NULL, NULL);

挂断的代码：

pjsua_call_hangup(call_id, 0, NULL, NULL);

这些API用起来很简单，但背后pjsip做了大量工作：生成SIP INVITE消息、处理100 Trying、180 Ringing、200 OK、ACK等。你只需要关注业务逻辑就行。

3.3 RTP媒体传输与音频处理

SIP负责信令，RTP负责媒体。pjsip的媒体层会自动处理RTP的收发。当呼叫建立后，on_call_media_state回调会被触发，你可以在里面检查媒体状态：

static void on_call_media_state(pjsua_call_id call_id) { pjsua_call_info ci; pjsua_call_get_info(call_id, &ci); if (ci.media_status == PJSUA_CALL_MEDIA_ACTIVE) { pjsua_conf_connect(ci.conf_slot, 0); pjsua_conf_connect(0, ci.conf_slot); } }

pjsua_conf_connect把呼叫的音频通道连接到声卡通道。ci.conf_slot是呼叫在会议桥里的槽位，0是声卡的槽位。这两行代码的意思是：把呼叫的音频输出到声卡，同时把声卡的音频输入到呼叫。

音频处理这块，pjsip的pjmedia模块提供了完整的音频管道：采集、编码、RTP打包、抖动缓冲、解码、播放。你只需要实现一个音频设备驱动，把采集到的PCM数据喂给pjsip，同时从pjsip取PCM数据播放。

在STM32H7上，我用的音频接口是SAI（Serial Audio Interface），配合DMA双缓冲。SAI的配置大概是这样：

SAI_HandleTypeDef hsai; hsai.Instance = SAI1_Block_A; hsai.Init.AudioMode = SAI_MODEMASTER_TX; hsai.Init.Synchro = SAI_ASYNCHRONOUS; hsai.Init.OutputDrive = SAI_OUTPUTDRIVE_ENABLE; hsai.Init.NoDivider = SAI_MASTERDIVIDER_ENABLE; hsai.Init.FIFOThreshold = SAI_FIFOTHRESHOLD_1QF; hsai.Init.AudioFrequency = SAI_AUDIO_FREQUENCY_16K; hsai.Init.MonoStereoMode = SAI_STEREOMODE; hsai.Init.CompandingMode = SAI_NOCOMPANDING;

DMA双缓冲的意思是：DMA在播放缓冲区A的时候，CPU可以往缓冲区B写数据。这样能避免音频断流。缓冲区大小我设的是160个采样点（16kHz下10ms），这个延迟在可接受范围内。

注意：音频缓冲区的数量建议设成2的幂次，比如2、4、8。这样可以用位运算代替取模运算，提高效率。我一开始用了3个缓冲区，结果发现DMA配置起来很麻烦，后来改成4个就顺了。

4. 常见问题与排查技巧实录

4.1 注册失败与呼叫不通的排查思路

注册失败是最常见的问题。排查步骤一般是这样的：

第一步，检查网络是否通。用ping命令测试设备到SIP服务器的连通性。如果ping不通，说明网络配置有问题，检查IP地址、子网掩码、网关。

第二步，检查SIP消息是否发出。在pjsip的日志里可以看到发送和接收的SIP消息。如果只看到发送没有接收，说明服务器没响应，可能是端口不对或者服务器地址错了。

第三步，检查认证信息。如果收到401或407响应，说明认证失败。检查用户名、密码、realm是否正确。realm一般是*，但有些服务器要求填具体域名。

第四步，检查防火墙。有些服务器会限制来源IP，或者要求特定的User-Agent。可以在acc_cfg里设置user_agent字段。

呼叫不通的问题，排查思路类似。先看SIP信令是否正常（INVITE、100、180、200、ACK），再看RTP是否通。如果信令正常但没声音，多半是RTP的问题。可以用Wireshark抓包分析。

实操心得：pjsip的日志级别设成4或5可以看到详细的SIP消息内容。但日志输出会占用串口带宽，调试完后记得改回3。

4.2 内存不足与任务栈溢出的处理

内存不足是嵌入式系统跑pjsip的常见问题。表现是pj_pool_create返回NULL，或者系统直接HardFault。排查方法是：在pj_pool_create失败的地方加日志，看看是哪个池子分配失败了。

我的经验是，pjsip的内存需求主要来自三个方面：SIP消息缓冲、RTP抖动缓冲、音频编解码缓冲。SIP消息一般不大，几KB就够了。RTP抖动缓冲取决于网络质量，网络差的时候需要更大的缓冲。音频编解码缓冲取决于编解码器，G.722需要约16KB，G.711需要约8KB。

任务栈溢出也是常见问题。pjsip的线程栈默认是4KB，但在嵌入式系统里可能不够。我建议把pjsip相关任务的栈设成8KB以上。FreeRTOS有栈溢出检测功能，可以在FreeRTOSConfig.h里打开：

#define configCHECK_FOR_STACK_OVERFLOW 2

然后在vApplicationStackOverflowHook里打印出问题的任务名。

4.3 音频质量问题的调优经验

音频质量问题主要有几种：断断续续、有杂音、延迟大、回声。

断断续续一般是缓冲区不够或者DMA配置有问题。检查DMA缓冲区大小和数量，确保在DMA传输完成中断里及时填充数据。

杂音可能是采样率不匹配或者时钟配置有问题。检查SAI的时钟配置，确保MCLK、BCLK、LRCLK的频率正确。16kHz采样率下，MCLK一般是4.096MHz（256倍采样率）。

延迟大可能是抖动缓冲设得太大。pjsip的pjmedia模块有抖动缓冲配置，可以在pjsua_media_config里设置jb_max和jb_min。我一般设jb_min=2、jb_max=10，对应20ms到100ms的延迟。

回声问题在嵌入式设备上比较难解决，因为回声消除算法计算量大。如果设备有硬件回声消除，尽量用硬件。如果没有，可以尝试降低扬声器音量、调整麦克风位置。

4.4 长时间运行的稳定性问题

pjsip在嵌入式系统上长时间运行可能会遇到稳定性问题。我遇到过几种情况：

第一种是内存泄漏。pjsip的内存池机制本来是为了避免泄漏，但如果使用不当，比如创建了池子但忘记释放，还是会泄漏。排查方法是定期打印内存池的使用情况。

第二种是socket泄漏。pjsip的传输层会创建socket，如果呼叫异常结束，socket可能没被正确关闭。排查方法是检查PJ_IOQUEUE_MAX_HANDLES是否够用，如果不够，新的socket就创建不了。

第三种是任务死锁。pjsip内部有多个线程，如果互斥锁使用不当，可能会死锁。排查方法是看任务是否卡在某个锁上。FreeRTOS有任务状态查询功能，可以打印出所有任务的状态。

实操心得：建议在系统里加一个看门狗任务，定期检查pjsip的关键任务是否还在运行。如果某个任务卡住了，看门狗可以触发重启。

5. 性能优化与资源占用分析

5.1 CPU占用率与优化方向

在STM32H7上跑pjsip，CPU占用率主要取决于编解码器和RTP处理。我实测的数据是：G.711编解码占用约5% CPU（480MHz下），G.722占用约12%。RTP打包和解包占用约3%。SIP信令处理占用约2%。总体下来，一路通话的CPU占用在10%到20%之间。

如果CPU占用率过高，可以从几个方向优化。一是降低编解码复杂度，比如从G.722换回G.711。二是减少RTP打包频率，比如从20ms一包改成40ms一包。三是优化内存拷贝，pjsip内部有不少memcpy操作，可以用DMA来加速。

5.2 内存占用分析与裁剪

pjsip的内存占用主要包括：代码段（Flash）、数据段（RAM）、堆（内存池）。我实测的数据是：代码段约350KB，数据段约20KB，堆约512KB。总共约880KB。

如果Flash不够，可以进一步裁剪。比如关掉pjsip-ua里的某些功能，或者关掉pjmedia里的某些编解码器。如果RAM不够，可以减小内存池，或者关掉一些缓冲。

5.3 实时性保障与任务优先级配置

在FreeRTOS下，任务优先级配置对实时性影响很大。我的配置是：音频任务优先级最高（configMAX_PRIORITIES - 1），RTP任务次之（configMAX_PRIORITIES - 2），SIP任务再次之（configMAX_PRIORITIES - 3），应用任务最低。

音频任务优先级最高的原因是：音频断流是不可接受的，必须保证音频数据及时处理。RTP任务优先级次之，因为RTP包延迟会导致抖动缓冲溢出。SIP任务优先级可以低一些，因为SIP信令对实时性要求没那么高。

注意：FreeRTOS的优先级数值越大优先级越高。configMAX_PRIORITIES一般设成8或16。我设的是16，够用了。

6. 项目扩展与后续演进方向

6.1 从单路通话到多路并发

目前项目只支持单路通话。如果要支持多路并发，需要做几件事：一是增大内存池，每路通话需要额外的SIP事务池和媒体流池。二是增大PJ_IOQUEUE_MAX_HANDLES，每路通话需要额外的socket。三是调整任务优先级，确保多路音频都能及时处理。

多路并发的瓶颈一般在CPU和内存。STM32H7的算力可以支持4路G.711通话，或者2路G.722通话。如果不够，可以考虑用STM32H7的双核版本（H745/H755），把音频处理放到M4核上。

6.2 加入回声消除与噪声抑制

回声消除（AEC）和噪声抑制（NS）是VoIP终端的刚需。pjsip自带了一个简单的AEC（pjmedia_echo），但效果一般。如果要求高，可以集成WebRTC的AEC模块。WebRTC的AEC计算量较大，但在STM32H7上跑一路还是没问题的。

噪声抑制可以用pjsip自带的pjmedia_denoise，或者集成RNNoise。RNNoise是一个轻量级的噪声抑制库，计算量小，效果不错。

6.3 安全加固与异常恢复机制

安全方面，可以考虑加入SRTP（安全RTP）和SIPS（安全SIP）。pjsip支持SRTP，但需要集成libsrtp。SIPS需要TLS，计算量较大，在嵌入式系统上要谨慎使用。

异常恢复方面，建议加入看门狗和自动重启机制。如果pjsip的任务卡死或者内存耗尽，看门狗可以触发重启，恢复系统正常运行。另外，建议定期保存关键状态到Flash，重启后可以恢复。

我个人在实际操作中的体会是：pjsip在嵌入式系统上的移植工作量主要集中在OS适配和内存配置上。一旦跑通，后续的开发和维护会轻松很多。踩过的坑主要是内存不足和任务栈溢出，这两个问题在资源受限的MCU上特别常见。建议在项目初期就把内存和栈的余量留足，不然后期调试会很痛苦。另外，pjsip的日志系统很强大，善用日志可以快速定位问题。最后再分享一个小技巧：在config_site.h里把PJ_LOG_MAX_LEVEL设成5，然后在代码里用PJ_LOG宏输出调试信息，调试完后改回3，这样既能快速定位问题，又不会影响正式版本的性能。