MMS实现详细分析（BENQ M22模块）*--（1）---------MMS实现的流程分析

MMS实现的流程分析

转载注明源地址：

%5Fresplendent/blog/item/2b49fab536468ccb37d3ca41.html
      基于MMS的终端系统中，MMS实现的步骤如下:
      (1)串口初始化和设置模块参数;
      (2)经过处理模块处理过的数据流在控制模块控制下，按照MMS协议封装格式进行MMS信息封装;
      (3)无线模块与GPRS的WAP网关进行连接，向串口发出拨号连接的AT命令，建立发送数据的PPP链路;
      (4)控制模块向串口发送经过发送协议封装的MMS信息;
      (5)将封装好的 MMS信息通过无线模块发送到GPRS的WAP网关，再发送到多媒体信息服务中心MMSC上;
      (6)由MMSC转发MMS到指定号码的用户手机上，实现个人实时化掌握监视环境的图像信息。
    整个系统发送MMS时，由控制模块向无线模块发送AT指令，无线网络连接上
GPRS网络后，再利用无线模块通过GPRS无线网络发送MMS信息到目的用户手机上。

下面我将重点分析MMS协议封装、无线网络连接协议和MMS发送协议。

MMS协议封装格式分析：

SMS只能传输文本信息，每次最多140个字节，而MMS的传输内容要丰富的多，包括视频、图片、声音和文字等信息。在远程监视终端系统中主要是利用MMS传输文字和图片，图片格式为压缩后的JPEG格式。实现MMS也要比SMS复杂得多，MMS有自己的消息格式，并且为了减少传输的数据量，克服无线网络带宽窄、高延迟、稳定性差等特点，需要对传输的数据进行压缩。基本的压缩编码机制是由WAP-209-MMSEncapsulation定义的。发送和接收MMS的通信中，被传输的是MMSPDU(协议数据单元)。

下面将对MMS PDU进行分析。

MMS PDU模型
    完整的MMS信息被包含在MMS PDU之中，采用多媒体邮件扩展MIME方式打包。在基于WAP的传输方式中，MMS PDU被封装在WSP PDU之中，作为WSP的消息体传输。WSP PDU的内容类型必须被指定为application/vnd.-wap.mms-message，用以指明客户端应该进行的处理操作，它可以将多媒体部分的内容与显示控制部分的内容封装成为一个消息体。
    MMS PDU由MMS头和消息体组成。MMS头具体的描述了PDU的特定信息，消息体是可选的。通信的大多数情况是没有消息体的，只有在M-Send.req和M-Retrieve.conf原语中有消息体。在一个MMS中一次可填充多个消息体，消息体可以是不同类型的，由多个媒体对象组成，每个对象占据一个part(按照RFC2387标准)。根据消息内容的组装是否有序，消息的组装方式分为:
    .application/vnd.wap.multipart.mixed方式
    所有的消息内容混合在一起，没有时间上的顺序，在终端同一时间一次就把所有的消息内容显示出来。
    .application/vnd.wap.multipart.related方式
    各消息内容之间有一定关系，该关系可能是显示的时间上的先后，显示的位置等。这样在终端显示该消息的时候，就可以以类似“小电影”的方式显示一系列消息，使得该MM的显示更加趣味化。

   在MMS PDU之中，application/vnd.wap.multipart.related含有显示控制语言" presentation "，而application/vnd.wap.multipart.mixed不含有显示控制语言。通过application/vnd.wap.multipart.related内容类型可以将多媒体部分的内容与显示控制部分" presentation”内容封装成为一个消息体。Content-Type为application/vnd.wap.multipart.related的MMS PDU封装模型参考下图

application/vnd.wap.multipart.related MMS PDU封装模型

    当存在多媒体对象和显示控制信息时，如果在multipart/related中存在Start参数，"presentation”如果不是消息体的第一个part，则必须用start字段指出其所在位置，上
述各多媒体对象的排列顺序是无关紧要的;当不存在Start参数时，"presentation”部分应该排列在第一位的位置上;当根本不存在“presentation”部分时，如何显示则由客户端的显示策略来决定
    在MMS PDU中，
"presentation”也是MMLanguage)一个消息内容，但是终端显示消息内容
时，并不把这个消息内容显示出来，而仅是根据它获取一些消息，这些消息就决定了其
他的消息内容的显示的大小、先后顺序、位置等。而书写“presentation”这个消息内容
的语言，就是SMIL (Synchronized Multimedia Integration，SMIL是一种简单的标记性语言，内容书写格式和XML一样。消息体中最下层为媒体文件，如音频，视频，文本及图片文件。然后“presentation”用SMIL来表示这些文件播放的次序，文件名，开始播放时间，结束时间，当然如果是图片，文本则为显示时间，已经在屏幕中显示的具体位置。最后再用MIME来封装消息体。MMS消息的文本格式采用IETF规定的MIME结构(RFC2045-2049 )，它和OMA制定的Multimedia Messaging ServiceEncapsulation Protocol规定的二进制码格式有一一对应的关系。MIME主要是负责把所有的独立的文本、图像、声音、视频内容以及SMIL文件本身捆绑在一起，这个规范称为MIME Encapsulation Aggregate Documents，用于告诉接受的终端这个MMS的内容是相互相关并且相互参考的。
MMS PDU分析
    下面是MMS客户终端系统需要处理的20种MMS PDU:
    ★ 客户端将MM发送给发端MMS代理中继(M-Send.req )
    ★发端MMS代理中继发送给客户端(M-Send.conf )
    .★从MMS代理中继取回消息(WSP/HTTP GET.req )
    .★接收MM回复，收端代理中继发送至客户端(M-Retrieve.conf )
    .★新MM到达通知，收端代理中继发送至客户端(M-Notification.ind )
    .★MM通知回复，客户端发送至收端代理中继(M-NotifyResp. ind )
    .★己发送消息的发送报告(M-Delivery.ind )
    .★应答发送的消息(M-Acknowledge.ind )
    .★已发送消息的阅读报告(M-Read-Rec.ind, M-Read-Orig.ind)
    .★转发消息(MMS客户端发送一个请求让MMS代理中继转发消息 M-Forward.req和M-Forward. conf )
    .★存储或更新消息(M-Mbox-Store.req, M-Mbox-Store.conf)
    .★浏览下载消息(M-Mbox-View.req, M-Mbox-View.conf)
    .★MMBOX上传操作(M-Mbox-Upload.req, M-Mbox-Upload.conf)
    .★MMBOX删除操作(M-Mbox-Delete.req, M-Mbox-Delete.conf)
    MMS服务的实现是通过MMS客户端和MMS分发代理之间相互唤起和响应来传递信息的，这些传输流包括MM信息和相应的响应状态信息等。而这些MM信息被封装在相关的PDU中进行传输。

图2所示的是一个完整的MMS传输过程中的MM相关PDU。其中MMBOX是位于MMS中心服务器上的一块空间，类似于一个“邮箱”，功能及操作和电子邮件的IMAP相近。对于MMBOX的支持是可选的，MMBOX用于存储MM，本次并没有实现此功能，在此只做简单介绍。

由上图可看出MMS传输MM相关的PDU的整个过程为:
    1) MMS客户端发送MM时，MM被封装在称为M-Send.req PDU中，并被传送给MMS分发代理;
    2)通过M-Send.conf PDU接收分发代理返回的信息;
    3) MMS分发代理通过M-Notification.ind PDU通知MMS客户端有新MM到达，
MMS客户端通过M-NotifyResp.ind PDU进行回应;
    4) MMS客户端从MMS分发代理请求MM下载的操作基于标准的WSP/HTTPGET方法，本项目中采用WSP GET.req PDU，回应下载的PDU类型为M-Retrive.conf PDU;
    5) MMS客户端可以向MMS分发代理请求M-Forward.req PDU转发位于服务器上的MM，并获取回应信息M-Forward.conf PDU;
    6)当MMS客户端发送或转发的MM被接收方成功接收后，如果发送方请求传达报告、接收方允许该操作，则分发代理会向发送方发送传达报告M-Delivery.ind PDU,指示mm传送状态信息，不需要客户端进行回应或确认;
    7)当发送方要求已读报告、接收方允许己读报告时，MMS客户端产生M-read-rec.ind PDU发送给接收方的分发代理，由其转发给原始发送方的分发代理，后者接收到M-read-rec.ind PDU后，产生一个M-read-orig.ind PDU并将其发送到MMS客户端来传送已读报告;
    8) MMS客户端通过M-Mbox-Store.req PDU和M-Mbox-Store.conf PDU将新到MM存储到MMBOX，或更新已在MMBOX中的MM的状态和标记;通过M-Mbox-View.req PDU向MMS分发代理请求位于MMBOX中的一个或多个MM的信息用于浏览，也可以获取指定的MM的内容;通过M-Mbox-Upload.req PDU将本地的MM上传存储到MMBOX中;通过M-Mbox-Delete.req PDU请求MMS分发代理删除位于MMBOX中的MM. MMB OX中的MM均有MM标记属性，其由客户端进行维护，主要用于客户端检索、过滤MM之用，这些功能支持是可选的。
MMS PDU头域分析和头域编码
    每个MMS PDU都是由MMS头域和MMS消息体组成，MMS PDU中的头域由客户端指定，一些头域也可以被分发代理修改或补充，分发代理使用这些头域信息生成MM通知以及构造接收MM的PDU中的相关头域，连同消息实体一同送往接收方，消息体跟在头域之后。大多数MMS PDU只含有头域，它们起到建立和维持通信的作用，消息体只用在M-Send.req和M-Retrieve.conf PDU中。
    MMS头域根据WAP-209协议和RFC2387的规定，由一系列的域组成，这些域定义了PDU的各种属性，包括PDU类型，接受方，发送方，发送时间等，头域中的域名分为可选项和必选项。在编码MMS头域时，X-Mms-Message-Type ,X-Mms-Transaction-ID和X-Mms-MMS-Version必须位于MMS头的开始，并且按照前面所列的顺序。Content-Type必须在MMS头域的最后，其后为消息体，其它域的顺序可以随意安排。