媒体数据传输方法及设备与流程

本申请涉及电信和互联网通信技术，尤其涉及媒体数据传输方法及设备。

背景技术：
现有技术中，请求方设备与被请求方设备在同一个会话中，可以发起多个媒体业务。请求方设备与被请求方设备通过进行媒体协商，可以传输每个媒体业务的媒体数据，以建立对应的媒体通道，完成每个媒体业务。例如，富通信套件(RichCommunicationSuite，RCS)是一种以地址簿为基础，提供包括即时消息、文件传输、视频通话、视频共享等多种功能的业务集合。根据当前的会话描述协议(SessionDescriptionProtocol，SDP)规范，请求方设备会把所述请求方设备支持的媒体信息发送给被请求方设备。请求方设备可以同时利用SDP信息发起多个媒体业务，例如，同时发起视频共享业务和视频通话业务两个业务。虽然，这两个业务都是视频业务，但是，可能各自所对应的媒体信息有所区别，例如，视频共享业务支持VP8，而视频通话业务支持H.261和H.264。被请求方设备在接收到SDP信息后，只能知道请求方设备支持VP8、H.261和H.264三种编码格式，却不知道两种视频业务各自支持哪种编码格式。如果被请求方设备的视频共享业务支持H.261，视频通话业务支持H.264和VP8。根据当前的SDP规范，被请求方设备在向请求方设备回复的响应中可以包括这三种编码格式，表明可以进行媒体数据传输。但实际上，请求方设备和被请求方设备所支持的视频业务则会因为各自所支持的编码格式不同，而导致无法进行视频共享业务和视频通话业务的媒体数据的传输。因此，如果请求方设备所发起的多个媒体业务的媒体类型相同，由于两个设备(即请求方设备与被请求方设备)所支持的每个媒体业务的媒体信息(例如，编码格式、端口号或采样频率等)可能会不相同，致使请求方设备和被请求方设备则会因为各自所支持的与视频业务对应的媒体信息不同，而导致无法进行所述多个媒体业务的媒体数据的传输。

技术实现要素：
本申请的多个方面提供媒体数据传输方法及设备，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输。本申请的一方面，提供一种媒体数据传输方法，包括：请求方设备向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述请求方设备接收所述被请求方设备发送的业务响应消息，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果；所述请求方设备根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述请求方设备根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作，包括：所述请求方设备根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述请求方设备根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作，包括：所述请求方设备根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述请求方设备向被请求方设备发送业务请求消息之前，还包括：所述请求方设备向所述被请求方设备发送业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述请求方设备接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息；所述请求方设备向被请求方设备发送业务请求消息，包括：所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本申请的另一方面，提供一种媒体数据传输方法，包括：被请求方设备接收请求方设备发送的业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果；所述被请求方设备向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果；所述被请求方设备根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果，包括：所述被请求方设备确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务信息的数量与所述特征标签的数量相等，所述被请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果；或者如果所述业务信息的数量与所述特征标签的数量不相等，所述被请求方设备判断所述特征标签所指示的业务是否没有包含相同的媒体类型；如果所述特征标签所指示的业务没有包含相同的媒体类型，所述被请求方设备根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述请求方设备支持的每个所述媒体业务的媒体类型对应的媒体信息，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述被请求方设备根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作，包括：所述被请求方设备根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述被请求方设备根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作，包括：所述被请求方设备根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述被请求方设备接收请求方设备发送的业务请求消息之前，还包括：所述被请求方设备接收所述请求方设备发送的业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述被请求方设备根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本申请的另一方面，提供一种请求方设备，包括：发送单元，用于向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；接收单元，用于接收所述被请求方设备发送的业务响应消息，以及将所述业务响应消息传输给处理单元，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果；所述处理单元，用于根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送单元发送的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述处理单元具体用于根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述处理单元具体用于根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送单元发送的所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述接收单元接收的所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送单元还用于向所述被请求方设备发送业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述接收单元还用于接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以及将所述被请求方设备支持的与每个所述媒体业务对应的媒体信息传输给所述发送单元；所述发送单元具体用于根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本申请的另一方面，提供一种被请求方设备，包括：接收单元，用于接收请求方设备发送的业务请求消息，以及将所述业务请求消息传输给协商单元，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述协商单元，用于根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果，以及将所述协商结果传输给发送单元和处理单元；所述发送单元，用于向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果；所述处理单元，用于根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收单元接收的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商单元具体用于确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务信息的数量与所述特征标签的数量相等，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果；或者如果所述业务信息的数量与所述特征标签的数量不相等，判断所述特征标签所指示的业务是否没有包含相同的媒体类型；如果所述特征标签所指示的业务没有包含相同的媒体类型，根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述请求方设备支持的每个所述媒体业务的媒体类型对应的媒体信息，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述处理单元具体用于根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述处理单元具体用于根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收单元接收的所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述发送单元发送的所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收单元还用于接收所述请求方设备发送的业务能力查询请求消息，以及将所述业务能力查询请求消息传输给所述发送单元，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述发送单元还用于根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本申请的另一方面，提供一种请求方设备，包括：发送器，用于向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；接收器，用于接收所述被请求方设备发送的业务响应消息，以及将所述业务响应消息传输给处理器，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果；所述处理器，用于根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送器发送的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述处理器具体用于根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述处理器具体用于根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送器发送的所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述接收器接收的所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述发送器还用于向所述被请求方设备发送业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述接收器还用于接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以及将所述被请求方设备支持的与每个所述媒体业务对应的媒体信息传输给所述发送器；所述发送器具体用于根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本申请的另一方面，提供一种被请求方设备，包括：接收器，用于接收请求方设备发送的业务请求消息，以及将所述业务请求消息传输给处理器，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述处理器，用于根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果，以及将所述协商结果传输给发送器；所述发送器，用于向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果；所述处理器，还用于根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收器接收的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述处理器具体用于确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务信息的数量与所述特征标签的数量相等，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果；或者如果所述业务信息的数量与所述特征标签的数量不相等，判断所述特征标签所指示的业务是否没有包含相同的媒体类型；如果所述特征标签所指示的业务没有包含相同的媒体类型，根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述请求方设备支持的每个所述媒体业务的媒体类型对应的媒体信息，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；所述处理器具体用于根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述协商结果为协商失败信息；所述处理器具体用于根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收器接收的所述业务请求消息包括SIP消息、HTTP消息或XMPP消息；所述发送器发送的所述业务响应消息包括SIP消息、HTTP消息或XMPP消息。如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述接收器还用于接收所述请求方设备发送的业务能力查询请求消息，以及将所述业务能力查询请求消息传输给所述发送器，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务；所述发送器还用于根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。由上述技术方案可知，本申请实施例由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。图1为本申请一实施例提供的媒体数据传输方法的流程示意图；图2为本申请另一实施例提供的媒体数据传输方法的流程示意图；图3为本申请另一实施例提供的请求方设备的结构示意图；图4为本申请另一实施例提供的被请求方设备的结构示意图；图5为本申请另一实施例提供的请求方设备的结构示意图；图6为本申请另一实施例提供的被请求方设备的结构示意图。具体实施方式为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本发明提供的技术方案可以应用于多种应用中，例如，多业务会话邀请中的应用、基于WEB的实时通信(WEBRealTimeCommunication，WEBRTC)中的应用或业务能力发现中的应用等。另外，本文中术语“和／或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和／或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“／”，一般表示前后关联对象是一种“或”的关系。图1为本申请一实施例提供的媒体数据传输方法的流程示意图，如图1所示。101、请求方设备向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。102、所述请求方设备接收所述被请求方设备发送的业务响应消息，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果。103、所述请求方设备根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.323、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.323或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescriptionProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，具体可以在所述业务请求消息的消息体(即SDP信息)中增加标识媒体业务的参数“a＝：”行。具体地，可以为a＝featuretag：或a＝service：等形式，其取值可以唯一标识一个媒体业务。其后的其他媒体行则可以表示所述请求方设备支持的该媒体业务对应的媒体信息。例如，SDP信息可以采用纯文本形式进行描述，那么，所述业务请求消息的SDP信息可以为如下形式：a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝video49176RTP／AVP3132a＝rtpmap：31H261／90000a＝rtpmap：32MPV／90000a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”m＝video49178RTP／AVP3132a＝rtpmap：31H264／90000a＝rtpmap：32VP8／90000该SDP信息中包括了两个媒体业务，分别是urn：urn-7：3gpp-application.ims.iari.gsma-vs(3GPP定义的视频共享业务VS：VideoShare)和urn：urn-7：3gpp-service.ims.icsi.mmtel.video(3GPP定义的视频通话业务)。在视频共享业务中，视频流所使用的端口号为49176，传输协议为RTP，可选的编码格式有两种，一种是H261(采样频率为90000)，另一种是MPV(采样频率为90000)。在视频通话业务中，视频流所使用的端口号为49178，传输协议为RTP，可选的编码格式有两种，一种是H264(采样频率为90000)，另一种是VP8(采样频率为90000)再例如，SDP信息可以采用JSON(JavaScriptObjectNotation)格式进行描述，那么，所述业务请求消息的SDP信息可以为如下形式：“SDP”：[“／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”/nm＝video49170RTP／AVP3132／na＝rtpmap：31H261／90000／na＝rtpmap：32MPV／90000／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”/nm＝video49172RTP／AVP3334／na＝rtpmap：33H264／60000／na＝rtpmap：34VP8／60000／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel”/nm＝audio49174RTP／AVP0897／na＝rtpmap：0PCMU／8000／na＝rtpmap：8PCMA／8000／na＝rtpmap：97iLBC／8000／n“]该SDP信息中包括了三个媒体业务(2个视频媒体业务和1个音频媒体业务)，分别是urn：urn-7：3gpp-application.ims.iari.gsma-vs(3GPP定义的视频共享业务VS：VideoShare)、urn：urn-7：3gpp-service.ims.icsi.mmtel.video(3GPP定义的视频通话业务)和urn：urn-7：3gpp-service.ims.icsi.mmtel(3GPP定义的呼叫业务)。在视频共享业务中，视频流所使用的端口号为49170，传输协议为RTP，可选的编码格式有两种，一种是H261(采样频率为90000)，另一种是MPV(采样频率为90000)。在视频通话业务中，视频流所使用的端口号为49172，传输协议为RTP，可选的编码格式有两种，一种是H264(采样频率为60000)，另一种是VP8(采样频率为60000)。在呼叫业务中，音频流所使用的端口号为49174，传输协议为RTP，可选的编码格式有三种，第一种是PCMU(采样频率为8000)，第二种是PCMA(采样频率为8000)，第三种是iLBC(采样频率为8000)。从上述例中可以看出，媒体信息按照媒体业务进行了分隔，这样则可以对每个媒体业务对应的媒体信息进行分别描述，即每个a＝featuretag：行后的媒体信息均是针对于某一特定媒体业务，由a＝featuretag的取值来标识该媒体业务。可选地，在本实施例的一个可能的实现方式中，具体可以在所述业务请求消息的消息体包含多个部分即每一个部分可以对应一个SDP信息，每个SDP信息对应一个媒体业务对应的媒体信息，各个SDP信息可以通过分隔符隔开。例如，所述业务请求消息的多个SDP信息可以为如下形式：INVITEsip：to@192.168.105.14SIP／2.0From：<sip：from@192.168.105.5>；tag＝29244To：<sip：to@192.168.105.14>Call-ID：8103CSeq：20INVITEContact：<sip：from@192.168.105.5：5060>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Content-Type：multipart／application；boundary＝”----000_0009_01CD06B0.D0D652D0”------000_0009_01CD06B0.D0D652D0Content-Type：application／sdp；v＝0o＝alice28908445262890844526INIP4host.atlanta.example.coms＝c＝INIP4host.atlanta.example.comt＝00a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝audio49170RTP／AVP08a＝rtpmap：0PCMU／8000a＝rtpmap：8PCMA／8000------000_0009_01CD06B0.D0D652D0Content-Type：application／sdp；v＝0o＝alice28908445262890844526INIP4host.atlanta.example.coms＝c＝INIP4host.atlanta.example.comt＝00a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”／nm＝audio49172RTP／AVP0897／na＝rtpmap：0PCMU／8000／na＝rtpmap：8PCMA／8000／na＝rtpmap：97iLBC／8000／n从上述例中可以看出，Content-Type的值是multipart／application，表示消息体中包括多个部分，各部分间的分隔符为”------000_0009_01CD06B0.D0D652D0”。在每一部分前由分隔符开始，并指出本部分的类型是application／sdp，即SDP信息描述。可选地，消息体中各部分的顺序可以与Contact头域中FeatureTag的顺序一一对应。如果各部分的顺序与Contact头域中FeatureTag的顺序不一致，例如消息体中的第一部分对应第二个FeatureTag中的媒体业务，则需要在每个部分中增加相应的业务标识进行区分。例如，增加标识媒体业务的“a＝：”行。具体地，可以为a＝featuretag：或a＝service：等形式，其取值可以唯一标识一个媒体业务。其后的其他媒体行则可以表示所述请求方设备支持的该媒体业务对应的媒体信息。具体地，所述被请求方设备具体可以根据所述业务请求消息的联系方(contact)头域中的特征标签(FeatureTag)，判断所述业务请求消息是否为多业务请求。首先，所述被请求方设备可以确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务请求消息为多业务请求(即请求消息Contact头域中的特征标签FeatureTag的数量大于1个)，则判断媒体信息中描述的业务信息的数量(即a＝FeatureTag的数量)是否与所述联系方(contact)头域中的特征标签(FeatureTag)的数量相等。如果所述业务请求消息不为多业务请求(即特征标签的数量为1)，则执行按照现有技术中的流程，此处不再赘述。如果所述媒体信息(即所述请求方设备支持的与每个所述媒体业务对应的媒体信息)中描述的业务信息的数量与所述请求消息中联系方(contact)头域中的特征标签(FeatureTag)的数量相等，所述被请求方设备则可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出与每个所述媒体业务对应的媒体信息发送给所述请求方设备。如果所述媒体信息(即所述请求方设备支持的与每个所述媒体业务对应的媒体信息)中描述的业务信息的数量与所述请求消息中联系方(contact)头域中的特征标签(FeatureTag)的数量不相等，所述被请求方设备则再判断所述业务请求消息中所请求的多个媒体业务是否具有相同的媒体类型(例如，被请求方设备具体可以根据特征标签，判断多个媒体业务是否具有相同的媒体类型，例如：是否均为视频业务，或均为音频业务，或者包括均包括视频和音频业务)。如果是，所述被请求方设备则向请求方设备返回错误响应。否则，所述被请求方设备则可以根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述媒体类型对应的媒体信息，所述被请求方设备则可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出与每个所述媒体业务对应的媒体信息发送给所述请求方设备。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息。例如，所述业务响应消息的消息体中可以包含所述协商结果。具体地，所述业务响应消息的消息体(SDP信息)的详细描述可以参见所述业务请求消息的相关内容，此处不再赘述。相应地，在103中，所述请求方设备具体则可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息。例如，所述协商结果为协商失败信息的场景，可以包括但不限于以下场景：场景1、被请求方设备接收到业务请求消息之后，判断该业务请求消息所请求的媒体业务中至少有一种媒体业务该被请求方设备不支持，则向请求方设备返回所述协商失败信息。例如，请求方设备请求视频通话业务和视频共享业务，但被请求方设备不支持视频通话业务。场景2、被请求方设备接收到业务请求消息之后，判断该业务请求消息所请求的媒体业务对应的全部编码格式该被请求方设备不支持，则向请求方设备返回所述协商失败信息。例如，请求方设备请求视频通话业务对应的VP8或H.264两种编码格式，但被请求方设备只支持视频通话业务的H.261编码格式。场景3、被请求方设备根据用户设置或指示拒绝请求方设备所请求的多个媒体业务。相应地，在103中，所述请求方设备具体则可以根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，在101之前，所述请求方设备还可以进一步向所述被请求方设备发送业务能力查询请求消息。其中，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。然后，所述请求方设备则可以接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息。其中，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息。相应地，在101中，所述请求方设备具体可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的技术方案可以适用于多种应用中，例如，多业务会话邀请中的应用、基于WEB的实时通信(WEBRealTimeCommunication，WEBRTC)中的应用或业务能力发现中的应用等。例如，在多业务会话邀请中的应用中，即请求方设备向被请求方设备发起视频共享业务和视频通话业务的多业务会话邀请。本实施例中，“a＝featuretag”的取值可以唯一标识媒体业务，例如，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs代表视频共享业务，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video代表视频通话业务；“a＝featuretag”后面的媒体描述行中的信息则为该媒体业务对应的媒体信息，包括但不限于m＝行、a＝行等。具体地，请求方设备向被请求方设备发送的业务请求消息可以如下所示：INVITEsip：to@192.168.105.14SIP／2.0From：<sip：from@192.168.105.5>；tag＝29244To：<sip：to@192.168.105.14>；tag＝87963Call-ID：8103CSeq：20INVITEContact：<sip：from@192.168.105.5：5060>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Content-Type：application／sdpContent-Length：299a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝video49176RTP／AVP3132a＝rtpmap：31H261／90000a＝rtpmap：32MPV／90000a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”m＝video49178RTP／AVP3132a＝rtpmap：31H264／90000a＝rtpmap：32VP8／90000被请求方设备接收业务请求消息，首先则可以通过解析所述业务请求消息的头域，从而确定邀请中所包含哪些媒体业务，根据被请求方情况确定是否支持请求方设备所希望发起的媒体业务，如果支持，则可以继续解析所述业务请求消息的SDP信息，并向请求方返回多业务会话响应消息；如果不支持，则向请求方返回错误响应，表示不支持某种媒体业务。该多业务会话响应消息可以如下所示：SIP／2.0200OKFrom：<sip：from@192.168.105.5>；tag＝29244To：<sip：to@192.168.105.14>Call-ID：8103CSeq：20INVITEContact：<sip：from@192.168.105.5：5060>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Content-Type：application／sdpContent-Length：288v＝0a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝video49176RTP／AVP3132a＝rtpmap：31H261／90000a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”m＝video49178RTP／AVP3132a＝rtpmap：31H264／90000a＝rtpmap：32VP8／90000可以看出，以上多业务会话响应消息表示被请求方设备接收邀请，该多业务会话响应消息中包含协商出的与每个所述媒体业务对应的媒体信息。其中，由于被请求方设备不支持视频共享业务对应的音乐图片视频(MusicPhotoVideo，MPV)编码，因此，在所述业务响应消息并没有包含视频共享业务对应的MPV编码，说明被请求方设备不支持MPV编码。请求方接收业务响应消息，至此，请求方设备则可以根据所述业务响应消息，执行与被请求方设备建立视频共享业务的媒体通道和视频通话业务的媒体通道的操作。例如，在WEBRTC中的应用中，即请求方设备向被请求方设备发起屏幕共享业务和视频通话业务的HTTP请求。本实施例中，“a＝featuretag”的取值可以唯一标识媒体业务，具体可以由开发者统一设置业务标识以唯一标识媒体业务，例如，screen-share代表视频共享业务，video-call代表视频通话业务；“a＝featuretag”后面的描述信息则为该媒体业务对应的媒体信息。具体地，请求方设备首先可以根据自身情况设置请求方SDP(Local-SDP)为：a＝featuretag：screen-sharem＝video49170RTP／AVP31a＝rtpmap：31VP8／90000a＝featuretag：video-callm＝video49172RTP／AVP34a＝rtpmap：34H264／90000然后，请求方设备向被请求方设备发送的HTTP请求消息具体可以包括请求方设备设置的请求方SDP(Local-SDP)。被请求方设备接收HTTP请求消息，判断是否支持相应的业务(即SDP信息中所描述的screen-share和screen-video业务)，如果支持，被请求方设备则可以设置请求方SDP(Remote-SDP)为：a＝featuretag：screen-sharem＝video49170RTP／AVP31a＝rtpmap：31VP8／90000a＝featuretag：video-callm＝video49172RTP／AVP34a＝rtpmap：34H264／90000然后，被请求方设备根据自身情况设置被请求方的SDP(Local-SDP)为：a＝featuretag：screen-sharem＝video3566RTP／AVP31a＝rtpmap：31VP8／90000a＝featuretag：video-callm＝video3568RTP／AVP34a＝rtpmap：34H264／90000然后，被请求方设备向请求方设备发送的HTTP响应消息，具体可以包括被请求方设备设置的被请求方的SDP(Local-SDP)。请求方设备接收HTTP响应消息，则可以设置被请求方的SDP(Remote-SDP)为：a＝featuretag：screen-sharem＝video3566RTP／AVP31a＝rtpmap：31VP8／90000a＝featuretag：video-callm＝video3568RTP／AVP34a＝rtpmap：34H264／90000至此，请求方设备则可以根据所述HTTP响应消息，执行与被请求方设备建立屏幕共享业务的媒体通道和视频通话业务的媒体通道的操作。例如，在业务能力发现中的应用(例如，请求方设备上线时，向所有好友发起业务能力发现，或者请求方设备想与某好友进行通话之前，向该好友发起业务能力发现等)中，即请求方设备与被请求方设备通过提供／应答(OFFER／ANSWER)机制，获取被请求方设备当前所支持的媒体业务对应的媒体信息。本实施例中，“a＝featuretag”的取值可以唯一标识媒体业务，例如，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs代表视频共享业务，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video代表视频通话业务；“a＝featuretag”后面的描述信息则为该媒体业务对应的媒体信息。具体地，请求方设备向被请求方设备发送的用以查询业务能力的SIP选项(SIPOPTIONS)请求消息可以如下所示：OPTIONSsip：carol@chicago.comSIP／2.0Via：SIP／2.0／UDPpc33.atlanta.com；branch＝z9hG4bKhjhs8ass877Max-Forwards：70To：<sip：carol@chicago.com>From：Alice<sip：alice@atlanta.com>；tag＝1928301774Call-ID：a84b4c76e66710CSeq：63104OPTIONSContact：<sip：alice@pc33.atlanta.com>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Accept：application／sdpContent-Length：0被请求方设备接收SIP选项请求消息，该SIP选项请求消息中包含请求方设备的标识，进一步可以包含请求方设备所支持的媒体业务。被请求方设备根据所述SIP选项请求消息，向请求方设备返回SIP选项响应消息，该SIP选项响应消息可以如下所示：SIP／2.0200OKVia：SIP／2.0／UDPpc33.atlanta.com；branch＝z9hG4bKhjhs8ass877；received＝192.0.2.4To：<sip：carol@chicago.com>；tag＝93810874From：Alice<sip：alice@atlanta.com>；tag＝1928301774Call-ID：a84b4c76e66710nCSeq：63104OPTIONSContact：<sip：carol@chicago.com>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Allow：INVITE，ACK，CANCEL，OPTIONS，BYEAccept：application／sdpAccept-Encoding：gzipAccept-Language：enSupported：fooContent-Type：application／sdpContent-Length：311v＝0a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝video49176RTP／AVP3132a＝rtpmap：31H261／90000a＝rtpmap：32MPV／90000a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”m＝video49178RTP／AVP3132a＝rtpmap：31H264／90000a＝rtpmap：32VP8／90000请求方设备接收SIP选项响应消息，该SIP选项响应消息中包含被请求方设备的标识和被请求方设备所支持的媒体业务，至此，请求方设备则可以根据所述SIP选项响应消息，获取所述被请求方设备所支持的媒体业务对应的媒体信息。进一步地，还可以进一步在请求方设备向被请求方设备发送的SIP选项(SIPOPTIONS)请求消息中增加一个头域，例如Answer-SDP-Needed头域，表示是否需要被请求方设备在返回的SIP选项响应消息中包含所述被请求方设备所支持的媒体业务对应的媒体信息。具体地，请求方设备向被请求方设备发送的SIP选项(SIPOPTIONS)请求消息还可以如下所示：OPTIONSsip：carol@chicago.comSIP／2.0Via：SIP／2.0／UDPpc33.atlanta.com；branch＝z9hG4bKhjhs8ass877Max-Forwards：70To：<sip：carol@chicago.com>From：Alice<sip：alice@atlanta.com>；tag＝1928301774Call-ID：a84b4c76e66710CSeq：63104OPTIONSContact：<sip：alice@pc33.atlanta.com>Accept：application／sdpAnswer-SDP-Needed：yesContent-Length：0新增加的Answer-SDP-Needed头域，其取值为yes时，表示需要被请求方在返回的SIP选项响应消息中包含所述被请求方所支持的媒体业务对应的媒体信息；其取值为no时，表示不需要被请求方在返回的SIP选项响应消息中包含所述被请求方所支持的媒体业务对应的媒体信息。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。图2为本申请另一实施例提供的媒体数据传输方法的流程示意图，如图2所示。201、被请求方设备接收请求方设备发送的业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。202、所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果。203、所述被请求方设备向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果。204、所述被请求方设备根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。也就是说，所述请求方设备接收到所述业务响应消息之后，可以根据所述协商结果，向所述被请求方设备发起或者不向所述被请求方设备发起所述至少两个媒体业务的媒体数据的传输；相应地，所述被请求方设备则可以根据所述协商结果，响应或者不再响应所述至少两个媒体业务的媒体数据的传输。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.323、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.323或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescriptionProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，具体可以在所述业务请求消息的消息体(即SDP信息)中增加标识媒体业务的参数“a＝：”行。具体地，可以为a＝featuretag：或a＝service：等形式，其取值可以唯一标识一个媒体业务。其后的其他媒体行则可以表示所述请求方设备支持的该媒体业务对应的媒体信息。例如，SDP信息可以采用纯文本形式进行描述，那么，所述业务请求消息的SDP信息可以为如下形式：a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝video49176RTP／AVP3132a＝rtpmap：31H261／90000a＝rtpmap：32MPV／90000a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”m＝video49178RTP／AVP3132a＝rtpmap：31H264／90000a＝rtpmap：32VP8／90000该SDP信息中包括了两个媒体业务，分别是urn：urn-7：3gpp-application.ims.iari.gsma-vs(3GPP定义的视频共享业务VS：VideoShare)和urn：urn-7：3gpp-service.ims.icsi.mmtel.video(3GPP定义的视频通话业务)。在视频共享业务中，视频流所使用的端口号为49176，传输协议为RTP，可选的编码格式有两种，一种是H261(采样频率为90000)，另一种是MPV(采样频率为90000)。在视频通话业务中，视频流所使用的端口号为49178，传输协议为RTP，可选的编码格式有两种，一种是H264(采样频率为90000)，另一种是VP8(采样频率为90000)再例如，SDP信息可以采用JSON(JavaScriptObjectNotation)格式进行描述，那么，所述业务请求消息的SDP信息可以为如下形式：“SDP”：[“／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”/nm＝video49170RTP／AVP3132／na＝rtpmap：31H261／90000／na＝rtpmap：32MPV／90000／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”/nm＝video49172RTP／AVP3334／na＝rtpmap：33H264／60000／na＝rtpmap：34VP8／60000／na＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel”/nm＝audio49174RTP／AVP0897／na＝rtpmap：0PCMU／8000／na＝rtpmap：8PCMA／8000／na＝rtpmap：97iLBC／8000／n“]该SDP信息中包括了三个媒体业务(2个视频媒体业务和1个音频媒体业务)，分别是urn：urn-7：3gpp-application.ims.iari.gsma-vs(3GPP定义的视频共享业务VS：VideoShare)、urn：urn-7：3gpp-service.ims.icsi.mmtel.video(3GPP定义的视频通话业务)和urn：urn-7：3gpp-service.ims.icsi.mmtel(3GPP定义的呼叫业务)。在视频共享业务中，视频流所使用的端口号为49170，传输协议为RTP，可选的编码格式有两种，一种是H261(采样频率为90000)，另一种是MPV(采样频率为90000)。在视频通话业务中，视频流所使用的端口号为49172，传输协议为RTP，可选的编码格式有两种，一种是H264(采样频率为60000)，另一种是VP8(采样频率为60000)。在呼叫业务中，音频流所使用的端口号为49174，传输协议为RTP，可选的编码格式有三种，第一种是PCMU(采样频率为8000)，第二种是PCMA(采样频率为8000)，第三种是iLBC(采样频率为8000)。从上述例中可以看出，媒体信息按照媒体业务进行了分隔，这样则可以对每个媒体业务对应的媒体信息进行分别描述，即每个a＝featuretag：行后的媒体信息均是针对于某一特定媒体业务，由a＝featuretag的取值来标识该媒体业务。可选地，在本实施例的一个可能的实现方式中，具体可以在所述业务请求消息的消息体包含多个部分即一个部分可以对应一个SDP信息，每个SDP信息对应一个媒体业务对应的媒体信息，各个SDP信息可以通过分隔符隔开。例如，所述业务请求消息的多个SDP信息可以为如下形式：INVITEsip：to@192.168.105.14SIP／2.0From：<sip：from@192.168.105.5>；tag＝29244To：<sip：to@192.168.105.14>Call-ID：8103CSeq：20INVITEContact：<sip：from@192.168.105.5：5060>；featuretag＝+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”，+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”Content-Type：multipart／application；boundary＝”----000_0009_01CD06B0.D0D652D0”------000_0009_01CD06B0.D0D652D0Content-Type：application／sdp；v＝0o＝alice28908445262890844526INIP4host.atlanta.example.coms＝c＝INIP4host.atlanta.example.comt＝00a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-application.ims.iari.gsma-vs”m＝audio49170RTP／AVP08a＝rtpmap：0PCMU／8000a＝rtpmap：8PCMA／8000------000_0009_01CD06B0.D0D652D0Content-Type：application／sdp；v＝0o＝alice28908445262890844526INIP4host.atlanta.example.coms＝c＝INIP4host.atlanta.example.comt＝00a＝featuretag：+g.3gpp.iari-ref＝“urn：urn-7：3gpp-service.ims.icsi.mmtel.video”／nm＝audio49172RTP／AVP0897／na＝rtpmap：0PCMU／8000／na＝rtpmap：8PCMA／8000／na＝rtpmap：97iLBC／8000／n从上述例中可以看出，Content-Type的值是multipart／application，表示消息体中包括多个部分，各部分间的分隔符为”------000_0009_01CD06B0.D0D652D0”。在每一部分前由分隔符开始，并指出本部分的类型是application／sdp，即SDP信息描述。可选地，消息体中各部分的顺序可以与Contact头域中FeatureTag的顺序一一对应。如果各部分的顺序与Contact头域中FeatureTag的顺序不一致，例如消息体中的第一部分对应第二个FeatureTag中的媒体业务，则需要在每个部分中增加相应的业务标识进行区分，则需要在每个部分中增加相应的业务标识进行区分。例如，增加标识媒体业务的“a＝：”行。具体地，可以为a＝featuretag：或a＝service：等形式，其取值可以唯一标识一个媒体业务。其后的其他媒体行则可以表示所述请求方设备支持的该媒体业务对应的媒体信息。具体地，在202中，所述被请求方设备具体可以根据所述业务请求消息的联系方(contact)头域中的特征标签(FeatureTag)，判断所述业务请求消息是否为多业务请求。如果所述业务请求消息为多业务请求(即特征标签的数量不为1)，则判断媒体信息的数量是否与所述特征标签的数量相等。如果所述业务请求消息不为多业务请求(即特征标签的数量为1)，则执行按照现有技术中的流程，此处不再赘述。如果所述媒体信息(即所述请求方设备支持的与每个所述媒体业务对应的媒体信息)的数量与所述特征标签的数量相等，所述被请求方设备则可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出与每个所述媒体业务对应的媒体信息发送给所述请求方设备。如果所述媒体信息(即所述请求方设备支持的与每个所述媒体业务对应的媒体信息)的数量与所述特征标签的数量不相等，所述被请求方设备则再判断所述业务请求消息中所请求的多个媒体业务是否具有相同的媒体类型(例如，被请求方设备具体可以根据特征标签，判断多个媒体业务是否具有相同的媒体类型)。如果是，所述被请求方设备则向请求方设备返回错误响应。否则，所述被请求方设备则可以根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述媒体类型对应的媒体信息，所述被请求方设备则可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出与每个所述媒体业务对应的媒体信息发送给所述请求方设备。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息。例如，所述业务响应消息的消息体中可以包含所述协商结果。具体地，所述业务响应消息的消息体(SDP信息)的详细描述可以参见所述业务请求消息的相关内容，此处不再赘述。相应地，在204中，所述被请求方设备具体可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息。例如，所述协商结果为协商失败信息的场景，可以包括但不限于以下场景：场景1、被请求方设备接收到业务请求消息之后，判断该业务请求消息所请求的媒体业务中至少有一种媒体业务该被请求方设备不支持，则向请求方设备返回所述协商失败信息。例如，请求方设备请求视频通话业务和视频共享业务，但被请求方设备不支持视频通话业务。场景2、被请求方设备接收到业务请求消息之后，判断该业务请求消息所请求的媒体业务对应的全部编码格式该被请求方设备不支持，则向请求方设备返回所述协商失败信息。例如，请求方设备请求视频通话业务对应的VP8或H.264两种编码格式，但被请求方设备只支持视频通话业务的H.261编码格式。场景3、被请求方设备根据用户设置或指示拒绝请求方设备所请求的多个媒体业务。相应地，在204中，所述被请求方设备具体可以根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，在201之前，所述被请求方设备还可以进一步接收所述请求方设备发送的业务能力查询请求消息。其中，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。然后，所述被请求方设备则可以根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息。其中，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的技术方案可以适用于多种应用中，例如，多业务会话邀请中的应用、基于WEB的实时通信(WEBRealTimeCommunication，WEBRTC)中的应用或业务能力发现中的应用等。详细描述可以参见图1对应的实施例中的相关内容，此处不再赘述。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。图3为本申请另一实施例提供的请求方设备的结构示意图，如图3所示，本实施例的请求方设备可以包括发送单元31、接收单元32和处理单元33。其中，发送单元31，用于向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；接收单元32，用于接收所述被请求方设备发送的业务响应消息，以及将所述业务响应消息传输给处理单元33，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果；所述处理单元33，用于根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.323、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.323或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述发送单元31发送的所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescriptionProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述发送单元31发送的所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述接收单元32接收的所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；相应地，所述处理单元33具体可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息；相应地，所述处理单元33具体可以根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，所述发送单元31还可以进一步向所述被请求方设备发送业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。所述接收单元32还可以进一步接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以及将所述被请求方设备支持的与每个所述媒体业务对应的媒体信息传输给所述发送单元31。相应地，所述发送单元31具体可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的请求方设备用于对应执行如图1所示实施例的方法，对于图1所示实施例已经描述的细节，此处不再赘述。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。图4为本申请另一实施例提供的被请求方设备的结构示意图，如图4所示，本实施例的被请求方设备可以包括接收单元41、协商单元42、发送单元43和处理单元44。其中，接收单元41，用于接收请求方设备发送的业务请求消息，以及将所述业务请求消息传输给协商单元42，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述协商单元42，用于根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果，以及将所述协商结果传输给发送单元43和处理单元44；所述发送单元43，用于向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果；所述处理单元44，用于根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.323、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.323或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述接收单元41接收的所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescriptionProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述接收单元41接收的所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述发送单元43发送的所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，所述协商单元42具体可以确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务信息的数量与所述特征标签的数量相等，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。或者，如果所述业务信息的数量与所述特征标签的数量不相等，判断所述特征标签所指示的业务是否没有包含相同的媒体类型；如果所述特征标签所指示的业务没有包含相同的媒体类型，根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述媒体类型对应的媒体信息，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；相应地，所述处理单元44具体可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息；相应地，所述处理单元44具体可以根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，所述接收单元41还可以进一步接收所述请求方设备发送的业务能力查询请求消息，以及将所述业务能力查询请求消息传输给所述发送单元43，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。所述发送单元43还可以进一步根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的请求方设备用于对应执行如图2所示实施例的方法，对于图2所示实施例已经描述的细节，此处不再赘述。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。图5为本申请另一实施例提供的请求方设备的结构示意图，如图5所示，本实施例的请求方设备可以包括发送器51、接收器52和处理器53。其中，发送器51，用于向被请求方设备发送业务请求消息，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；接收器52，用于接收所述被请求方设备发送的业务响应消息，以及将所述业务响应消息传输给处理器53，所述业务响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商获得的协商结果；所述处理器53，用于根据所述协商结果，执行或不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.323、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.323或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述发送器51发送的所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescriptionProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述发送器51发送的所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述接收器52接收的所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；相应地，所述处理器53具体可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述被请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息；相应地，所述处理器53具体可以根据所述协商失败信息，不执行与所述被请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，所述发送器51还可以进一步向所述被请求方设备发送业务能力查询请求消息，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。所述接收器52还可以进一步接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以及将所述被请求方设备支持的与每个所述媒体业务对应的媒体信息传输给所述发送器51。相应地，所述发送器51具体可以根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的请求方设备用于对应执行如图1所示实施例的方法，对于图1所示实施例已经描述的细节，此处不再赘述。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。图6为本申请另一实施例提供的被请求方设备的结构示意图，如图6所示，本实施例的被请求方设备可以包括接收器61、处理器62和发送器63。其中，接收器61，用于接收请求方设备发送的业务请求消息，以及将所述业务请求消息传输给处理器62，所述业务请求消息用以指示至少两个媒体业务，所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息；所述处理器62，用于根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，进行媒体协商，以获得协商结果，以及将所述协商结果传输给发送器63；所述发送器63，用于向所述请求方设备发送业务响应消息，所述业务响应消息中包含所述协商结果；所述处理器62，还用于根据所述协商结果，执行或不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。其中，所述媒体信息包括媒体流接收的地址和端口号、媒体流的采样频率以及编码格式(如H.523、动态图像专家组(MovingPicturesExpertsGroup，MPEG)或VP8等)；此外，媒体信息还可以包括媒体类型(如视频或音频等)、传输协议(如传输控制协议(TransmissionControlProtocol，TCP)、用户数据报协议(UserDatagramProtocol，UDP)、H.523或实时传输协议(Real-TimeTransportProtocol，RTP)等)等信息。可选地，在本实施例的一个可能的实现方式中，所述接收器61接收的所述业务请求消息的消息体中可以包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。可选地，在本实施例的一个可能的实现方式中，所述业务请求消息和所述业务响应消息的消息体可以是通过会话描述协议(SessionDescripitonProtocol，SDP)协议描述的，为了简化描述，可以称其消息体为一个SDP信息。其中，所述接收器61接收的所述业务请求消息可以包括但不限于会话初始化协议(SessionInitiationProtocol，SIP)消息、超文体传输协议(HypertextTransferProtocol，HTTP)消息或(ExtensibleMessagingandPresenceProtocol，XMPP)消息；相应地，所述发送器63发送的所述业务响应消息可以包括但不限于SIP消息、HTTP消息或XMPP消息。可选地，在本实施例的一个可能的实现方式中，所述处理器62具体可以确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量；如果所述业务信息的数量与所述特征标签的数量相等，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。或者如果所述业务信息的数量与所述特征标签的数量不相等，判断所述特征标签所指示的业务是否没有包含相同的媒体类型；如果所述特征标签所指示的业务没有包含相同的媒体类型，根据所述请求方设备支持的每个所述媒体业务的媒体类型，确定所述媒体类型对应的媒体信息，根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息，协商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，作为所述协商结果。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息；相应地，所述处理器62具体可以根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信息，与所述请求方设备传输所述至少两个媒体业务的媒体数据。可选地，在本实施例的一个可能的实现方式中，所述协商结果具体可以为协商失败信息；相应地，所述处理器62具体可以根据所述协商失败信息，不执行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作。可选地，在本实施例的一个可能的实现方式中，所述接收器61还可以进一步接收所述请求方设备发送的业务能力查询请求消息，以及将所述业务能力查询请求消息传输给所述发送器63，所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体业务。所述发送器63还可以进一步根据所述业务能力查询请求消息，向所述请求方设备发送业务能力查询响应消息，所述业务能力查询响应消息中包含所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，以使得所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息，向被请求方设备发送所述业务请求消息。本实施例提供的请求方设备用于对应执行如图2所示实施例的方法，对于图2所示实施例已经描述的细节，此处不再赘述。本实施例中，由于请求方设备与被请求方设备之间传输的媒体信息是与所述请求方设备或所述被请求方设备支持的每个媒体业务分别对应的，因此，当请求方设备发起媒体类型相同的多个媒体业务，且请求方设备与被请求方设备所支持的每个媒体业务的媒体信息不相同时，能够实现请求方设备与被请求方设备进行所述多个媒体业务的媒体数据的传输，以建立对应的媒体通道，完成每个媒体业务。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。