简介彩信信令流程是移动通信网络中一项关键业务流程涉及移动终端、MMSC、WAP 网关、短信中心与梦网邮箱等多类网元。该 PDF 面向通信工程、网络优化与核心网运维人员用于理解彩信从发送、通知、提取到超时转移的完整信令链路。资源共 1 个文件压缩包大小约 1.06MB便于随时查阅。内容详细拆解了终端到终端业务的三大场景立即取、超时转梦网相册、非 MMS 终端处理覆盖发送方通过 WAP 网关发起连接、MMSC 归属判断与转发、短信中心下发 push 通知、接收方 PDP 上下文激活取信等关键步骤并说明了 10 分钟超时、48 小时有效期等时间窗口对消息路由的影响。读者可借此梳理各网元之间的交互关系快速掌握彩信信令流程的排查思路与协议要点。目前已有 81 人学习下载适合作为通信信令入门或日常查阅的参考资料。1. 彩信信令流程为什么我要把这份 PDF 当故障手册读“彩信信令流程”这六个字拆开看就是一条从发送方手机到接收方手机的消息链提交、存储、通知、取信、回执每一环都有对应的协议消息和参数缺一步都会让体验卡住。这类 PDF 的价值不在“彩信是什么”的科普而在把先后顺序、超时窗口、重试逻辑固定成一份能对照排查的手册遇到问题直接定位“现在卡在哪一环”。它适合三类人看终端协议栈或 MMS 客户端开发MMSC 与增值平台 VASP 的联调工程师以及拿信令分析工具做网络定位的测试人员。读完不需要背下 3GPP TS 23.140 的每一页但能知道哪条消息带 Transaction-ID哪条决定“未取”状态哪条触发投递报告这份材料就算读透了。2. 彩信信令流程的前置骨架先分清 MM1 到 MM7再谈时序彩信信令里最容易翻车的地方是大家把“终端到 MMSC”和“MMSC 到 MMSC”混在一张图里讲。实际定位问题时我习惯先把流程按接口切开因为不同接口的排查手段完全不一样。终端侧抓包能看到的是 MM1跨运营商查日志要看的是 MM4SP 接入出问题则基本都落在 MM7。接口不先分清后面所有时序都是空的。2.1 四个关键接口一张表先立住MM1、MM3、MM4、MM7接口两端承担的工作常见协议形式MM1终端与 MMSC彩信提交、通知响应、内容取回、回执交互HTTP POST/GETbody 是二进制 MMS PDUMM3MMSC 与外部服务器彩信转邮件、短信、语音信箱等异系统互通SMTP、SMPP、HTTPMM4MMSC 与 MMSC运营商间或厂商间转发彩信SMTP/MIME消息类型 m-forward-req/resMM7VASP 与 MMSCSP/平台提交彩信、查询状态、接收回执SOAP/HTTPXML 封装这张表对应到日常排障里非常直接如果用户在终端上提交总是超时先查 MM1 的 APN 和 MMSC 地址如果本地发送正常但异地用户收不到重点看 MM4 的 SMTP 会话和对方 MMSC 返回的状态如果某个 SP 的彩信带不起图去查 MM7 的 XML 里 content 字段有没有被转义破坏。别看这些接口都叫“彩信”它们的报错信息经常是不同体系里的东西混在一起只会越查越乱。我一般拿到一份信令流程材料第一件事就是画一条横向的接口链终端→MM1→归属 MMSC→MM4→对方 MMSC→MM1→对方终端。这条链上的每个箭头就是一个独立的可观测点。凡是有人说“彩信丢了”我都先问一句丢在哪个箭头之间。明确了箭头再谈数据包和日志。2.2 WAP Push 与取内容为什么走两条路彩信通知用的是 WAP Push也就是一条可以附带在短消息承载里的 PUSH 消息里面有消息类型、Transaction-ID、发送方地址、主题、消息大小、过期时间以及取信用的 URI。这条通知非常轻几十上百字节就能搞定目的是让接收方先知道“有一条彩信来了”而不是直接把几千字节的 SMIL 和图片推到手机上。早期 GSM 网络里这条 PUSH 走的是 SMS 通道到了 3G/4G 时代可以用数据通道直接下推但消息类型和核心字段没有本质变化。真正取信的时候是另一条路。接收方终端收到通知后根据消息里的 URI 发起 HTTP GET把完整内容从 MMSC 拉回来。这样做的好处很实际终端可以按用户设置决定“自动取还是等用户点开再取”弱网下也可以分段重试不至于逼着 MMSC 向所有终端盲目推数据。信令流程材料里如果只画了“发送到接收”一条线很容易漏掉这个分叉实际网络里通知负责唤醒取信负责搬运两条路承载不同数据量超时和重试策略也不是一套。这个设计直接影响参数配置。通知下发如果被短消息中心限速或丢弃用户永远不知道有彩信来取信链路如果 APN 配置错误用户点了下载却拿不到内容。所以排查到一半必须先判断当前消息在通知段还是取信段再决定是查短信网关日志还是查 HTTP 日志。2.3 一套流程本质上是消息状态机如果跳出协议字段把彩信信令流程当作状态机看会更容易理解为什么有那么多“看似正常但结果不对”的问题。一条彩信在 MMSC 侧通常经历这些状态提交成功、已存储、通知已下发、等待取信、部分取信取了一半断链、完整取信、已读回执、过期删除。每个状态之间都有超时和重试文档里画的箭头越多实际上要维护的状态分支就越多。我实际调过的 MMSC 里最容易出事故的状态是“等待取信”和“取信中断”。这两个状态时间窗很长涉及终端主动重试、MMSC 超时回收、用户重复点击下载等并发行为。一套流程文档如果只画了一条完美直线那它只适合演示不适合排障真正有用的材料会把终端重试多少次、MMSC 多久清一次存储、通知过期后还能不能取信写清楚。3. 一条彩信从发送到接收的完整信令流程每一跳的关键字段与时序这一章把流程从接口层落到消息层按时间顺序走一遍发送方终端先把彩信提交到 MMSCMMSC 确认后向接收方下发通知接收方终端再回来取内容最后按需把投递报告回给发送方。每条消息里真正决定成败的字段就那几个字段值写错了比链路断了更难查。3.1 发送端提交MM1_submit 请求里哪些字段不能省发送方手机组好彩信后通过 HTTP POST 发给 MMSC 的接收地址Content-Type 是 application/vnd.wap.mms-messagebody 是一个二进制编码的 MMS PDU消息类型为 m-send-req。常见的实现里POST 也可能带 Authorization 头用于给用户计费和鉴权但这部分各厂商差异较大不能拿一套标准套所有网络。字段典型取值作用X-Mms-Message-Typem-send-req告诉 MMSC 这是一次提交X-Mms-Transaction-ID终端生成的十六进制串关联提交请求与提交响应X-Mms-MMS-Version1.0 / 1.1 / 1.3版本协商From终端用户地址计费和回执路由依据To / Cc / Bcc接收方地址接收方列表Bcc 不会带回执Subject标题文本通知给接收方预览Message-Classpersonal / advertisement / auto决定终端如何对待这条消息X-Mms-Expiry相对时间或绝对时间MMSC 保留消息的期限X-Mms-Delivery-Reportyes / no是否要求投递报告终端提交后MMSC 回的是 m-send-conf里面带 response-status、response-text 和一个 Message-ID。这一步排障时注意区分“HTTP 200 OK”和“业务层成功”哪怕 HTTP 层返回 200MMSC 也可能在 PDU 里写了一个错误状态码比如地址无效或内容过大。只看 Wireshark 里的 HTTP 状态容易被这个假象带偏。提示提交阶段最容易忽略的是 Expiry。某些定制 ROM 发送时默认把过期时间设成 0MMSC 理解为立刻过期消息刚入库就被清理接收方收到通知也取不到内容。建议联调时把发送时长的取值固定下来不要在真实用户环境里反复试。3.2 接收方通知与取信Notification.ind、NotifyResponse 与 Retrieve.confMMSC 收到并存储彩信后会向接收方下发 m-notification-ind也就是接收方手机上出现的“收到一条彩信”提示。这条消息里有 Transaction-ID、From、Subject、Message-Size 和 X-Mms-Expiry接收方终端据此决定是否自动下载。这里补充一个细节为了不把手机内存撑爆终端通常会先看 Message-Size超过阈值就只显示通知等用户手动点开。接收方终端收到通知后的典型行为分两步先回一个 m-notifyresp-ind告诉 MMSC“通知收到了我准备取信”然后发起 HTTP GET请求消息类型为 m-retrieve-req。MMSC 返回的内容是 m-retrieve-conf里面装着 SMIL 和各个附件也就是用户最终看到的彩信。有些终端实现里两步会合并GET 请求头里直接带 Transaction-IDMMSC 见到后就知道这是取信请求不再单独等 NotifyResponse。这个环节的时序是整个流程文档里最需要标注的部分。通知发了不代表终端一定会取终端取了一次不代表 MMSC 会立即清库。如果终端和 MMSC 之间的时间差太大或者取信请求里带的 Transaction-ID 与通知里的对不上MMSC 会返回取信失败。反之如果终端恰好取信时网络断开它会按自己的重试策略再发一次 GET这时 MMSC 必须保证重复请求不会让用户收到两遍内容或至少能正确处理重复取信。3.3 跨运营商转发与投递报告MM4_forward 在什么时候出现如果接收方不在发送方归属的 MMSC 范围内发送方 MMSC 要把彩信转发给接收方的 MMSC走的是 MM4 接口基于 SMTP 或专用 IP 承载。转发消息类型是 m-forward-req对方 MMSC 处理后回 m-forward-res。这一步对用户无感但对运营商的互联互通质量影响很大。MM4 转发时有一个关键字段叫 X-Mms-Message-ID它跟随彩信在整个转发过程中保持不变用来做去重。为什么需要去重因为 SMTP 传输可能超时重发接收方 MMSC 如果只看收件人可能把同一条彩信处理两遍只有拿 Message-ID 做幂等才能保证重复到达的邮件被安全丢弃。另有一个字段 X-Mms-Delivery-Report发送方要求回执时会在转发请求里带上由接收方 MMSC 在最后阶段触发回执。回执下发不经过 MM4 的文件内容部分它是一条独立的投递报告消息类型为 m-delivery-ind由接收侧 MMSC 生成后沿着 MM4 反方向送回发送侧再由发送侧 MMSC 以 WAP Push 方式告知发送方手机。这里要注意如果跨运营商时接收方 MMSC 没有把投递结果正确映射回原始 Message-ID发送侧就收不到可关联的回执表现为“用户发出去了但手机一直没显示送达”。4. 把流程变成可复现的操作抓包、解码和最小模拟光看流程图只能建立印象真正能用来判断问题在哪一环的手段是抓包加日志关联。彩信信令流程不是纯黑匣子只要你能在手机侧或 MMSC 网关侧抓到 HTTP 会话就能把提交、通知、取信、回执四段消息按 Transaction-ID 串起来。4.1 Wireshark 抓包过滤策略常见做法是在终端开热点、把手机流量指到测试服务器或者在 MMSC 前置机镜像流量然后用 tcpdump 落包。无线空口抓包不是人人都有条件但 HTTP 这一段很容易彩信终端与 MMSC 的交互基本都落在 80/8080 端口用一条过滤规则就能抓到全部关键消息。# 在网关侧或测试机上抓 MMS 相关 HTTP 会话 sudo tcpdump -i eth0 -s 0 -w mms.pcap tcp port 80 or tcp port 8080 # 如果只想看某个终端的会话加 host 过滤 sudo tcpdump -i eth0 -s 0 -w mms_ue.pcap host 192.168.1.100 and (tcp port 80 or tcp port 8080)抓到的 pcap 导进 Wireshark先用http ip.addr MMSC地址过滤再按时间排序。注意 Wireshark 不一定自动识别 MMS 二进制 PDU 的 message-type 字段如果看不出来需要右键解码为 application/vnd.wap.mms-message或者直接把 HTTP body 导出来用十六进制查看。这里有个经验不要只盯 HTTP 状态码要把 body 里的二进制 PDU 二进制解出来读字段因为 MMSC 的真实业务结果都在 PDU 里。4.2 用 curl 最小模拟一次 MM1 提交拿到一段真实抓包后最稳的复现方式是把里面的二进制 PDU 原样导出再原样发给 MMSC。这样不用自己从零拼二进制 PDU也能排除终端协议栈的变量。# 常见做法先用 curl 原样重放抓到的 m-send-req PDU curl -v -X POST http://mmsc.example.com/servlets/mms \ -H Content-Type: application/vnd.wap.mms-message \ -H Accept: application/vnd.wap.mms-message \ --data-binary send_pdu.bin这里send_pdu.bin必须是从真实终端抓包中导出的原始 body而不是把十六进制文本直接粘进去。重放前先确认 MMSC 不会因为重复 Transaction-ID 拒绝你否则结果没有参考意义。重放时重点看两个返回值HTTP 层的响应码以及响应 body 里的 response-status。前者代表网络链路是否通后者代表 MMSC 是否接收了这条业务请求。如果连不上 MMSC优先检查终端配置里的 MMSC 地址、APN 类型、代理端口三项。很多测试环境里MMSC 地址配成域名但 DNS 解析到了内网无关机器导致 curl 一直超时这时先dig short或nslookup确认解析结果是否与现网一致。4.3 用三个字段做端到端日志关联抓包只是拿到了网络侧的那一面MMSC 内部处理结果还得看业务日志。把两边串起来靠的是几个跨系统不变的标识字段关联字段出现在哪里用来解决什么问题X-Mms-Transaction-ID终端侧 PDU、MMSC 接入日志关联一次提交或一次取信请求X-Mms-Message-IDMMSC 内部消息记录、MM4 SMTP 信封跨系统追踪同一封彩信Date / X-Mms-Date终端发送时间、MMSC 入库时间校准时间差判断是否过期我一般会把 MMSC 接入日志按 Transaction-ID 排序再和抓包里的时间戳对齐。这里有个不算少见的现象终端已经发了取信请求但 MMSC 日志里没有对应记录多数是负载均衡把相同 Transaction-ID 的请求分到了不同节点会话关联失败。这时候不要急着怀疑协议先查上层路由。5. 彩信信令流程排查笔记五个踩坑点和对症处理这一章写的是我在现网和联调环境里真正踩过的坑。每条都按“现象→原因→解决”的组织方式写方便你拿自己的日志对照。彩信信令流程的多数问题不是协议看不懂而是某个字段或者某个时序配置不对让整个流程卡死。5.1 现象一发送方显示已发出接收方迟迟没有通知原因分两类一是 MMSC 收到提交后WAP Push 通知没送出去二是通知送出去了但接收方终端没把它当作有效彩信提示。前者要查 MMSC 到短消息中心或 PUSH 网关的下发结果码后者要查通知里的消息类型和版本号。解决时先把接收方换一张已知可用的测试卡复测排除终端省电策略或后台限制。再看 MMSC 侧有没有产生 m-notification-ind如果产生了但最终下发失败去查 PUSH 网关回执如果 PUSH 网关显示成功但手机没弹通知多半是终端把通知当作垃圾消息过滤了需要检查终端里的消息设置和号码白名单。5.2 现象二通知已经到了一点开就提示“内容不存在”这个现象最常见的原因有三个过期时间太短、MMSC 存储被清理、取信 URI 在通知里已经失效。用户在通知到达后没有立刻查看隔了几个小时才点而消息过期时间设置的是 2 小时那 MMSC 早就把内容和通知一并删掉了。解决方法是先在 MMSC 里查消息状态是不是 deleted/expired如果是把配置里的过期时长调长。注意有些网络规范对过期时间有上限比如不能超过 48 小时调得太长会增加 MMSC 存储压力。另一个可能被忽略的点终端时间与服务器时间差太多导致终端计算的绝对过期时间早于 MMSC 的实际删除时间用户看起来就是“通知还在但取不到”。5.3 现象三弱网下用户重复点下载MMSC 返回重复请求错误终端在弱网里发出去一个取信 GET超时没有收到响应用户又点了一次这时 MMSC 会收到两个相同 Transaction-ID 的取信请求。有的 MMSC 实现会直接把第二个请求判为异常不会返回内容导致用户怎么点都失败。这种问题要区分对待如果第一个请求其实已经成功只是响应在回程丢了正确做法是 MMSC 对相同 Transaction-ID 做幂等返回第一次存储的结果如果第一个请求根本没到达第二个请求应该正常处理。联调时建议把终端重试间隔调成 30 秒以上同时让 MMSC 日志能打印 Transaction-ID便于确认重复请求到达顺序。5.4 现象四发送侧要求了投递报告但一直收不到回执很多定制终端在发送界面上有“送达报告”开关但开关不一定会在 PDU 里把 X-Mms-Delivery-Report 置成 yes。如果发送 PDU 里根本没这个字段MMSC 按默认“不要求回执”处理后面所有环节都不会产生投递报告。解决的办法是先抓一次真实发送 PDU确认开关是否真的写进了协议字段。确认置 yes 之后还没回执就要看接收侧是否产生了投递报告以及跨运营商时 MM4 反向转发是否正确。回执路由依赖 From 地址和原始 Message-ID如果接收侧把 Message-ID 改写过发送侧就关联不上。遇到这种情况只能通过 MMSC 日志找原始消息手工确认回执内容是否完整。5.5 现象五抓包里全是分段报文看不到完整彩信内容彩信附件一大HTTP body 会被拆成多个 TCP 段Wireshark 默认按包显示时看起来就是一堆乱序数据根本没法直接读。还有人会碰上 MMSC 对响应做了压缩传输HTTP body 是 gzip 内容十六进制里看不到 PDU 头。处理方法是先在 Wireshark 里开启 TCP 流重组然后对 HTTP 内容做“导出对象”或“追踪流”把完整响应 body 保存成文件。如果 body 头是1f 8b开头说明是 gzip先解压再解析。解析二进制 MMS PDU 时不要把十六进制直接复制到在线转换器里长度容易出错最好让脚本按字节流一步到位导出字段列表。6. 用 Transaction-ID 和时间窗做一次逆向验证前面几章讲的是顺着流程走最后一章讲一个我常用的逆向验证习惯拿到一份新环境的彩信信令流程材料不要急着信先做一次最小验证把时序和字段读出来再判断它跟实际网络是否一致。具体做法是构造一条测试消息从提交开始记录以下四列时间、Transaction-ID、消息类型、结果。提交阶段记录 POST 请求和响应通知阶段记录 m-notification-ind 是否到达取信阶段记录 GET 以及返回的状态码。把这张表做出来以后和手里的 PDF 流程文档逐行对照偏差最大的地方往往就是需要本地化适配的参数。时间Transaction-ID消息类型结果10:00:01.1236A3F…m-send-req200 OK10:00:01.8916A3F…m-send-confresponse-status 成功10:00:03.2048B12…m-notification-ind通知下发10:00:06.5778B12…m-retrieve-req取信成功附件 3 个对照时我会特别看两个时间窗一个是提交到通知的时间差另一个是通知到取信的时间差。第一个差值如果大于 5 秒基本能确认 PUSH 网关排队或短信中心限速不是终端逻辑问题第二个差值如果特别小说明终端没有等用户确认就直接自动取信符合 auto 消息类的行为但也可能带来弱网下的失败。这几年我做彩信联调养成的习惯是先标出每个环节谁是主动方、谁是被动方再用 Transaction-ID 把分散的日志串起来。彩信信令流程里的不少“玄学”问题最后都落在字段关联和时间校准上而不是协议本身。希望这份基于一线经验的流程拆解能帮你在自己的网络里少走一段弯路也希望你手里的排障日志越翻越薄。本文还有配套的精品资源点击获取