<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>
编写者 |
日期 |
关键词 |
郑昀@ultrapower |
2005-10-17 |
mms streaming protocol
ethereal 协议分析 流媒体
|
为了改造mimms，我分析了SDP和流媒体服务器的来往包，看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解 “Microsoft Windows Media Services”协议有帮助。
下面是每一个数据包。我们对每一个“包头”和“包体”的每一个字节都做了尽可能详细的分析。
对了，编码格式是“Little Endian”，也就是0f 00 00 00的实际值是0x0f。
第三对包：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 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 FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l “60 00 00 00”，表明在“协议类型(也就是接下来的4d 4d 53 20)”后面的所有数据的长度。4字节。
l “4d 4d 53 20”，表明协议类型，就是“MMS<space></space>”的ASCII码。4字节。
l “0c 00 00 00”，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 network 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指明客户端发往服务器。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 “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 2e 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.85\TCP\2516”的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 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 94 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是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字节。数据的长度，有可能是假的。
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”。不知道为什么偏偏是这个上帝的漏斗，我们不妨假设服务器是想告诉我们传输协议被接受了。
第四对包：client to server 告知媒体文件名
第四回合之第1个包：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 31 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 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 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 告知流属性(广播标志/比特率)
第四回合之第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 ................
0080 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 “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字节。
在“06 00 04 00”之后，就是这个包的Body了。
“包体”解释：
l “00 00 00 00”，错误号。
l “01 00 00 00”，后面跟随的都是本次结构数据了。
l “01 00 00 00”，结果标志，4字节。
l “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, live = 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”，代表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 “16 09 00 00”，代表整个header的大小。0x0916代表2326字节。
l 之后是40字节的“00”。
前面第6个包中的“00 00 00 02”，广播标志，是什么意思呢？
对于“00 00”，指的是索引定位类型，有这么几个值：
n 0x00，没有索引可供定位。
n 0x80，有索引。
对于“00 02”，广播类型，有这么几个值：
n 0x01，指预录制的广播；
n 0x02，指实况广播，Live的。
n 0x42，包含了脚本命令的presentation。
第6个包中的“01 00 00 00”，结果标志，是什么意思呢？
l 0x01，媒体文件路径和名字被接受，没有身份验证。
l 0x02，BASIC验证媒体通过。
l 0x03，NTLM验证通过。
我们本次下载不需要验证，所以是0x01。
郑昀编写，随时更新。
第五对包：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 00 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 “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”，标志。4字节。之后就是数据结构了。
l “00 00 00 00”，4个0。
l “00 80 00 00”，说明连带自己共8个字段。
l “ff ff ff ff”，不知道。
l “00 00 00 00”，有可能是其他数值。
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
font-family:
分享到：
Global site tag (gtag.js) - Google Analytics
|
相关推荐
《live555流媒体服务器：深入解析与应用》 在信息技术飞速发展的今天，流媒体技术已经成为互联网内容传播的重要手段。其中，live555流媒体服务器作为一个开源且广泛使用的解决方案，备受业界关注。本文将深入探讨...
内容由流媒体协议等基本知识，视频媒体基本知识，流媒体服务器搭建实战，流媒体工具使用实战等内容组成。由本人“天地会珠海分舵”(http://blog.csdn.net/zhubaitian)耗时一个月整理而成，现分享给大家。 章节内容...
“实例分析mms.doc”可能是一个文档，详尽解释了MMS协议的工作原理、消息结构以及如何解析MMS文件。通常，这样的文档会涵盖以下知识点： 1. **MMS协议基础**：介绍MMS协议的基本概念，包括协议的层次结构、组成部分...
开关电源设计入门与实例解析是一本面向初学者和行业工程师的实用工具书，旨在通过基础知识的讲解和具体实例的分析，帮助读者掌握开关电源设计的核心技术。 首先，我们需要理解开关电源的基本工作原理。开关电源的...
2. **URLs**：流媒体的地址，可以是HTTP、RTSP、M3U8等不同协议的链接。 3. **编码信息**：描述了媒体文件的编码格式，有助于VLC选择正确的解码器。 4. **播放参数**：如循环播放、延迟播放、缓冲区大小等，这些参数...
《C语言高级实例解析》本书特点： ·以实例为主。本书采用实例讲解的方式，先介绍必要背景知识，之后是加注释的源码，再给出分析和改进方向。 ·涉及的知识面广。从内存分配，到串行、并行口编程，再到...
RTSP信令包括播放、暂停、停止等控制命令，这些命令用于管理和控制媒体流的传输。同时，测试工具会接收并解析RTP（Real-time Transport Protocol）包，RTP是用于传输实时数据的协议，通常与RTSP一起使用。尽管工具会...
海康流媒体SDK开发实例，支持VS2010，这个版本使用了负载均衡ACE模块开发.
在IT领域，协议解析是通信系统中的重要环节，它涉及到数据传输的理解与处理。本示例将关注如何使用C++语言解析"highway map data"协议。C++是一种通用、面向对象的编程语言，因其高效性和灵活性，在系统编程、游戏...
C++实现RTSP/RTP流媒体服务器，同时支持Linux和Windows编译环境。使用VLC客户端测试通过。实现RTSP的OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN，实现SDP生成，实现RTP打包，实现TS文件解析。有相应的源码...
Canoe实例解析概述 Canoe实例解析是CanOe入门的非常重要的一步，对于学习CanOe的开发者来说尤其重要。在本文中，我们将通过一个完整的Canoe实例解析，带领读者了解Canoe的基本概念和开发方法。 首先，我们需要...
这个源码实例提供了从不同流媒体服务器接收数据并进行解码、播放的技术实现，对于理解多媒体播放原理和C#编程在媒体处理中的应用具有重要意义。 在C#中，流媒体播放器的开发主要依赖于.NET Framework提供的类库，...
3. 协议解析：MMS协议头包含了消息类型、长度、序列号等信息，解析这部分需要对MMS协议有深入理解。通常会用到循环、条件判断等控制结构来逐个解析字段。 4. 编码和解码：MMS支持多种编码格式，如JPEG、GIF、MP3等...
CAN总线简介，CAN物理层数据交换原理，CAN报文格式分析，J1939协议介绍，PDU格式，报文实例分析，PGN报文实例分析，J1939的传输协议-连接管理和多包传输，Intel与Motorola格式的区别
《欧姆龙PLC的FINS通讯手册与使用实例解析》是针对欧姆龙自动化设备中FINS（Fieldbus Network System）通信协议的一份详细指南。这份资源集合了FINS通讯手册、FINS命令协议以及丰富的使用实例，旨在帮助用户理解和...
它提供了开始、暂停、停止、快进、快退等功能，使得用户能灵活地操控实时媒体流。`rtsp协议取流.txt`可能是介绍RTSP取流步骤或命令的文档，可能包含如何使用VLC或其他工具连接到RTSP服务器的示例代码。 3. **实例...
VLC支持RTSP、HTTP、MMS等流媒体协议，你可以直接传入流媒体URL给VLCPlayer进行播放。注意，不同类型的流媒体可能需要不同的配置，例如设置正确的播放器选项。 8. **性能优化** 考虑到内存和CPU的使用，可以配置...
HLS（HTTP Live Streaming）是一种基于HTTP的流媒体网络传输协议，由Apple公司开发，主要用于实时视频流的分发。在本实例中，我们关注的是HLS的拉流和推流技术，以及C#语言实现的相关源码。下面将详细介绍HLS拉流、...