1、YD 中华人民共和国通信行业标准YDff 1498-2006 数字蜂窝移动通倍网多媒体消息业务（MMS）接口技术要求Interface Technical Requirements of MMS in Digital Cellular Mobile丁elecommunicationNetwork 20060926发布2007-01-01实施中华人民共和国信息产业部发布YD厅1498”2006四次前言.III I 他自22规范性引用文件.3缩略谱.罔.z 4术语和定义.25 系统接口描述.町.回.4 6本标准中相关定义的说明.国.47 MMl接口定义.刷.67.1 提交多媒体消息.6 7.2 多
2、媒体消息通知.咽.”咽.g 7.3 接收多媒体消息.9 7.4发送报告.喇127.5 阅读报告.127.6刷刷ox中存储和更新多媒体消息（可选卜.13 M上裁和永久存储MM（可选卜喃喃，167.9 删除已存储的如刷（湾选）.17 7.10 MMl地址If.“国国“188 MM2接口定义.199 MM3接口定义.19 9.1 2史送消息.199.2接收消息.面199.3发现外部服务器上的新消息、“.“1910胁14接口定义.zo 10.1 多媒体消息的路由前转.zo 10.2路由前转递送报告咽.21 10.3路由前转阅读报告.”.也10.4 MM4上的消息格式.2310.5 MM4上的消息传输协
3、议.，嘲.30 11 MM5接日寇义.31 12 MM6接口定义.31 13 MM7接口定义.31 13.1 提交增值l&务的多媒体消息.32 YD厅1498-200613.2传送请求.34 13.3 多媒体消息的删除和替换（可选卜3513.4传递递送报告到VASP. 37 13.5 VASP的阅读报货.3813.6一般错误处琅国.3913.7分发表的管理“4013.8 MM7摘要消息的实现.，4013.9将信息单元映射至SOAP单元.4314 MM8接口定义.54附录A（资料性附录）WAPPDU头到3GPP摘要消息信息单元的映射.55II YD/T 1498-2006 前该rp司本标准是数字
4、蜂窝移动通信网多媒体消息业务系列标准之飞该系列标准的名称及结构如下：1. 数字蜂窝移动通信网多媒体消息业务（阳岱）帆、设备技术要求；2.数字蜂窝移动通信网多媒体消息业务（I仙iS）中心设备测试方法：3.数字蜂窝移动通信网多媒体消息，业务（I价s）终端设备技术要求：4数字蜂窝移动通信网多媒体消息J1k务（MMS）终端设备测试方法；1数字峰窝移动通信网多媒体消息业务（阳S）接口技术要求。随着技术的发展，还将制定后续的相关标准。本标准主娶参考了3GPPTS 23.140( V5.3.0）和OMA组织的OMA刷WAP剖MS-ENC-vi_!( 20021030), 并根据我周数字蜂窝移动通信网络的实际
5、业务情况和功能需要而制定的。本标准附录A为资料性附录。本标准由中国通信标准化协会提出并归口。本标准起草单位：信息产业部电信研究院华为技术有限公司本标准主要起草人：杨红梅孙元宁黄先琼杨伟淑Ill YD厅1498町2006数字蜂窝移动i爵倍网多媒体消息业务（MMS）接口技术要求1-m圈本标准规定了数字蜂窝移动通信网多媒体消息业务相关的功能实体之间接口的技术要求和协议要求。本标准适用于数字蜂窝移动通信网多媒体消息业务中心设备、终端设备、多媒体消息增值戚朋服务器等多媒体业务相关实体的接口。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改感（不包
6、括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注臼朔的引用文件，其最新版本适用于本标准。3GPPTS 23.140 V5.3.0 ( 2002-06) Multimedia Messaging Service ( l.刷的，Functionaldes口iption;Stage 2 (Rel础e5)IETF STD 0010 （盯c2821) 简单邮件传输协议（SimpleMail Transfer Protocol), URL: ht咿：ww毗ietf.org/rfc/rfc2821.txtIETF STD 0011 （民配8
7、22)因特网消息格式（Intern巳tMessage Format ) , IETF RFC 1327 IETF RFC 2045 IETF RFC 2046 IETFRFC 2616 IETF民FC2376 阻：TFRFC2387U议L:h即：llww吼ietf.org/rfc/rfc2822.txtx.份。（1988) /ISO 10021与RFC822之间的映射（Mappingbetween X.400 ( 1988) /ISO 10021 and RFC 822 ), URL: h即：www.ietf.org/rfc/rfc 1327 .txt 多用途因特网邮件扩展（M即但）第一部分：
8、因特阿消息iE文的格式（Multipurpose Internet Mail Extensions ( M岛也）Part One: p，四matof Internet Message Bodies ), URL: http: /www.总tf.org/rfc/rfc2045.txt多用途因特网邮件扩殷（！.刷侃）第2部分：媒体类型( Multip田poseInternet Mail extension ( 仙也）Part于WO:Media乃pes), URL: http: /www.ietf.org/rfc/rfc2046.txt 超文本传输协议，HTIP/1.1( Hyp巳rtextTran
9、sfer Protocol, HTIP/1.1 ), URL: ht叨：。www.ietf.时串rfc/rfc2616.txtXM比媒体类型（灿1LM创iaType), URL: h即：www.ietf.org/rfc/rfc2376刷MIMIE多部分相关内容类型（The MIME Multipart/Related Content Type ), URL: ht：www.ietf.org/rfc/rfc2387. txt YD厅1498叩20062000年5月8日W3C说明书简单对象访问协议（SOAP) 1.l (Simple Obj时tAccess Protocol (SOAP) 1.1
10、), URL: http: /www.w3.orgffR/SOAP 2000年12月11日W3C说明书带有附件的SOAP消息（SOAP Messages wi甘1Attachments ) , U议L:ht：www.w3.org厅议SOAP-attachmnts3缩略谱下列缩回各i普适用于本标准。FIP File Transfer Protocol 文牛传输协议E证.RHorne Location Register 归属伎毁寄存糕HTTP Hypertext丁rransfer衍。tocol超文本传输协议LDAP Lightweight Directory Ac臼ssProtocol 较最级目录
11、访问协议如肌1SMultimedia Messaging Service 多媒体消息业务如iMSCMultimedia Messaging Service Center 多媒体消息业务中心如仙fS.巴Multimedia Messaging S町viceEnvironment 多媒体消息业务环境SMTP Simple Mail Transfer Protocol 简单邮件传输协议VAS Value Added Service 增值业务WAP Wireless Application f汁。tocol元钱成用协议WSP WAP Session Protocol WAP会话协议UA User Ag
12、ent 用户代理4术语和定义下列术语和定义适用于本标准。必备：本标准中规定的“必备”字段要求设备必须实现并且在消息中必须携带。可选：本标准中规定的“可选”字段要求设备必须实现但是否在消息中携带可以根据业务需求决定。视情况而定：本标准中规定的“视情况而定”字段要求设备必须实现但是否在消息中携带需主要根据相关条件确定。摘要消，息：在两个MMS实体之间传送的信息，用于夜这两个实体之间输部剧和f或相关的控制传息。注1：如刷s:Jt务功能的应用协议框架与技术实现依据本文街的摘要消息描述。发送报1!f:rEMMS Relay/Server提供给胁f发方（皿tlS用户代理成VASP），关于MM传送状态的反馈
13、信息。外部服务楞：诸如因特网电子邮件、统一消息传递系统或传真等外部系统的网络实体应用程序，b你4可发送给该服务器，Iif!ill:通过MMS业务提供商，可由MMS用户代理从该服务帮获得如剧。出：外部服务器通过非MMS特定协议连接到该剧S业务提供商。转发阳tlS用户代理：MM的预期收方，M请求将阳4前转传送给其他收方而不先下载阳4的阳.fS用户代理。已转发h仙也从发方发送到预期收方，并被该收方将其转发给其他收方的h胁4，该过程将产生相应的发送报告和或阅读报告，该MM可能被迸步转发。2 vorr 1498币2006消息m：用于标识MM的憔一标识符。消息万！月号：指示MMi主慧的做一标识符。MMBo
14、x：与朋户相关联的网络存储器，在其中可以存储和更新、浏览、上载以及删除MM和MM的状态、相关标志。MM状态：Ml侣。x内的MM状态，为几个相互排它枚举值之一。MM标记：0、l或更多个关键字标记的列袋，由MMS用户代理定义，与岛仙f栩关联OMM发送：收方则SRelay/Server将MM发送到收方MMS用户代理的操作。MM提交：发方则$用户代理刷刷提交给收方MMSRelay/Server的操作。MMSNA：多媒体消息业务网络体系纺构，包含向用户提供完接E励S的所有不同要素。MMSE：统一管理下阳S相关网元的集合。MMS Relay/Server: MMS业务提供商管理下的h仙1S特定网络实体和应
15、用。泼3:MMS Relay/S己凹er传送消息，提供MMS特定的操作或移动环境所有昏的操作，并（暂时和或永久）提供MMS的存储业务。MMS用户代现：常驻在UE,MS或外部设备上的应用稳序，代表用户执行h也丽特定操作。泼hh仙1S用户代混不是MMSE的一部分。MMSVAS应用程序：向阳1S用户援供增值业务（如新业务或天气预报）的应用程序。原灿f：从发方发送到收方的（初始）MM，西I能产生相应的发送报告抑或阅读报告和rt!J.$.辛辛MM,且或可能要进一步转发。发方胁fSE：与刷发方相关联的胁1SEo发方协1SRelay/Server：与MM发方相关联的MMSRelay/Servero 发方棚”
16、用户代酌与协峨方相关联的阳.fS用户代理。发方VASP：正在发送MM的VASPo阅读报告：自收方MMS用户代理发送给发方MMS用户代臻的反馈信息，该信息是反映原MM在收方如包1S用户代理中的处理状态。收方MMSE：与刚收j.相关联的则S篮。收方MMSRelay/Server：与MM收方相关联的MMSRelay/Servero 收方孔仙1S用户代理：与h仙4收方相关联的MMS用户代理。收方VASP：正在接收b仙f的VASPo成辛辛胁4：在)llq事计费情况下，收方MMSRelay/Server接受的第一个应答（在检查应答计费限制后，如簸迟提交时间）。短码：业务提供商特定的地址，是一组字母、数字、
17、字符串的组合。SOAP附件：从MMSVASP传送到灿.fSRelay/Serv町，或从MMSRelay/Server传送到MMSVASP的多媒体内容，例如，商膏、图像、文本、演示或不同媒体类型和或格式的组合。事务：MMS用户代理与MMSRelay/Se凹er.之闭，或者不同MMSRelay/Server之间发送的消息对。超凡在MMSC系统规定的时间内，MMSUA没有对MMSC下发的通知消息进行响应。过期：超过设寰的MM有效期，加刷l_submit.REQ的Timeof Expiry中设定或由则SC系统进行设最缺省值。3 YD厅1498-2006交易：MMSCI可SCP究成对预付费用户的次拍费，
18、称为一次交易。5 系统接口揄迷MMS业务系统结构如图l所豆豆。Billi吨Sy唱itemExternal Se阴阳的(eg. UMS) MMSVAS Applications 咱也、卢也一”二一，牛.份一-”- - 百市琛在消息业务翩翩如刷1：胁fSRelay/Server l否用户终端的接口，具体描述见第7意；曰MM2:. MMS Relay和h刷SServer.之间的接口，该接口为内部接口，本标准不作具体规定，具体描述见篇8章：MM3: MMS Relay/Server与外部服务糕的接口，具体捕述见第9章；MM4: MMS Relay/Se凹er之间互联的接口，具体描述.w.第10尊贵；M
19、MS: MMS Relay/Server与肌议的接口，具体描述见第11章：MM6: MMS Relay/Serv即与用户数据库的接口，具体描述.w.第12意；MM7: MMS Relay/Server与VASApplication的接口，具体描述见第13章：灿18:MMS Relay/Server与计费系统的接口，具体描述见第141害。6 J在标准中相关定义的说明本审定义务接口摘姿消息的应用协议书室架，并说明MMS服务功能的技术实现。摘要消息可以归类为自请求和响应构成的事务处理。MMS摘要消息标记遵循以下规范：4 协1SUA和MMSRelay/Server.之间事务处理的前缀为MMl”； 伪1
20、SRelay/Server.之间事务处琐的前缀为“MM4飞请求的后缀标识为“阳Q”；YD厅1498-2006响应的后缀标识为“.RES”。4每个摘要害消息均包含特定的信息单元，这些信息单元可能因具体消息，的习之间而有所不肉。作为言息单元，所有消息都应包含协议版本和消息、类型型，以便MMS巳组件可以iE确识别和管理消息内容。摘要哥消息利具体协议的映射不一定遵循一一对应的关系。直日身在PDU中携带的信息是所脱摘要消息中的必需内容，则根据MMS的具体实现（WAP酌，一个或多个摘巢消息可以映射到一个低层P川，而且一个捎姿消息可以映射到多个低层PDUo在提供状态信息的如伪n响应中，返回的状态信息与MM4
21、响应中返回的状态俗息不具有对应关系，它们彼此独立。设计时，将MM！响应状态限于一组尽可能小的饶，可以与实现MM4摘要消息的通信协议中出现的状态和错误相关联。同样，h伽14状态E可以与实现MM！摘要消息的通俗协议中出现的状态和错误相关联。图如将多媒体消息从始发方MMS用户代理发送至接收方MMS用户代理时的摘要消息流。图2的范围仅限于参考点则1牵n:r.刷4上的摘要消息。发送报告由接收方胁4SRelay/Server.发送。阅读报告由接收/JMMS用户代理发送。因2描述了个MMS用户代理提交条多媒体消息交另一个MMSRelay/Server下的MMS用户代理的般察务处理过程；酌为采用灿B峭的摘娶消
22、息。这两个阁只是举例，并未全部描述MMS用户代理和h似!lSRelay/Server之间所有可能的事务处理过稼。Originator MMS Relay/S使VetMMIJ四d_reply_M胆tator.RllQMM4J创war也RllQMM4_fawa此R.llSMM4_deliv町J叩OMMS用户代现则！no刷刷刷| 响应/MMS用户代蜘MM咀Rel州叫7.2.1 汪常操作：当收到灿n二.notification.阻Q后，接收方MMS用户代理会向接收方阳（S刷a扩Server响应如伪HJto也fie州州的.RES，以确认成功接收MMl_notificatio毗阳、MM !_notific
23、ation.阻S将明确指向相应的协11_notification.R吨。7.2,2异常搬作在此情况下A削SUA将响应MMl_no削ca阳明阻S，其中包含了一个指示无法处理通知原因的状态。如果MMS用户代理不提供附n_notification.阳S,1刷SRelay/Server稍厉应能够意新发送通知。7.2.3信息单元表5和司怖分别给出了b刷l_notification.REQ和MMlJtotification.RES消息中的信息单元。袋5MM1_n创iflcatlon.REQ中的情息单元信息元素存在情况说明M刷刷四Tvoe必4量将此消息标识为MMI_notification.REQTnmsa
24、ction ID 必备MM! notification.REQI!刷l_noti而cation.RES对的标识MMS V时sion必备标识MMSRelay/Serv阻Rel町iServ即所交椅接口的版本Mes阻四Cl幽S必备MM的类别（例如，个人服务、广告服务、信息服务；默认值.1-人服务）M由扭扭Size必备b刷的近似大小T加mofExoirv 街MM的烦时时间Messa.ie Reference 必备MM的参考，例如，URISubj毗可逃整个MM的标题Priority 可逃消息的优先级（重要做）$巳nd即Ad伽ess视情量用知量户识近代M处M理理被过已自M经动M请存求（储E对P$到接E附交
25、收或方IB转隐0：藏中tM其M地）址的，MMS用户代理的地址。如泉始发1时MMS则它的地址不会提供给接收JiStored 可选Deliv时VReport 可Jl!i请求发送报传8 YD斤1498-2006表5（续）商息:JGJ:存在情况说明Reply-Char后ng可选对这个特定的脱始MM的成答信息免费Reply刷D崎dline可ill:成答计费情况下，向接收方保证的最晚提交ill答时间Reply-Chargmg-S1ze 可逃应答计费情况下，向接收方保证的最大$i.答MM大小限制R叩ly-Charging-IDOJ选如果这个通知指添一个应答MM的话，成4害的居在始MM的标识Element D
26、es口iptor可选MM的一个元素参考，这个如如4可能旬含关于参考元素的更多信息，如消息JG素的,g称、尺寸和或类型自以及格式Me喝sageDisrribul!On 可逃着设为false”，VASP指出MM的内容不可以再次分发；Indicator 若设为“true”，VASP指出h倒的内容可以分发襄6MM1_no创1ca甘on.RES中的情息单元信息元素存在情况说明Mess昭eype必备将此消息标识为MMl_notification.RE喝Transaction ID 必备MMl_notification皿咖刷J_no创阳tion.即啤对的标识蛐4SVersion 必备标识MMS用户代现所交待
27、接口的版本如你AS阳阳S可选MM接收的状态Report Allowed 可选请求允许或不允许向MM始发方发送发送报告7.3接收多媒体消息此部分MMS服务定义了协f的接收。为实现接收目的，接收方灿岱用户代现应始终从接收方MMSRelay/Server，接收MMo表7从类君臣和方向方iii概括了其中涉及的摘要消息。摘要害消息MMIJ咄咄ve.REQMMl_re创eveRESMM！川knowledgement.REQ7.3.1 正常操作接7在MMS申接收MM;t.周到的摘要消息类型| 方向请求IMNls用户代胁MMSRelay/Server 响应刷SRelay/Server-MMS用户代理请求阴阳代
28、现4川阳圳阴阳接收方h刷S用户代现通过向含有指示要被取阔的阳位置的U阳的协1SRelay/Server发送协H川创eve.REQ来请求取回个MM。如果成功，MMSRelay/Se附峭响应MM!_retrieve.阳S，其中包含MM按制信息和MM内容。接收到UMMl_retrieve.RES之后，如果MMSRelay/Server请求，接收方MMS用户代理会向相应的MMSRelay/Server.发送一个灿U_a巾1owledgement.REQ消息。MMl_acknowledgement础Q将明确指向相应的如岱U_re创eve.RES,7.3.2 异常自醒你如果接收方MMSRelay/Serv
29、er:JG法处理协lll_retrieve.阳Q，例如，由于内容位置无效或消息超时，接收方阳1SRelay/Serv即将响应一个MM!_retrieve.RES消息成一个低协议层错误消息，其中包含未传递多媒体消息的原因。如果h刷SRelay/Server不提供MMl_retrieve.RES或低协议层错误消息，则阳1S用户代理l成能够恢复。7.3.3信息.元9 YD!T 1498-2006 棚、拙和我10分别是灿11retri川民间、MMl_retrieve.阻附MM!acknolegement.阳Q消息中的信息单元。袋8MM1_retrieve.REQ中的倍息单元信息元素存夜情况| 说明Me
30、ss鸣eReference 必备将刷刷刷的内容位毁装9MM1_retrieve.问ES申的倍息原先信息单元存在情况说明Message Type 必备将此消息、标识为MMl_relrieve.RESTra时actionID 视情况而定如巢MMSRelay/ServerRelay/Serv町请求接收加剧S用户代理进行确认，则应提供事务处理由。这样，官将标识.MMl.r由四ve.R囚川H_acknowl吨阳盹阳Q消息MMS Version 必备标识MMSRelay/ServerRelay/S阳前所支持的接口版本Message ID 必备MM的消息BSend即A创ress视情况而定最近处理过MM（即挺
31、交过或转发过MM）的MMS朋户代涩的地址。如果始发方MMS用户代澳已经请求对接收方隐藏其地址，则它的地址不会提供给接收1iContent TvDe 必斗量MM的内容类型Recipient Addre盹可选MM接收方的地址。可能存夜多个RecipientAddreso信息单元区分多个接收方Mes地ageQass 可逃消息的类别（例如，个人服务、广告服务和信息服务）Date and Time 必备灿1S用户代理最近处理（ftP，提交或转发）MM的时间和日期Delivery Report 视情况而定:lMMS用户代凛 MM!Jorward.RES 7.3.5正常操作MMS用户代现采用MMl_forw
32、ard.REQ消息将如旧转发给MMSRelay/Server, MMS R刷y/Server；将返回一个灿n_forward.R皿响应消息蜘IMS用户代现指明操作状态。对于支持协岱oxes的MMSRelay/Server.来讲，支持MMl_forward.REQ和MMl_forward.RES：、选的。然而，对灿fS用户代理和MMSRelay/Server来讲，支持MMl_forw削.REQ是可选的。7.3.6异常操作在异常情况下，胁fS民elay/Server将返回一个协H_forward.RES消息，其中包含指示拒绝转发多媒体消息原因的状态信息，例如，消息格式错误、未找到消息等。当阳Ifo
33、rward.阻Q中包含一个存储请求，MMSRelay/Se附r应该在MMl_forward.础S中提供存储操作的结果。如果阳1SRelay/Server.不提供MMl_forward.RES,I刷S用户代恐应该能够恢复。7.3.7信息单元表12和表13给出了协.f!Jorward皿Q和MMlJorward.阻S消息中的信息单元。酷12MM1_fo阳ard.问EQ申的偏跑单元曹息单元存在情况说明M出sage乃pe必备将此消息称识为MM!Jorw时，阳。Transaction ID 必备MMl_forward.REQ岛IM!Jorward泯邸对的标识MMSVer晤。n必u备标识前转MMS用户代理E
34、支持的接口版本Recipient Address 必备被前转MM的接收1f地址，允许存在多个R时ipientad伽四sf窗J息单元区分多个接收方Forw缸咀fogAddress E可选前转MMS用户代理的地址Da协剧dTime 可选前转MM的时间和日期Time of Expiry llJ逃前转MM的期望过期时间Earliest Delivery Time 可选期望将MM下发给接收方的最早时间Store 可选如果支持MMBoxes, MMl_forw町d.REQ中S阳目信息单元的存在导致被前转的刚刚被存储在用户的MMBox，除非其中已经存在这个酬的消息参考MM Sta艳可选直H在存储的话，在MM
35、S阳时宵息单ji;中存储的MM状态的健MMFI电gs可选如果存储的话，在MMFlag信息单元中存储的一个或多个MMFlag关键字Delivery Report 可选前转MM的发送报食请求Read R句ly可选阅读报告请求M出盹，geRef扭扭nee必备参考，如前转MM的URI可以是从b他们noti自由tion.REQ、MML阳nbox_store.REQ成MMIJlllilbox_view.REQ中得来的消息参考11 YD厅1498-2006袋13MMUorward.RES中的情息单元信息、单元将在情况说明Message Type 必备将此消息称识为MMI forward.阳也Transact
36、ion ID 必备MMl_forward.REQ/MMI“forward.RESX才的标识MMSV配sion必备MMS Relay/Serv配支持的接口版本Request Status 必备MM Forward Request的状态Request Status Text 可选lMMForwardR问U制的状态描述Mes恼ageID 必备前转MM的憔一栋识Store Status 视情况而定如果在MMl_forward.阳Q。中存在Store请求，得储请求的状态Store S阳阳SText 可i串相应的存储状态示意义本（如果存在的话）Stored Me回ageRe岛ren四视情况而定如果在MMU
37、o阳ard.REQ中有Store请求并鼠存储操作已经成功的话，前转MM新的存储拷贝的消息参考7.4发送报告此部分附48服务讲述将发送报告从始发方MMSRelay/Server发送交始发方MMS用户代理。表14从类罪盟和方向两Ji商概括了其中涉及的摘要消息。摘要消息MM！.：如liv时y_report.REQ7.4.1 .iE常镰作班14在MMS中发送发送报告时周到的摘要消息类型方向MMSRelay/S剧协MM啤用户代现请求如果亦在用于创建发送报翁的相应信息，则始发方MMSRelay/S破四z将（取决于用户、如如1S服务提供商和或运营商之选择）创建MMUleli咽ry_repon.反应Q并将其发
38、送给始发方MMS用户代E盟。MMS用户代理可以支捋或不支持如刷！delivery.J即侃阻吨，回胁。刷刷Se附必须文持MMl_delivery_;repon.议院Q。7.4.2异常操作MMS协议框架不提供涉及和处理h刷l_delivery_repon.REQ传递失败的机制。基本协议将可靠地传输b刷l_deliv，町rep。“.REQo7.4.3信息单元表15是MMl_deliveryJepon.REQ中的信息单元。提15MM1.delive叩report.REQ中的情息单元信息单元存在情况说明Messageype 必备将此消息标识为酬Ldelivery_;eport皿QMMS V时ion必备标
39、RMMSRelay/Serv前Relay/Server所支持的接口版本Message ID 必备原始MM的标识R出1p1entAd曲也因必备原始MM的灿4接收方地址Dat.eandT1me 必备处现（接收、终止、拒绝等）旧的日期和时间（时间戳）MM Status 必备MM的状态，例如，已接收、已转发、已超时、已lt!绝7.5 阅读报告此部分如伪的服务讲述将阅读报告从接收方MMS用户代理发送给接收方扣岱1SRelay/Server，以及将阅读报告从始发方MMS应答服务器发送给始发方胁48用户代豫。表16从类型和方向两方面概括了其中涉及的摘要消息。12 YD厅1498-2006摘主哥消息、MM！二阻ad_reply二recipient.REQMMl.read.
