CN107026887A - 一种多媒体系统中快速信息交互机制及网络传输方法 - Google Patents

Abstract

本发明提供一种多媒体系统中快速信息交互机制及网络传输方法，所述多媒体系统中快速信息交互机制，针对协议传输格式强制的最简数据包，对协议格式头数据大小进行简化，使协议格式适应快速信息交互；所述对协议格式头数据大小进行简化，是指：选取原协议传输格式中保留字段为标志位，提供简化掉Packet_id、Timestamp、Packet_squence_number三个字段的是否使用的选择，使协议格式头数据字节数变小。并进一步针对性地设计快速消息交互格式和双向资源快速请求响应消息格式，能用于所有媒体传输系统。本发明能够解决现有媒体传输系统中缺乏高效双向快速信息交互机制的缺陷。

Description

一种多媒体系统中快速信息交互机制及网络传输方法

技术领域

本发明涉及一种多媒体系统中快速信息交互机制，更确切地说，涉及一种多媒体系统中快速信息交互机制及网络传输方法。

背景技术

随着云计算、物联网、智能可穿戴设备等新一代应用消费模式的兴起，基于传统的音视频媒体的单向数据传输已经不能满足各种应用的需求了。新一代多媒体传输系统中传输新型的数据传输格式应该包括各种可能的数据类型，同时通信双方需支持双向通信来实现不同的业务逻辑与业务流程。

实时信息交互越来越成为未来多媒体系统中数据交换的重要趋势，其中用户需要将交互数据实时上传服务器，以便服务器能够知道用户当前操作与工作状态，另一方面服务器对获知信息进行分析和计算，做出快速响应，将处理结果实时传递给用户。其特点是信息单次数据量小，但交互频率很高，对上传、下推实时性要求非常高，所以消息格式应简单，开销越小越好。因此对于这种快速信息交互的格式设计与网络传输方法设计就显得尤为重要。

非实时信息交互主要为资源请求响应交互信息，其目的是满足用户根据自身需要主动请求服务器端的资源数据的需求，其特点为会话式交互，非实时频繁交互，但需要客户端到服务器端的通信链路支持及服务器的有效响应。流程为用户接收到节目流之后得到其提供的可用资源信息，包括描述文件与媒体数据，然后向服务器端请求相应数据，服务器接收到请求后核实请求合法性，若合法则发送确认信息并传输数据，否则发送失败信息。高效的多媒体传输系统应满足更轻量级的请求与响应交互方式，同时面向多媒体的交互格式也应该被支持。

经检索，中国发明专利CN200310123710.5，该系统中涉及一种便于附带有多媒体对象的节目内容和节目指南数据进行通信的节目特有信息数据结构，多媒体对象包括音频、视频、动画、静止图像、因特网、电子邮件、文本和其它类型的数据。该数据结构支持例如被动观看的单向通信应用和例如交互类型功能的双向通信应用。解码器处理分组化节目数据和包含辅助描述信息的节目特有信息，辅助描述信息包括多媒体对象类型、位置和其它描述性指示符。这些指示符用于获取和解码从不同信源获得的多媒体对象，以便在表示视频节目内容或节目指南的复合视频图像中显现。利用附加的辅助位置和获取描述信息，能够获取补充的节目特有信息单元和节目内容数据。该专利仍旧无法很好解决现有媒体传输系统中缺乏高效双向快速信息交互的问题。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种多媒体系统中快速信息交互机制及网络传输方法，旨在解决现有媒体传输系统中缺乏高效双向快速信息交互机制的缺陷。

根据本发明的一个目的，提供一种多媒体系统中快速信息交互机制，包括：

针对协议传输格式强制的最简数据包，对协议格式头数据大小进行简化，使协议格式适应快速信息交互；

所述对协议格式头数据大小进行简化，是指：选取原协议传输格式中保留字段为标志位，提供简化掉Packet_id、Timestamp、Packet_squence_number三个字段的是否使用的选择，使协议格式头数据字节数变小，从而使得协议格式适应快速信息交互。

进一步的，所述对协议格式头数据的大小进行简化，具体为：选取原协议传输格式中保留字段分别修改为T、P和F标识字段，其中：

T:timestamp_flag，若置1使用timestamp字段；若置0不使用；当交互信息具有非常强的即时性，即一旦客户端或者服务器端收到此信息便做出响应，将此字段置0，前提是提供可靠的底层通信协议；

P：packet_id_flag，若置1使用packet_id字段；若置0不使用；当负载信息量较小，能够放入一个数据包进行传输，或者将数据分包交给底层协议实现时，将此字段置0，前提是提供可靠的底层通信协议；

F：fragmentation_flag，若置1使用packet_sequence_number字段；若置0不使用；此字段与“P”字段联合使用，当“P”字段置0条件满足时，将此字段置为0。

本发明上述的对协议格式头数据大小进行简化，大大减少了字节数，从而提高了网络传输的快捷性，能适应快速网络信息交互。进一步的，在该快速网络信息交互的前提下，可以针对各种媒体业务具体需求，设计快速消息交互格式和双向资源快速请求响应消息格式，快捷高效的传输协议结合灵活可定制的消息体格式，使本发明能应用到所有媒体传输系统。

所述快速信息交互，其中：快速交互的消息实体在信令模式中传输。

进一步的，所述快速信息交互，其中：快速交互信息主体包含如下字段：

包含实时交互消息的消息标识字段；

包含消息的版本号字段；

包含消息长度标识字段；

包含扩展字段；

包含标示当前消息负载(payload)的数据段。

更进一步的，不同类型的消息负载具有不同的格式，其中：

实时交互消息负载(payload)，包含如下字段：

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分；

包含标示了此消息信令中包含的交互数据个数的字段；

包含标示当前交互信息的类型；

包含标示当前交互数据长度的字段；

包含标示当前交互信息的字节数据段；

包含用于用户自定义或未来扩展的数据格式数据段；

资源请求响应消息负载(payload)，包含如下字段：

包含资源请求方法标识字段，用来表示当前用户请求资源的方法；

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分。

对于上述的实时交互消息负载(payload)，本发明预先定义好其通用格式，预置具体消息格式的定义。资源请求响应消息为会话式交互，用户请求与系统响应格式有机统一，支持本机制的服务器客户端双方，即使没有http协议的接口，也能实现面向多媒体的资源请求响应类的轻量级交互应用。这为媒体网络传输，带来了极大的便利。

根据本发明的另一目的，提供一种基于上述机制的多媒体系统中交互信息数据的网络传输方法，包括：

步骤a，网络终端设备按消息体已预先定义的快速交互消息负载数据段(payload)的格式或自定义的payload格式封装消息体“payload”字段。

步骤b，网络终端设备按快速交互消息主体格式封装消息整体。

步骤c，网络终端设备按MMT(ISO/IEC 23008-1)原协议“payload”格式定义把消息封装进协议“payload”。

步骤d，网络终端设备按协议格式定义生成一个或多个packet网络传送数据包。

步骤e，网络服务器接收一个或多个客户端提交的packet数据包后，按数据包协议头，解析出完整的协议级“payload”数据段。

步骤f，网络服务器按协议“payload”格式定义解出完整的消息体数据段。

步骤g，网络服务器按消息头定义解出消息体的“payload”数据段。

步骤h，网络服务器按消息定义或自定义的格式，解读消息“payload”数据段，并进行相应处理和回应。

服务器端到网络终端设备的通信，也遵照上述步骤。此数据格式和应用方法，满足网络双向通信的要求。

与现有技术相比，本发明具有如下的有益效果：

采用本发明的技术方案，快速信息交互机制可以针对各种不同的交互式数据的特点，设计统一的交互式数据的传输格式，通过统一的交互式数据的传输步骤，通信双方可以大大节省为适应不同类型数据所带来的开销；进一步的，消息体内“payload”数据段也允许自定义，结合消息头内的保留字段，十分便利地就可以实现系统的扩展。本发明可以有效提高媒体网络的传输效率。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1是本发明一实施例中消息传递解析的流程框架；

图2是MMTP原有协议传输格式强制的最简数据包格式示意图；

图3是本发明一实施例中实时交互消息应用示意图；

图4是本发明一实施例中简化后最小数据头格式示意图；

图5是本发明一实施例中资源请求响应消息应用示意图；

图6是MMT现有的payload的头数据格式示意图；

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进。这些都属于本发明的保护范围。

本发明提供了一种多媒体传输系统中快速信息交互机制，针对协议传输格式强制的最简数据包，对协议格式头数据大小进行简化，使协议格式适应快速信息交互，进一步针对性地设计了快速消息交互格式和双向资源快速请求响应消息格式，能应用到所有媒体传输系统；同时提供了相应的网络传输方法，来应用这一快速信息交互中的数据格式，旨在解决现有媒体传输系统中，缺乏高效双向快速信息交互机制的缺陷。

以下提供部分实施例，对本发明实施细节进行举例说明。

(1)协议改进

本发明中的交互信息的协议格式，改进了MMTP协议，使之更适应高效快速的网络信息交互，也使应用的范围扩大到所有媒体传输系统，而不仅仅只局限于MMTP协议。

除去可选字段以外，MMTP原有协议传输格式强制的最简数据包包括以下字段:

包含用于标识协议版本的字段-“V”；

包含用于标识是否存在“packet_counter”数据段的标志字段-“C”；

包含用于标识是否存在“FEC”(前向数据纠错)数据段的标志字段-“FEC”；

包含用于标识是否存在扩展头数据段的标志字段-“X”；

包含用于标识此负载信息内容是否具备随机接入点(Random Access Point)特性的标志字段-“R”；

包含保留字段-“r”和“RES”；

包含用于标识负载信息类型的标志字段-“Type”；

包含Packet_id标识字段；

包含Timestamp时间戳字段；

包含Packet_sequence_number序列号标识字段。

其字节格式可以表示，如图2所示。

本发明针对交互信息高效快速的要求，使用原格式中保留字段(即r与RES字段)作为标志位，提供简化掉Packet_id、Timestamp、Packet_squence_number三个字段的选择，从而有效简化了协议格式头数据的大小。

原有的保留字段位置r(1bit)修改为T标识字段：

T:timestamp_flag，若置1使用timestamp字段；若置0不使用。当交互信息具有非常强的即时性，即一旦客户端或者服务器端收到此信息便做出响应，可以将此字段置0，前提是提供可靠的底层通信协议。

原有的保留字段位置RES(2bits)修改为P和F标识字段(各1bit)：

P：packet_id_flag，若置1使用packet_id字段；若置0不使用。当负载信息量较小，可以放入一个数据包进行传输，或者将数据分包交给底层协议实现时，可以将此字段置0，前提是提供可靠的底层通信协议。

F：fragmentation_flag，若置1使用packet_sequence_number字段；若置0不使用。此字段一般与“P”字段联合使用，当“P”字段置0条件满足时，此字段也可置为0。

结合原有MMT各强制字段，简化后最小数据头格式如图4所示。

显然简化后的最简协议格式，大大减少了字节数，从而提高了网络传输的快捷性。

为了更好地保持兼容性，快速交互的消息实体可以在MMTP的信令模式中传输，此处给出MMT现有的payload的头数据格式如下(如图6所示)：

MMTP信令模式的数据头部分包括以下字段：

包含用于标识碎片聚合的字段-“f_i”；

包含用于标识数据段是否只包含1个信令的字段-“A”；

包含用于标识剩余待接收组合的碎片个数的字段-“frag_counter”；

包含保留字段-“res”；

包含用于标识信息长度字段长度的字段-“H”；

包含用于表示信息长度的字段-“MSG_length”。

但需要再次强调的是，本发明不仅仅局限于MMT协议的应用场景，由于消息体负载数据段(payload)格式的灵活可定制性，所以理论上本发明的消息机制，可以适用于任何媒体系统的信息交互传输。

(1)快速交互信息主体格式

快速交互信息主体包含如下字段：

包含实时交互消息的消息标识字段；

包含消息的版本号字段；

包含消息长度标识字段；

包含扩展字段；

包含标示当前消息负载(payload)的数据段；

作为一具体实施方式，可以采用以下格式：

更具体的，所述不同类型的消息负载有不同的具体格式，也由此可以看出，本发明可以灵活高效地兼容各种消息需求。在一实施方式中，可以采用以下消息负载具体格式：

1)实时交互消息负载(payload)定义

实时交互消息(Real-time Interaction Message,RIC_message)用来传送实时交互数据。该消息主要特点是消息数据量小，频率高，能够满足对上传实时性要求比较高的一些场景的需求。我们预先定义好其通用格式，预置具体消息格式的定义，也应被视为本发明的一部分：

实时交互消息负载包含如下字段：

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分；

包含标示了此消息信令中包含的交互数据个数的字段；

包含标示当前交互信息的类型；

包含标示当前交互数据长度的字段；

包含标示当前交互信息的字节数据段；

包含用于用户自定义或未来扩展的数据格式数据段；

整个数据格式的结构可参见以下实时交互消息格式表表示：

实时交互消息格式表

2)资源请求响应消息负载(payload)定义

资源请求响应消息(Resource Request/Response Message,3R_message)主要特点为会话式交互，用户请求与系统响应格式有机统一。本消息吸收了http协议机制的设计思想及其优点，并针对媒体网络中最广泛的应用，客户端从服务器端获取资源进行的网络交互进行了全新设计。从而使支持本机制的服务器客户端双方，即使没有http协议的接口，也能实现面向多媒体的资源请求响应类的轻量级交互应用。这为媒体网络传输，带来了极大的便利。

如图5所示，资源请求响应消息应用示意图，其中资源请求响应消息包含如下字段：

包含资源请求方法标识字段，用来表示当前用户请求资源的方法，类型值与描述见下表；

Value	描述
		00b	“REQUEST_GET”
01b	“REQUEST_POST”
		10b	“RESPONSE_GET”
11b	“RESPONSE_POST”

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分；

●更具体的，对于标志当前用户请求资源的方法类型字段赋值为对应“REQUEST_GET”形式下：

包含用户使用GET方式请求资源的URL信息长度字段；

包含用户使用GET方式请求资源的URL具体内容字段；

●更具体的，对于标志当前用户请求资源的方法类型字段赋值为对应“REQUEST_POST”形式下：

包含标识当前用户使用POST方式请求资源的数据类型的字段，类型值与描述见下表；

Value	描述
		0x0000	Asset/Asset_edit
0x0001	MPU
		0x0002	MPU头数据
0x0003	MPU媒体实体数据
		0x0004	信令数据
0x0005	数据库数据
		0x0006	一般化文件
0x0007～0x7FFF	Reserved for ISO
		0x80000～0xFFFF	Reserved for private

其中，更具体的，对于此标识POST方式请求资源的数据类型的字段赋值“0x0000”情况下：

包含标识所请求资源的唯一Asset标识号字段，用来定位所请求的媒体资源，其定义由ISO/IEC 23008-1得到；

包含标识当前消息所请求Asset的编辑号字段，不同的编辑号对应媒体资源的不同编辑版本，其包含的MPU列表关系可以从相关描述中获得；其中完整版本的edit_id字段值默认为0，若协议不支持编辑号方式，此字段亦置为0；

其中，更具体的，对于此标识POST方式请求资源的数据类型的字段赋值“0x0001”或“0x0002”或“0x0003”情况下：

包含标识所请求资源的唯一Asset标识号字段，用来定位所请求的媒体资源，其定义由ISO/IEC 23008-1得到；

包含标识媒体处理单元在媒资中的唯一序号字段，用来定位具体媒体处理单元，其定义由ISO/IEC 23008-1得到；

其中，更具体的，对于此标识POST方式请求资源的数据类型的字段赋值“0x0004”情况下：

包含标识资源集合package的唯一标识号字段，其定义由ISO/IEC 23008-1得到；

包含标识该资源集合所相关的信令的信息类型的唯一标识号字段，用来识别信令的类型，其定义由ISO/IEC 23008-1得到；

包含标识该资源集合所相关的信令信息版本号字段，用来识别信令的更新版本，其定义由ISO/IEC 23008-1得到；

其中，更具体的，对于此标识POST方式请求资源的数据类型的字段赋值“0x0005”情况下：

包含唯一标识用户账号的标识号字段，用以定位具体用户账号；

包含用以标识上传数据库类型的字段，说明数据库的类型，具体取值与类型对应可以根据应用定义；

包含标识上传数据库数据版本的字段，用以维护和更新服务器中用户数据库；

包含用以标识上传数据库数据段长度字段；

包含上传数据库数据段字段；

其中，更具体的，对于此标识POST方式请求资源的数据类型的字段赋值“0x0006”情况下：

包含标识用户上传一般化文件MIME类型的字段，用以指示服务器按照相应文件格式解析数据；

包含用以标识上传一般化文件数据段长度的字段；

包含上传的一般化文件的数据段字段；

●更具体的，对于标志当前用户请求资源的方法类型字段赋值为对应“RESPONSE_GET”形式下：

包含描述服务器返回状态的字段，其值与描述见下表；

其中，更具体的，对于标志服务器返回状态的字段赋值为“0x02”形式下：

包含指示服务器返回的用户请求数据MIME类型的字段，提前告知客户端使其提前检验是否能够消费此资源；

包含标识返回内容的字节长度字段；

包含标识返回内容的数据段字段；

●更具体的，对于标志当前用户请求资源的方法类型字段赋值为对应“RESPONSE_POST”形式下：

包含描述服务器返回状态的字段，其值与描述同上表；

其中，更具体的，对于标志服务器返回状态的字段赋值为“0x03”形式下：

包含唯一标识传输包号的字段，其值与Asset_id值一一对应，其定义由ISO/IEC23008-1得到。用以指示返回资源所在的传输包。

包含用于用户自定义或未来扩展的数据段；

整个数据格式的结构可参见以下资源请求响应消息格式表表示：

资源请求响应消息格式表

3)消息交互的实施步骤

本发明提供的交互信息数据的网络传输方法包括以下步骤:

步骤a，网络终端设备按消息体已预先定义的快速交互消息负载数据段(payload)的格式或自定义的payload格式封装消息体“payload”字段。

步骤b，网络终端设备按快速交互消息主体格式封装消息整体。

步骤c，网络终端设备按MMT(ISO/IEC 23008-1)原协议“payload”格式定义把消息封装进协议“payload”。

步骤d，网络终端设备按协议格式定义生成一个或多个packet网络传送数据包。

步骤e，网络服务器接收一个或多个客户端提交的packet数据包后，按数据包协议头，解析出完整的协议级“payload”数据段。

步骤f，网络服务器按协议“payload”格式定义解出完整的消息体数据段

步骤g，网络服务器按消息头定义解出消息体的“payload”数据段。

步骤h，网络服务器按消息定义或自定义的格式，解读消息“payload”数据段。并进行相应处理和回应。

服务器端到网络终端设备的通信，也遵照此步骤。此数据格式和应用方法，满足网络双向通信的要求。

进一步的，作为一个实施方式，本发明所述的消息数据的网络传输方法是应用在网络终端设备与网络服务器之间。

1)反馈特定数据的实时交互消息

下面是一种在云桌面应用中，用此快速交互数据类型来传输鼠标键盘等需实时反馈给服务端数据的具体用法：

按下述方式决定字段值：

使用消息标识符字段，取某一特定值以指示此传输数据用于交互数据的传输；

使用消息中的版本表示当前时间数据在该时间内的序列号，每更新一个消息，本字段值加1，达到满值后下一轮重新置0。

使用消息中的消息数据类型表示不同类型的鼠标键盘等实时交互事件；

对应的交互数据类型的选取参见表1；

表1 实时交互信息数据类型(interaction_data_type)

Value	描述
		0x0000	表示按下键盘的某按钮
0x0001	表示松开键盘的某按钮
		0x0002	表示键盘里的指示灯键状态
0x0003	表示鼠标在显示屏的绝对位置
		0x0004	表示鼠标的移动操作
0x0005	表示按下鼠标某个按钮
		0x0006	表示松开鼠标某个按钮
0x0007～0x7FFF	Reserved for ISO
		0x80000～0xFFFF	Reserved for private

使用消息中的交互数据长度表示当前事件所对应数据的大小，对应的交互数据的数据定义如表2；

表2 传输鼠标键盘消息所用的交互数据定义

然后按附图3的结构，依次顺序填充数据段。当填充好完整的消息“payload”数据段后，再按照上述“消息交互的实施步骤”，来进行消息的发送。

对于虚拟现实设备上丰富多样的上行数据，如：陀螺仪数据，加速计数据，磁罗盘数据，操纵杆数据，触觉反馈数据，力觉反馈数据，都可通过定义相应的交互数据类型和交互数据格式，来实现在媒体系统中的传输。

2)用本发明的消息格式传输用户自定义的json格式的消息内容

本发明有着良好的扩展性和灵活性，用户可以十分方便地使用json等格式，来传输自己的定制信息。以下为实际步骤描述：

参见表3，选取一个未定义的私有字段保留值，作为当前消息的消息标识符值。

表3—消息标识符预定义值

Value	Description
		0x0000	PA message
0x0001～0x000F	MPI message
		0x0010～0x001F	MPT message
0x0200	CRI message
		0x0201	DCI message
0x0203	AL_FEC message
		0x0204	HRBM message
0x0205	MC message
		0x0206	AC message
0x0207	AF message
		0x0208	RQF message
0x0209	ADC message
		0x200A	RIC message
0x020B	3R message
		0x020A～0x6FFF	根据ISO标准保留(16-bit length message)
0x7000～0x7FFF	根据ISO标准保留(32-bit length message)
		0x8000～0xFFFF	保留为用户扩展使用的私有字段

把信息内容填充进json文件。例如用户点播节目进行播放，期间拖动播放器进度条，直接跳到节目某一时间点进行观看。需要上传此时间点信息，从而从特定位置开始获取数据包。则按此请求生成的json文件内容为：

{"eventType":"request_movie_by_time","movieID":"123","time":"17:50"}

把此json文件作为bit流填充进消息体的“payload”数据段，然后按照上述“消息交互的实施步骤”，来进行消息的发送即可。

通过不标准的信息格式进行信息交互的方式，需要针对不同服务器客户端不停进行重复开发。使用本发明，通过信息格式的标准化，可以有效降低构架多媒体传输网络的复杂度。同时，对协议进行的改进，可以大幅度提高网络信息交互的性能。特别是在网络带宽拥挤的情况下，用户满意度得到很好地提升。

应当理解的是，以上仅仅是本发明的部分实施例，本发明还可以应用到其他的传输系统，只需通过针对具体的业务需求，提炼出需要传输的网络交互信息数据，把信息数据填充进消息的“payload”数据段，之后按照交互信息数据的网络传输方法所描述的步骤，便可以实现，在本发明描述的技术方案基础上，对于本领域技术人员来说是很容易理解的。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (16)

1.一种多媒体系统中快速信息交互机制，其特征在于：包括：

针对协议传输格式强制的最简数据包，对协议格式头数据大小进行简化，使协议格式适应快速信息交互；

所述对协议格式头数据大小进行简化，是指：选取原协议传输格式中保留字段为标志位，提供简化掉Packet_id、Timestamp、Packet_squence_number三个字段的是否使用的选择，使协议格式头数据字节数变小。

2.根据权利要求1所述的一种多媒体系统中快速信息交互机制，其特征在于：所述对协议格式头数据的大小进行简化，具体为：选取原协议传输格式中保留字段分别修改为T、P和F标识字段，其中：

T:timestamp_flag，若置1使用timestamp字段；若置0不使用；当交互信息具有非常强的即时性，即一旦客户端或者服务器端收到此信息便做出响应，将此字段置0，前提是提供可靠的底层通信协议；

P：packet_id_flag，若置1使用packet_id字段；若置0不使用；当负载信息量较小，能够放入一个数据包进行传输，或者将数据分包交给底层协议实现时，将此字段置0，前提是提供可靠的底层通信协议；

F：fragmentation_flag，若置1使用packet_sequence_number字段；若置0不使用；此字段与“P”字段联合使用，当“P”字段置0条件满足时，将此字段置为0。

3.根据权利要求1所述的一种多媒体系统中快速信息交互机制，其特征在于：所述快速信息交互，其中：快速交互的消息实体在信令模式中传输。

4.根据权利要求1所述的一种多媒体系统中快速信息交互机制，其特征在于：所述快速信息交互，其中：快速交互信息主体包含如下字段：

包含实时交互消息的消息标识字段；

包含消息的版本号字段；

包含消息长度标识字段；

包含扩展字段；

包含标示当前消息负载(payload)的数据段。

5.根据权利要求4所述的一种多媒体系统中快速信息交互机制，其特征在于：不同类型的消息负载具有不同的格式，其中：实时交互消息负载(payload)包含如下字段：

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分；

包含标示了此消息信令中包含的交互数据个数的字段；

包含标示当前交互信息的类型；

包含标示当前交互数据长度的字段；

包含标示当前交互信息的字节数据段；

包含用于用户自定义或未来扩展的数据格式数据段。

6.根据权利要求4所述的一种多媒体系统中快速信息交互机制，其特征在于：不同类型的消息负载具有不同的格式，其中：资源请求响应消息负载(payload)包含如下字段：

包含资源请求方法标识字段，用来表示当前用户请求资源的方法；

包含一个扩展标志位字段，用来表示当前消息信令负载部分是否包括可扩展数据部分。

7.根据权利要求6所述的一种多媒体系统中快速信息交互机制，其特征在于：

所述包含资源请求方法标识字段，用来表示当前用户请求资源的方法，类型值与描述如下：

类型值“00b”表示当前用户请求方法为“REQUEST_GET”，解释为GET方式的请求信息；

类型值“01b”表示当前用户请求方法为“REQUEST_POST”，解释为POST方式的请求信息；

类型值“10b”表示当前用户请求方法为“RESPONSE_GET”，解释为GET方式的响应信息；

类型值“11b”表示当前用户请求方法为“RESPONSE_POST”，解释为POST方式的响应信息。

8.根据权利要求7所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于标志当前用户请求资源的方法类型字段赋值为对应“REQUEST_GET”形式下：

包含用户使用GET方式请求资源的URL信息长度字段；

包含用户使用GET方式请求资源的URL具体内容字段。

9.根据权利要求7所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于标志当前用户请求资源的方法类型字段赋值为对应“REQUEST_POST”形式 下：

包含标识当前用户使用POST方式请求资源的数据类型的字段。

10.根据权利要求9所述的一种多媒体系统中快速信息交互机制，其特征在于：

包含标识当前用户使用POST方式请求资源的数据类型的字段，类型值与描述如下：

类型值“0x0000”表示当前用户使用POST方式请求资源的数据类型为“Asset/Asset_edit”，解释为Asset的所有资源或Asset资源中某一edit版本；

类型值“0x0001”表示当前用户使用POST方式请求资源的数据类型为“MPU”，解释为Asset资源中的一个MPU数据；

类型值“0x0002”表示当前用户使用POST方式请求资源的数据类型为“MPU头数据”，解释为Asset资源中的一个MPU头数据；

类型值“0x0003”表示当前用户使用POST方式请求资源的数据类型为“MPU媒体实体数据”，解释为Asset资源中的一个MPU媒体实体数据；

类型值“0x0004”表示当前用户使用POST方式请求资源的数据类型为“信令数据”，解释为描述与指示媒体服务的信令数据；

类型值“0x0005”表示当前用户使用POST方式请求资源的数据类型为“数据库数据”，解释为用户消费服务产生的数据库信息数据；

类型值“0x0006”表示当前用户使用POST方式请求资源的数据类型为“一般化文件”，解释为客户端需要与服务器交互的一般化文件；

类型值“0x0007～0x7FFF”表示当前用户使用POST方式请求资源的数据类型为“ISO保留类型”，为ISO以后扩展使用；

类型值“0x0007～0x7FFF”表示当前用户使用POST方式请求资源的数据类型为“私人保留类型”，为私人数据扩展使用。

11.根据权利要求10所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于此标识POST方式请求资源的数据类型的字段赋值“0x0000”情况下：

包含标识所请求资源的唯一Asset标识号字段，用来定位所请求的媒体资源；

包含标识当前消息所请求Asset的编辑号字段，不同的编辑号对应媒体资源的不同编辑版本，其包含的MPU列表关系从相关描述中获得；其中完整版本的edit_id字段值默认为0，若协议不支持编辑号方式，此字段亦置为0；

对于此标识POST方式请求资源的数据类型的字段赋值“0x0001”或“0x0002”或“0x0003”情况下：

包含标识所请求资源的唯一Asset标识号字段，用来定位所请求的媒体资源；

包含标识媒体处理单元在媒资中的唯一序号字段，用来定位具体媒体处理单元；

对于此标识POST方式请求资源的数据类型的字段赋值“0x0004”情况下：

包含标识资源集合package的唯一标识号字段；

包含标识该资源集合所相关的信令的信息类型的唯一标识号字段，用来识别信令的类型；

包含标识该资源集合所相关的信令信息版本号字段，用来识别信令的更新版本；

对于此标识POST方式请求资源的数据类型的字段赋值“0x0005”情况下：

包含唯一标识用户账号的标识号字段，用以定位具体用户账号；

包含用以标识上传数据库类型的字段，说明数据库的类型，具体取值与类型对应可以根据应用定义；

包含标识上传数据库数据版本的字段，用以维护和更新服务器中用户数据库；

包含用以标识上传数据库数据段长度字段；

包含上传数据库数据段字段；

对于此标识POST方式请求资源的数据类型的字段赋值“0x0006”情况下：

包含标识用户上传一般化文件MIME类型的字段，用以指示服务器按照相应文件格式解析数据；

包含用以标识上传一般化文件数据段长度的字段；

包含上传的一般化文件的数据段字段。

12.根据权利要求7所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于标志当前用户请求资源的方法类型字段赋值为对应“RESPONSE_GET”形式下：

包含描述服务器返回状态的字段。

13.根据权利要求7所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于标志当前用户请求资源的方法类型字段赋值为对应“RESPONSE_POST”形式下：

包含描述服务器返回状态的字段。

14.根据权利要求12或13所述的一种多媒体系统中快速信息交互机制，其特征在于：包含描述服务器返回状态的字段，其值与描述如下；

类型值“0x00”表示当前服务器返回状态为“请求失败，请求所希望得到的资源未被 在服务器上发现”，解释为服务器在相应位置没有发现请求资源，所以返回请求失败消息；

类型值“0x01”表示当前服务器返回状态为“请求已成功”，解释为服务器已经收到用户的请求，向客户端发送此消息以确认；

类型值“0x02”表示当前服务器返回状态为“请求已成功，请求所希望的响应头或数据体将随此响应返回”，服务器已经收到用户的请求，并在此响应消息中添加了所请求的数据；

类型值“0x03”表示当前服务器返回状态为“请求已成功，请求所希望的响应头或数据体将在指定packet_id的流负载中返回”，解释为服务器已经收到用户的请求，并在对应packet_id流负载添加所请求的数据；

类型值“0x04～0x7F”表示当前服务器返回状态为“ISO保留值”,为ISO以后扩展使用；

类型值“0x80～0xFF”表示当前服务器返回状态为“私人保留值”，为私人数据扩展使用。

15.根据权利要求14所述的一种多媒体系统中快速信息交互机制，其特征在于：

对于标志服务器返回状态的字段赋值为“0x02”形式下：

包含指示服务器返回的用户请求数据MIME类型的字段，提前告知客户端使其提前检验是否能够消费此资源；

包含标识返回内容的字节长度字段；

包含标识返回内容的数据段字段；

对于标志当前用户请求资源的方法类型字段赋值为对应“RESPONSE_POST”形式下：

对于标志服务器返回状态的字段赋值为“0x03”形式下：

包含唯一标识传输包号的字段，其值与Asset_id值一一对应，用以指示返回资源所在的传输包；

包含用于用户自定义或未来扩展的数据段。

16.一种采用权利要求1-15任一项所述机制的多媒体系统中交互信息数据的网络传输方法，其特征在于包括：

步骤a，网络终端设备按消息体已预先定义的快速交互消息负载数据段(payload)的格式或自定义的payload格式封装消息体“payload”字段；

步骤b，网络终端设备按快速交互消息主体格式封装消息整体；

步骤c，网络终端设备按原协议“payload”格式定义把消息封装进协议“payload”；

步骤d，网络终端设备按协议格式定义生成一个或多个packet网络传送数据包；

步骤e，网络服务器接收一个或多个客户端提交的packet数据包后，按数据包协议头，解析出完整的协议级“payload”数据段；

步骤f，网络服务器按协议“payload”格式定义解出完整的消息体数据段；

步骤g，网络服务器按消息头定义解出消息体的“payload”数据段；

步骤h，网络服务器按消息定义或自定义的格式，解读消息“payload”数据段，并进行相应处理和回应；

服务器端到网络终端设备的通信，也遵照上述步骤。