全部博文(80)
分类: IT业界
2012-03-25 23:23:58
MMS PDU结构
MMS PDU(Protocol Data Unit,协议数据单元)由MMS头和MMS消息体组成,MMS头由多个域名和域值组成,由客户端指定, MMS头里面的一些域可以被MMS Proxy-Replay修改或补充,MMS Proxy-Replay使用这些头域信息生成MM通知以及构造接收MM PDU中的相关头域,连同消息实体一同送往接收方。消息体跟在MMS头之后,大多数MMS PDU只含有MMS头,它们起到建立和维持通信的作用,只有在M-Send.req和M-Retrieve.conf PDU中才有消息体。
MMS PDU和HTTP 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变得有效。
这个解决的办法就是MIME(Multipart Internet Mail Extensions)规范,这个规范的最初作用是在email的plain 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)。而在信息体里面的Content-Type用来指定该部分内容的数据类型。
Boundary
Boundary参数指定分隔符,用于分割各个不同的消息part。分隔符以两个短杠“-”开头。第一个部分是一个html类型的消息,这里只是取得了相关的部分。第二和第三部分省略了实际的images图像的实体。
Content-Location 和 Content-ID
在HTML文本部分我们可以看到,我们可以利用两种方式来索引消息内容的不同部分。这两种不同的方式是 content-ID 和 content–Location。这两个域的属性应该是唯一的,以便区分不同的数据块。
如果一部分的消息体想通过content-ID指向(refer to)另外一部分的消息体,可以使用“CID”。关于MIME的部分的信息可以参考RFC文档(RFC2387和RFC2357)。
Multipart data
Message Body的结构正如上面MIME的封装结构。在实际的MMS PDU中,为了压缩数据,每个域的域名用固定的字节编码,并且去掉了分隔符。Message Body多媒体数据(Multipart,对应于多媒体文件数据)的编码结构如图12所示:
图12 Application/vnd.wap.multipart 的格式
图13 uintvar变量结构
整个uintvar变量的长度少于5 byte因此,uintvar可以表示无符号整型数的表示范围(0~32bit)。实际使用过程中,先把要编码的数值的二进制从最低位按每7位一组分好,然后把它们填到PayLoad域中,高位不足的补零,举例说明
数值0x8715(1000 0111 1010 0101)编码成uintvar类型如下所示:
图14 0x8715的uintvar表示
注意,如果高7位正好是7个零的话,不能编码成0x80,而是略去该字节。
Entries域结构如表2所示:
表2 Entries结构
HeaderLen指示ContentType域和Header域的总长度,是一个Uintvar变量,DataLen指示后面Data域的长度,在这里指的是一块多媒体数据的字节数,ContentType域用来表示后面的数据块是什么类型的数据(如txt文本,jpeg图片,还是vidoe数据流),已经注册过的类型编码值可见附录A。Header域指定该块数据的其它信息,其中最重要的是Content Location和Content ID值,因此,在Message Body部分,Header域是不能省略的。Content Location和Content ID值通常是多媒体数据的文件名,Content Location域以单引号“””开始,后面一对<>里面包含文件名,Content ID域则直接就是一对<>里面包含文件名,关于这两个域的格式可参考MIME 的Part one,该部分在rfc2045里面。接着Header的是Data域,它的长度由DataLen指定,现在应该明白为什么MMS中的Message Body的MIME封装中不需要分隔符了吧,每个域的长度都是指定的。
一个Entries域的后面紧接着另外一个Entries域(如果有的话),直到整个的MMS PDU尾,smil部分也是一个Entries。
封装示例
下面举一个实际的MMS PDU编码示例来结束本节,该MMS是multipart/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