[流媒体]实例解析MMS流媒体协议，下载LiveMediaVideo[1]
[流媒体]实例解析MMS流媒体协议，下载LiveMediaVideo[1] [流媒体]按照MMS协议和MS Media Server交互
下载实时交通录像的包分析
编写者
日期
关键词
郑昀@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”协议有帮助。
对了，编码格式是“Little Endian”，也就是0f 00 00 00的实际值是0x0f。
对了，编码格式是“Little Endian”，也就是0f 00 00 00的实际值是0x0f。
下面是每一个数据包。我们对每一个“包头”和“包体”的每一个字节都做了尽可能详细的分析。
第一个包：client to server
第一个包：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 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 “ce fa 0b b0”，这也是固定不变的。通常被人称为“BOOB FACE”。他可能是一个版本号或者序列号。以后你会看到客户端和服务器端发出的每一个包都是如此开头的。4字节。
l “58 00 00 00”，表明在“协议类型(也就是接下来的4d 4d 53 20)”后面的所有数据的长度。4字节。
l “4d 4d 53 20”，表明协议类型，就是“MMS<space>”的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 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 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。01 00是Command数值。03 00是Direction数值，0x03代表客户端发往服务器，0x04代表服务器发往客户端。4字节。
按照我的理解，上面的可以算作包头，每个客户端发出的数据包差不多都有类似的头。
在“Comm 2 bytes | Dir 2 bytes”之后，就是这个包的Body了。
“包体”解释：
l “f0 f0 f0 f0”，MMS协议标志1。
l “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>”的ASCII码。这是向服务器说明客户端的播放器的版本名。值得注意的是，这个版本名字必须以“NSPlayer”开头，否则MMS服务器将不管你的请求是什么，强制返回给客户端一个15秒的电影文件“Upgrade Your Player”，用来展示如何升级你的播放器。“NSPlayer”后面跟随的版本号无所谓是什么，比如mimms的是“9.0.0.2800”。
l “00 00 00 00 00 00 00 00 00 00”，补零的部分。
郑昀编写，随时更新。
