MMS协议解析

这篇文章来自于网络,因为怕忘记才上传到这里如果侵犯了原作者的权利,还望通知,会及时删除!

MMS(Multimedia Messaging Service)的缩写,中文意为多媒体短信服务,它最大的特色就是支持多媒体功能。多媒体信息使具有功能全面的内容和信息得以传递,这些信息包括图像、音频信息、视频信息、数据以及文本等多媒体信息,可以支持语音、因特网浏览、电子邮件、会议电视等多种高速数据业务,在GPRS网络的支持下,以WAP无线应用协议为载体传送视频片段、图片、声音和文字。多媒体信息业务可实现即时的手机端到端、手机终端到互联网或互联网到手机终端的多媒体信息传送。

MMS
信息是以标准方式压缩的,因此,接收一方可以确认它不支持的内容格式,并以控制方式进行处置。这也是互联网上解决内容交互问题所用的方法。


MMS
标准推荐支持的媒体类型有:JPEGGIFTEXTAMR语音和其他一些非主流格式。为了获得更好的交互性,诺基亚和其他一些制造商已共同拟就了“MMS一致性文件,列出了MMS手机能支持的最小一组内容类型

 

// MMS – PC

MMS协议解析1(原创)

1.简介

  可以传输音、视频的通用服务器有两种,都有各自的优缺点。分别是:标准WEB服务器和流媒体服务器。标准WEB服务器使用HTTP协议。流媒体服务器使用两种协议提供媒体服务。这两种协议分别是HTTP1.01.1以及MMS(Multi Media Server)协议。流媒体服务器使用的HTTP协议是经过修改的版本,扩展了语法命令以支持实时传输。这是普通HTTP所不支持的。

  使用两种协议提供媒体服务和WEB服务器有着显著区别。一个区别是在WEB服务器上使用标准HTTP协议的数据不需要一个特殊的服务器和软件进行浏览甚至下载。另外一个区别是使用MMS(例如Microsoft Windows Media Services)的流媒体服务器通过流形式提供媒体给使用者。流媒体服务器可以处理大量数据。

1.MMS是什么

  MMS是微软的私有流媒体协议。它的最初目的是通过网络传输多媒体广播、视频、音轨、现场直播和一系列的实时或实况材料。使用这个协议的观众可以通过电脑观看电视图像或音轨。微软为有网络连接的家用电脑使用者开发了免费软件。MMS建立在UDPTCP传输/网络层上,是属于应用层的。

使用TCPMMSURLMMS://或者MMST://,如果是UDPMMS使用MMSU://。在低带宽的情况下推荐使用UDP连接。HTTP带有大量的头信息,UDP一般不能通过防火墙,在有防火墙的情况下使用HTTPTCP的无差错特性是非常诱人的,它的吞吐量比UDP小,但是在下载MMS的时候TCP是不二的选择。

2.哈!看起来开始有趣了!

  到目前为止还没有关于MMS协议的任何有效的细节。网络搜索和库阅读也是徒劳无功的。微软不打算就MMS的内容发表任何看法。这真是水到山前疑无路,从使用HTTP协议的流媒体服务器上下载流信息已经成为了可能,使用MMS协议的服务器还只能在线观看,事实上,也只是目前为止!

3.让我们从这里开始--包和流

  MMS协议是以包和数据块的形式从服务器向使用者发送数据到你的计算机上。服务器上的媒体文件是以ASFWMA形式存在。直播通过流媒体服务器组装成数据包。如果是TV/视频的话,一个包可能会由多个流组成,但是语音广播就只有一个流。可以认为多个流是被混合到了一个实际的包中。包中发送的流取决于媒体类型。下面会涉及到更多关于流的内容。

MMS协议包有两种:命令包和数据包。

4.首先,让我们来处理命令包

 MMS协议使用一段命令来完成多种人物,比如:连接到流服务器、请求文件、丢包重传请求及类似事宜。这是应用层协议,在这一层上媒体使用者和服务器进行通讯。这些都要传输到使用者。

5.MMS命令包头
下面分析MMS包头结构。以下是小端格式。左边=LSB,右边=MSB0f 00 00 00 就相当于0f

开始---->

4bytes = 01 00 00 [00]

client发出的格式是固定的。[00]域从服务器发出的时候是可以发生变化的。现在不能理解这个比特的含义--总是0,可能是版本号。

4bytes = CE FA 0B B0

命令ID值,或许是版本或者序列号。这总是固定的。如果你按照大端来读就是“Boob Face”.可能是巧合吧。

4bytes

命令数据包长度,计算到全部数据末尾。单位为比特,从协议类型域之后开始计算。

 

4bytes = 4D 4D 53 20

协议类型,固定值为MMS<空格>ASCII

 

4 bytes

直到包尾的长度,8比特为单位。包含自身数据域。例如,8bytes,value = 1

 

4 bytes

序列号。命令是由客户端发向服务器的,序列号的计数从0开始。命令的响应拥有同样的序列号。也就是说序列号就是ECHO。客户端总是发起命令。

 

8 bytes

双精度时间戳,用于网络时序。

 

4 bytes

到包尾的长度,单位为8比特。包括自身。例如,8 bytes ,value = 1

 

Comm 2bytes | Dir 2bytes

标志命令方向流的值。命令值含义参考MMS命令列表。对于方向域,0x03 = 向服务器,0x02 = 向客户端。

----> 长度为40比特的命令头到此为止。

命令包长度跟在其后,先是‘prefix 1’然后是‘prefix 2’,接下来直到命令包结束都是‘command specific data’。命令指定数据可以是字符串文本‘Unicode 16bit’,或者是raw 8位数据。在prefix 数据解说之后可以看到命令特定数据段含义。

命令包通常都包括上述内容,最小字节是40。命令包头是作为命令发送的最小包。注意:包长域包括到包末尾所有的padding

01 Server

Prefix 1 f0 f0 f0 f0 - 标志(见标志段)

Prefix 2 0b 00 04 00

Then 1c 00 03 00

结构题定义如下。

功能:发送初始链接信息,包含播放器的版本号、客户端GUID(随机产生)和要连接的服务器地址。这个命令是在协议初始化之初发送的。它发送本地信息给服务器。Unicode数据字符串由以下信息组成:

“NSPlayer/7.0.0.1956; {128比特16进制文本客户端GUID }; Host: The.Host.Net” + 0x00 + 全零隐藏数据域(可选项)

注意:

客户端GUID是随机生成的,具体内容见'locally generated GUIDs'.

'Host' 域为可选字段。只在Media Player 7.0及后续版本中使用。播放器名称必须以 “NSPlayer”开始,如果服务器收到其他名称,将会自动发送名为'Upgrade Your Player'缺省的电影。这是一个15秒的教你如何升级的电影。在NSPlayer之后可以接任意的东西。例如像

/7.0.0.1956的版本号。MediaPlayer7.0及后续版本才支持'MMS Proxy Server'选项。'Host'域指明实际流媒体服务器的域名或者IP地址,这同是否使用代理并不相关。代理服务器使用这个主机地址连接到流媒体服务器。这就是在7.0以前版本里面没有'host'域的原因。

 

01 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 f0 f0 f0 f0 - 标志(详见标志段)

结构体定义如下:

服务器返回诸如服务器软件版本等信息。

0b 00 04 00 ??

1c 00 03 00 ??

00 00 00 00 00 00 f0 3f 双精值为1内容不详

01 00 00 00 ??

01 00 00 00 ??

00 80 00 00 ??

00 00 a0 00 ??时有为80 96 98 00 = 10000000

Ww ww ww ww 服务器版本字符串长度

Xx xx xx xx 工具版本字符串长度

Yy yy yy yy 播放器下载链接长度

Zz zz zz zz 加密方式字符串长度

Unicode字符串长度在结构体中给出。当域不需要时length=0。长度的统计是以两个byte为单位。有趣的是服务器版本低于3.0时,不接受0x32命令。媒体播放器也不会发送这个命令给服务器。准确的说,这个特征在那个版本里还没有实现。

 

 

02 Server

Prefix 1 f1 f0 f0 f0 - 标志(见标志段)

Prefix 2 ff ff ff ff

Then 00 00 00 00

Then 00 00 a0 00 - 未知

Then 02 00 00 00 – 映射包头ID类型(Header PacketIDType

发送传输协议、客户端地址和客户端套接字端口号到服务器。Unicode字符串格式如下:

“ //123.456.789.012/TCP/1234” + null + 可选Unicode数据,如“0”

可选数据:当传输协议使用UDP时可以显示10Bytes的未知数据。

Where: 123.456.789.012 是客户端IP地址,

TCP (UDP)标志欲是用的传输协议。

1234 是客户端TCPUDP套接口端口号。

02 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 f1 f0 f0 f0 - 标志

Then nn nn nn nn - 4 bytes 数据长度

长度计数单位是4字节,也包括了Length域,所以4Bytes就是1

Then Unicode字符串数据

这是协议选择命令0x02的响应数据。文本“Funnel Of The”'Funnel of the gods'是常见的数据。这说明协议的选择已经生效。

03 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 00 00 00 00

由服务器返回,指明协议选择的错误。同时也表示从服务器发向客户端的关闭套接字连接的请求。在这个命令之后连接中断。

05 Server

Prefix 1 01 00 00 00 -命令级别

Prefix 2 ff ff ff ff

Then 8 zeros (未知)或许是双精值

Then Unicode数据,下文解析。

这条命令请求位于服务器上的文件路径和文件名。这不包含IPDNS信息,只有媒体的路径和文件名。Unicode数据字符串格式如下:

“this/is/the/file/path/on/server/with/filename.ext” + null + 未知可选数据如“2C3”

注意: 文件名后,例如 …/filename.asf 可以跟随数字签名管理数据。传到服务器的字符串形如:…/filename.asf?parameter1, parameter2

就像其他人和.ASP.JSP Active输入的字符串参数一样,parameter1可以为0parameter2可以是32bytes16进制字符串数据。如果媒体文件需要DRM数据,而你并未提供有效的授权字符串,那么访问将被拒绝。在这种情况下,服务器会向客户端发送命令03报告断开连接。并附带'licence required'错误码.

05 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 04 00 00 00 - 响应Media PacketIDType

Then 下述结构体

现在发送媒体数据,包括媒体的播放时间。

01 00 00 00

未知但是可以改为01

00 00 00 00

可能是偏移时间,例如00 00 00 40 2

00 00 00 00

??

00 00 00 00

??

00 00 00 00

??

Xx xx xx xx

单精浮点值,显示文件时间减去缓冲区时间,仅在seek模式有效,其他情况下总为1

06 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 01 00 00 00

Then 结构体如下

功能:答复文件名和路径请求。包括文件数据的包数,包长度和文件播放时间。06命令的数据类似于ASF文件的头信息。一旦媒体在服务器上定位,媒体流的细节和包便被返回。下面是prefix后的结构体信息:

01 00 00 00 结果标志

00 00 00 00

00 00 00 00

00 00 xx yy 广播标志

Tt tt tt tt tt tt tt tt 双精度文件时间点

Ll ll ll ll 回放文件的长度(秒为单位),实时则为0

00 00 00 00

00 00 00 00

00 00 00 00

00 00 00 00

Pp pp pp pp 媒体包长度,单位byte

Nn nn nn nn 媒体总包数,实时为0x000xffffffff

00 00 00 00

Ss ss ss ss 最高流比率值

Hh hh hh hh 头大小,单位bytes

Zeros 数据结构末尾的40bytes零数据

 

07 Server

Prefix 1 01 00 00 00 - 命令级别

Prefix 2 ff ff 01 00 - 76 04 00 00 #

Then 结构题描述如下

功能:从包xx 开始文件播放。这条命令也用以恢复下载或请求丢包。在Seek模式下用来发送播放点。

8 bytes 双精格式,Seek秒数。

4 bytes FF

4 bytes 包序列号

ff ff ff ff 从开始播放

注意:v9版本中不可用,任何值都是从头开始播放

3 bytes 最大的流时间限制

1 byte 允许流限制标志

4 bytes Media PacketIDtype

4 bytes 可选数据# ff ff ff 7f

4 bytes 可选数据# 00 00 00 00

4 bytes 可选数据# ff ff ff 7f

4 bytes 可选数据# 00 00 00 00

 

09 Server

Prefix 1 01 00 00 00 - 命令级别

Prefix 2 ff ff 01 00

停止播放,媒体播放器发送这条命令,流停止,保持套接字连接。

0A Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 04 00 00 00 - 响应PacketIDType

Data 00 00 00 00 00 00 00 00 - 双精值

此命令在快进/后退中使用。

0D Server

Prefix 1 01 00 00 00 - 命令级别

Prefix 2 01 00 00 00

协议中止。常用在关闭套接字连接时。

11 Client

Prefix 1 00 00 00 00 - 错误码

Prefix 2 02 00 00 00 - 显示头的PacketIDType

Then 00 00 00 00 - ??

Then 00 00 00 00 1c 00 03 00 用法未知。

在播放器请求时发送头或UDP包。

来自:http://www2.minitos.com/article/sort06/info-11149.html

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: MMS(Multimedia Messaging Service)是一种用于发送多媒体信息的协议。具体来说,MMS可以用来发送图片、视频、音频和文本等类型的多媒体消息。 解析MMS协议的脚本通常是用于处理接收到的MMS消息,并将其中的多媒体内容提取出来。 以下是用Python编写的一个简单的MMS解析脚本的例子: ``` import email def parse_mms(mms_data): # 使用email库解析MMS数据 mms = email.message_from_bytes(mms_data) # 遍历MMS中的所有部分 for part in mms.walk(): # 如果部分是多媒体文件,则提取内容 if part.get_content_maintype() == 'multipart': continue if part.get('Content-Disposition') is None: continue # 获取文件名和内容 file_name = part.get_filename() file_content = part.get_payload(decode=True) # 将文件内容保存到文件中 with open(file_name, 'wb') as f: f.write(file_content) ``` 在这段代码中,我们使用了Python的`email`库来解析MMS数据,然后使用`walk`方法遍历MMS中的所有部分。对于每个部分,如果它是多媒体文件,我们就获取文件名和内容,并将内容保存到文件中。 希望这个例子能帮到你。 ### 回答2: MMS(多媒体短信)是一种用于发送与接收多媒体内容(如图像、音频和视频)的消息协议。编写一个MMS协议解析脚本,可以按照以下步骤来实现: 1. 导入必要的库:首先导入Python中适用于网络编程和二进制文件处理的库,如socket和struct。 2. 建立与MMS服务器的连接:使用socket库建立与MMS服务器的TCP连接。 3. 发送请求并接收响应:发送获取MMS消息的请求,并接收来自服务器的响应消息。按照MMS协议规范,请求消息应包含必要的标识符和参数。 4. 解析响应消息:使用结构化的数据分析方法,如struct库来解析收到的响应消息。 5. 提取MMS消息内容:从响应消息中提取MMS消息的各个组成部分,如主题、发送者、接收者和多媒体内容(如图片、音频和视频)。 6. 展示或保存MMS内容:根据需要,可以选择展示MMS内容在屏幕上或将其保存到本地磁盘。 7. 关闭连接:完成消息解析后,关闭与MMS服务器的连接。 以上步骤提供了一个基本的框架,您可以根据具体的需求和MMS协议规范,进一步完善脚本的功能和扩展性。 ### 回答3: MMS(Multimedia Messaging Service)是一种用于发送和接收多媒体消息的协议。要编写一个MMS协议解析脚本,可以按照以下步骤进行: 1. 打开MMS消息文件:首先,脚本需要能够打开MMS消息文件,通常是以二进制格式存储的。 2. 解析消息头:接下来,脚本需要解析MMS消息头部。消息头部包含有关消息的元数据,如发送者、接收者、主题以及时间戳等信息。 3. 解析消息体:消息体是MMS消息的实际内容,可以是文本、图片、音频或视频等多媒体文件。脚本需要能够解析并提取出消息体中的各个部分。 4. 解析附件:如果消息体包含附件文件,脚本需要能够解析并提取出这些附件文件。 5. 重建消息:解析完消息头、消息体和附件后,脚本可以将这些部分重新组合成完整的MMS消息。 6. 输出解析结果:最后,脚本可以将解析得到的消息元数据以及提取的附件文件进行输出,以方便用户查看或进一步处理。 编写这样一个MMS协议解析脚本需要具备对MMS协议格式的理解,以及对二进制数据的解析和处理能力。可以使用Python等编程语言来实现这个脚本,并结合相关的解析库或工具来简化开发过程。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值