[流媒体]实例解析MMS流媒体协议，下载LiveMediaVideo[2]

[流媒体]实例解析MMS流媒体协议，下载LiveMediaVideo[2] [流媒体]按照MMS协议和MS Media Server交互

下载实时交通录像的包分析[2]

编写者

日期

关键词

郑昀@ultrapower

2005-10-17

mms streaming protocol

ethereal 协议分析流媒体

通过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播放的时候，却报告错误“无法播放，因为此文件已损坏”。

只有SDP2.0(Streaming Download Project)可以正常下载并播放它。

为了改造mimms，我分析了SDP和流媒体服务器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services”协议有帮助。

下面是第2个数据包。我们对每一个“包头”和“包体”的每一个字节都做了尽可能详细的分析。

实际上，上文第一个包体应该是类似于这样的格式：

NSPlayer/版本号;<space>{128位的客户端GUID};<space>Host:<space>服务器的IP地址

举一个实际的例子：

NSPlayer/9.0.0.2800; {f5cec3a0-3e2c-11da-b2a2-00055d1a21bd}; Host: 220.194.63.17

但是，抓SDP2.0得到的包有点不一样。

第2个包：server to client

第一个包：to client;Len=144：

0030 01 00 00 00 ce fa 0b b0 80 00 ..p.............

0040 00 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 39 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”固定开头。以后你会看到每一个包都是如此开头的。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 until 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。

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字节。

在“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 “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 “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。

这个包中，在服务器版本号之后，加密类型之前，也可能有以下两种数据：

工具版本号，如5.1.0.0；

更新播放器的链接，如http://www.theupdatesite.com/updateplayer.html，微软有时候通过这个URL让你的客户端Windows Media Player更新最新的版本。

这两个数据不一定会有，但是服务器版本号必须要有。

郑昀编写，随时更新。