分类：
2011-01-06 17:10:33
什么是 MMS
MMS 是 Multimedia Messaging Service (多媒体消息服务) 的缩写，中文译为“彩信”，可以用于传送文字、图片、动画、音频和视频等多媒体信息。
手机终端合成多媒体消息后，可以向网内所有合法用户发送多媒体消息，由 MMSC ( 多媒体消息中心 )对消息进行存储和处理，并负责将消息在不同MMSC之间的进行传递转发，同时接收方用户可以从MMSC接收多媒体消息。
多媒体消息服务要求一个WAP网关，一个数据传输网（例如：电路交换网、GPRS 或者WCDMA等）和一个短消息中心。目前MMS业务在实现时是以WAP作承载，短消息作提示通知，由MMS手机自动到MMSC中去提取。
多媒体消息 的大小通常在几十K字节到上百K字节之间，这是由运营商和手机终端双方面决定的，目前中国大部分地区的手机仅支持小於50KB的多媒体信息。
MMS与SMS在消息发送方式上是相同的：都是存储一转发业务——即消息不直接送达用户，而是先送至消息中心，再经过消息中心转发到目标用户。但是MMS与SMS也存在很大差异，首先是网络结构和承载方式的不同：SMS是使用GSM的信令通道，而MMS是基于WAP协议栈，走数据通道，其传输能力大大超过SMS，用户不再受带宽的限制；第二，而MMS可以支持丰富的数据格式，包括图形、图像、声音、动画，在带宽允许的情况下还可以支持流媒体，这大大提高了消息内容的丰富程度和表达能力。
MMS协议概述
MMS是由OMA(Open Mobile Alliance)和3GPP(3G Partnership Project)共同主持制定的工业标准，其旨在寻求一种与系统无关的、开放的，使各种应用和业务能够在全球范围内的各种终端上实现的多媒体消息通讯标准。
MMS运行在WAP协议层之上，它不局限于传输格式，既支持CSD(Circuit-Switched Data 电路交换数据格式)，也支持GPRS格式(General Packet Radio Service 通用分组无线服务)，以WAP为载体传送视频、图片、声音和文字。
OMA负责定义的相关协议关注“消息如何打包 ”的问题，3GPP负责定义的协议则关注“消息如何发送、路由和接收 ”的问题。
OMA的主要协议文档：
3GPP的主要协议文档：
除以上罗列之文档外，还有WAP无线会话协议相关的文档需要了解，例如：SMIL等 等 。
MMS系统构成
构成MMS业务系统的主要网络单元如下图所示：
MMSC（多媒体消息业务中心）是整个系统的核心，它完成对MM的存储和处理，包括消息的输入输出、地址解析、通知、报告等等，它由MMS中继服务器MMS Relay 、MMS Server、User DB、Message Store共同组成。
WAP网关，因为SMS的传输信道对于MMS来说太窄了，所以MMS使用WAP的WSP作为传输协议，因此需要一个WAP网关连接MMSC和无线WAP网络 。
MMS Redirector（MMS重定向器）：全网范围内会有若干个MMSC，它们的URL地址是唯一的，MMS重定向器就是负责发送者用户归属MMSC路由查询功能的网络实体 。
ENUM-DNS（号码域名解析器）：解析接收方用户归属的MMSC的地址，接收MMSC发送的查询请求，查询接收者地址对应的归属MMSC的URI地址，并返回给MMSC，由MMSC将消息发往该用户归属MMSC服务器。
MMS系统接口
注：接口命名有两种方式，一种是MMSm / MMSR 等 等 ，另一种是MM1/MM2等 等 ，其都指相同东西；
整个MMS业务系统的运转是所有相关网络功能实体的相互通讯协作来达成，MMS相关协议文档的主要功能之一，就是 明确定义各网络功能实体之间相互通讯协作的标准接口，以下是相关接口的简要说明：
MM1(MMSM )接口将是我们的学习重点，这是我们开发彩信应用程序必须要了解的规范知识。
MMS Client 业务模型（MMS Client Transaction Model）
以MM1接口为讨论范围，则MMS服务实现了MMS Client和MMS Proxy-Relay服务器之间的业务调用，业务（Transaction）特指信息的传递流程及方式，以其对MMS终端设备状态变化的影响。下面详述各种不同的与MMS Client 相关的业务类型：
M-Send业务提供了MMS Client向MMS-Relay提交多媒体彩信，并获得响应信息的基本机制，下图是该业务的通讯流程：
在MMS Client向MMS Relay提交的PDU（Protocol Data Unit）中，包含有能唯一标识其自身的ID字段，该字段使得请求/回应（req/resp）被对应关联起来。
当 MMS Relay服务器 收到一个M-Send.req PDU时，它会回应一个M-Send.conf数据包，其中包含有请求处理结果的状态代码。如果MMS Relay能够成功处理该请求，那状态代码将为'OK'，并会返回一个message-ID作为MM的唯一标识。
MMS Relay服务器发送 M-NotificationPDU 给MMS Client，以告知其有新的多媒体消息，同时MMS Client 会 回应状态代码 ，下图是该业务的通讯流程：
在MMS-Relay服务器发往MMS Client的PDU——M-Notification.ind 中包含有一个兼容于RFC2396的URI，这是收取MM的入口地址，还有消息大小、过期时间、推荐收取方式等附加信息。
MMS Client收到M-Notification.ind PDU后会主动回应一个M-NotifyResp.ind数据包，以表明已得到通知。
M-Retrieve业务是MMS Client发送给 MMS Relay服务器以收取MM的请求，该请求的PDU传输在WSP/HTTP协议之上。取决于收取方式（即时收取or延时收取）的不同，在MMS-Relay服务器和MMS Client之间可能需要一个确认环节，下面分别是即时收取和延时收取时的通讯流程：
MMS Client会以 M-Notification.ind PDU中的URI为参数，向MMS Relay服务器 索取MM内容。服务器会想MMS Client回应M-retrieve.conf数据包，如果成功的话其中会包含完整的MM内容，当然回应中的状态代码会指示操作是否成功。
M-Forward业务使得MMS Client可以将MMS-Relay服务器中的一条MM转发给其它用户，下面是该业务的通讯流程：
MMS Client发送一个M-Forward.req PDU到MMS-Relay服务器，该请求中包含有定位MM的URI，以及至少1个的目标地址（即被叫用户的号码）等参数，MMS-Relay服务器会回应一个M-Forward.conf PDU，其中包含指示操作是否成功的状态码。另外， 转发业务是一个可选功能，在某些运营商的网络上可能不会被支持。
M-Delivery业务允许源MMS Client（即 发送 彩信的用户）及时得到信息被投递的通知，该通知是一个M-Delivery.ind数据包，下面是该业务的通讯流程：
该业务 只有一个步骤，没有对应回应环节，其发送给MMS Client的PDU 包含了源消息的发送情况，如果有多个目标用户，则会有多条 M-Delivery.ind 数据包 。
另外，与投递报告相似的还有“已读报告（Read Report）”，取决于Client端的版本会有两种不同的情况：MM阅读报告、PDU阅读报告。
M-Cancel业务允许MMS-Relay服务器向MMS Clinet发送撤销一条多媒体消息的请求，下面是该业务的通讯流程图：
MMS-Relay服务器会向MMS Client发送M-Cancel.req数据包，其中包含了目标MM的ID，例如：cancel ID。该业务是可选功能，在某些运营商的网络上可能不会实现 。
M-Delete业务允许MMS Client删除MMS-Relay服务器上的一条多媒体信息，下面是该业务的通讯流程图：
MMS Client想要删除1条或多条存储在MMS-Relay服务器上的MM时，可以发送M-Delete.req数据包到MMS-Relay服务器，该数据包含1个或多个标识具体MM的URI，而MMS-Relay服务器会回应M-Delete.conf数据包，其中包含有操作完成情况的状态码。
MMS消息格式及封装
在以上 业务模型的介绍中，通讯流程中的主体是 用于承载业务数据的PDUs（Protocol Data Units），本节将关注这些数据单元的基本机构、内容组成、封装编码等几个方面。 MMS PDU的内容类型（content-type）必须被指定为 application/vnd.-wap.mms-message ，用于被客户端准确识别。
基本结构
MMS PDU由消息头（Header）和消息体（Body）组成。Header具体描述了PDU的特定信息，Body是消息的具体内容（Body体是可选的）。大多数MMS PDU只含有 Header 域，用于建立和维持通信， Body体 只用在M-Send.req 和 M-Retrieve.conf 两个数据包中。下图是MMS PDU基本结构的示意图：
消息头（Header） 由一系列的域组成，包括PDU类型，接受方，发送方，发送时间等等。Header域中的项分为可选项和必选项，并且在编码MM头域时，X-Mms-Message-Type，X-Mms-Transaction-ID 和 X-Mms-MMS-Version必须位于MM头的最开始，而且要严格按照所列顺序，Content-Type头域必须在MMS头域的最后，其后为消息体，其它域的顺序可以随意安排。
消息体 （ Body ） 是多个不同类型的多媒体对象组成的，每个对象占据一个部分——Part(参见RFC2387标准)，根据各个部分是否有序，消息的组装方式分为：
消息体的内容组成
在application/vnd.wap.multipart.mixed类型的PDU中，仅包含有组成MM的所有多媒体内容，而在application/vnd.wap.multipart.related类型的PDU中还会包括Presentation —— 即消息内容的显示控制部分，该部分使用SMIL标记语言编写，用来描述MM中各部分的播放次序，显示/播放时间，结束时间以及在屏幕中 的 显示位置，等控制信息 。
通常， Presentation部分是消息体的第一个part，若不是则必须使用start 字段指出其所在位置， Presentation部分并不会被显示出来，而仅仅是让终端根据它获取一些控制信息，这些信息决定了其它内容的显示大小、先后顺序、位置等 。
最后 采用 MIME标准（ Multipurpose Internet Mail Extensions - 多用途互联网邮件扩展 ）将 完整的MM（包括： SMIL 、 文本、图像、声音、视频等 各个独立部分） 打包封装在一起，并发送。 MIME标准定义在 、 、 、 、 等多个RFC标准之中。
MM的二进制编码封装
大多数情况下，MM都基于WAP协议进行传输，它将MMS PDU被封装在WSP/PDU之中 作为WSP的消息体进行传输，并采用WAP/WSP协议作为传输内容的二进制编码（binary encoding）机制，进行消息的封装（Encapsulation）。
在OMA-TS-MMS-ENC-V1_3-20080128-C.pdf文档所在规范中，详细定义了每个PDU所涉及的Header域和值，以及为它们分配的二进制码的一一对应关系。采用此二进制编码规范，节约了无线领域的带宽资源，并最优化其在空中传播的数据量。
具体对应关系请参阅相关文档。
OMA-TS-MMS-ENC-V1_3-20080128-C.pdf
