Chinaunix首页 | 论坛 | 博客
  • 博客访问: 343105
  • 博文数量: 80
  • 博客积分: 711
  • 博客等级: 上士
  • 技术积分: 733
  • 用 户 组: 普通用户
  • 注册时间: 2012-03-23 15:43
文章分类

全部博文(80)

文章存档

2015年(9)

2014年(14)

2013年(33)

2012年(24)

我的朋友

分类: IT业界

2012-03-25 23:23:58

 MMS PDU结构

       MMS PDUProtocol Data Unit协议数据单元)由MMS头和MMS消息体组成,MMS头由多个域名和域值组成,由客户端指定, MMS头里面的一些域可以被MMS Proxy-Replay修改或补充,MMS Proxy-Replay使用这些头域信息生成MM通知以及构造接收MM PDU中的相关头域,连同消息实体一同送往接收方。消息体跟在MMS头之后,大多数MMS PDU只含有MMS头,它们起到建立和维持通信的作用,只有在M-Send.reqM-Retrieve.conf PDU中才有消息体。

MMS PDUHTTP PDU极为类似,但要简单一些。一个MMS PDU对应一种消息格式。不同类型的MMS PDU有不同的MMS Header MMS Header根据WAP-209协议和RFC2387的规定,由一系列的域组成,这些域定义了PDU的各种属性,包括PDU类型,版本号,接受方,发送方,主题,发送时间等。MMS Header中的域分为可选项和必选项,根据PDU的类型不同而不同。

常见的PDU的类型有:

        发送请求:     M-send.req

         发送确认:     M-send.conf

         彩信通知:     M-notification.ind

         通知回应:     M-notifyresp.ind

         获取彩信回应: M-retrieve.conf

         接收确认:     M-acknowledge.ind

         彩信回执:     M-delivery.ind

MMS Header后面立即接的就是Message Body。根据MMS Body组装的是否有序(是否有位置控制信息,有显示先后顺序),MMS消息体的组装方式分为:

application/vnd.wap.multipart.mixed方式
    
所有的消息内容混合在一起,没有时间上的顺序,内容怎么显示由客户端的显示控制策略来决定。
application/vnd.wap.multipart.related
方式
    
各消息内容之间有一定关系,该关系可能是显示的时间上的先后,显示的位置等。这样在终端显示该消息的时候,就可以以幻灯片的方式显示一系列消息,使得该MM的显示更加趣味化。

application/vnd.wap.multipart.related方式的MMS PDU之中,含有显示控制部分“presentation”,而application/vnd.wap.multipart.mixed不含有该部分。

presentation”是 MMS 中一个特殊的消息内容(part),它决定了其他消息内容的显示控制信息。实现“presentation”这个消息内容的语言,就是SMIL (Synchronized Multimedia Integration Language)SMIL是一种简单的标记性语言,内容书写格式和HTML类似。“presentation”正是用SMIL来表示这些多媒体元素显示的次序,位置,开始播放的时间,结束时间。下面给出一个SMIL结构的例子,其中注释-->是注释部分:

例子(包含两帧,每帧包括一张图片和一段文本)

<--!smil开始-->

<--!header smil -->

<--!显示的底板控制-->

<--!显示的内容定义-->

<--!显示内容控制-->

<--!第一帧持续时间为20秒,显示文件名称是videofilename.3gp -->

<--!第二帧开始,持续2-->

<--!第二帧结束-->

<--!smil结束-->

看见了吧,和HTML语言差不多。SMIL写好了以后,在windows平台上,另存为.smil文件以后,可以用支持smil格式的视频播放器打开,前提是smil文件和里面引用到的多媒体元素放在同一个目录里面。

前面说过,同音频,视频,文本及图片文件这些多媒体元素一样,“presentation”也是一个消息part,它们在Message Body中的排列顺序可以是任意的。还记得前面说过的MMS Header最后一个域Content Type吧,当MM内容包含SMIL格式的表现层时,content type必须为application/vnd.wap.multipart.related,否则使用application/vnd.wap.multipart.mixed

客户端怎么知道从哪个部分开始显示呢?当存在多媒体对象和显示控制信息时,即存在“presentation”部分,如果在Content Type中存在Start参数,“presentation”如果不是消息体的第一个part,则必须用start参数指出其所在位置;当不存在Start参数时,“presentation”部分应该排列在第一位的位置上,即紧接在MMS Header后面;当根本不存在“presentation”部分时,如何显示则由客户端的显示策略来决定。

的封装(Encapsulation

对于使用SMIL语言描述的MMS,在通过无线网络发送的时候,我们必须通过一种方式把SMIL和附属的多媒体内容包装在一起,能够以一个unit(整体)的形式发送出去,以便SMIL文件各个部分内容的reference变得有效。

这个解决的办法就是MIMEMultipart Internet Mail Extensions)规范,这个规范的最初作用是在emailplain text的主体中加入不同的内容。比如说,发送带有附件的email,这个时候你就使用了MIME的规范。MIME负责把所有的独立的文本、图像、声音、视频内容以及SMIL文件本身捆绑在一起,用于告诉接受的终端这个MMS的内容是相互相关(related to one another)并且相互参考的(referenced to one another)。MIME规范(RFC2045-2049)OMA制定的Multimedia Messaging Service Encapsulation Protocol规定的二进制码格式有一一对应的关系。

MIME封装示例

下面是根据RFC文档给出的MIME的封装示例:

Content-Type: application/vnd.wap.multipart.related; boundary="boundary-example"; type="application/smil"

--boundary-example

  Content-Type: text/html; charset="US-ASCII"

  ... ... ... ...

... ... ... ...

 --boundary-example

 Content-Type: image/gif

Content-ID:

Content-Location: fiction1/fiction2

…………………..Gif data

--boundary-example

Content-Type: image/gif

Content-ID:

Content-Location: fiction1/fiction3

…………………..Gif data

--boundary-example--

Content-type

位于信息头部的content-type用于通知接收的终端消息的各个不同部分的内容是相互关联的、并且可能是相互索引的(refer to one another)。而在信息体里面的ContentType用来指定该部分内容的数据类型。

Boundary

Boundary参数指定分隔符,用于分割各个不同的消息part。分隔符以两个短杠“-”开头。第一个部分是一个html类型的消息,这里只是取得了相关的部分。第二和第三部分省略了实际的images图像的实体。

Content-Location 和 Content-ID

HTML文本部分我们可以看到,我们可以利用两种方式来索引消息内容的不同部分。这两种不同的方式是 content-ID 和 content–Location。这两个域的属性应该是唯一的,以便区分不同的数据块。

如果一部分的消息体想通过content-ID指向(refer to)另外一部分的消息体,可以使用“CID”关于MIME的部分的信息可以参考RFC文档(RFC2387RFC2357)。

Multipart data

Message Body的结构正如上面MIME的封装结构。在实际的MMS PDU中,为了压缩数据,每个域的域名用固定的字节编码,并且去掉了分隔符。Message Body多媒体数据(Multipart,对应于多媒体文件数据)的编码结构如图12所示:

12 Application/vnd.wap.multipart 的格式

13 uintvar变量结构

整个uintvar变量的长度少于5 byte因此,uintvar可以表示无符号整型数的表示范围(032bit)。实际使用过程中,先把要编码的数值的二进制从最低位按每7位一组分好,然后把它们填到PayLoad域中,高位不足的补零,举例说明

数值0x87151000 0111 1010 0101)编码成uintvar类型如下所示:

14 0x8715uintvar表示

注意,如果高7位正好是7个零的话,不能编码成0x80,而是略去该字节。

Entries域结构如表2所示:

2 Entries结构

HeaderLen指示ContentType域和Header域的总长度,是一个Uintvar变量,DataLen指示后面Data域的长度,在这里指的是一块多媒体数据的字节数,ContentType域用来表示后面的数据块是什么类型的数据(如txt文本,jpeg图片,还是vidoe数据流),已经注册过的类型编码值可见附录AHeader域指定该块数据的其它信息,其中最重要的是Content LocationContent ID值,因此,在Message Body部分,Header域是不能省略的。Content LocationContent ID值通常是多媒体数据的文件名,Content Location域以单引号“”开始,后面一对<>里面包含文件名,Content ID域则直接就是一对<>里面包含文件名,关于这两个域的格式可参考MIME Part one,该部分在rfc2045里面。接着Header的是Data域,它的长度由DataLen指定,现在应该明白为什么MMS中的Message BodyMIME封装中不需要分隔符了吧,每个域的长度都是指定的。

    一个Entries域的后面紧接着另外一个Entries域(如果有的话),直到整个的MMS PDU尾,smil部分也是一个Entries

封装示例

下面举一个实际的MMS PDU编码示例来结束本节,该MMSmultipart/related类型。

实际发送MMS PDU完整的十六进制编码如下,为了节省篇幅,用“……”代替多媒体的具体数据:

8c 80 98 33 36 35 38 32 34 00 8d 92 89 1a 80 2b

38 36 31 33 34 36 39 30 37 32 34 30 34 2f 54 59

50 45 3d 50 4c 4d 4e 00 97 2b 38 36 31 35 38 37

34 32 38 39 37 36 36 2f 54 59 50 45 3d 50 4c 4d

4e 00 96 62 69 67 20 4d 4d 53 00 84 1f 1f b3 8a

3c 62 69 67 2e 73 6d 69 6c 3e 00 89 61 70 70 6c

69 63 61 74 69 6f 6e 2f 73 6d 69 6c 00 05

阅读(4534) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~