基于WSP/WTP的MMS传输(5)——WSP 协议的实现

WSP协议位于WTP协议层之上，它没有保证数据正确传送的机制（这个部分是由WTP实现的），在WSP层提供会话管理功能，即连接——交互——断开连接这样的流程，WSP协议与HTTP协议实现上有对应的关系，如果熟悉HTTP，则WSP很容易理解。

       WSP提供两种事务交互模式，无连接模式和有连接模式。无连接模式用于不可靠的信息交互服务，这和WTP的Class0模式比较相像，它不需要对方的回应，比如说彩信的PUSH通知就使用的这种模型。有连接模式提供可靠的数据传送服务，服务请求方发出一个请求，响应方需要给出一个响应以表示请求的结果，彩信应用的就是这种模式。所有应用层的的服务请求都是通过WSP相应的方法（Method）来实现的，服务数据作为WSP PDU的Data域，一个WSP PDU的结构如图18所示：

 

图18 WSP PDU结构

TID是事务ID，在无连接模式下，该域必须出现；在有连接的模式下，该域不能出现。WSP的功能分为会话管理能力和方法请求功能，Type指出请求的类型，要么是会话管理的子类型要么是方法请求功能的相应的方法类型。Type-Specific Contents包括的有各PDU类型指定的域和应用层的数据，我们这里的数据就是MMS PDU了。下面仅仅介绍几种与彩信传输相关的PDU 类型及其结构。

Connect

       Connect 类型的PDU用于会话开始之前与WAP网关建立连接，同时完成双方的能力协商，即后面会话的一些参数设定。Connect域的结构如表14所示：

表14 Connect域结构

 

Version 版本号，占用8bit，其编码格式是这样的：高4位放主版本号，低4位放次版本号。WAP-230-WSP-20010705-a.pdf所指的版本号是1.0，编码为0001 0000，即0x10。接着后面的是能力值长度，即Capabilities域的长度，以byte为单位，使用的是大字节序（即高字节放在低地址，低字节放在高地址），这个域的类型是uintvar，前面详细的解释过。

再接在后面的是HeadersLen，指示Headers域占用的字节数，它也是uintvar类型，和上面的编码规则一样。在MMS的传输中，所有WSP PDU中的Header域都可以省略不填，即HeadersLen可设为0。后面紧跟的是Capabilities域，其结构如表15所示：

表15 Capabilities域结构

 

       开始是长度，是Identifier域和Parameters域长度的总和，uintvar类型，实际中占用1个字节就够了，然后是Identifier，Capability共有10中Identifier，它们的名称、编码值和默认值如下表所示：

 

表16 Capabilitity Identitier域名称及其编码

Name

Encode Value

Default Setting

Client SDU Size

0x00

1400 bytes

Server SDU size

0x01

1400 bytes

Protocol Options

0x02

0x00

Method MOR

0x03

0

Push MOR

0x04

0

Extended Methods

0x05

None

Header Code Pages

0x06

None

Aliases

0x07

None

Client Message Size

0x08

1400 bytes

Server Message Size

0x09

1400 bytes

       实际的WSP PDU 的Encode Value值最高位需要置1。这里和彩信传输相关的有Client SDU Size和Server SDU size两个域，分别用来指定客户端可以接收的最大WSP PDU包的长度和客户端将要发送的最大WSP PDU长度。注意：由于彩信的最大可以有50k，为了一次把彩信数据传送完，这两个值都需设定大于50k。对于其它域的含义和设定值可以参考WSP协议的8.3节。最后面的是Header域，可以不填。

看起来一个完整的Connect PDU如下：

01 10 0b 00 05 80 81 83 e0 00 04 81 86 a0 00

01 //指示是Connect PDU

10 //版本号1.0

0b //CapaliLen 11字节

00 //HeadersLen 0字节

05 //该Capability 域长度为5字节

80 //设定的是Client SDU Size

81 83 e0 00 //60k大小，uintvar编码

04 //该Capability 域长度为4字节

81 //设定的是Server SDU Size

86 a0 00  //100k的uintvar编码

ConnectReply PDU

    客户端给服务器发送Connect PDU后，服务端收到以后会返回一个ConnectReply PDU，结构如下：

表17 ConnectReply PDU结构

SenverSessionID 用于后面的Disconnect PDU, 其它域和Connect对应的域一样。注意一点：ConnectReply PDU里面的Capabilities的含义与Connect域里面的不一样，如果服务器接受Connect PDU里面的设定，服务器返回的ConnectReply里面是没有Capabilities的，只有在我们设定的参数服务器有改变是，才在ConnectReply PDU中存在Capabilities域指示，服务器采用的设定值。

DisConnect PDU

    DisConnect PDU里面唯一的一个域是ConnectReply里面的SenverSessionID。用于客户端或服务端断开连接。这个PDU可能是客户端发出的，也可能是服务器发出的。

 

Get PDU

    这个PDU用于向服务器请求数据，用来接收彩信，结构如下：

表18 Disconnect PDU结构

 

里面包含彩信所在服务器的URI地址，URILen指定URI域的长度。URI是在彩信Push通知中取得，一般是一系列的字符串。Header对于接收彩信来说可以省略。

完整的PDU像下面的样子：

0E 00 02 12 40 22 68 74 74 70 3A 2F 2F 32 31 31

2E 31 33 36 2E 32 32 31 2E 37 35 2F 61 52 63 36

78 71 59 66 35 72 72 42

0E 00 02 12 是WTP的Invoke Header部分

40 指定是GetPDU

22 后面的URI域长度是34个字节

68～42 的34个字节是http://211.136.221.75/aRc6xqYf5rr的ASCⅡ编码，彩信的URI地址

POST PDU

    结构如下：

表19 POST PDU结构

这些域不多做解释，这里的Uri域不同于Get PDU里面的Uri域，彩信的传送中指的是彩信服务中心的Uri，对于移动用户来说是：http://mmsc.monternet.com,联通用户是：http://mmsc.myuni.com.cn。ContentType固定为application/vnd.wap.mms-message，Data域是MMS PDU内容。

POST PDU 的完整结构像这样子：

60 19 20 68 74 74 70 3A 2F 2F 6D 6D 73 63 2E 6D

6F 6E 74 65 72 6E 65 74 2E 63 6F 6D 61 70 70 6C

69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E

6D 6D 73 2D 6D 65 73 73 61 67 65 00 80 8C 98 30

………………………..

60 指定是POST PDU

19 URI长度25字节

20 Header和ContentType总长度32字节

68～6D Uri：http://mmsc.monternet.com 的ASCⅡ编码

61～00 ContentType：application/vnd.wap.mms-message的ASCⅡ编码 00为字串结束符

80 8C 98 30 ……是我们熟悉的MMS PDU内容

Reply PDU

       这个是我们用POST方法发送彩信或者用GET方法接收彩信时，服务器给我们应答的WSP PDU，结构如表20：

表20 Reply PDU结构

 

       Status指定请求是否执行成功，和HTTP里面的状态码有一一对应关系，如果执行成功则是0x20，否则是其它的状态码，指定出错的类型，其编码可参考WSP说明文档中附录A的Table36.，如果GET方法执行成功的话，Data域是MMS PDU。

完整的Reply看起来像下面的样子：

13 80 02 04 20 33 61 70 70 6c 69 63 61 74 69 6f

6e 2f 76 6e 64 2e 77 61 70 2e 6d 6d 73 2d 6d 65

73 73 61 67 65 00 a6 52 65 73 69 6e 2f 33 2e 30

2e 37 00 92 04 49 a2 79 95 8c 84 98 30 ………

13 80 02  WTP Result PDU Header部分

04 表示该PDU是Reply PDU

20 状态码，请求成功响应

33 ContentType和Header的总长度

a6 0x26的最高位置1，指明是Header的Server域

52～00 Server域值：Resin/3.0.7

92 Header的Data域

04 Data域值的长度

49 a2 79 95 Data域的值，是从1970年1月1号0点0分0秒到现在的秒数

8c 84 98 30 我们熟悉的MMS Header 后面就是整个的MMS PDU数据。

 

整个WSP/WTP协议就介绍到这里，如果要了解更多的细节，可以参考WAP-230-WSP-20010705-a.pdf和WAP-224-WTP-20010710-a.pdf，这两个文档可以从官方免费下载。

   图19所示的是一个完整的MMS传输过程中的MM相关PDU。其中MMBOX是位于MMS中心服务器上的一块空间，类似于一个“邮箱”，功能及操作和电子邮件的IMAP相近。对于MMBOX的支持是可选的，MMBOX用于存储MM。

 

 

图 19 相对比较完整的MMS传输的过程

由上图可看出MMS传输MM相关的PDU的整个过程为:

    1) MMS客户端发送MM时，MM被封装在称为M-Send.req PDU中，信息以WAP WSP/WTP的协议进行编码，通过无线网络传送到WAP网关，并被转送给MMS Proxy Reply;

    2) MMS客户端通过M-Send.conf PDU接收MMS Proxy Reply返回的信息;

    3) MMS Proxy Reply通过M-Notification.ind PDU通知MMS客户端有新MM到达，MMS通知是以SMS的方式发送的，通知是以WSP协议进行的编码，这个通知里面包含了多媒体信息在彩信服务中心（MMSC）的地址。在没有确认被叫用户已经接受了信息之前，该信息始终保存在短信存储器中。运营商可以通过软件设定保存的时间长度。MMS客户端通过M-NotifyResp.ind PDU进行回应;

    4) MMS客户端从MMS Proxy Reply请求下载MM的操作基于标准的WSP/HTTP GET方法，采用WSP GET.req PDU，MMS Proxy Reply回应下载请求的PDU类型为M-Retrive.conf PDU;

    5) MMS客户端可以向MMS Proxy Reply请求M-Forward.req PDU转发位于服务器上的MM，并获取MMS Proxy Reply回应信息M-Forward.conf PDU;

    6)当MMS客户端发送或转发的MM被接收方成功接收后，如果发送方请求传达报告、接收方允许该操作，则MMS Proxy Reply会向发送方发送传达报告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 Proxy Reply请求位于MMBOX中的一个或多个MM的信息用于浏览，也可以获取指定的MM的内容;通过M-Mbox-Upload.req PDU将本地的MM上传存储到MMBOX中;通过M-Mbox-Delete.req PDU请求MMS Proxy Reply删除位于MMBOX中的MM. MMBOX中的MM均有MM标记属性，其由客户端进行维护，主要用于客户端检索、过滤MM之用，这些功能支持是可选的。

下面是MMS客户终端系统需要处理的20种MMS PDU:
    1.客户端将MM发送给MMS Proxy Reply (M-Send.req )
    2.MMS Proxy Reply中继发送给客户端(M-Send.conf )
    3.从MMS Proxy Reply取回消息(WSP/HTTP GET.req )
    4.接收MM回复，MMS Proxy Reply发送至客户端(M-Retrieve.conf )
    5.新MM到达通知，MMS Proxy Reply发送至客户端(M-Notification.ind )
    6.MM通知回复，客户端发送至MMS Proxy Reply (M-NotifyResp.ind )
    7.己发送消息的发送报告(M-Delivery.ind )
    8.应答发送的消息(M-Acknowledge.ind )
    9.已发送消息的阅读报告(M-Read-Rec.ind, M-Read-Orig.ind)
    10.转发消息(MMS客户端发送一个请求让MMS Proxy Reply转发消息  M-Forward.req和M-Forward. conf )
    11.存储或更新消息(M-Mbox-Store.req, M-Mbox-Store.conf)
    12.浏览下载消息(M-Mbox-View.req, M-Mbox-View.conf)
    13.MMBOX上传操作(M-Mbox-Upload.req, M-Mbox-Upload.conf)
    14.MMBOX删除操作(M-Mbox-Delete.req, M-Mbox-Delete.conf)

    MMS服务的实现是通过MMS客户端和MMS Proxy Reply之间相互唤起和响应来传递信息的，这些传输流包括MM信息和相应的响应状态信息等。而这些MM信息被封装在相关的PDU中进行传输。这里再强调一下，实际的数据发送与接收是在客户端与WAP网关之间。MMS客户端和MMS Proxy Reply通过WAP网关传递信息。WAP 1.x网关上，每种MMS PDU有对应的WSP协议实现，MMS与WSP的对应关系可参见OMA-MMS-CTR-V1_2-20031215-C.pdf的第8节Binding to Transport Protocols，里面有详细的说明。

转载请注明出处