简介MSRPMessage Session Relay Protocol是SIP会话中承载富媒体内容的重要扩展这套C源码以轻量实现展示了SIP客户端如何集成MSRP协议适合VoIP、即时通信及SIP协议栈开发者作为参考样例。压缩包内共46个文件解压后约56KB其中23个.h头文件与16个.cpp源文件构成主体并附带Makefile、vcproj工程文件以及说明文档便于在Linux或Windows工程环境中直接编译研究。具体代码覆盖MSRP URI解析、报文头部与消息体封装、TCP连接管理、状态与报告处理等关键模块协议栈按连接、地址、消息、报告等模块拆分组织基于SIP INVITE协商完成后通过SETUP/SEND/TEARDOWN方法完成通道建立、消息传输与会话释放从URI构造、SEND消息分片到成功/失败报告解析均有实现可对照逻辑路径清晰基本构成一套可学习的MSRP协议栈雏形。目前已有135人访问学习适合期望快速理解SIP与MSRP交互细节、需要构建客户端协议模块的开发者。1. 把 MSRP 塞进 SIP 会话里这个 zip 到底解决什么问题MSRP 全称 Message Session Relay Protocol是跑在 SIP 信令之上的一条消息/文件传输通道。很多从业者第一次见到它是在 IMS 里的即时消息、企业通讯录推送、或者语音网关的“大容量留言”场景——SIP INVITE 里带一段 mmessage 的 SDP协商完就建起一条 TCP 连接消息以 MSRP SEND 请求的方式在这条连接上交换。标题里这个 “MSRP.zip_SIP Client MSRP” 压缩包本质就是一份可以直接落地的 SIP MSRP 客户端实现解压后既能当信令模块用也能把 MSRP 收发消息的细节封装好省去你从零啃 RFC 4975 的功夫。适合谁做 SIP 终端、IMS 应用、企业 IM 网关、或者给海康类平台做 SIP 对接的工程师都适用。它能帮你少踩 TCP 分片、Byte-Range 拼接和 SDP 协商这三种最容易翻车的坑。2. 拆开 zip 看门道SIP 信令里那段 SDP 就是 MSRP 的“会话合同”拿到这个MSRP.zip压缩包别急着编译。先把它当成一个SIP 信令服务器源码 消息客户端的组合来读你才能理解为什么会有那么多文件名里重复 msrp、sip。我一般先解压到一个固定目录比如/opt/msrp_client/然后按“信令层 → 消息层 → 传输层”的顺序看代码。大多数打包的 SIP Client 都会有一个负责 INVITE 事务的模块一个负责 MSRP 消息收发的模块还有一个管理 TCP 连接的 transport 模块。如果你打开源码发现这三个模块是揉在一个文件里的建议先花时间拆清楚否则后面调试字节偏移会非常痛苦。2.1 SDP 协商mmessage 一行决定了你的 MSRP 会话怎么建MSRP 会话不是凭空出现的它必须由 SIP 信令先“牵线”。客户端发起 INVITE 时SDP 里不再是 audio/video而是这样一段mmessage 9000 TCP/MSRP aaccept-types:text/plain message/cpim apath:msrp://192.168.1.10:9000/abcdefgh;tcp asetup:active aconnection:new这段 SDP 的含义m 行声明了传输协议是 TCP/MSRP端口 9000apath 是 MSRP 层的 URI末尾的;tcp表示用 TCP 承载asetup 则告诉对端谁主动建 TCP 连接。逻辑说明setup:active表示本端是主动连接方对端应答时通常会回setup:passive于是本端立刻向 apath 里的 IP 和端口发起 TCP 连接。参数说明accept-types 决定了这条会话能传什么类型如果对端不支持你列出的类型会回 488 Not Acceptable Here所以别把一种类型写死常用做法是写text/plain message/cpim。你可能会遇到一种情况INVITE 里没带 mmessage只带了 audio。那 MSRP 根本起不来终端会一直等对端发 183。很多人在这里踩坑——拿普通 SIP 话机调试 MSRP 客户端结果话机只协商 audio消息自然发不出去。所以拿到这个 zip 后第一件事是确认它的 INVITE 构造代码里 SDP 是硬编码 mmessage还是开放了接口让你自己填。2.2 MSRP 消息格式SEND 请求和 200 响应是怎么对上号的SDP 协商完成后两条 TCP 连接上跑的就是 MSRP 消息了。MSRP 请求长这样MSRP a54h9 SEND To-Path: msrp://192.168.1.20:9000/abcdef;tcp From-Path: msrp://192.168.1.10:9000/abcdefgh;tcp Message-ID: 1234567890 Byte-Range: 1-100/100 Content-Type: text/plain Hello, MSRP! -------a54h9$关键点说明第一行MSRP a54h9 SEND是方法行a54h9是事务标识对端回复时会把 SEND 换成200 OKByte-Range 的1-100/100表示这是唯一分片总共 100 字节、当前是第 1 到第 100 字节消息尾部用-------a54h9$表示结束如果还有后续分片则用-------a54h9来告诉对端“更多分片要来了”。这个尾标记是新手最容易搞错的地方$和差一个字符写错的话对端会一直等后续分片直到 TCP 超时。我建议拿到 zip 后先不要看它的 SEND 构造代码而是用 tcpdump 抓一次真实会话把上面这段结构在抓包里对照一遍。这个zip 里如果有示例抓包文件优先看那一个比读十遍代码都有用。2.3 最小可复现解压、编译、跑通一次 MSRP 会话的命令这个 zip 里的客户端如果带 Makefile 或 CMakeLists编译路径一般是这样cd /opt/msrp_client unzip MSRP.zip ls -la # 看有没有 README 或 config.example ./configure --with-sip-stackpjsip make -j4逻辑说明第一行把压缩包解压到固定目录configure这一步常见做法是让你选择 SIP 信令栈——标题里这个客户端通常有 PJSIP 和自带轻量栈两个选项我一般选 PJSIP因为它的事务状态机和重传处理比裸写稳定得多。参数说明如果你只做消息传输、不注册到服务器可以用--disable-register之类选项关掉注册模块减少出问题的面。编译完成后跑一个自带的演示程序通常是这样的命令./msrp_client -l 9000 -s sip:msrp-test192.168.1.20如果你不先看 README 就乱跑大概率会在“缺少编译选项”和“运行时找不到配置文件”上浪费半小时。别问我怎么知道的。3. 从零写一个能用的 MSRP SIP Client选型、信令时序和最小实现如果你不想依赖 zip 里那份现成代码或者你手里的 zip 只提供了库文件而没有源码那完全可以自己写一个最小实现。方向上有两条路一是基于 PJSIP 的 pjsua 或 pjsip 高层 API 改二是只依赖一个 SIP 事务栈自己拼 SDP 和 MSRP 消息。对绝大多数人我推荐前者因为 PJSIP 已经把 SIP 重传、认证摘要、事务超时这些都处理好了你只需要关系 MSRP 消息本身。用裸栈听上去很“硬核”但光是一个 TCP 半开连接的重连逻辑就够你调一整天。3.1 选型为什么我不用 SIPp 而用 PJSIP 扩展一个 Client很多人测试 SIP 的时候会想到 SIPp。但 SIPp 对 MSRP 的支持非常有限它擅长的是 INVITE、REGISTER 这类标准信令压测到了 MSRP 消息层SIPp 根本不会帮你拼接 SEND 请求和处理Byte-Range。所以“SIP 信令服务器源码”可以在你自己的项目里参考但客户端这边我常见做法是直接用 PJSIP 的pjsua_call回调在on_media_update之后自行管理一条 TCP socket。这样做的好处是信令仍然由 PJSIP 负责你只写 MSRP 部分的几百行代码工作量小、坑也少。zip 里那份实现如果也是这么组织的那它的架构就是干净可借鉴的。3.2 最小时序INVITE → 183 → 200 → ACK → SEND一次 MSRP 客户端完整会话的时序是这样的客户端 A 发 INVITESDP 携带 mmessage对端 B 回 183 Session ProgressSDP 里写入自己的 msrp URI客户端 A 确认 B 的 asetup 值如果自己是 active 就往 B 的 TCP 端口建连接B 回 200 OKA 发 ACKTCP 连接建立后A 发 MSRP SENDB 回 MSRP 200 OK需要关闭时A 发 BYE。很多刚上手的工程师会在第 3 步翻车他们以为 183 就代表 TCP 连接已建好实际 183 只是信令层的答复TCP 连接要等你自己去 connect。如果 asetup 写的是 passive那就要等对端主动连你结果对端也没来连两边干等这就是经典的“黑匣子”问题。调试方法很简单在代码里把每步的状态打点打到日志里看看卡在哪个阶段。3.3 最小 Python 脚本不依赖任何库先跑通 MSRP SEND如果你只是想验证 MSRP 消息拼接逻辑不一定要先编译整个 C 工程。我用 Python 写过一个最小模拟器核心就是对 TCP socket 做一次原始的 MSRP 请求交换import socket MSRP_MSG ( MSRP 1a2b3 SEND\r\n To-Path: msrp://192.168.1.20:9000/abcdef;tcp\r\n From-Path: msrp://192.168.1.10:9000/abcdefgh;tcp\r\n Message-ID: 9876543210\r\n Byte-Range: 1-12/12\r\n Content-Type: text/plain\r\n \r\n hello msrp\r\n -------1a2b3$\r\n ) sock socket.create_connection((192.168.1.20, 9000), timeout5) sock.sendall(MSRP_MSG.encode()) resp sock.recv(4096) print(resp.decode()) sock.close()逻辑说明这段脚本构造了一个完整的 MSRP SEND 帧然后连到对端的 MSRP 端口 9000。对端如果是合法 MSRP 服务端会返回MSRP 1a2b3 200 OK头部里会带上原事务 ID表示消息已接收。参数说明Byte-Range: 1-12/12中的 12 必须和hello msrp的字节数一致——注意末尾有一个换行符实际长度是 11 个字符加 1 个 CRLF所以写 12 是安全的。如果你分片数写错对端会回复413或直接不回。这个脚本最大的价值是帮你把 MSRP 帧结构彻底吃透之后再去看 C 工程代码一眼就能看出它哪里写错。4. 从 demo 到生产IMS Trunk 与语音平台对接要调的 5 个 MSRP 参数跑通 demo 只是第一步。真要把它用到set sip voice trunk ims on router这类网关注册场景或者跟海康平台做 SIP 对接时有 5 个参数你必须逐一校一遍。这些参数在 zip 里通常散落在配置文件中默认值往往和实际网络环境不匹配直接套用就会遇到莫名其妙的消息丢失。参数默认常见值生产建议值说明asetupactive听 SDP 对端决定两端都 active 会导致连接重入Byte-Range 分片大小无1024 或 2048 字节大消息不切片会被中间网元丢弃MSRP keepalive无每 30 秒发一个空 SEND防止 NAT 和运营商超时断连最大消息大小无按平台规格设常见 5MB超过后会回 413 拒绝TLS 模式tcpmsrps明文 TCP 在跨网段时容易被丢4.1 apath 和路由谁决定 MSRP 消息往哪走MSRP 的 SDP 里apath有两个作用一是告诉对端你愿意接收消息的 URI二是作为 SIP 消息路由的补充。在 IMS 场景里S-CSCF 会通过 Path 头来定位用户归属但 MSRP 的连接是端到端直连的中间最多经过一个 MRF 或 SBC 做中继。如果你在网关注册后发现 MSRP 消息能发出去但收不到八成是 apath 里写的地址是内网 IP对端回包打到内网直接被防火墙丢弃。常见做法是在 SDP 里填公网可达的地址并且把端口固定下来不要用 ephemeral 端口。4.2 大消息分片为什么大于 4KB 的消息会被静默丢弃很多 MSRP 客户端在发送超过 4KB 的消息时会突然失败这是因为 TCP 层会分段但 MSRP 层面要求你在一个 SEND 帧里明确声明Byte-Range。如果你把整个 10MB 的消息塞进一个 SEND 帧中间网元可能因为缓冲区溢出直接断开 TCP 连接。正确做法是应用层把消息切成 1KB–2KB 的块每个块发一个 SEND 请求第一块的 Byte-Range 写1-n/total中间块尾部用最后一块用$。我在实际对接中常用 1024 字节分片这样既能避开 MTU 问题也不会因为分片太多导致 CPU 消耗过高。4.3 NAT 穿透与 keepalive别让 TCP 连接被静默回收MSRP 使用长连接在 NAT 后面的客户端如果长时间不发数据NAT 映射会老化对端的 TCP 连接状态也会被中间设备强制清理。最直接的现象就是消息发出去后一直收不到 200客户端超时后重发又被对端以事务冲突拒绝。要解决这个问题除了在 SBC 上开 rport 保持绑定客户端自身也必须周期性发送 keepalive。MSRP 没有专门的 keepalive 方法常见做法是发一个带空消息体的 SEND头部的 Message-ID 每次变化对端收到后回 200这样连接就被续期一次。我一般把间隔设在 25 到 30 秒比运营商 NAT 老化的典型 60 秒留出一倍余量。4.4 认证与 TLSmsrps 端口的选择和证书坑真实网络里 MSRP 基本不会跑明文 TCP。SDP 中的 m 行如果写成TCP/MSRP就是明文TCP/MSRPS才是 TLS。在 IMS 环境中虽然信令走 SIP over TLS媒体层面同样要求 MSRP over TLS。这时会引入一个常见坑客户端用自签名证书连对端对端校验失败直接握手断掉。我建议在你的on_establish回调里先打印对端证书指纹再决定要不要做深度校验如果是在小范围试点可以把对端 CA 加进本地信任库而不是全局关闭验证否则后面安全审计会让你返工。4.5 与既有系统对接海康平台、IMS Trunk 与 zip 里的配置模板如果你是要做“海康平台 SIP 对接配置”这类工作往往不只是调 MSRP还要关注 SIP 注册、Keepalive 和呼叫流程。zip 里一般会附带若干平台对接配置模板命名可能是config.platform.example里面已经写好了常见的海康、华为 IMS 平台的参数。我第一次做这类对接时犯过一个很傻的错误直接把模板里的setup:passive改成了active结果两边互相等待对方建连。后来养成了习惯配置文件里每个参数都记下来源是平台文档里来的还是模板自带的这样出了问题能往回查不用把责任归给“玄学”。5. 避坑MSRP 客户端调试里最常见的 5 个翻车现场5.1 现象INVITE 发出后一直收不到 183客户端界面永远“呼出中”原因对端是普通 SIP 终端或旧版软交换只支持 audio不支持 message。INVITE 里的 mmessage 被对端忽略或者直接被回 488。解决在抓包确认 SDP 中 m 行确实存在且accept-types包含对端能识别的内容类然后查对端日志是否显示拒绝原因。另一个隐蔽原因是 zip 里附带的客户端默认把 INVITE 的 Content-Disposition 写成了session而正确写法是render——这也能导致部分平台不识别。5.2 现象大文件发送时对端只收到第一块后续分片全部丢失原因Byte-Range 的尾标记写错了。第一块用结尾最后一块用$如果所有块都用$对端在收完第一块后以为事务结束后续 SEND 被视为新事务但因为 Message-ID 一致对端会直接忽略。解决在代码里把分片函数单独抽出来测试用 3 个分片分别检查尾部标记。另外确认每块的字节偏移是连续的比如第一块1-1024/2048第二块必须是1025-2048/2048如果出现跳跃对端会回 481 并关闭会话。5.3 现象SEND 发出去后收到了 200但业务层面没有触发“消息已读”原因MSRP 的 200 是传输层确认服务端收到并落盘了但业务逻辑没处理。这在对接 IMS 时很常见S-CSCF 帮你把 MSRP 消息转给了 AS但 AS 上的业务逻辑没被触发。解决看 200 OK 里有没有附带Report-To头如果应用需要接收方回执你必须在 SDP 里声明aaccept-types: message/cpim同时业务端要支持 CPIM 格式的Message-ID关联。很多 zip 里的 demo 只实现了 SENDREPORT方法没有实现导致上层看不到完整的消息状态。5.4 现象TCP 连接建立后一段时间没消息再发 SEND 就超时原因NAT 或中间防火墙回收了空闲连接但客户端没有感知仍然往旧 socket 写数据。解决在传输层做 socket 错误检测写失败时立即触发重建连接在会话层做 keepalive每 30 秒发一次空 SEND。另外一个容易忽略的点有些路由器会针对长连接设置空闲超时需要主动在客户端配置 TCP keepalive 的内核参数而不是只靠应用层空包。Linux 下常见做法是设置net.ipv4.tcp_keepalive_time 30。5.5 现象zip 包解压后编译缺依赖运行时提示找不到某符号原因这个 zip 里的二进制或源码生成于特定版本依赖环境。常见的有libpj版本不对、openssl 版本太新导致 TLS 回调签名不一致还有就是你解压时用了系统 zip 工具结果没有保留可执行权限。解决先看 README 里要求的依赖版本然后在干净环境编译如果 zip 里带了.so或.a先确认它们和你系统架构一致不要直接拷到 x86 机器上跑。用ldd检查一遍可执行文件的依赖缺什么补什么不必重新编译全部源码。6. 用 tshark 验证一次完整 MSRP 会话把“能跑”变成“能证明”最后一件事我建议你把这套流程固化成每次调试的固定动作不只是看日志而是直接抓包验证。日志是你程序视角看到的抓包是协议栈真正发生的两者对照能发现大量隐藏问题。操作很简单同时抓信令和媒体两路流量sudo tshark -i any -f tcp port 5060 or tcp port 9000 -Y sip || msrp -w msrp.pcap跑完一个完整会话后用下面的过滤条件检查关键帧tshark -r msrp.pcap -Y msrp我一般重点看三个地方INVITE 里的 SDP 是否包含 mmessageTCP 三次握手是否发生在 183 之后以及最后一个 SEND 的尾标记是不是$。这些通过 tshark 的msrp协议解析字段都可以直接看到。做完整条链路后我自己的习惯是写一个小的验证清单把 SDP、连接方向、Byte-Range、尾部标记、keepalive 间隔五项逐条勾掉再交给测试同事去验收避免反复“能跑但说不出原因”的状态。希望这份笔记能帮你把 MSRP 这条常常被当成黑匣子的通道彻底打开调试和对接都少走点弯路。本文还有配套的精品资源点击获取 MSRP客户端开发指南：从SIP SDP协商到消息传输与调试避坑
简介MSRPMessage Session Relay Protocol是SIP会话中承载富媒体内容的重要扩展这套C源码以轻量实现展示了SIP客户端如何集成MSRP协议适合VoIP、即时通信及SIP协议栈开发者作为参考样例。压缩包内共46个文件解压后约56KB其中23个.h头文件与16个.cpp源文件构成主体并附带Makefile、vcproj工程文件以及说明文档便于在Linux或Windows工程环境中直接编译研究。具体代码覆盖MSRP URI解析、报文头部与消息体封装、TCP连接管理、状态与报告处理等关键模块协议栈按连接、地址、消息、报告等模块拆分组织基于SIP INVITE协商完成后通过SETUP/SEND/TEARDOWN方法完成通道建立、消息传输与会话释放从URI构造、SEND消息分片到成功/失败报告解析均有实现可对照逻辑路径清晰基本构成一套可学习的MSRP协议栈雏形。目前已有135人访问学习适合期望快速理解SIP与MSRP交互细节、需要构建客户端协议模块的开发者。1. 把 MSRP 塞进 SIP 会话里这个 zip 到底解决什么问题MSRP 全称 Message Session Relay Protocol是跑在 SIP 信令之上的一条消息/文件传输通道。很多从业者第一次见到它是在 IMS 里的即时消息、企业通讯录推送、或者语音网关的“大容量留言”场景——SIP INVITE 里带一段 mmessage 的 SDP协商完就建起一条 TCP 连接消息以 MSRP SEND 请求的方式在这条连接上交换。标题里这个 “MSRP.zip_SIP Client MSRP” 压缩包本质就是一份可以直接落地的 SIP MSRP 客户端实现解压后既能当信令模块用也能把 MSRP 收发消息的细节封装好省去你从零啃 RFC 4975 的功夫。适合谁做 SIP 终端、IMS 应用、企业 IM 网关、或者给海康类平台做 SIP 对接的工程师都适用。它能帮你少踩 TCP 分片、Byte-Range 拼接和 SDP 协商这三种最容易翻车的坑。2. 拆开 zip 看门道SIP 信令里那段 SDP 就是 MSRP 的“会话合同”拿到这个MSRP.zip压缩包别急着编译。先把它当成一个SIP 信令服务器源码 消息客户端的组合来读你才能理解为什么会有那么多文件名里重复 msrp、sip。我一般先解压到一个固定目录比如/opt/msrp_client/然后按“信令层 → 消息层 → 传输层”的顺序看代码。大多数打包的 SIP Client 都会有一个负责 INVITE 事务的模块一个负责 MSRP 消息收发的模块还有一个管理 TCP 连接的 transport 模块。如果你打开源码发现这三个模块是揉在一个文件里的建议先花时间拆清楚否则后面调试字节偏移会非常痛苦。2.1 SDP 协商mmessage 一行决定了你的 MSRP 会话怎么建MSRP 会话不是凭空出现的它必须由 SIP 信令先“牵线”。客户端发起 INVITE 时SDP 里不再是 audio/video而是这样一段mmessage 9000 TCP/MSRP aaccept-types:text/plain message/cpim apath:msrp://192.168.1.10:9000/abcdefgh;tcp asetup:active aconnection:new这段 SDP 的含义m 行声明了传输协议是 TCP/MSRP端口 9000apath 是 MSRP 层的 URI末尾的;tcp表示用 TCP 承载asetup 则告诉对端谁主动建 TCP 连接。逻辑说明setup:active表示本端是主动连接方对端应答时通常会回setup:passive于是本端立刻向 apath 里的 IP 和端口发起 TCP 连接。参数说明accept-types 决定了这条会话能传什么类型如果对端不支持你列出的类型会回 488 Not Acceptable Here所以别把一种类型写死常用做法是写text/plain message/cpim。你可能会遇到一种情况INVITE 里没带 mmessage只带了 audio。那 MSRP 根本起不来终端会一直等对端发 183。很多人在这里踩坑——拿普通 SIP 话机调试 MSRP 客户端结果话机只协商 audio消息自然发不出去。所以拿到这个 zip 后第一件事是确认它的 INVITE 构造代码里 SDP 是硬编码 mmessage还是开放了接口让你自己填。2.2 MSRP 消息格式SEND 请求和 200 响应是怎么对上号的SDP 协商完成后两条 TCP 连接上跑的就是 MSRP 消息了。MSRP 请求长这样MSRP a54h9 SEND To-Path: msrp://192.168.1.20:9000/abcdef;tcp From-Path: msrp://192.168.1.10:9000/abcdefgh;tcp Message-ID: 1234567890 Byte-Range: 1-100/100 Content-Type: text/plain Hello, MSRP! -------a54h9$关键点说明第一行MSRP a54h9 SEND是方法行a54h9是事务标识对端回复时会把 SEND 换成200 OKByte-Range 的1-100/100表示这是唯一分片总共 100 字节、当前是第 1 到第 100 字节消息尾部用-------a54h9$表示结束如果还有后续分片则用-------a54h9来告诉对端“更多分片要来了”。这个尾标记是新手最容易搞错的地方$和差一个字符写错的话对端会一直等后续分片直到 TCP 超时。我建议拿到 zip 后先不要看它的 SEND 构造代码而是用 tcpdump 抓一次真实会话把上面这段结构在抓包里对照一遍。这个zip 里如果有示例抓包文件优先看那一个比读十遍代码都有用。2.3 最小可复现解压、编译、跑通一次 MSRP 会话的命令这个 zip 里的客户端如果带 Makefile 或 CMakeLists编译路径一般是这样cd /opt/msrp_client unzip MSRP.zip ls -la # 看有没有 README 或 config.example ./configure --with-sip-stackpjsip make -j4逻辑说明第一行把压缩包解压到固定目录configure这一步常见做法是让你选择 SIP 信令栈——标题里这个客户端通常有 PJSIP 和自带轻量栈两个选项我一般选 PJSIP因为它的事务状态机和重传处理比裸写稳定得多。参数说明如果你只做消息传输、不注册到服务器可以用--disable-register之类选项关掉注册模块减少出问题的面。编译完成后跑一个自带的演示程序通常是这样的命令./msrp_client -l 9000 -s sip:msrp-test192.168.1.20如果你不先看 README 就乱跑大概率会在“缺少编译选项”和“运行时找不到配置文件”上浪费半小时。别问我怎么知道的。3. 从零写一个能用的 MSRP SIP Client选型、信令时序和最小实现如果你不想依赖 zip 里那份现成代码或者你手里的 zip 只提供了库文件而没有源码那完全可以自己写一个最小实现。方向上有两条路一是基于 PJSIP 的 pjsua 或 pjsip 高层 API 改二是只依赖一个 SIP 事务栈自己拼 SDP 和 MSRP 消息。对绝大多数人我推荐前者因为 PJSIP 已经把 SIP 重传、认证摘要、事务超时这些都处理好了你只需要关系 MSRP 消息本身。用裸栈听上去很“硬核”但光是一个 TCP 半开连接的重连逻辑就够你调一整天。3.1 选型为什么我不用 SIPp 而用 PJSIP 扩展一个 Client很多人测试 SIP 的时候会想到 SIPp。但 SIPp 对 MSRP 的支持非常有限它擅长的是 INVITE、REGISTER 这类标准信令压测到了 MSRP 消息层SIPp 根本不会帮你拼接 SEND 请求和处理Byte-Range。所以“SIP 信令服务器源码”可以在你自己的项目里参考但客户端这边我常见做法是直接用 PJSIP 的pjsua_call回调在on_media_update之后自行管理一条 TCP socket。这样做的好处是信令仍然由 PJSIP 负责你只写 MSRP 部分的几百行代码工作量小、坑也少。zip 里那份实现如果也是这么组织的那它的架构就是干净可借鉴的。3.2 最小时序INVITE → 183 → 200 → ACK → SEND一次 MSRP 客户端完整会话的时序是这样的客户端 A 发 INVITESDP 携带 mmessage对端 B 回 183 Session ProgressSDP 里写入自己的 msrp URI客户端 A 确认 B 的 asetup 值如果自己是 active 就往 B 的 TCP 端口建连接B 回 200 OKA 发 ACKTCP 连接建立后A 发 MSRP SENDB 回 MSRP 200 OK需要关闭时A 发 BYE。很多刚上手的工程师会在第 3 步翻车他们以为 183 就代表 TCP 连接已建好实际 183 只是信令层的答复TCP 连接要等你自己去 connect。如果 asetup 写的是 passive那就要等对端主动连你结果对端也没来连两边干等这就是经典的“黑匣子”问题。调试方法很简单在代码里把每步的状态打点打到日志里看看卡在哪个阶段。3.3 最小 Python 脚本不依赖任何库先跑通 MSRP SEND如果你只是想验证 MSRP 消息拼接逻辑不一定要先编译整个 C 工程。我用 Python 写过一个最小模拟器核心就是对 TCP socket 做一次原始的 MSRP 请求交换import socket MSRP_MSG ( MSRP 1a2b3 SEND\r\n To-Path: msrp://192.168.1.20:9000/abcdef;tcp\r\n From-Path: msrp://192.168.1.10:9000/abcdefgh;tcp\r\n Message-ID: 9876543210\r\n Byte-Range: 1-12/12\r\n Content-Type: text/plain\r\n \r\n hello msrp\r\n -------1a2b3$\r\n ) sock socket.create_connection((192.168.1.20, 9000), timeout5) sock.sendall(MSRP_MSG.encode()) resp sock.recv(4096) print(resp.decode()) sock.close()逻辑说明这段脚本构造了一个完整的 MSRP SEND 帧然后连到对端的 MSRP 端口 9000。对端如果是合法 MSRP 服务端会返回MSRP 1a2b3 200 OK头部里会带上原事务 ID表示消息已接收。参数说明Byte-Range: 1-12/12中的 12 必须和hello msrp的字节数一致——注意末尾有一个换行符实际长度是 11 个字符加 1 个 CRLF所以写 12 是安全的。如果你分片数写错对端会回复413或直接不回。这个脚本最大的价值是帮你把 MSRP 帧结构彻底吃透之后再去看 C 工程代码一眼就能看出它哪里写错。4. 从 demo 到生产IMS Trunk 与语音平台对接要调的 5 个 MSRP 参数跑通 demo 只是第一步。真要把它用到set sip voice trunk ims on router这类网关注册场景或者跟海康平台做 SIP 对接时有 5 个参数你必须逐一校一遍。这些参数在 zip 里通常散落在配置文件中默认值往往和实际网络环境不匹配直接套用就会遇到莫名其妙的消息丢失。参数默认常见值生产建议值说明asetupactive听 SDP 对端决定两端都 active 会导致连接重入Byte-Range 分片大小无1024 或 2048 字节大消息不切片会被中间网元丢弃MSRP keepalive无每 30 秒发一个空 SEND防止 NAT 和运营商超时断连最大消息大小无按平台规格设常见 5MB超过后会回 413 拒绝TLS 模式tcpmsrps明文 TCP 在跨网段时容易被丢4.1 apath 和路由谁决定 MSRP 消息往哪走MSRP 的 SDP 里apath有两个作用一是告诉对端你愿意接收消息的 URI二是作为 SIP 消息路由的补充。在 IMS 场景里S-CSCF 会通过 Path 头来定位用户归属但 MSRP 的连接是端到端直连的中间最多经过一个 MRF 或 SBC 做中继。如果你在网关注册后发现 MSRP 消息能发出去但收不到八成是 apath 里写的地址是内网 IP对端回包打到内网直接被防火墙丢弃。常见做法是在 SDP 里填公网可达的地址并且把端口固定下来不要用 ephemeral 端口。4.2 大消息分片为什么大于 4KB 的消息会被静默丢弃很多 MSRP 客户端在发送超过 4KB 的消息时会突然失败这是因为 TCP 层会分段但 MSRP 层面要求你在一个 SEND 帧里明确声明Byte-Range。如果你把整个 10MB 的消息塞进一个 SEND 帧中间网元可能因为缓冲区溢出直接断开 TCP 连接。正确做法是应用层把消息切成 1KB–2KB 的块每个块发一个 SEND 请求第一块的 Byte-Range 写1-n/total中间块尾部用最后一块用$。我在实际对接中常用 1024 字节分片这样既能避开 MTU 问题也不会因为分片太多导致 CPU 消耗过高。4.3 NAT 穿透与 keepalive别让 TCP 连接被静默回收MSRP 使用长连接在 NAT 后面的客户端如果长时间不发数据NAT 映射会老化对端的 TCP 连接状态也会被中间设备强制清理。最直接的现象就是消息发出去后一直收不到 200客户端超时后重发又被对端以事务冲突拒绝。要解决这个问题除了在 SBC 上开 rport 保持绑定客户端自身也必须周期性发送 keepalive。MSRP 没有专门的 keepalive 方法常见做法是发一个带空消息体的 SEND头部的 Message-ID 每次变化对端收到后回 200这样连接就被续期一次。我一般把间隔设在 25 到 30 秒比运营商 NAT 老化的典型 60 秒留出一倍余量。4.4 认证与 TLSmsrps 端口的选择和证书坑真实网络里 MSRP 基本不会跑明文 TCP。SDP 中的 m 行如果写成TCP/MSRP就是明文TCP/MSRPS才是 TLS。在 IMS 环境中虽然信令走 SIP over TLS媒体层面同样要求 MSRP over TLS。这时会引入一个常见坑客户端用自签名证书连对端对端校验失败直接握手断掉。我建议在你的on_establish回调里先打印对端证书指纹再决定要不要做深度校验如果是在小范围试点可以把对端 CA 加进本地信任库而不是全局关闭验证否则后面安全审计会让你返工。4.5 与既有系统对接海康平台、IMS Trunk 与 zip 里的配置模板如果你是要做“海康平台 SIP 对接配置”这类工作往往不只是调 MSRP还要关注 SIP 注册、Keepalive 和呼叫流程。zip 里一般会附带若干平台对接配置模板命名可能是config.platform.example里面已经写好了常见的海康、华为 IMS 平台的参数。我第一次做这类对接时犯过一个很傻的错误直接把模板里的setup:passive改成了active结果两边互相等待对方建连。后来养成了习惯配置文件里每个参数都记下来源是平台文档里来的还是模板自带的这样出了问题能往回查不用把责任归给“玄学”。5. 避坑MSRP 客户端调试里最常见的 5 个翻车现场5.1 现象INVITE 发出后一直收不到 183客户端界面永远“呼出中”原因对端是普通 SIP 终端或旧版软交换只支持 audio不支持 message。INVITE 里的 mmessage 被对端忽略或者直接被回 488。解决在抓包确认 SDP 中 m 行确实存在且accept-types包含对端能识别的内容类然后查对端日志是否显示拒绝原因。另一个隐蔽原因是 zip 里附带的客户端默认把 INVITE 的 Content-Disposition 写成了session而正确写法是render——这也能导致部分平台不识别。5.2 现象大文件发送时对端只收到第一块后续分片全部丢失原因Byte-Range 的尾标记写错了。第一块用结尾最后一块用$如果所有块都用$对端在收完第一块后以为事务结束后续 SEND 被视为新事务但因为 Message-ID 一致对端会直接忽略。解决在代码里把分片函数单独抽出来测试用 3 个分片分别检查尾部标记。另外确认每块的字节偏移是连续的比如第一块1-1024/2048第二块必须是1025-2048/2048如果出现跳跃对端会回 481 并关闭会话。5.3 现象SEND 发出去后收到了 200但业务层面没有触发“消息已读”原因MSRP 的 200 是传输层确认服务端收到并落盘了但业务逻辑没处理。这在对接 IMS 时很常见S-CSCF 帮你把 MSRP 消息转给了 AS但 AS 上的业务逻辑没被触发。解决看 200 OK 里有没有附带Report-To头如果应用需要接收方回执你必须在 SDP 里声明aaccept-types: message/cpim同时业务端要支持 CPIM 格式的Message-ID关联。很多 zip 里的 demo 只实现了 SENDREPORT方法没有实现导致上层看不到完整的消息状态。5.4 现象TCP 连接建立后一段时间没消息再发 SEND 就超时原因NAT 或中间防火墙回收了空闲连接但客户端没有感知仍然往旧 socket 写数据。解决在传输层做 socket 错误检测写失败时立即触发重建连接在会话层做 keepalive每 30 秒发一次空 SEND。另外一个容易忽略的点有些路由器会针对长连接设置空闲超时需要主动在客户端配置 TCP keepalive 的内核参数而不是只靠应用层空包。Linux 下常见做法是设置net.ipv4.tcp_keepalive_time 30。5.5 现象zip 包解压后编译缺依赖运行时提示找不到某符号原因这个 zip 里的二进制或源码生成于特定版本依赖环境。常见的有libpj版本不对、openssl 版本太新导致 TLS 回调签名不一致还有就是你解压时用了系统 zip 工具结果没有保留可执行权限。解决先看 README 里要求的依赖版本然后在干净环境编译如果 zip 里带了.so或.a先确认它们和你系统架构一致不要直接拷到 x86 机器上跑。用ldd检查一遍可执行文件的依赖缺什么补什么不必重新编译全部源码。6. 用 tshark 验证一次完整 MSRP 会话把“能跑”变成“能证明”最后一件事我建议你把这套流程固化成每次调试的固定动作不只是看日志而是直接抓包验证。日志是你程序视角看到的抓包是协议栈真正发生的两者对照能发现大量隐藏问题。操作很简单同时抓信令和媒体两路流量sudo tshark -i any -f tcp port 5060 or tcp port 9000 -Y sip || msrp -w msrp.pcap跑完一个完整会话后用下面的过滤条件检查关键帧tshark -r msrp.pcap -Y msrp我一般重点看三个地方INVITE 里的 SDP 是否包含 mmessageTCP 三次握手是否发生在 183 之后以及最后一个 SEND 的尾标记是不是$。这些通过 tshark 的msrp协议解析字段都可以直接看到。做完整条链路后我自己的习惯是写一个小的验证清单把 SDP、连接方向、Byte-Range、尾部标记、keepalive 间隔五项逐条勾掉再交给测试同事去验收避免反复“能跑但说不出原因”的状态。希望这份笔记能帮你把 MSRP 这条常常被当成黑匣子的通道彻底打开调试和对接都少走点弯路。本文还有配套的精品资源点击获取