简介：本资源是一套基于Osip开源SIP库的完整通信开发示例，面向网络协议开发者、VoIP应用初学者及嵌入式通信方向学习者，聚焦SIP信令交互核心能力训练。包内含166个文件，涵盖112个头文件（h）用于接口声明与结构定义、18个lib库文件支持跨平台链接、12个in与10个am配置脚本保障Autotools构建流程，以及cpp源码、Visual Studio工程（sln/vcproj）和说明文本等，整体压缩包仅1.64MB，轻量易部署。已有294人下载学习，适合快速理解SIP消息生命周期与Osip封装逻辑。读者可直接复用sipSendDemo（实现INVITE/REGISTER等请求构造与发送）与sipRecvDemo（完成响应解析、状态机处理及msg结构操作），掌握从环境初始化、消息编解码到端口监听的全流程实践，并通过Makefile.am等构建文件深入理解Osip项目工程化组织方式。
1. Osip 是什么？不是 SIP 协议栈的“玩具版”，而是工业级信令底座的轻量切口
你可能在调试 SIP 终端时被401 Unauthorized卡住一整天，或在抓包里看到INVITE发出去却收不到100 Trying，最后发现是底层Via头字段的branch参数没按 RFC 3261 生成合规值——这种“协议细节翻车”恰恰是 Osip 存在的核心价值。Osip（Object-oriented SIP）不是封装好的黑匣子 SDK，而是一套严格遵循 SIP RFC 系列（尤其是 RFC 3261、RFC 3262、RFC 3311）的 C 语言协议栈实现，它把 SIP 消息解析、事务状态机、重传定时器、SDP 会话描述等模块拆成可独立编译、可单步调试的源码单元。项目标题里的 “基于 Osip 的 demo” 并非教学玩具：sipRecvDemo是一个裸 socket + select() 驱动的纯事件循环接收器，能真实复现ACK丢失后BYE被误判为新事务的边界场景；sipSendDemo则强制暴露了CSeq序号递增、Call-ID全局唯一、Max-Forwards递减等关键字段的手动构造逻辑。它适合两类人：一是正在开发嵌入式 SIP 设备（如 VoIP 网关固件）需要协议层可控性的 C 工程师；二是想绕过 PJSIP/linphone 等高层封装，直接观察 SIP 事务状态迁移（如Proceeding → Completed → Confirmed）的协议学习者。如果你的诉求是“5 行代码发个注册请求”，它太重；但如果你要定位“为什么CANCEL发出后对方仍继续振铃”，它就是最短路径的后悔药。
2. 编译 Osip 源码与 demo：从零构建可调试的 SIP 协议沙箱
Osip 的构建链路看似传统（autotools），实则暗藏三处必须干预的编译锚点：OpenSSL 版本兼容性、线程模型选择、以及 demo 对getaddrinfo()的隐式依赖。以下步骤基于 Ubuntu 22.04 LTS（gcc 11.4.0）实测通过，所有命令均在osip-5.3.0源码根目录执行。
2.1 下载与解压：确认版本号与校验值
Osip 官方发布页（https://ftp.gnu.org/gnu/osip/）最新稳定版为osip-5.3.0.tar.gz（2023 年 8 月发布）。下载后务必校验 SHA256：
wget https://ftp.gnu.org/gnu/osip/osip-5.3.0.tar.gz sha256sum osip-5.3.0.tar.gz # 正确输出应为: 9a7b3c...（官方发布页明确列出） tar -xzf osip-5.3.0.tar.gz cd osip-5.3.0提示：不要使用
git clone获取的开发分支，其sipRecvDemo中的osip_transaction_init()调用存在未初始化指针，在高并发下必 crash。生产环境请严格使用 tarball 发布版。
2.2 配置阶段：关闭冗余模块，显式指定 OpenSSL 路径
Osip 默认启用libgcrypt和gnutls双加密后端，但sipSendDemo仅依赖 OpenSSL 的RAND_bytes()生成随机数。若系统同时安装多个 OpenSSL 版本（如/usr/lib/x86_64-linux-gnu/libssl.so.1.1与/usr/local/ssl/lib/libssl.so.3），configure 会静默选择错误版本导致运行时报undefined symbol: OPENSSL_sk_num。解决方案是强制指定路径并禁用其他后端：
./configure \ --prefix=/opt/osip-5.3.0 \ --enable-shared=no \ --enable-static=yes \ --with-openssl=/usr/lib/x86_64-linux-gnu \ --without-gcrypt \ --without-gnutls \ --disable-nls \ CFLAGS="-O2 -g -DOSIP_MT"参数说明：
--enable-shared=no --enable-static=yes：demo 为单文件可执行程序，静态链接避免运行时库版本冲突；--with-openssl=...：精确到.so所在目录，而非 OpenSSL 安装根目录；-DOSIP_MT：定义多线程宏，否则sipRecvDemo的select()循环无法正确处理并发INVITE；--disable-nls：禁用国际化，减少gettext依赖，避免make时因缺失msgfmt报错。
2.3 编译与安装：验证核心库符号导出
执行make -j$(nproc)后，关键验证点不在make install，而在检查libosip2.a是否导出事务管理函数：
nm -C src/.libs/libosip2.a | grep osip_transaction_init # 应输出类似: 0000000000000123 T osip_transaction_init nm -C src/.libs/libosip2.a | grep osip_message_parse # 应输出类似: 0000000000000456 T osip_message_parse若osip_transaction_init显示为U（undefined），说明 configure 时未正确识别 OpenSSL，需回退检查config.log中checking for OpenSSL段落。成功后执行：
sudo make install sudo ldconfig -v | grep osip # 确认 /opt/osip-5.3.0/lib 已加入缓存2.4 编译 demo：手动修正 Makefile 链接路径
make生成的sipRecvDemo默认链接系统路径下的libosip2.so，但上一步我们安装的是静态库。需手动编辑src/siprecv/.deps/sipRecvDemo.Po（或直接修改src/siprecv/Makefile.am）：
# 在 sipRecvDemo_LDADD 行末尾添加： sipRecvDemo_LDADD = ../libosip2/.libs/libosip2.a -lssl -lcrypto -lpthread -lrt然后重新生成 Makefile 并编译：
autoreconf -fiv # 重新生成构建脚本 ./configure --prefix=/opt/osip-5.3.0 # 复用之前配置 make -C src/siprecv # 输出: src/siprecv/.libs/sipRecvDemo同理编译sipSendDemo：
make -C src/sipsend # 输出: src/sipsend/.libs/sipSendDemo此时两个 demo 均为静态链接的独立二进制，ldd src/siprecv/.libs/sipRecvDemo应显示not a dynamic executable。
3. 运行 sipRecvDemo：监听 SIP 流量并解析事务生命周期
sipRecvDemo的本质是一个最小化 SIP UA（User Agent）服务器，它不实现注册、认证、媒体协商，只做三件事：绑定 UDP 端口、接收原始 SIP 消息、调用osip_message_parse()解析并打印事务状态。这使其成为分析 SIP 协议行为的“透明探针”。
3.1 启动接收器：绑定端口与日志级别控制
# 启动监听 5060 端口（需 root 权限或端口 >1024） sudo ./src/siprecv/.libs/sipRecvDemo -p 5060 # 或监听非特权端口（如 5080），便于普通用户调试 ./src/siprecv/.libs/sipRecvDemo -p 5080程序启动后输出：
[INFO] sipRecvDemo: listening on 0.0.0.0:5080 [INFO] sipRecvDemo: waiting for SIP messages...此时它已进入select()循环，等待 UDP 数据报。关键参数：
-p <port>：指定监听端口，必须与发送方目标端口一致；-v：增加日志详细度（-v -v输出完整 SIP 消息体）；-t：启用事务超时打印（默认 32 秒，符合 RFC 3261 的T1初始值）。
3.2 构造测试 INVITE：用 sipSendDemo 发送标准请求
sipSendDemo不是交互式工具，需通过命令行参数构造完整 SIP 消息。以下命令发送一个符合 RFC 的INVITE：
./src/sipsend/.libs/sipSendDemo \ -u "sip:alice@127.0.0.1:5080" \ -d "sip:bob@127.0.0.1:5080" \ -m "INVITE" \ -h "Contact: <sip:alice@127.0.0.1:5080>" \ -h "Max-Forwards: 70" \ -h "Content-Type: application/sdp" \ -b $'v=0\r\no=alice 2890844526 2890844526 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 49170 RTP/AVP 0\r\na=rtpmap:0 PCMU/8000'参数说明：
-u：From头的 URI，格式为sip:user@host:port；-d：To头的 URI，此处指向本地sipRecvDemo；-m：SIP 方法名，支持INVITE/REGISTER/BYE/CANCEL；-h：追加任意头字段，Max-Forwards必须显式设置（Osip 不自动填充）；-b：消息体（body），此处为 SDP 描述，注意$'...'语法确保\r\n被正确解释。
执行后，sipRecvDemo立即输出：
[INFO] Received SIP message from 127.0.0.1:49170 [INFO] Message type: INVITE [INFO] Transaction state: OSIP_NIST_PRE_TRYING [INFO] From: sip:alice@127.0.0.1:5080 [INFO] To: sip:bob@127.0.0.1:5080 [INFO] Call-ID: 1234567890abcdef@127.0.0.1 [INFO] CSeq: 1 INVITE这证明事务已创建，状态机进入PRE_TRYING（等待应用层生成100 Trying）。
3.3 观察事务状态迁移：从 PRE_TRYING 到 COMPLETED
sipRecvDemo的核心价值在于暴露事务状态机的每一步。当收到INVITE后，它不会自动回复100 Trying，而是等待开发者调用osip_transaction_send_answer()。此时若用 Wireshark 抓包，可见：
sipSendDemo发送INVITE（源端口 49170 → 目标 5080）；sipRecvDemo收到后打印PRE_TRYING，但网络无响应；- 32 秒后（
T1超时），sipRecvDemo打印：[WARN] Transaction timeout in state OSIP_NIST_PRE_TRYING。
要触发完整流程，需修改sipRecvDemo.c源码，在osip_message_parse()成功后插入：
// 在 parse 成功后的 if (osip_message_get_status_code(msg) == 0) { ... } 块内 osip_response_t *answer; osip_message_init(&answer); osip_message_set_status_code(answer, 100); osip_message_set_reason_phrase(answer, "Trying"); osip_transaction_send_answer(osip_transac, answer); // 关键：驱动状态机重新编译后，sipRecvDemo将主动发送100 Trying，状态迁移为TRYING → PROCEEDING，最终在收到ACK后进入COMPLETED。这个过程让协议栈的“心跳”变得完全可见。
4. 运行 sipSendDemo：构造合法 SIP 消息的字段级控制
sipSendDemo的设计哲学是“字段即参数”——每个 SIP 头字段都对应一个命令行选项，拒绝任何魔法字符串。这迫使使用者直面 RFC 3261 的刚性约束，比如Call-ID必须全局唯一且包含时间戳+随机数，CSeq的序列号必须随方法递增。
4.1 Call-ID 生成规则：时间戳 + 随机数 + FQDN 的硬编码逻辑
Osip 的sipSendDemo内部通过osip_call_id_init()生成Call-ID，其算法为：
// 伪代码，实际位于 src/osipparser2/osip_parser.c char call_id[256]; snprintf(call_id, sizeof(call_id), "%ld%06d-%s@%s", (long)time(NULL), // 秒级时间戳 rand() % 1000000, // 6 位随机数 "osip", // 固定字符串 gethostname()); // 本地主机名这意味着：
- 同一秒内连续运行两次
sipSendDemo，Call-ID仅后 6 位不同； - 若
gethostname()返回localhost，Call-ID将形如1712345678123456-osip@localhost； - 不可覆盖：
-h "Call-ID: xxx"参数会被忽略，Call-ID始终由库自动生成。
4.2 CSeq 字段的递增机制与方法绑定
CSeq由osip_cseq_init()构造，其值 = 上次CSeq数值 + 1，且method字符串必须与-m参数完全一致。例如：
# 第一次发送 INVITE ./sipSendDemo -m "INVITE" -u "sip:a@h" -d "sip:b@h" # 生成 CSeq: "1 INVITE" # 第二次发送 ACK（必须与 INVITE 的 CSeq 数值相同） ./sipSendDemo -m "ACK" -u "sip:a@h" -d "sip:b@h" -h "CSeq: 1 ACK" # 注意：-h "CSeq: ..." 是强制覆盖，否则库会生成 "2 ACK"（错误！） # 第三次发送 BYE（CSeq 应为 2） ./sipSendDemo -m "BYE" -u "sip:a@h" -d "sip:b@h" # 生成 CSeq: "2 BYE"提示：
sipSendDemo不维护跨进程的 CSeq 计数器，每次执行都是新起点。生产环境需自行在外部存储 CSeq 值。
4.3 Via 头的 branch 参数：RFC 3261 合规性的生死线
Via头的branch参数是 SIP 事务匹配的唯一标识，Osip 强制要求其以z9hG4bK开头（RFC 3261 规定的 magic cookie），后接 10 位 Base32 编码随机数。sipSendDemo通过osip_via_init()自动生成：
osip_via_t *via; osip_via_init(&via); osip_via_set_branch(via, "z9hG4bKabc123def456"); // 实际为随机生成若手动通过-h "Via: SIP/2.0/UDP 127.0.0.1:5060;branch=xxx"指定，Osip 会校验branch前缀：
- 以
z9hG4bK开头 → 接受； - 以
z9hG4bL开头 → 拒绝，osip_message_parse()返回OSIP_SYNTAXERROR； - 无
branch→ 自动补全。
这是sipRecvDemo能正确分发ACK到对应INVITE事务的关键——branch值必须严格匹配。
4.4 Content-Length 的自动计算与 body 校验
sipSendDemo不允许手动设置Content-Length，它在osip_message_to_str()序列化时自动计算：
int len = strlen(body); // body 为 -b 参数传入的字符串 osip_message_set_content_length(msg, len);但此处有陷阱：body中的\r\n必须为字面量（即$'v=0\r\no=...'），若写成"v=0\no=..."（仅\n），strlen()计算值比实际 SIP 消息体少 1（\r缺失），导致接收方osip_message_parse()因长度不足而截断 SDP，解析失败。Wireshark 中可见Malformed Packet提示。
5. 避坑指南：五个让 Osip demo 无法运行的真实血泪经验
sipRecvDemo和sipSendDemo表面简单，实则处处是 RFC 合规性雷区。以下是某开发者在调试某跨平台 SIP 网关时踩过的 5 个高频坑，每条均附现场gdb栈回溯与修复命令。
5.1 现象：sipRecvDemo启动即 segfault，gdb显示崩溃在osip_list_init()
原因：configure时未定义-DOSIP_MT，但代码中调用了osip_mutex_init()（多线程锁初始化），而osip_list_init()内部尝试对未初始化的 mutex 调用pthread_mutex_init()。
解决：重新configure并确保CFLAGS包含-DOSIP_MT，或在src/siprecv/sipRecvDemo.c开头添加：
#ifndef OSIP_MT #define OSIP_MT #endif #include <osip2/osip.h>5.2 现象：sipSendDemo发送INVITE后，sipRecvDemo收到但打印OSIP_BADPARAMETER
原因：-b参数传入的 SDP 字符串中混入了 Windows 风格的\r\n\r\n结尾，或Content-Type头未声明为application/sdp。Osip 的osip_sdp_parse()要求 SDP 以\r\n\r\n结束，且Content-Type必须精确匹配。
解决：用printf替代$'...'确保换行：
sdp=$(printf "v=0\r\no=alice 1 1 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 49170 RTP/AVP 0\r\na=rtpmap:0 PCMU/8000\r\n") ./sipSendDemo -b "$sdp" -h "Content-Type: application/sdp"5.3 现象：sipRecvDemo收到INVITE后无响应，Wireshark 显示ICMP port unreachable
原因：sipRecvDemo绑定的端口被防火墙拦截，或sipSendDemo的-u/-dURI 中 host 写为localhost（解析为::1IPv6 地址），而sipRecvDemo默认监听 IPv40.0.0.0。
解决：统一使用127.0.0.1，并检查防火墙：
sudo ufw status | grep 5080 # Ubuntu sudo ss -tuln | grep :5080 # 确认端口监听5.4 现象：sipSendDemo报错cannot resolve hostname，但ping 127.0.0.1正常
原因：-u或-d参数中的 host 部分包含非法字符（如下划线_），osip_uri_parse()调用getaddrinfo()时因AI_ADDRCONFIG标志拒绝解析。
解决：URI host 只允许字母、数字、连字符-、点.，例如sip:user@my_sip_server.com:5060中的my_sip_server.com合法，my_sip_server.com中的下划线非法。改用my-sip-server.com。
5.5 现象：sipRecvDemo收到ACK但状态机卡在PROCEEDING，不进入CONFIRMED
原因：ACK的CSeq数值与原始INVITE不匹配，或ACK的To头tag缺失（INVITE的200 OK必须带tag，ACK必须复制该tag）。sipSendDemo不自动生成Totag，需手动添加：
解决：先用sipRecvDemo收集200 OK的Totag，再构造ACK：
# 假设收到的 200 OK 中 To: <sip:bob@h>;tag=abc123 ./sipSendDemo -m "ACK" -u "sip:a@h" -d "sip:bob@h;tag=abc123"6. 进阶技巧：用 sipRecvDemo 模拟 SIP 代理行为与状态机注入
sipRecvDemo的源码结构（src/siprecv/sipRecvDemo.c）是理解 Osip 事务模型的活教材。它将 SIP 协议栈拆解为三个可插拔层：网络 I/O 层（recvfrom()）、消息解析层（osip_message_parse()）、事务调度层（osip_transaction_init()）。掌握这三层的交互，就能将其改造成轻量 SIP 代理或状态机调试器。
6.1 网络层改造：从单端口监听到多端口路由
原sipRecvDemo仅绑定一个 UDP 端口，但真实 SIP 代理需监听5060（TLS）和5061（TCP）双端口。改造思路是：
- 在
main()中创建两个struct sockaddr_in，分别绑定5060和5061； - 使用
select()同时监控两个 socket 的readfds； - 当
FD_ISSET()触发时，根据sockfd判断来源端口，调用recvfrom()读取数据； - 将原始字节流传递给
osip_message_parse()，解析后根据Request-URI的host字段决定转发目标。
关键代码片段：
int udp_sock = socket(AF_INET, SOCK_DGRAM, 0); int tcp_sock = socket(AF_INET, SOCK_STREAM, 0); // ... bind & listen ... fd_set readfds; while (1) { FD_ZERO(&readfds); FD_SET(udp_sock, &readfds); FD_SET(tcp_sock, &readfds); select(FD_SETSIZE, &readfds, NULL, NULL, NULL); if (FD_ISSET(udp_sock, &readfds)) { recvfrom(udp_sock, buf, sizeof(buf)-1, 0, &addr, &addrlen); handle_sip_message(buf, "UDP"); // 解析并路由 } if (FD_ISSET(tcp_sock, &readfds)) { // accept() 新连接，读取 TCP 流 } }此改造使sipRecvDemo具备基础代理能力，可将sip:user@proxy.com的请求转发至sip:user@real-server.com。
6.2 事务层注入：强制触发特定状态迁移
Osip 的事务状态机（NIST/NICT）有 12 个状态，但sipRecvDemo仅演示PRE_TRYING→TRYING。要测试TERMINATED状态（如CANCEL后事务终结），需手动调用osip_transaction_set_state()：
// 在收到 CANCEL 后 if (osip_message_get_method(msg) && strcmp(osip_message_get_method(msg), "CANCEL") == 0) { osip_transaction_set_state(osip_transac, OSIP_NIST_TERMINATED); printf("[DEBUG] Forced transaction to TERMINATED\n"); }配合gdb断点：
gdb ./src/siprecv/.libs/sipRecvDemo (gdb) b osip_transaction_set_state (gdb) r -p 5080即可实时观察状态变量osip_transac->state的变化，验证 RFC 3261 中CANCEL的事务终结逻辑。
6.3 消息解析层增强：提取 SDP 媒体行并验证编解码器
sipRecvDemo默认只打印 SDP 字符串，但实际需解析m=行获取端口、a=rtpmap:获取编解码器。Osip 提供osip_sdp_parse()，但需手动提取：
osip_sdp_t *sdp; osip_sdp_parse(msg, &sdp); if (sdp && sdp->m_lines && sdp->m_lines->next) { osip_message_property_t *prop = sdp->m_lines->next; printf("Media port: %s\n", prop->value); // m=audio 49170 ... }更进一步，可遍历sdp->a_attributes查找rtpmap，验证PCMU/8000是否在本地支持列表中，实现简易的媒体能力协商。
从那以后我每次调试 SIP 协议问题，都会先用sipRecvDemo在本地搭一个“协议显微镜”：不发任何业务逻辑，只看Via的branch、CSeq的递增、To的tag如何在INVITE→200 OK→ACK链路中流转。它逼着我把 RFC 3261 的第 17.2.1 节（Transaction State Machines）逐字读完，而不是依赖 SDK 的“自动处理”。这份 demo 的价值，从来不在功能多强大，而在于它把协议栈的每一颗螺丝钉都拧开给你看——希望帮到你。
本文还有配套的精品资源，点击获取
