企业官网建设流程全解析

简介：面向移动通信与核心网学习者的彩信信令流程图解资料，以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直连：WSP+WTP才是现网主流

终端到MMSC的MM1接口，直观上很像一个HTTP POST请求，但现网大部分落地实现走的是WAP协议栈里的WSP（Wireless Session Protocol）和WTP（Wireless 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是终端与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?MsgID=20240507103000 from: +8613800000000/TYPE=PLMN

其中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 Context，5G时代叫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核心网里这个参数改名为DNN，SMF在会话建立时会根据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/mmsc'

X-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字段，它的取值直接决定终端界面上显示的是“发送成功”还是“发送失败”。

手机终端的“发送失败”弹窗通常不显示这个状态值，但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-a@operator-a.net> RCPT TO:<mmsc-b@operator-b.net> DATA Content-Type: multipart/related; boundary=MMS_BOUNDARY X-Mms-Message-Type: MM4_forward.REQ X-Mms-Transaction-ID: 20240507103000-0001 X-Mms-Version: 1.3 From: <mmsc-a@operator-a.net> To: <+8613800000000/TYPE=PLMN> 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/TYPE=PLMN，解析时要把/TYPE=PLMN去掉再查号段路由。

跨运营商排错时，可以用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，而是叫DNN（Data Network Name）。UE在PDU Session Establishment请求里带上彩信专用DNN后，SMF会从PCF获取对应的QoS规则，再通过PFCP协议下发到UPF。

彩信下载通常一次性拉取几十到几百KB的数据，如果走了默认DNN且5QI为9，在无线侧会被划分到non-GBR的低优先级队列，出现“能上网但彩信图片转圈”的现象。现网的常见做法是给彩信DNN分配不低于5QI=7的QoS等级，保证下载时获得足够的调度优先级。VoNR信令流程详细介绍里常说的“语音走IMS专用DNN，数据走Internet DNN”，彩信是第三类独立DNN，不要图省事把MMSC流量并入IMS DNN，SMF和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”这四跳。哪一跳缺失，故障点就在哪一跳对应的接口上。

本文还有配套的精品资源，点击获取