MMS规范翻译（MMS Architecture Overview)

WAP^TM MMS Architecture Overview

                                                         Version 25-April-2001

                                                          无线应用层协议

                                                          多媒体消息服务

                                                          框架总览规范

译者：一切皆有可能

Mail:[e-mail]

Blog:blog.csdn.net/dlmu2001

WAP^TM MMS Architecture Overview.. 1

1.    范围（Scope）... 2

2.    文档地位... 2

2.1      文档历史... 2

2.2 勘误表... 3

2.3评论... 3

3.    参考（Reference）... 3

3.1      标准化参考（Normative Reference）... 3

3.2      资讯性参考（Informative Reference）... 3

4.    定义和缩略词... 4

4.1      术语（Terminology）... 4

4.2      定义... 5

4.3      缩略语... 5

5.    介绍... 6

6.    MMS信息框架... 6

6.1 使用例子... 8

7.    MMS客户端/MMS Proxy-Relay接口... 9

8.    MMS Internet Email相互作用... 10

8.1      发送信息给Internet Email Servers. 10

8.2      接收(Receiving)发自Internet Email系统的消息... 11

8.3      从Internet Email Servers获取(Retrieving)消息... 11

9.    MMS Proxy-Relay到Proxy-Relay的操作... 11

9.1 同等MMS Proxy-Relay元素的发现... 11

9.2 相互协作的MMS Proxy-Relays之间的信息流... 12

10.      MMS客户端架构... 12

11.      MMS寻址... 12

11.1     Internet寻址... 12

11.2     无线网络寻址... 13

12 MMS陈述(MMS Presentation) 13

12.1 多媒体陈述概念（Multimedia presentation concepts）... 13

12.2 陈述例子（Presentation examples）... 14

13 安全性考虑... 14

14 内容改编（Content Adaptation）... 15

14.1 确定内容适应的需要... 15

14.2 内容适应活动... 15

15 WAP MMS文档... 16

 

1.   范围（Scope）

无线应用层协议（WAP）是为开发运行于无线传输网络上的应用程序定义了一套工业标准规范而进行的持续的工作的结果。WAP论坛的范围是定义一套用于服务程序的规范。无线市场正在快速发展，并且延伸出了新的消费者和服务。为了使运营商和厂商可以迎接在高级服务，区分和快速/灵活服务创建的挑战，WAP论坛定义了一套传输（transport），安全（security），事务（transaction），会话（session）和应用层的协议。对于WAP架构的额外信息，参阅“无线应用层协议框架规范（wireless application protocol architecture specification）”[WAPARCH]。

多媒体信息服务（MMS：Multimedia Messaging Service）是一个系统应用程序，通过该程序，WAP客户端可以提供各种媒体类型的信息操作。服务根据WAP MMS客户端和它的服务伙伴，MMS网关（MMS Proxy-Relay），一个为了这个特别的服务作为AP源服务器的设备所采取的行为进行描述。额外的服务方面由MMS服务器和其它消息服务器进行支持，比如email服务器和无线信息系统（如：SMSC，短信中心）。本规范定义了在WAP环境中为实现MMS服务所发生的应用层协议活动。

2.   文档地位

2.1     文档历史

Date                                     Description

25 Apr 2001                               Initial version

2.2 勘误表

同本文档相关的已知问题发布在http://www.wapforum.org/

2.3评论

关于这个文档的的评论可以以http://www.wapforum.org发布的方式提交给WAP论坛

3.   参考（Reference）

3.1     标准化参考（Normative Reference）

没有；这是一个资讯性的文档

3.2     资讯性参考（Informative Reference）

[MMSENCAPS] “WAP MMS Encapsulation Protocols”,WAP-209-MMSEncapsulation,WAP Forum. URI:http://www.wapform.org/

[MMSCTR]     “WAP MMS Client Transactions”, WAP-206-MMSCTR

URI:http://www.wapform.org/

[PKI]          “WAP Public Key Infrastructure Difinition”,WAP-217-WPKI.
               URI:http://www.wapform.org/

[RFC821]      “Simple Mail Transfer Protocol”,J.Postel,1982-08-01.

              URI:http://www.ietf.org/rfc0821.txt

[RFC1869]     “SMTP Service Extensions”

              URI:http://www.ietf.org/rfc/rfc1869.txt

[RFC1870]     “SMTP Service Extension for message size declaration”

              URI:http://www.ietf.org/rfc/rfc1870.txt

[RFC1939]    “Post Office Protocol – Version 3”,J.Myers,May 1996

             URI:http://www.ietf.org/rfc/rfc1870.txt

[RFC2060]    “Internet Message Access Protocol – Version 4rev1”,M.Crispin,December 1996
             URI:http://www.ietf.org/rfc/rfc2060.txt

[RFC2616]   “Hypertex Transport Protovol –HTTP/1.1”,R.Fielding et al.,June 1999.

            URI:http://www.ietf.org/rfc/rfc2616.txt

[RFC2633]  “S/MIME Version 3 Message Specification.”

           URI:http://www.ietf.org/rfc/rfc2633.txt

[SMIL]     “Synchronized Multimedia Integration Language Boston Specification”,W3C,

Working Draft SMIL 2.0 September 2000.

URI:http://www.w3.org/TR/smil20/

[UAPROF]  “WAP User Agent Profile”,WAP-174-UAProf,WAP Forum,

           URI:http://www.wapforum.org

[WAPARCH] “Wireless Application Protocol Archiecture Specification”,WAP-100-WAPArch,

WAP Forum. URI:http://www.wapforum.org

[WAPWAE]  “Wireless Application Environment Overview”,WAP-190-WAE,WAP Forum.

            URI:http://www.wapforum.org

[WIM]      “Wireless Application Protocol Identity Module”,WAP-160-WIM,WAP Forum.

            URI:http://www.wapforum.org

[WML]      “Wireless Markup Language Specification”,WAP-166-WML,WAP Forum.

            URI:http://www.wapforum.org

[WSP]      “Wireless Session Protocol Specification”,WAP-158-WSP,WAP Forum

            URI:http://www.wapforum.org

[WTLS]     “Wireless Transport Layer Security Specification”,WAP-121-WTLS,WAP Forum

            URI:http://www.wapforum.org

4.   定义和缩略词

4.1     术语（Terminology）

本文是资讯性的，不包含任何要求

4.2     定义

本节引入了将在文档中使用的术语

邮件服务器（Email Server）

     一个一般类型的服务器，名义上提供email服务，使用SMTP，POP和/或IMAP协议工作

多媒体信息服务（MMS：Multimedia Messaging Service）

     一个系统应用程序，通过该应用程序，WAP客户端能够提供各种介质类型的信息操作

MMS客户端（MMS Client）

     位于WAP客户端设备上的MMS服务端点

MMS Proxy-Relay
     提供各种消息系统的访问通路的服务器。它可以作为一个WAP源服务器（WAP origin

Server）运行，在这种情况下，它可以利用WAP系统的特性

MMS服务器（MMS Server）

     为MMS服务提供存储服务和操作性支持的服务器。

4.3     缩略语

规范运用了以下的缩略语

Email    Electronic mail（电子邮件）

ESMTP  Extended Simple Mail Transfer Protocol（扩展简单邮件传输协议）

HTTP    HyperText Transport Protocol，for detail see[RFC2616](超文本传输协议)

IMAP    Internet Message Access Protocol，for detail see[RFC2060](Internet信息访问协议)

ISDN    Integrated Services Digital Network (综合服务数字网络)

MIME   Multipurpose Internet Mail Extension（多功能邮件扩展）

MMS   Multimedia Messaging Service(多媒体信息服务)

MSISDN Mobile Station ISDN Number(移动台ISDN编号)

PKI     Public Key Infrastructure ,for detail see[PKI] (公钥机制)

POP    Post Office Protocol ,for details see[RFC1939] (邮局协议)

SMIL   Synchronized Multimedia Integration Language(同步多媒体综合语言)

S/MIME Secure/Multipurpose Internet Mail Extensions(安全/多功能Internet邮件扩展)

SMS   Short Message Service(短消息服务)

SMTP  Simple Mail Transfer Protocol ,for details see [RFC821](简单邮件传输协议)

WAP   Wireless Application Protocol (无线应用层协议)

WIM   WAP Identity Module ,for details see [WIM] (WAP标识模块)

WML   Wireless Markup Language (无线标记语言)

WSP   Wireless Session Protocol ,for details see [WSP](无线会话协议)

WTLS  Wireless Transport Layer Security(无线传输层协议)

5.   介绍

多媒体信息服务（MMS），就如同它的名字所隐含的意思，就是要在一个消息上下文中提供丰富的内容给用户。具备MMS客户端功能的设备支持发送和接收这样的信息。下图1中使这样的一条消息的例子。

多媒体信息服务被视为一个非实时的投递系统。这比得上很多现在使用的信息系统。最初的例子包含了在Internet可用的传统email和无线信息系统比如分页（paging）或者SMS。这些服务提供了一个存储和前推的使用范例，期望MMS将能够同这些系统协调工作。

实时信息也以各种各样的形式存在。比如，可以从各种个样的出售者获得的立即信息或者各种个样的聊天服务（比如，文本，语音）越来越流行。这样的服务现在不被MMS系统支持，但在将来的发布中可能会有所考虑。

6.   MMS信息框架

MMS的主要特性是支持同其它可用的信息系统的信息活动的能力。图2中展示了一个MMS网络图标的一个抽象视图。特定的MMS网络可以有一个或者多个这样的连接，同时包含特定未直接描绘的信息服务（比如，传真或者声音邮件系统）

注意通过图2标识的各种接口，在有些情况下，他们的定义使为了进一步的研究。在这个文档中对这些接口的描述并不意味着WAP论坛将发展必要的规范来详细描述他们。

图2中展示的系统元素可以概括如下：

l         MMS Client（MMS客户端）--这是同用户交互的系统元素。它被期望作为一个应用程序在用户无线设备实现

l         MMS Proxy-Relay—这是与MMS Client交互的系统元素。它提供了到提供信息存储服务的部件的访问通路，并且负责同其它可用的信息系统之间的信息活动。有些实现可能将该部件同MMS服务器结合在一起。

l         MMS Server（MMS服务器）--这个系统元素提供了MM信息的存储服务。有些实现可能将该部件同MMS Proxy-Relay结合在一起

l         Email Server（Email服务器）--这个系统元素提供了MMS消息的存储服务。它支持SMTP协议来发送消息，也支持POP和/或IMAP协议来接收消息

l         Legacy Wireless Messaging Systems（遗赠无线信息系统）--这个系统元素代表了各种当前存在的支持无线信息系统的系统。可能包括提供信息给大量用户的分页（paging）和SMS系统。

图表中显示的接口描述如下

l         MMS_m—MMS客户端和MMS Proxy-Relay之间的接口，参见第7节,[MMSCTR]和[MMSENCAPS].

l         MMS_s—MMS服务器和MMS Proxy-Relay之间的接口。当MMS服务器和MMS Proxy-Relay结合成一个单独的部件的时候，该接口可能使先验的。定义这个接口的要求还没有确定。

l         MMS_R—各个MMS系统的MMS Proxy-Relay之间的接口，参见第9节。当前，没有规范对这个接口进行定义。该接口可能在将来由WAP论坛或者其它标准团体进行标准化。

l         E—用于MMS Proxy-Relay和给予Internet的email系统之间的标准email接口，使用了SMTP，POP和IMAP传输协议，参见第8节。该接口可能在将来由WAP论坛或者其它标准化团体进行标准化。

l         L—MMS Proxy-Relay和遗赠无线信息系统之间的接口。由于有很多这样的系统，这被视为一套接口。该接口可能在将来由WAP论坛或者其它标准化团体进行标准化。

6.1 使用例子

下面的例子信息流程进一步参数了MMS框架中的各个系统元素的功能和角色。这个例子仅涉及终端之间的端到端的MMS信息。

1.       用户触发MMS客户端（假定在终端上有该客户端）

2.       用户选择或者输入MM目标地址（es）

3.       用户组合/编辑要发送的MM消息

4.       用户要求发送MM消息

5.       MMS客户端将该消息通过MMS_M接口提交给相关的MMS Proxy-Relay

6.       MMS Proxy-Relay解析MM目标地址（es）

7.       MMS Proxy-Relay通过MMS_R接口选路前推MM消息给每个目标MMS Proxy-Relay

8.       MM被存储在同目标MMS Proxy-Relay关联的MMS Server上

9.       目标MMS Proxy-Relay通过MMS_M发送通知给目标MMS客户端

10.   目标MMS客户端从MMS Server获取MM

11.   目标MMS客户端通知目标用户新的MM可用

12.   目标用户要求绘制接收到的MM消息

13.   目标MMS客户端在目标用户终端上绘制MMS信息

注意，步骤1-3和12-13同终端上的用户接口相关，被认为是依赖于实现的，因此不再规范的范围内。也要注意步骤10和11可能以相反的顺序发生，依赖于MMS客户端的实现。也就是说，一个MM的获取政策可能导致MMS客户端仅当用户允许的情况下去获取一个MM。

MMS支持上面的使用例子，以及其它的很多例子。MMS的特性和功能在后面的章节描述，包括：

l         MMS_M，E和MMS_R接口，参见第7，8和9节

l         WAP MMS客户端结构，涉及到MM组成，发送，获取，表述和绘制，参见第10节

l         MMS寻址方面，涉及到所有的MMS接口和MMS框架中的各个元素，参见第11节

l         MM表述，当在一个MMS客户端上绘制MM的时候使用。参见第12节

l         安全服务，对MMS应用程序可能基于每个连接或者端到端可以获得。参见第13节

l         内容改写服务，MMS系统可能能够在投递MM之前提供该服务，参见第14节

7.   MMS客户端/MMS Proxy-Relay接口

如图2所示，MMS客户端同MMS Proxy-Relay进行交互。这个操作同WAP模型一致，在该模型中，MMS Proxy-Relay作为一个源服务器（Pull操作）或者一个Push发起者（Push操作）

MMS Client和MMS Proxy-Relay的关系如图3所示。在两个部件之间传输的消息在WSP 客户端和WAP网关之间使用无线传输如WSP，然后从WAP网关到MMS Proxy-Relay之间在HTTP上进行传输。

这个网络表述包含了一些项目需要描述。MMS Proxy-Relay是同用户邮箱交互的网络实体，负责发送通知给MMS客户端。WAP网关提供实现MMS所需要的标准WAP服务，包括：HTTP 方法；PUSH服务；OTA安全性；和性能协商（UAProf）。

MMS系统由MMS 客户端和MMS Proxy-Relay之间的活动所引导。这些活动在WAP MMS Client Transaction文档[MMSTC]和MMS Encapsulation文档[MMSENCAPS]中进行描述。

网络视图同时耶显示了由无线传输和HTTP承载的载荷。载荷在WAP MMS Message Encapsulation 文档]MMSENCAPS]中描述。期望这些数据在MMS Proxy-Relay和用户终端之间被完整传输。

8.   MMS Internet Email相互作用

在网络图表上的一个重要链接使MMS Proxy-Relay到Email Servers之间通过Internet连接在一起的连接。连接是双向的。

8.1     发送信息给Internet Email Servers

要发送信息，MMS Proxy-Relay会使用SMTP协议提交信息给指定地址的主机。消息载荷将被转化为标准的Internet MIME格式以允许被携带的各种介质部件同Internet环境一致。MMS特定的头部将通过填充”X-Mms-“前缀被转化为合适的头部。这就让那些熟识MMS的系统理解该字段而那些不熟识MMS的系统也不会出现问题。

8.2     接收(Receiving)发自Internet Email系统的消息

接收消息有类似的转化。MIME部分的消息将转化未MMS格式。类似的，任何发现“X-Mms-“前缀的头部将被转化为相应的MMS头部。

8.3     从Internet Email Servers获取(Retrieving)消息

对MMS 客户端来说，能够获取存储在Internet Email servers上的消息是重要的。这通常通过使用POP或者IMAP协议来完成。这样的获取由MMS Proxy-Relay执行（这是proxy的角色之一），然后会将数据转化为合适的MMS格式。

9.   MMS Proxy-Relay到Proxy-Relay的操作

MMS系统提供区别于其它消息系统的服务和性能。当这些系统相互通信的时候，有些服务和性能在他们之间提供。这些特定的服务和性能被期望得到进一步加强。也就是说，这些系统可以在MM系统之间通知和支持这些服务使重要的。

如果MMS Proxy-Relay到Proxy-Relay的操作使给予Internet email方法，那么SMTP/ESMTP可用用于互连。互连也可以采用其它合适的通信协议。

9.1 同等MMS Proxy-Relay元素的发现

在协同运作的MMS Proxy-Relay之间的任何生效的活动被执行之前，MMS Proxy-Relay需要知道它正在同其它MMS Proxy-Relay通信。取决于在这些元素之间使用的协议，可以使用不同的方法。比如，当使用正常的SMTP email，ESMTP【RFC1869】的性能报告体系，和【RFC1870】的协商体系使期望的方法。

注意ESMTP通过大量的RFCs和上面列举的指定，它简单定义了一个可以被扩展的框架。ESTMP的其它特定方面可以通过阅读相关的RFC了解。

在意识到一个MMS Proxy-Relay正在同一个同等部件通信的情况下，他们就能够执行额外的操作，提高他们之间的效率，扩展通信性能。同等系统之间可以支持的战斗力或者协商性能作为发现过程的一部分进行通信。

9.2 相互协作的MMS Proxy-Relays之间的信息流

MMS Proxy-Relays负责延伸当前的数据流，这些数据流为MMS 客户端到MMS Proxy-Relay(居家系统)所文档化，以到达其它MMS系统的MMS Proxy-Relay(目标系统)。这些扩展的信息流可以在SMTP或者其它通信协议上运行。这些元素之间的通信将利用从MMS 客户端来的可用的消息头部和为同等MMS Proxy-Relay链接指定的新的消息头部。

10.             MMS客户端架构

在通用WAP客户端架构中MMS用户代理适合的通用模型在图4中描述

MMS用户代理负责多媒体消息的合成和绘制。消息绘制通过使用合适的内容绘制服务来完成。MMS用户代理也通过使用合适的网络协议的传输服务来发送和接收多媒体消息。

MMS用户代理，就如WAP MMS规范中所描述的，不取决于，但是可能使用图4中显示的其它模块的服务，比如，公共函数（Common Functions），WIM和EFI。

关于通用的WAP客户端架构的额外信息可以从当前的[WAPWAE]文档获得。

11.             MMS寻址

以一个对系统来说是高效率和对信息的发送者来说是有意义的方式寻址用户的能力使消息系统的一个重要方面。这个平衡使难以取得的。

11.1         Internet寻址

在Internet世界，带宽不是主要考虑的问题，地址一般都是以email地址格式表达。在这种框架中，地址类似于user@system，这里系统规范可以使域名或者一个完全有资格的主机地址。总的来说，这个方案提供了用户拥有一个极大文本字符串的完整的和独一无二的地址的能力。这个方案非常普遍，这样的地址经常在商业卡片中打印出来。

11.2         无线网络寻址

在无线的世界里，带宽效率是至关重要的，短的地址和减少用户在受限的键盘上的输入是各种系统的特点。比如，在GSM网络，一个用户的地址是基于设备使用的MSISDN号码，类似地，在很多分页系统中，用户被分配一个允许呼叫者存放消息的PINS。

MMS寻址模型在[MMSENCAPS]中定义，采用了一个比较直接和高效的对MMS用户和服务可用的方案。这对于同遗留系统的相互操作性是特别重要的，比如上面提到的一些遗留系统，比如，移动台到移动台的操作。

随着来自于有线世界对无线网络的消息流的增加，很多系统使用服务器提供外部实体直接寻址他们的无线用户的机会。很多这样的系统使用了ID@carrier方式来为从email系统访问设定地址。

MMS采用了一个扩展的寻址方案，允许各种寻址格式被支持。关于寻址的更多详细细节参见MMS encapsulation规范[MMSENCAPS]

12 MMS陈述(MMS Presentation)

12.1 多媒体陈述概念（Multimedia presentation concepts）

MMS陈述的概念意味着在终端屏幕和其它设备如扬声器上对媒体对象的分类，排版，排序和分时。通过MMS陈述，多媒体信息的发送者能够将多媒体内容组织成有意义的顺序，并指导多媒体对象在接收终端上的绘制。

现在，终端通常有一个比较小的屏幕和受限的音频性能。但是在将来，可以期望终端的性能将有所提高，使完全对媒体陈述成为可能。MMS陈述的使用范例包括广告，新闻flashes等等。为了让内容提供商建立的多媒体陈述同尽可能多的终端兼容，MMS陈述被一贯地处理就显得很重要，需要考虑现在和将来的终端的性能，以及他们的相互操作性。

MM的陈述使可选的，因为有些终端的陈述性能非常有限。但是，接收终端仍然可能能够绘制接收到的多媒体内容，只要他们支持信息里面的媒介类型，即使陈述指令，比如排序（sequencing），排版（layout）和分时（timing）信息不支持。

12.2 陈述例子（Presentation examples）

有各种个样的陈述语言，最常用的的是【WML】和同步多媒体综合语言SMIL^TM【SMIL】

12.2.1 WML

多媒体消息的WML陈述提供了同浏览一样的排序和排版性能

12.2.2 SMIL

SMIL^TM提供了扩展的性能，比如多媒体对象的分时以及动画

SMIL^TM是一个简单的基于XML的语言，它包含了一套定义了特定区域的功能的语法。这些模块的例子使排版模块，分时和同步模块和动画模块，SMIL^TM的配置是特定用于应用程序域的模块的集合。SMIL^TM基本配置是提供限制数目的模块的轻量级配置，是同多媒体信息相关的。

MMS陈述语言在多媒体对象传输的相同消息中被传输。因此，多媒体消息使多媒体对象和可选的陈述信息的一个压缩包。陈述语言包括指向消息中的对媒体对象的指针（如URLs）

13 安全性考虑

MMS服务主要是一个应用层级别的服务。作为这样一个级别的服务，它能够建立在应用层可用的各种安全服务上。比如，MMS客户端和WAP网关之间的通信可以通过使用WTLS层的服务来进行加密。其它的安全服务可用通过使用其它的相应的部件可以得到的安全服务来获得。

安全服务例子包括：

WTLS    WAP WTLS层提供WAP客户端同WAP网关之间的安全数据传输

WIM     WAP标识模块【WIM】用于执行WTLS和应用层安全功能，特别地，用来存储

和处理用户标识和鉴权所需要的信息。

PKI     公钥架构【PKI】指的是产生服务器和客户端所需要的鉴权的信任关系需要的架构

和程序

S/MIME 安全MIME[RFC2633]提供了一种处理MIME部件的加密的方法。这对于在SMTP

上传输的消息是有用的。S/MIME提供了一套包括鉴权，消息完整性，对源的非批

判（使用数字签名），隐私和数据安全性（使用加密）的安全服务。

MMS并不提供它自己的特定的安全支持，也不强制任何特定的安全性解决方案。虽然它可能能够加密消息的内容，它提出了MMS消息的完整的端到端的安全性和控制活动做不到的可能性。MMS用户接口的的一个方面是关于安全性和/或鉴权的传输信息被接收和发送。同一些Internet浏览器一样，关于消息的安全性的基本信息可以通过图形化陈述提供。关于消息的额外细节也被正常对待。这样的机制对MMS客户端是需要的，但是现在没有强制。

14 内容改编（Content Adaptation）

MMS系统能够提供的一个可能的服务是内容适应.事实上,可能有机会在投递到MMS客户端之前从多媒体信息转变,代替或者删除特定的数据元素.

14.1 确定内容适应的需要

这种服务可能因为各种原因被触发：

l         设备性能—设备可能受到限制无法处理特定的类型。这种限制可能基于内容类型，字符集或者大小（比如缓冲空间）

l         带宽考虑—特定的数据类型可能在特定类型的承载上不合适（比如在SMS上传输流媒体）。这种考虑基于用户或者网络运营商设定的因素

l         漫游考虑—在一个交替的承载网络上传输各种类型的多媒体介质可能会有问题。可能由服务限制或者价格考虑会影响到消息元素的投递。这样的过滤将发生在“居家（home）”系统。

有各种服务可以帮助MMS系统来确定内容适应是否需要。特别地，WAP UAProf[UAPROF]提供了一个机制告诉MMS Proxy-Relay关于MMS客户端的信息。这些信息同设备的特性和服务网络相关。

14.2 内容适应活动

各种形式的内容适应可能被执行。比如，图形化图像可能被移除，按比例拉伸缩放或者转化颜色。

特定的内容适应服务超出了MMS规范的范围。

15 WAP MMS文档

l         MMS Architecture Overview
本文当。这是任何想了解MMS的人的开始点

l         MMS Client Transaction（MMS客户端事务）
文档【MMSCTR】描述了运行于MMS客户端和MMS Proxy-Relay之间的MMS消息系统的操作

l         MMS Encapsulation Protocol（MMS封装协议）
文档【MMSENCAPS】描述了运行于MMS客户端和MMS Proxy-Relay之间的协议。