[流媒体]实例解析MMS流媒体协议

1、流媒体实例解析MMS流媒体协议，下载LiveMediaVideo1修正版，增加了带宽测试包 通过mms:/220.194.63.17/cebeijing8，我们可以看到交通部门设置在北京西直门上的摄像头的实时录像，从而了解西直门的交通状况。但是，要是想下载这个流媒体到本地的话，我试验了asfr+、ASF Recorder以及StreamBox vcr，均无法下载。又找了一个mimms-0.0.9的linux版本，也就是以前的mmsclient，将其依赖于Linux的某些函数库换成Windows版本的对应包，编译之后，可以下载mms:/220.194.63.17/cebeijing8的数据，但是

2、用WindowsMediaPlayer9播放的时候，却报告错误“无法播放，因为此文件已损坏。只有SDP2.0(Streaming Download Project)可以正常下载并播放它。为了改造mimms，我分析了SDP和流媒体效劳器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services协议有帮助。对了，编码格式是“Little Endian，也就是0f 00 00 00的实际值是0x0f。下面是每一个数据包。我们对每一个“包头和“包体的每一个字节都做了尽可能详细的分析。  第一

3、对包：client to server 告知Player版本号 第一回合之第一个包：to server;Len=104：0030 01 00 00 00 ce fa 0b b0 58 00 .a.X.0040 00 00 4d 4d 53 20 0b 00 00 00 00 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 09 00 00 00 01 00 03 00 f0 f0 .0060 f0 f0 0b 00 04 00 1c 00 03 00 4e 00 53 00 50 00 .N.S.P.0070 6c 00 61 00 79 00

4、 65 00 72 00 2f 00 37 00 2e 00 l.a.y.e.r./.7.0080 31 00 2e 00 30 00 2e 00 31 00 39 00 35 00 36 00 1.0.1.9.5.6.0090 3b 00 20 00 00 00 00 00 00 00 00 00 00 00 ;. .“包头解释：l         “01 00 00 00”是客户端向效劳器端发包的固定开头。以后你会看到每一个包都是如此开头的。4字节。l     

5、    “ce fa 0b b0”，这也是固定不变的。通常被人称为“BOOB FACE。他可能是一个版本号或者序列号。以后你会看到客户端和效劳器端发出的每一个包都是如此开头的。4字节。l         “58 00 00 00”，说明在“协议类型(也就是接下来的4d 4d 53 20)后面的所有数据的长度。4字节。l         “4d 4d 53 20”，说明协议类型，就是“MMS<space

6、>的ASCII码。4字节。l         “0b 00 00 00”，Length until end of packet in 8 byte boundary lengths，Including own data field。4字节。l         “00 00 00 00”，Sequence number。4字节。l         “00

7、 00 00 00 00 00 00 00”，8字节。Double precision time stamp (see notes) used for network timing。l         “09 00 00 00”，Length until end of packet in 8 byte boundary lengths. Including own data field。4字节。l         “01 00 03 0

8、0”, 指的是“Comm 2 bytes | Dir 2 bytes。01 00是Command数值。03 00是Direction数值，这里的0x03指明客户端发往效劳器。4字节。按照我的理解，上面的可以算作包头，每个客户端发出的数据包差不多都有类似的头。在“Comm 2 bytes | Dir 2 bytes之后，就是这个包的Body了。“包体解释：l         “f0 f0 f0 f0”，MMS协议标志1。l        

9、 “0b 00 04 00”，不知道。l         “1c 00 03 00”，不知道。l         “4e 00 53 00 50 00 6c 00 61 00 79 00 65 00 72 00 2f 00 37 00 2e 00 31 00 2e 00 30 00 2e 00 31 00 39 00 35 00 36 00 3b 00 20 00”，其实就是“NSPlayer/7.1.0.1956;<space&

10、gt;的ASCII码。这是向效劳器说明客户端的播放器的版本名。值得注意的是，这个版本名字必须以“NSPlayer开头，否那么MMS效劳器将不管你的请求是什么，强制返回给客户端一个15秒的电影文件“Upgrade Your Player，用来展示如何升级你的播放器。“NSPlayer后面跟随的版本号无所谓是什么，比方mimms的是“9.0.0.2800”。l         “00 00 00 00 00 00 00 00 00 00”，补零的局部。实际上，上面第一个包体应该是类似于这样的格式：NSPlayer/版本

11、号;<space>128位的客户端GUID;<space>Host:<space>效劳器的IP地址举一个实际的例子：NSPlayer/9.0.0.2800; f5cec3a0-3e2c-11da-b2a2-00055d1a21bd; Host: 220.194.63.17但是，抓SDP2.0得到的包有点不一样。郑昀编写，随时更新。第一对包：server to client 告知效劳器版本号以及加密协议 第一回合之第2个包：to client;Len=144：0030 01 00 00 00 ce fa 0b b0 80 00 .p.0040 00

12、00 4d 4d 53 20 10 00 00 00 00 00 00 00 73 00 .MMS .s.0050 70 00 3a 00 2f 00 0e 00 00 00 01 00 04 00 00 00 p.:./.0060 00 00 f0 f0 f0 f0 0b 00 04 00 1c 00 03 00 00 00 .0070 00 00 00 00 f0 3f 01 00 00 00 01 00 00 00 00 80 .?.0080 00 00 80 96 98 00 0d 00 00 00 00 00 00 00 00 00 .0090 00 00 05 00 00 00 3

13、9 00 2e 00 30 00 31 00 2e 00 .9.0.1.00a0 30 00 31 00 2e 00 33 00 38 00 31 00 34 00 00 00 0.1.3.8.1.4.00b0 4e 00 54 00 4c 00 4d 00 00 00 00 00 00 00 00 00 N.T.L.M.00c0 00 00 00 00 00 00 .“包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到

14、每一个包都是如此开头的。8字节。l         “80 00 00 00”，说明在“协议类型(也就是接下来的4d 4d 53 20)后面的所有数据的长度。4字节。l         “4d 4d 53 20”，说明协议类型，就是“MMS<space>的ASCII码。4字节。l         “10 00 00 00”，Length unti

15、l end of packet in 8 byte boundary lengths，Including own data field。4字节。l         “00 00 00 00”，Sequence number。4字节。l         “73 00 70 00 3a 00 2f 00”，8字节。Double precision time stamp (see notes) used for network timing。

16、l         “0e 00 00 00”，Length until end of packet in 8 byte boundary lengths. Including own data field。4字节。l         “01 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes。01 00是Command数值。04 00是Direction数值，这里的0x04指明效劳器发往客户端。4字节。

17、在“Comm 2 bytes | Dir 2 bytes之后，就是这个包的Body了。“包体解释：l         “f0 f0 f0 f0”，MMS协议标志1。4字节。l         “0b 00 04 00”，不知道。4字节。l         “1c 00 03 00”，不知道。4字节。l     

18、;    “00 00 00 00 00 00 f0 3f，固定数值，不知道含义。8字节。l         “01 00 00 00 01 00 00 00 00 80 00 00”，固定数值，不知道含义。12字节。l         “80 96 98 00”，有时候也会是“00 00 a0 00”， 8字节。l       

19、0; “39 00 2e 00 30 00 31 00 2e 00 30 00 31 00 2e 00 33 00 38 00 31 00 34 00”，其实就是“9.01.01.3814”的ASCII码。这是向客户端说明效劳器端的版本号，“9.01.01.3814”看来是很新的Media Server版本。l         “4e 00 54 00 4c 00 4d 00”，是“NTLM的ASCII码。代表效劳器的加密类型，诸如BASIC, DIGEST或者NTLM。这个包中，在效劳器版本号之后，加密类型之前，

20、也可能有以下两种数据：l         工具版本号，如5.1.0.0；l         更新播放器的链接，如 :/ theupdatesite /updateplayer.html，微软有时候通过这个URL让你的客户端Windows Media Player更新最新的版本。这两个数据不一定会有，但是效劳器版本号必须要有。郑昀编写，随时更新。第二对包：client to server 请求“the timing test data m

21、ethod 第二回合之第1个包：to server;Len=48：0030 01 00 00 00 ce fa 0b b0 20 00 .o.6. .0040 00 00 4d 4d 53 20 04 00 00 00 01 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 02 00 00 00 18 00 03 00 f1 f0 .0060 f0 f0 0b 00 04 00 .“包头解释：l         “01 00 00 00 ce fa 0b b0”是效

22、劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l         “18 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes。18 00是Command数值。03 00是Direction数值，这里的0x03指明客户端发往效劳器。4字节。是不是奇怪，怎么突然跳到了命令18。看来并不是按照命令顺序发送命令的。这个命令代表：“what ti

23、ming tests to do, if any。在“18 00 03 00”之后，就是这个包的Body了。“包体解释：l         “f1 f0 f0 f0”，说明“the TCP timing method is required。4字节。l         “0b 00 04 00”，不知道，4字节。第二对包：server to client 网络带宽和数据速率测试包 第二回合之第2个包：to client;Len

24、=512：0030 01 00 00 00 ce fa 0b b0 f0 01 .g.0040 00 00 4d 4d 53 20 3e 00 00 00 01 00 00 00 73 00 .MMS >.s.0050 70 00 3a 00 2f 00 3c 00 00 00 15 00 04 00 00 00 p.:./.<.0060 00 00 f1 f0 f0 f0 08 00 00 00 01 00 00 00 00 00 .0070 01 00 d4 b9 42 f1 00 00 00 00 01 00 00 00 00 00 .B.0080 00 00 00 00 0

25、0 00 2d eb 9b 2d d2 fa e6 1c 09 12 .-.-.0090 b7 df ab 5e 07 71 a7 a0 a2 77 fe d1 ea db 9d 07 .q.w.00a0 ce 15 9c 80 bc d4 ae af 29 56 0e 44 77 b9 a8 c3 .)V.Dw.00b0 c1 1c 4d 4f 80 00 6c fd 06 6e b1 a8 0b 2e e1 25 .MO.l.n.%00c0 21 15 2a fc e0 8e be 0f ae c4 8d c0 fb a7 df 5b !.*.00d0 ca 77 58 7b 88 14

26、14 de 7d 68 13 d7 f9 ea 1b a8 .wX.h.00e0 26 ea 3f 17 09 8f c9 26 01 0b 83 39 70 d3 e7 d0 &.?.&.9p.00f0 6e e8 d5 75 76 e8 09 00 c1 91 2c 04 18 e1 6b a3 n.uv.,.k.0100 77 f3 1e 38 a0 39 fe 4a 7b e0 96 62 3d fa 33 e6 w.8.9.J.b=.3.0110 69 b3 89 90 06 71 eb 50 50 88 03 fb 2d b8 89 78 i.q.PP.-.x012

27、0 0b 7e 3f be fe 5f 7a da 88 de 9e 66 3e a6 a2 84 .?._z.f>.0130 5f b9 6b 9a 5c 9b f2 eb ef 64 16 73 3b 6a ac a7 _.k.d.s;j.0140 14 6f d2 20 17 5e 75 18 24 cd 49 22 69 c2 c9 b4 .o. .u.$.I"i.0150 50 25 76 32 ec 24 18 c9 9c bd 89 09 84 4a 28 c5 P%v2.$.J(.0160 d7 20 57 97 c7 ab 69 ee 89 7c e9 4c

28、f3 ae 57 9d . W.i.|.L.W.0170 c1 22 bf 45 83 38 f0 eb 81 94 f8 ff ad 3f d7 fe .".E.8.?.这个回应命令18的包属于命令15，可能有好几个，一般是两个512的包和一个1056的包，一般发送的假数据总字节数为1840字节。他是用来测试网络带宽，以及数据发送速率的。这些包中的数据可能是随机数据，而且可能不做压缩。这样可以测出在一个非压缩的连接上所能到达的带宽。“包头解释：l         “01 00 00 00 ce fa 0

29、b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l         “15 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes。15 00是Command数值。04 00是Direction数值，这里的0x04指明效劳器发往客户端。4字节。在“15 00 04 00”之后，就是这个包的Body了。“包体解释：l &

30、#160;       “00 00 00 00”，错误号。l         “f1 f0 f0 f0”，标志，后面跟随的都是本次结构数据了。l         “08 00 00 00”，说明本结构共8个字段，包括自己。l         “01 00 00 00”；l  &

31、#160;      “00 00 01 00”;l         “d4 b9 42 f1”，分配你一个客户端ID。每登录一个客户端，这个ID自增加一，以方便效劳器的UDP回复包知道向哪一个client发送。l         “00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00”，接下来就是随机数据了。l   

32、;      随机数据。流媒体实例解析MMS流媒体协议，下载LiveMediaVideo2 通过mms:/220.194.63.17/cebeijing8，我们可以看到交通部门设置在北京西直门上的摄像头的实时录像，从而了解西直门的交通状况。但是，要是想下载这个流媒体到本地的话，我试验了asfr+、ASF Recorder以及StreamBox vcr，均无法下载。又找了一个mimms-0.0.9的linux版本，也就是以前的mmsclient，将其依赖于Linux的某些函数库换成Windows版本的对应包，编译之后，可以下载mms:/220.1

33、94.63.17/cebeijing8的数据，但是用WindowsMediaPlayer9播放的时候，却报告错误“无法播放，因为此文件已损坏。只有SDP2.0(Streaming Download Project)可以正常下载并播放它。为了改造mimms，我分析了SDP和流媒体效劳器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services协议有帮助。下面是第三个回合的数据包。我们对每一个“包头和“包体的每一个字节都做了尽可能详细的分析。    

34、0;  第三对包：client to server 告知传输协议/IP地址/端口号 第三回合之第1个包：to server;Len=112：0030 01 00 00 00 ce fa 0b b0 60 00 .0040 00 00 4d 4d 53 20 0c 00 00 00 02 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 0a 00 00 00 02 00 03 00 f1 f0 .0060 f0 f0 ff ff ff ff 00 00 00 00 00 00 a0 00 02 00 .0070 00 00 5c 00

35、5c 00 31 00 39 00 32 00 2e 00 31 00 .1.9.2.1.0080 36 00 38 00 2e 00 31 00 2e 00 38 00 35 00 5c 00 6.8.1.8.5.0090 54 00 43 00 50 00 5c 00 32 00 35 00 31 00 36 00 T.C.P.2.5.1.6.00a0 00 00 00 00 00 00 “包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FAC

36、E固定开头。以后你会看到每一个包都是如此开头的。8字节。l         “60 00 00 00”，说明在“协议类型(也就是接下来的4d 4d 53 20)后面的所有数据的长度。4字节。l         “4d 4d 53 20”，说明协议类型，就是“MMS<space>的ASCII码。4字节。l         “0c 00 00 00”

37、，Length until end of packet in 8 byte boundary lengths，Including own data field。4字节。l         “02 00 00 00”，Sequence number。4字节。l         “00 00 00 00 00 00 00 00”，8字节。Double precision time stamp (see notes) used for net

38、work timing。l         “0a 00 00 00”，Length until end of packet in 8 byte boundary lengths. Including own data field。4字节。l         “02 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes。02 00是Command数值。03 00是Direction数值，这里的0x03指明客

39、户端发往效劳器。4字节。在“Comm 2 bytes | Dir 2 bytes之后，就是这个包的Body了。“包体解释：l         “f1 f0 f0 f0”，MMS协议标志2。4字节。l         “ff ff ff ff 00 00 00 00”，不知道。8字节。l         “00 00 a0 00”，不知道。4字节。l 

40、;        “02 00 00 00”，固定数值，反映了Header PacketIDType。4字节。l         “01 00 00 00 01 00 00 00 00 80 00 00”，固定数值，不知道含义。12字节。l         “5c 00 5c 00 31 00 39 00 32 00 2e 00 31 00 36 00 38 00 2

41、e 00 31 00 2e 00 38 00 35 00 5c 00 54 00 43 00 50 00 5c 00 32 00 35 00 31 00 36 00”，其实就是“192.168.1.85TCP2516”的ASCII码。这是向效劳器说明传输层协议类型TCP，客户端的IP地址192.168.1.85以及socket端口号2516。第三对包：server to client 表示接受传输协议 第三回合之第2个包：to client;Len=96：0030 01 00 00 00 ce fa 0b b0 50 00 .0.P.0040 00 00 4d 4d 53 20 0a

42、 00 00 00 04 00 00 00 73 00 .MMS .s.0050 70 00 3a 00 2f 00 08 00 00 00 02 00 04 00 00 00 p.:./.0060 00 00 f1 f0 f0 f0 08 00 00 00 46 00 75 00 6e 00 .F.u.n.0070 6e 00 65 00 6c 00 20 00 4f 00 66 00 20 00 54 00 n.e.l. .O.f. .T.0080 68 00 65 00 20 00 47 00 6f 00 64 00 73 00 00 00 h.e. .G.o.d.s.0090 8a 9

43、4 b9 30 c2 c1 .0.“包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l         “02 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes。02 00是

44、Command数值。04 00是Direction数值，这里的0x04指明效劳器发往客户端。4字节。在“02 00 04 00”之后，就是这个包的Body了。“包体解释：l         “00 00 00 00”，错误号。l         “f1 f0 f0 f0”，MMS协议标志2。4字节。l         “08 00 00 00”，4字节。数据

45、的长度，有可能是假的。l         “46 00 75 00 6e 00 6e 00 65 00 6c 00 20 00 4f 00 66 00 20 00 54 00 68 00 65 00 20 00 47 00 6f 00 64 00 73 00”，其实就是“Funnel Of The Gods的ASCII码。有时候也会是“Funnel Of The。不知道为什么偏偏是这个上帝的漏斗，我们不妨假设效劳器是想告诉我们传输协议被接受了。流媒体按照MMS协议和MS Media Server交互下载实时交通录像

46、的包分析3通过mms:/220.194.63.17/cebeijing8，我们可以看到交通部门设置在北京西直门上的摄像头的实时录像，从而了解西直门的交通状况。但是，要是想下载这个流媒体到本地的话，我试验了asfr+、ASF Recorder以及StreamBox vcr，均无法下载。又找了一个mimms-0.0.9的linux版本，也就是以前的mmsclient，将其依赖于Linux的某些函数库换成Windows版本的对应包，编译之后，可以下载mms:/220.194.63.17/cebeijing8的数据，但是用WindowsMediaPlayer9播放的时候，却报告错误“无法播放，因为此文

47、件已损坏。只有SDP2.0(Streaming Download Project)可以正常下载并播放它。为了改造mimms，我分析了SDP和流媒体效劳器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services协议有帮助。下面是第4回合数据包。我们对每一个“包头和“包体的每一个字节都做了尽可能详细的分析。对了，编码格式是“Little Endian，也就是0f 00 00 00的实际值是0x0f。  第四对包：client to server 告知媒体文件名 第四回合之第1

48、个包：to server;Len=80：0030 01 00 00 00 ce fa 0b b0 40 00 .0040 00 00 4d 4d 53 20 08 00 00 00 03 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 06 00 00 00 05 00 03 00 01 00 .0060 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 63 00 .c.0070 65 00 62 00 65 00 69 00 6a 00 69 00 6e 00 67 00 e.b.e.i.j.i.n.g.0080 3

49、1 00 31 00 00 00 1.1.“包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l         “05 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes。05

50、 00是Command数值。03 00是Direction数值，这里的0x03指明客户端发往效劳器。4字节。在“05 00 03 00”之后，就是这个包的Body了。“包体解释：l         “01 00 00 00”，Command Level。4字节。l         “ff ff ff ff，MMS协议标志3。4字节。l         “00

51、 00 00 00 00 00 00 00”，8个0。l         “63 00 65 00 62 00 65 00 69 00 6a 00 69 00 6e 00 67 00 31 00 31 00”，是“cebeijing11”的ASCII码。我们在告诉效劳器要读取的文件路径以及文件名。不包括IP地址或者DNS信息，仅仅是文件路径和名字，比方“this/is/the/file/path/on/server/with/filename.ext。第四对包：server to client 告知流属性(播送标志

52、/比特率) 第四回合之第2个包：to client;Len=152：0030 01 00 00 00 ce fa 0b b0 88 00 .M.0040 00 00 4d 4d 53 20 11 00 00 00 05 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 0f 00 00 00 06 00 04 00 00 00 .0060 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 .0070 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 .00

53、80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .0090 00 00 20 03 00 00 00 00 00 00 00 00 00 00 8e 10 . .00a0 01 00 16 09 00 00 00 00 00 00 00 00 00 00 00 00 .00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .“包头解释：l     

54、;    “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l         “06 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes。06 00是Command数值。04 00是Direction数值，这里的0x04指明效劳器发往客户端。4字节。在“0

55、6 00 04 00”之后，就是这个包的Body了。“包体解释：l         “00 00 00 00”，错误号。l         “01 00 00 00”，后面跟随的都是本次结构数据了。l         “01 00 00 00”，结果标志，4字节。l        

56、; “00 00 00 00 00 00 00 00”；l         “00 00 00 02”，播送标志。l         “00 00 00 00 00 00 00 00”,双精度的文件时间点。8字节。l         “00 00 00 00”，代表total pre-recorded media length in seconds, liv

57、e = 0。因为我们这个是一个实况录像，所以是00 00 00 00。l         “00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00”，16字节。l         “20 03 00 00”，用在media的包字节长度。4字节。0x0320也就是800个字节。l         “00 00 00 00

58、”，代表total number of packets in media, live = 0xffffffff or 0x00。因为我们这个是一个实况录像，所以是00 00 00 00。l         “00 00 00 00”；l         “8e 10 01 00”，代表流比特率最高速度，0x0001108e就是Bitrate: 69774 bps。l      

59、   “16 09 00 00”，代表整个header的大小。0x0916代表2326字节。l         之后是40字节的“00”。前面第6个包中的“00 00 00 02”，播送标志，是什么意思呢？对于“00 00”，指的是索引定位类型，有这么几个值：n         0x00，没有索引可供定位。n         0x80，有

60、索引。对于“00 02”，播送类型，有这么几个值：n         0x01，指预录制的播送；n         0x02，指实况播送，Live的。n         0x42，包含了脚本命令的presentation。第6个包中的“01 00 00 00”，结果标志，是什么意思呢？l      

61、   0x01，媒体文件路径和名字被接受，没有身份验证。l         0x02，BASIC验证媒体通过。l         0x03，NTLM验证通过。我们本次下载不需要验证，所以是0x01。为了改造mimms，我分析了SDP和流媒体效劳器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services协议有帮助。&

62、#160; 第五对包：client to server 请求header 第五回合之第1个包：to server;Len=88：0030 01 00 00 00 ce fa 0b b0 48 00 .j.H.0040 00 00 4d 4d 53 20 09 00 00 00 04 00 00 00 00 00 .MMS .0050 00 00 00 00 00 00 07 00 00 00 15 00 03 00 01 00 .0060 00 00 00 00 00 00 00 00 00 00 00 80 00 00 ff ff .0070 ff ff 00 00 00 00 0

63、0 00 00 00 00 00 00 00 00 00 .0080 00 00 00 20 ac 40 02 00 00 00 00 00 00 00 . .“包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l         略l      &#

64、160;  “15 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes。15 00是Command数值，就是命令15。03 00是Direction数值，这里的0x03指明客户端发往效劳器。4字节。在“15 00 03 00”之后，就是这个包的Body了。“包体解释：l         “01 00 00 00”，Command Level。4字节。l         “00 00 00 00”

65、，标志。4字节。之后就是数据结构了。l         “00 00 00 00”，4个0。l         “00 80 00 00”，说明连带自己共8个字段。l         “ff ff ff ff，不知道。l         “00 00 00 00”，有可能是其他数

66、值。l         “00 00 00 00 00 00 00 00”。l         “00 00 00 00 00 20 ac 40”，可能是媒体的什么毫秒数。l         “02 00 00 00”，Header Packet ID type，用在mms pre-headers。第五对包：server to client 发送header

67、 第五回合之第2个包：to client;Len=56：0030 01 00 00 00 ce fa 0b b0 28 00 .O:.(.0040 00 00 4d 4d 53 20 05 00 00 00 06 00 00 00 73 00 .MMS .s.0050 70 00 3a 00 2f 00 03 00 00 00 11 00 04 00 00 00 p.:./.0060 00 00 02 00 00 00 00 00 00 00 46 00 75 00 .F.u. “包头解释：l         “01 00 00 00 ce fa 0b b0”是效劳器端向客户端发包的“BOOB FACE固定开头。以后你会看到每一个包都是如此开头的。8字节。l