基于WSP/WTP的MMS传输(5)——WSP 协议的实现
2011-08-28 22:44
555 查看
WSP协议位于WTP协议层之上,它没有保证数据正确传送的机制(这个部分是由WTP实现的),在WSP层提供会话管理功能,即连接——交互——断开连接这样的流程,WSP协议与HTTP协议实现上有对应的关系,如果熟悉HTTP,则WSP很容易理解。
WSP提供两种事务交互模式,无连接模式和有连接模式。无连接模式用于不可靠的信息交互服务,这和WTP的Class0模式比较相像,它不需要对方的回应,比如说彩信的PUSH通知就使用的这种模型。有连接模式提供可靠的数据传送服务,服务请求方发出一个请求,响应方需要给出一个响应以表示请求的结果,彩信应用的就是这种模式。所有应用层的的服务请求都是通过WSP相应的方法(Method)来实现的,服务数据作为WSP PDU的Data域,一个WSP PDU的结构如图18所示:
![](http://hi.csdn.net/attachment/201008/8/0_12812771704Jjn.gif)
图18 WSP PDU结构
TID是事务ID,在无连接模式下,该域必须出现;在有连接的模式下,该域不能出现。WSP的功能分为会话管理能力和方法请求功能,Type指出请求的类型,要么是会话管理的子类型要么是方法请求功能的相应的方法类型。Type-Specific Contents包括的有各PDU类型指定的域和应用层的数据,我们这里的数据就是MMS PDU了。下面仅仅介绍几种与彩信传输相关的PDU 类型及其结构。
Connect
Connect 类型的PDU用于会话开始之前与WAP网关建立连接,同时完成双方的能力协商,即后面会话的一些参数设定。Connect域的结构如表14所示:
表14 Connect域结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277235oaJ6.gif)
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域结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277296yBZB.gif)
开始是长度,是Identifier域和Parameters域长度的总和,uintvar类型,实际中占用1个字节就够了,然后是Identifier,Capability共有10中Identifier,它们的名称、编码值和默认值如下表所示:
表16 Capabilitity Identitier域名称及其编码
实际的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277367k8k8.gif)
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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277445tlL6.gif)
里面包含彩信所在服务器的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277509UJAe.gif)
这些域不多做解释,这里的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277575TlSj.gif)
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。
![](http://hi.csdn.net/attachment/201008/8/0_1281277632B5mJ.gif)
图 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,里面有详细的说明。
转载请注明出处
WSP提供两种事务交互模式,无连接模式和有连接模式。无连接模式用于不可靠的信息交互服务,这和WTP的Class0模式比较相像,它不需要对方的回应,比如说彩信的PUSH通知就使用的这种模型。有连接模式提供可靠的数据传送服务,服务请求方发出一个请求,响应方需要给出一个响应以表示请求的结果,彩信应用的就是这种模式。所有应用层的的服务请求都是通过WSP相应的方法(Method)来实现的,服务数据作为WSP PDU的Data域,一个WSP PDU的结构如图18所示:
![](http://hi.csdn.net/attachment/201008/8/0_12812771704Jjn.gif)
图18 WSP PDU结构
TID是事务ID,在无连接模式下,该域必须出现;在有连接的模式下,该域不能出现。WSP的功能分为会话管理能力和方法请求功能,Type指出请求的类型,要么是会话管理的子类型要么是方法请求功能的相应的方法类型。Type-Specific Contents包括的有各PDU类型指定的域和应用层的数据,我们这里的数据就是MMS PDU了。下面仅仅介绍几种与彩信传输相关的PDU 类型及其结构。
Connect
Connect 类型的PDU用于会话开始之前与WAP网关建立连接,同时完成双方的能力协商,即后面会话的一些参数设定。Connect域的结构如表14所示:
表14 Connect域结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277235oaJ6.gif)
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域结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277296yBZB.gif)
开始是长度,是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 |
看起来一个完整的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277367k8k8.gif)
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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277445tlL6.gif)
里面包含彩信所在服务器的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277509UJAe.gif)
这些域不多做解释,这里的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结构
![](http://hi.csdn.net/attachment/201008/8/0_1281277575TlSj.gif)
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。
![](http://hi.csdn.net/attachment/201008/8/0_1281277632B5mJ.gif)
图 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,里面有详细的说明。
转载请注明出处
相关文章推荐
- 基于WSP/WTP的MMS传输(4)——WSP 协议的实现
- 基于WSP/WTP的MMS传输(4)——WTP协议的实现
- 基于WSP/WTP的MMS传输(5)——WTP协议的实现
- 基于WSP/WTP的MMS传输(6)——WSP 协议的实现
- 基于WSP/WTP的MMS传输(4)——MMS 传输
- 基于WSP/WTP的MMS传输——MMS PDU结构
- 基于WSP/WTP的MMS传输(5)——完整MMSWSP/WTP打包示例
- 基于WSP/WTP的MMS传输(3)——MMS 传输
- 基于WSP/WTP的MMS传输(10)——完整MMSWSP/WTP打包示例
- 基于WSP/WTP的MMS传输(11)——WSP Content Type
- 基于WSP/WTP的MMS传输(6)——MMS Notification 解析
- 基于WSP/WTP的MMS传输(7)——MMS Notification 解析
- 基于WSP/WTP的MMS传输(8)——测试工具
- 基于WSP/WTP的MMS传输(2)——MMS的传输模型
- 基于WSP/WTP的MMS传输(3)——MMS PDU结构
- 基于WSP/WTP的MMS传输(9)——开发中要解决的问题
- 基于WSP/WTP的MMS传输(1)——概述
- 基于WSP/WTP的MMS传输(1)——概述
- 基于WSP/WTP的MMS传输(2)——MMS的传输模型
- 基于WSP/WTP的MMS传输——MMS 传输