彩信信令流程详解：从MM1到MM4的完整链路与5G承载排错

简介面向移动通信与核心网学习者的彩信信令流程图解资料以PDF电子书形式系统梳理彩信从发送到提取的完整信令链路。资源围绕终端到终端主场景逐一拆解WAP网关、MMSC重定向、短信中心通知、PDP上下文激活等关键环节并区分立即取、超时转梦网相册、非MMS终端三种典型情况便于理解不同用户状态下的处理差异与超时机制。包体为1个PDF文件压缩包大小约1.06MB内容结构清晰适合运营商工程师、网络优化人员及通信专业学生阅读也可作为核心网信令面试的复习参考。目前已有81人学习文件虽轻量但信令时序、组件交互和异常分支覆盖完整可帮助读者建立从发起到送达的全局视图尤其对MMSC归属判断、10分钟超时转存、48小时有效期等关键细节有直观呈现。1. 彩信信令流程是什么从SMSC通知到MMSC取信的完整链路很多工程师能一口气画出VoLTE注册和呼叫的几十条信令但彩信一进来就有点尴尬手机上明明开着数据HTTP也能上网偏偏彩信发不出去或者收不到。原因在于彩信信令流程比普通上网多了一个“两层皮”的结构发送方先把m-send-req提交给MMSC接收方并不是直接收到媒体文件而是先被SMSC下发一条携带Content-Location的m-notification.ind“空短信”再由手机主动去MMSC取回m-retrieve.conf。这条链路由MM1到MM4四个接口拼接而成承载着WSP/WTP、SMTP和二进制PDU三套协议栈。本文按“接口地图→发送信令→投递信令→5G承载与排错”的顺序把这条链路拆开讲透适合核心网维护、无线优化、终端协议栈和自动化测试的工程师对照抓包日志使用。2. 先看懂彩信信令流程的接口地图MM1到MM4的协议栈2.1 彩信不是HTTP直连WSPWTP才是现网主流终端到MMSC的MM1接口直观上很像一个HTTP POST请求但现网大部分落地实现走的是WAP协议栈里的WSPWireless Session Protocol和WTPWireless Transaction Protocol而不是我们熟悉的HTTP over TCP。WTP层跑在UDP之上WSP层负责会话管理真正的彩信内容被封装成二进制MMS PDU塞进WTP的Data字段。为什么绕这么大一圈因为彩信标准诞生的早期终端内存和空中接口资源都极其紧张。二进制编码的MMS PDU比同等语义的HTTP头短得多WTP又自带事务重传机制不需要终端维护一条完整的TCP连接。这个历史包袱一直保留到现在。即使在5G VoNR已经普及的现网新规范允许MMSC直接收HTTP但终端兼容性测试时仍然会回退到WSP方式。所以在MMSC前端抓包时只盯着80/8080端口会漏掉相当一部分彩信请求需要按WSP和WTP的报文特征去做过滤。2.2 彩信信令流程的四个接口先分清谁跟谁说话彩信系统的接口划分在3GPP TS 23.140里定义得非常清楚实际排错时也是按这四个接口分段定位的。接口两端实体承载协议典型消息MM1终端 ↔ MMSCWSP/WTP over GPRS或HTTPm-send-req、m-retrieve.confMM2MMSC内部功能模块之间厂家私有协议不对外MM3MMSC ↔ 外部应用服务器SMTP、HTTP彩信转Email、SP接口MM4归属MMSC ↔ 接收方MMSCSMTP扩展RFC 2387MM4_forward.REQ、MM4_delivery_report.REQMM1是终端与MMSC之间的事务接口负责提交和取回MM4用于跨MMSC转发通常发生在异运营商互通或者集团彩信分发场景MM3则用于把彩信推送到邮箱或SP。现网最容易混淆的是MM1和MM4用户发送的彩信在MM1到达发送方MMSC后还要再经过MM4转发到接收方MMSC才触发那条短信通知。如果只看单侧MMSC日志经常误判成“消息丢了”。2.3 从SMS通知到Content-Location短信里藏着的MMS PDU接收方手机收到的“彩信通知”从空口上看就是一条普通短信但内容不是可见文字而是一段application/vnd.wap.mms-message类型的二进制数据。按规范还原后核心字段大致如下m-content-type: application/vnd.wap.mms-message x-mms-message-type: m-notification.ind x-mms-transaction-id: 8dHk2XrDd0 x-mms-mms-version: 1.3 x-mms-message-class: Personal x-mms-message-size: 12580 x-mms-expiry: 172800000 x-mms-content-location: http://mmsc.example.com/mms/wapenc?MsgID20240507103000 from: 8613800000000/TYPEPLMN其中x-mms-content-location是整条链路的关键它告诉终端“去哪个URL把彩信正文取回来”。URL里的MsgID参数往往直接对应MMSC内部的消息ID后续在MMSC日志里排查时就是靠这个ID把MM1和MM4两段流程串起来。x-mms-message-size是终端判断是否自动下载的重要依据超过运营商设置阈值时手机可能只显示“下载”按钮而不自动拉取这是很多用户抱怨“彩信要手动点才能看”的直接原因。x-mms-message-class区分Personal、Advertisement、Auto等类别广告类彩信在部分终端上会被直接丢进垃圾箱。x-mms-expiry是过期时间单位是毫秒过了这个时间再去取信MMSC会返回404。提示如果SMSC侧下发异常m-notification.ind根本到不了手机MMSC日志里也不会有取信记录现象就是“对方显示已发送但手机一直没收到彩信通知”。3. MM1发送信令实战m-send-req的构造与200 OK响应3.1 发送前先解决承载彩信APN与PDP上下文的特殊要求终端发起彩信发送前第一步不是构造PDU而是激活一条数据承载。4G以前叫PDP Context5G时代叫PDU Session。彩信有它自己的专用APN/DNN比如移动侧的CMWAP、联通侧的UNIWAP或者按集团规范命名的mms专用APN而不是手机默认的互联网APN。为什么不能直接复用互联网APN一是MMSC需要按APN区分计费策略与QoS等级二是彩信APN通常配合防火墙策略限制目的地址让终端只能访问MMSC的网段避免彩信通道被拿来当普通上网通道。现网经常出现的故障是用户自设了APN或者双卡手机上彩信APN和默认数据APN错位导致PDP激活成功但MMSC根本收不到请求。排错时看到“MMSC日志无任何记录”第一反应就应该是去看无线侧发出的PDN Connectivity Request里带的APN到底是不是彩信专用值。在实际工程里部分运营商允许彩信走默认APN而不强制专用APN但终端侧必须至少在会话建立阶段把APN带上。5G核心网里这个参数改名为DNNSMF在会话建立时会根据DNN从PCF拉取对应的QoS规则这一点在后面的5G承载部分细说。3.2 用curl构造一次m-send-req提交在实验室或自动化回归测试中直接用curl模拟彩信提交是定位MMSC问题最高效的手段。虽然现网终端走WSP但主流MMSC都同时支持HTTP接入方式。一个最小可用的请求长这样curl -v \ -H Content-Type: application/vnd.wap.mms-message \ -H X-Mms-Message-Type: m-send-req \ -H X-Mms-Transaction-ID: 8dHk2XrDd0 \ -H X-Mms-Version: 1.3 \ -H X-Mms-Message-Class: Personal \ -H X-Mms-Delivery-Report: Yes \ -H X-WAP-Profile: http://mmsc.example.com/UAProf.xml \ -u mmuser:pass \ --data-binary mms_sample.pdu http://mmsc.example.com/mmscX-Mms-Message-Type声明本次MM1事务类型MMSC会按这个字段把请求分发到对应的处理模块。X-Mms-Transaction-ID是全流程中最关键的参数MMSC用它在有效期内做幂等去重同一个Transaction-ID的重复提交不会被重复计费和重复投递。X-WAP-Profile指向终端能力描述文件的URL里面写明了该终端支持的最大图片分辨率、SMIL版本和编码格式MMSC据此决定是否需要对多媒体内容做转码。--data-binary后面的mms_sample.pdu是完整的二进制MMS PDU包含SMIL描述文件和附件这里展示的是HTTP封装层。如果目标是验证MM4转发则不需要走这条命令直接在MMSC上使用内置测试号码发起即可。3.3 MMSC的回执m-send-conf与Request-Status解读MMSC收到并校验通过后返回m-send-conf消息对应HTTP层面的200 OK。但这个200只代表MMSC接受了请求并不等于彩信已经投递成功。真正需要看的是m-send-conf消息体里的x-mms-request-status字段它的取值直接决定终端界面上显示的是“发送成功”还是“发送失败”。x-mms-request-status含义常见触发原因200成功—400请求格式错误MMS PDU损坏、WSP头缺少Transaction-ID401鉴权失败APN账号密码错误、UAProf地址无法访问403禁止发送号码被列入黑名单或SP限制404找不到资源Content-Location过期、消息已被清除405方法不允许发送请求误用了GET而不是POST407内存超出附件超过MMSC配置的最大限制手机终端的“发送失败”弹窗通常不显示这个状态值但MMSC的access log里一定会有记录。排错时不要只看HTTP状态码要抓请求体里的Request-Status。容易出现的一个坑是HTTP 200与Request-Status 500并存说明MMSC做了“先接后处理”的异步架构真正的错误延迟出现在回调逻辑里。4. 彩信投递信令流程拆解MM4_forward到m-retrieve.conf的回执链路4.1 跨MMSC转发MM4_forward.REQ的SMTP信封长什么样发送方MMSC把彩信接收并存储后接下来的动作不是直接推给终端而是按被叫号码路由到接收方归属MMSC。两个MMSC之间的交互走MM4接口传输层用SMTP的格式扩展而不是WSP。MM4_forward.REQ消息被封装在SMTP的DATA部分里核心头字段如下MAIL FROM:mmsc-aoperator-a.net RCPT TO:mmsc-boperator-b.net DATA Content-Type: multipart/related; boundaryMMS_BOUNDARY X-Mms-Message-Type: MM4_forward.REQ X-Mms-Transaction-ID: 20240507103000-0001 X-Mms-Version: 1.3 From: mmsc-aoperator-a.net To: 8613800000000/TYPEPLMN Subject: MMS Notification --MMS_BOUNDARY Content-Type: application/vnd.wap.mms-message 此处为二进制MMS PDU --MMS_BOUNDARY--RCPT TO里的地址通常是按号段配置好的路由表查出来的不是被叫手机号的邮箱形式。X-Mms-Message-Type在跨网时必须是MM4_forward.REQ很多自研对接系统会把这里误写成m-send-req导致对端MMSC直接拒收。To字段携带完整的目的手机号格式是CC NDC SN/TYPEPLMN解析时要把/TYPEPLMN去掉再查号段路由。跨运营商排错时可以用telnet到对端MMSC的25端口手动发送一个最小MM4_forward.REQ来验证路由和鉴权配置。注意MM4接口通常有IP白名单和TLS双向认证失败日志里看到SMTP 550就要优先查白名单。4.2 通知那一步m-notification.ind再次下发的判定逻辑接收方MMSC完成存储后会把第2.3节里那条m-notification.ind交给SMSC再由SMSC通过短信通道下发到终端。这条短信不是普通文本短信头里设置了UDHI用户数据头指示和WAP Push端口号终端收到后识别为WAP Push类型解析出Content-Location。这里有一个经常被5G信令流程详解文章忽略的点LTE/5G时代短信的投递通道有两条一条是CS域的SMS over SGs一条是IMS域的SMS over IP。如果接收方手机开启了VoLTE/VoNR但没有成功完成IMS注册SMS over IP不可用SGs兜底通道仍然能把m-notification.ind送下来。所以“VoNR注册失败导致收不到彩信”这个说法在绝大多数情况下是不成立的。真正会导致通知下不来的是SMSC到HLT/HSS的短信路由数据缺失或者手机侧关闭了WAP Push接收。4.3 终端取信m-retrieve.conf其实就是一个GET请求终端解析出Content-Location后会向MMSC发起一个HTTP GET请求来拉取彩信正文。在抓包里看到的就是标准GET不需要额外的X-Mms头这和发送流程完全不同。tcpdump -i any -A -s0 host mmsc.example.com and port 80 -w mms_retrieve.pcap用Wireshark打开抓包文件后过滤表达式可以写成http.request.method GET http.host mmsc.example.com终端对这个URL发起GET时如果MMSC返回200 OK响应体里就是完整的multipart/related消息SMIL文件负责控制页面布局图片和音频以附件形式跟在后面。如果返回403常见的原因是User-Agent被MMSC的UAProf服务器识别为不支持的终端返回404则说明Content-Location已经过期在m-notification.ind下发到取信之间隔了太长时间。注意m-retrieve.conf没有Request-Status字段可用这一段的成败直接看HTTP状态码和响应体是否完整。4.4 投递报告m-delivery.ind与MM4_delivery_report.REQ当发送方在m-send-req里要求投递报告X-Mms-Delivery-Report: Yes接收方MMSC在终端成功取信后会生成一条m-delivery.ind短信回给发送方终端。跨运营商时这条回报先走MM4_delivery_report.REQ从接收方MMSC回到发送方MMSC再由发送方MMSC以短信形式发给发起用户。判断“已送达”和“已读”是两个不同概念。m-delivery.ind的x-mms-status字段只有200代表最终成功送达其他400/4xx都代表投递失败或过期。跨网场景经常出现“发送成功”但永远收不到“送达回执”这往往不是网络丢消息而是对端MMSC在互通协议里禁用了delivery report。排查时在两个MMSC上分别过滤这笔消息的Transaction ID如果发送方MMSC根本没收到MM4_delivery_report.REQ问题就在接收方侧。5. 5G信令流程详解NSA架构下彩信承载的QoS映射与抓包验证5.1 5G核心网里彩信靠什么承载DNN、QoS Flow与SMF的联动5G核心网中彩信会话不再叫APN而是叫DNNData Network Name。UE在PDU Session Establishment请求里带上彩信专用DNN后SMF会从PCF获取对应的QoS规则再通过PFCP协议下发到UPF。彩信下载通常一次性拉取几十到几百KB的数据如果走了默认DNN且5QI为9在无线侧会被划分到non-GBR的低优先级队列出现“能上网但彩信图片转圈”的现象。现网的常见做法是给彩信DNN分配不低于5QI7的QoS等级保证下载时获得足够的调度优先级。VoNR信令流程详细介绍里常说的“语音走IMS专用DNN数据走Internet DNN”彩信是第三类独立DNN不要图省事把MMSC流量并入IMS DNNSMF和MMSC侧的路由都会不认。5.2 在MMSC前端验证完整链路一条tcpdump命令抓全所有请求当用户报告“发彩信失败”时最快的判断方法是直接在MMSC前端交换机做端口镜像抓包。如果MMSC网段是10.20.30.0/24命令可以这样写tcpdump -i any -s0 -A \ tcp port 80 and (dst net 10.20.30.0/24 or src net 10.20.30.0/24) \ -w mms_all.pcap-s0抓完整包避免截断后PDU解析失败-A用ASCII打印包内容方便直接看到HTTP头里的X-Mms-Message-Type-w mms_all.pcap保存成文件避免终端刷屏导致漏看抓完以后用grep直接看有没有关键特征tcpdump -r mms_all.pcap -A | grep -E m-send-req|m-retrieve|X-Mms-Message-ID如果完全没有m-send-req说明终端到MMSC的链路根本不通问题在路由、DNN或UPF一侧如果有m-send-req但没有对应的m-retrieve.conf说明转发和通知链路卡在MM4或SMSC环节。5.3 三个现场必查的失败点与判定方式第一个是“终端发了但MMSC没收到”。检查UE发起的PDU Session Establishment里是否携带彩信DNN再看SMF有没有给这个会话分配正确的UPF和S-NSSAI。这个环节最容易出的问题是MMSC的回程路由指向了另一个UPF导致报文到了UPF却送不进MMSC。第二个是“MMSC收到但转发失败”。在MMSC日志里找到目标号段后先ping对端MMSC的IP再telnet对端25端口确认SMTP可达。我一般会直接用openssl s_client验证TLS链路是否正常很多MM4转发失败是证书过期而不是路由问题。第三个是“通知到了但下载失败”。到终端侧看m-notification.ind里的Content-Location地址拿这个URL直接在PC上curl一下。如果curl能下载而手机不行多数是防火墙对手机所在IP段限制了对8080端口的访问或者MMSC做了User-Agent白名单。实际定位时可以把发送方MMSC和接收方MMSC两边的日志放在一起核对同一个X-Mms-Message-ID或者说Transaction ID是否完整走完“m-send-req → MM4_forward.REQ → m-notification.ind → m-retrieve.conf”这四跳。哪一跳缺失故障点就在哪一跳对应的接口上。本文还有配套的精品资源点击获取