LIANG GANG (CN)
| WO2009104082A2 | 2009-08-27 |
| CN102271320A | 2011-12-07 | |||
| CN1852300A | 2006-10-25 | |||
| CN101388881A | 2009-03-18 | |||
| US20020143678A1 | 2002-10-03 |
北京同立钧成知识产权代理有限公司 (CN)
| 权 利 要求 书 1、 一种媒体数据传输方法， 其特征在于， 包括： 请求方设备向被请求方设备发送业务请求消息， 所述业务请求消息用以 指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持的与 每个所述媒体业务对应的媒体信息； 所述请求方设备接收所述被请求方设备发送的业务响应消息， 所述业务 响应消息中包含所述被请求方设备根据所述请求方设备支持的与每个所述媒 体业务对应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应 的媒体信息， 进行媒体协商获得的协商结果； 所述请求方设备根据所述协商结果， 执行或不执行与所述被请求方设备 传输所述至少两个媒体业务的媒体数据的操作。 2、 根据权利要求 1所述的方法， 其特征在于， 所述业务请求消息的消息 体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。 3、根据权利要求 1或 2所述的方法， 其特征在于， 所述协商结果为所述 请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒 体信息； 所述请求方设备根据所述协商结果， 执行或不执行与所述被请求方 设备传输所述至少两个媒体业务的媒体数据的操作， 包括： 所述请求方设备根据所述请求方设备和所述被请求方设备均支持的与所 述每个所述媒体业务对应的媒体信息， 与所述被请求方设备传输所述至少两 个媒体业务的媒体数据。 4、根据权利要求 1或 2所述的方法， 其特征在于， 所述协商结果为协商 失败信息； 所述请求方设备根据所述协商结果， 执行或不执行与所述被请求 方设备传输所述至少两个媒体业务的媒体数据的操作， 包括： 所述请求方设备根据所述协商失败信息， 不执行与所述被请求方设备传 输所述至少两个媒体业务的媒体数据的操作。 5、 根据权利要求 1~4任一权利要求所述的方法， 其特征在于， 所述业务请求消息包括 SIP消息、 HTTP消息或 XMPP消息； 所述业务响应消息包括 SIP消息、 HTTP消息或 XMPP消息。 6、 根据权利要求 1~5任一权利要求所述的方法， 其特征在于， 所述请求方设备向被请求方设备发送业务请求消息之前， 还包括： 所述请求方设备向所述被请求方设备发送业务能力查询请求消息， 所述 业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述媒体 业务； 所述请求方设备接收所述被请求方设备根据所述业务能力查询请求消息 发送的业务能力查询响应消息， 所述业务能力查询响应消息中包含所述被请 求方设备支持的与每个所述媒体业务对应的媒体信息； 所述请求方设备向被请求方设备发送业务请求消息， 包括： 所述请求方设备根据所述被请求方设备支持的与每个所述媒体业务对应 的媒体信息， 向被请求方设备发送所述业务请求消息。 7、 一种媒体数据传输方法， 其特征在于， 包括： 被请求方设备接收请求方设备发送的业务请求消息， 所述业务请求消息 用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持 的与每个所述媒体业务对应的媒体信息； 所述被请求方设备根据所述请求方设备支持的与每个所述媒体业务对应 的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信 息， 进行媒体协商， 以获得协商结果； 所述被请求方设备向所述请求方设备发送业务响应消息， 所述业务响应 消息中包含所述协商结果； 所述被请求方设备根据所述协商结果， 执行或不执行与所述请求方设备 传输所述至少两个媒体业务的媒体数据的操作。 8、 根据权利要求 7所述的方法， 其特征在于， 所述业务请求消息的消息 体中包含所述请求方设备支持的与每个所述媒体业务对应的媒体信息。 9、根据权利要求 7或 8所述的方法， 其特征在于， 所述被请求方设备根 据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求 方设备支持的与每个所述媒体业务对应的媒体信息， 进行媒体协商， 以获得 协商结果， 包括： 所述被请求方设备确定所述业务请求消息所包含的媒体信息中描述的业 务信息的数量和所述业务请求消息的联系方头域中的特征标签的数量； 如果所述业务信息的数量与所述特征标签的数量相等， 所述被请求方设 备根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息和所述 请求方设备支持的与每个所述媒体业务对应的媒体信息， 协商出所述请求方 设备和所述被请求方设备均支持的与所述每个所述媒体业务对应的媒体信 息， 作为所述协商结果； 或者 如果所述业务信息的数量与所述特征标签的数量不相等， 所述被请求方 设备判断所述特征标签所指示的业务是否没有包含相同的媒体类型； 如果所 述特征标签所指示的业务没有包含相同的媒体类型， 所述被请求方设备根据 所述请求方设备支持的每个所述媒体业务的媒体类型， 确定所述请求方设备 支持的每个所述媒体业务的媒体类型对应的媒体信息， 根据所述被请求方设 备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的与每 个所述媒体业务对应的媒体信息， 协商出所述请求方设备和所述被请求方设 备均支持的与所述每个所述媒体业务对应的媒体信息， 作为所述协商结果。 10、 根据权利要求 7~9任一权利要求所述的方法， 其特征在于， 所述协 商结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息； 所述被请求方设备根据所述协商结果， 执行或不执行 与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作， 包括： 所述被请求方设备根据所述请求方设备和所述被请求方设备均支持的与 所述每个所述媒体业务对应的媒体信息 , 与所述请求方设备传输所述至少两 个媒体业务的媒体数据。 11、 根据权利要求 7~9任一权利要求所述的方法， 其特征在于， 所述协 商结果为协商失败信息； 所述被请求方设备根据所述协商结果， 执行或不执 行与所述请求方设备传输所述至少两个媒体业务的媒体数据的操作， 包括： 所述被请求方设备根据所述协商失败信息， 不执行与所述请求方设备传 输所述至少两个媒体业务的媒体数据的操作。 12、 根据权利要求 7~1 1任一权利要求所述的方法， 其特征在于， 所述业务请求消息包括 SIP消息、 HTTP消息或 XMPP消息； 所述业务响应消息包括 SIP消息、 HTTP消息或 XMPP消息。 13、 根据权利要求 7~12任一权利要求所述的方法， 其特征在于， 所述 被请求方设备接收请求方设备发送的业务请求消息之前， 还包括： 所述被请求方设备接收所述请求方设备发送的业务能力查询请求消息， 所述业务能力查询请求消息的消息体中包含所述请求方设备支持的每个所述 媒体业务； 所述被请求方设备根据所述业务能力查询请求消息， 向所述请求方设备 发送业务能力查询响应消息， 所述业务能力查询响应消息中包含所述被请求 方设备支持的与每个所述媒体业务对应的媒体信息， 以使得所述请求方设备 根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息， 向被请 求方设备发送所述业务请求消息。 14、 一种请求方设备， 其特征在于， 包括： 发送单元， 用于向被请求方设备发送业务请求消息， 所述业务请求消息 用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持 的与每个所述媒体业务对应的媒体信息； 接收单元， 用于接收所述被请求方设备发送的业务响应消息， 以及将所 述业务响应消息传输给处理单元， 所述业务响应消息中包含所述被请求方设 备根据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被 请求方设备支持的与每个所述媒体业务对应的媒体信息， 进行媒体协商获得 的协商结果； 所述处理单元， 用于根据所述协商结果， 执行或不执行与所述被请求方 设备传输所述至少两个媒体业务的媒体数据的操作。 15、 根据权利要求 14 所述的请求方设备， 其特征在于， 所述发送单元 发送的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述 媒体业务对应的媒体信息。 16、 根据权利要求 14或 15所述的请求方设备， 其特征在于， 所述协商 结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业 务对应的媒体信息； 所述处理单元具体用于 根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息， 与所述被请求方设备传输所述至少两个媒体业务的媒 体数据。 17、 根据权利要求 14或 16所述的请求方设备， 其特征在于， 所述协商 结果为协商失败信息； 所述处理单元具体用于 根据所述协商失败信息， 不执行与所述被请求方设备传输所述至少两个 媒体业务的媒体数据的操作。 18、根据权利要求 14~17任一权利要求所述的请求方设备，其特征在于， 所述发送单元发送的所述业务请求消息包括 SIP 消息、 HTTP 消息或 XMPP消息； 所述接收单元接收的所述业务响应消息包括 SIP 消息、 HTTP 消息或 XMPP消息。 19、根据权利要求 14~18任一权利要求所述的请求方设备，其特征在于， 所述发送单元还用于 向所述被请求方设备发送业务能力查询请求消息， 所述业务能力查询请 求消息的消息体中包含所述请求方设备支持的每个所述媒体业务； 所述接收单元还用于 接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力 查询响应消息， 所述业务能力查询响应消息中包含所述被请求方设备支持的 与每个所述媒体业务对应的媒体信息， 以及将所述被请求方设备支持的与每 个所述媒体业务对应的媒体信息传输给所述发送单元； 所述发送单元具体用于 根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息， 向 被请求方设备发送所述业务请求消息。 20、 一种被请求方设备， 其特征在于， 包括： 接收单元， 用于接收请求方设备发送的业务请求消息， 以及将所述业务 请求消息传输给协商单元， 所述业务请求消息用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的 媒体信息； 所述协商单元， 用于根据所述请求方设备支持的与每个所述媒体业务对 应的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信 息， 进行媒体协商， 以获得协商结果， 以及将所述协商结果传输给发送单元 和处理单元； 所述发送单元， 用于向所述请求方设备发送业务响应消息， 所述业务响 应消息中包含所述协商结果； 所述处理单元， 用于根据所述协商结果， 执行或不执行与所述请求方设 备传输所述至少两个媒体业务的媒体数据的操作。 21、 根据权利要求 20 所述的被请求方设备， 其特征在于， 所述接收单 元接收的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所 述媒体业务对应的媒体信息。 22、 根据权利要求 20或 21所述的被请求方设备， 其特征在于， 所述协 商单元具体用于 确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所 述业务请求消息的联系方头域中的特征标签的数量； 如果所述业务信息的数量与所述特征标签的数量相等， 根据所述被请求 方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的 与每个所述媒体业务对应的媒体信息， 协商出所述请求方设备和所述被请求 方设备均支持的与所述每个所述媒体业务对应的媒体信息， 作为所述协商结 果； 或者 如果所述业务信息的数量与所述特征标签的数量不相等， 判断所述特征 标签所指示的业务是否没有包含相同的媒体类型； 如果所述特征标签所指示 的业务没有包含相同的媒体类型， 根据所述请求方设备支持的每个所述媒体 业务的媒体类型 , 确定所述请求方设备支持的每个所述媒体业务的媒体类型 对应的媒体信息， 根据所述被请求方设备支持的与每个所述媒体业务对应的 媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息， 协 商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务 对应的媒体信息， 作为所述协商结果。 23、 根据权利要求 20~22任一权利要求所述的被请求方设备， 其特征在 于， 所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每 个所述媒体业务对应的媒体信息； 所述处理单元具体用于 根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息， 与所述请求方设备传输所述至少两个媒体业务的媒体 数据。 24、 根据权利要求 20~22任一权利要求所述的被请求方设备， 其特征在 于， 所述协商结果为协商失败信息； 所述处理单元具体用于 根据所述协商失败信息， 不执行与所述请求方设备传输所述至少两个媒 体业务的媒体数据的操作。 25、 根据权利要求 20~24任一权利要求所述的被请求方设备， 其特征在 于， 所述接收单元接收的所述业务请求消息包括 SIP 消息、 HTTP 消息或 XMPP消息； 所述发送单元发送的所述业务响应消息包括 SIP 消息、 HTTP 消息或 XMPP消息。 26、 根据权利要求 20~25任一权利要求所述的被请求方设备， 其特征在 于， 所述接收单元还用于 接收所述请求方设备发送的业务能力查询请求消息， 以及将所述业务能 力查询请求消息传输给所述发送单元， 所述业务能力查询请求消息的消息体 中包含所述请求方设备支持的每个所述媒体业务； 所述发送单元还用于 根据所述业务能力查询请求消息， 向所述请求方设备发送业务能力查询 响应消息， 所述业务能力查询响应消息中包含所述被请求方设备支持的与每 个所述媒体业务对应的媒体信息， 以使得所述请求方设备根据所述被请求方 设备支持的与每个所述媒体业务对应的媒体信息， 向被请求方设备发送所述 业务请求消息。 27、 一种请求方设备， 其特征在于， 包括： 发送器， 用于向被请求方设备发送业务请求消息， 所述业务请求消息用 以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持的 与每个所述媒体业务对应的媒体信息； 接收器， 用于接收所述被请求方设备发送的业务响应消息， 以及将所述 业务响应消息传输给处理器， 所述业务响应消息中包含所述被请求方设备根 据所述请求方设备支持的与每个所述媒体业务对应的媒体信息和所述被请求 方设备支持的与每个所述媒体业务对应的媒体信息 , 进行媒体协商获得的协 商结果； 所述处理器， 用于根据所述协商结果， 执行或不执行与所述被请求方设 备传输所述至少两个媒体业务的媒体数据的操作。 28、 根据权利要求 27 所述的请求方设备， 其特征在于， 所述发送器发 送的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述媒 体业务对应的媒体信息。 29、 根据权利要求 27或 28所述的请求方设备， 其特征在于， 所述协商 结果为所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业 务对应的媒体信息； 所述处理器具体用于 根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息， 与所述被请求方设备传输所述至少两个媒体业务的媒 体数据。 30、 根据权利要求 27或 29所述的请求方设备， 其特征在于， 所述协商 结果为协商失败信息； 所述处理器具体用于 根据所述协商失败信息， 不执行与所述被请求方设备传输所述至少两个 媒体业务的媒体数据的操作。 31、根据权利要求 27~30任一权利要求所述的请求方设备，其特征在于， 所述发送器发送的所述业务请求消息包括 SIP消息、 HTTP消息或 XMPP 消息； 所述接收器接收的所述业务响应消息包括 SIP消息、 HTTP消息或 XMPP 消息。 32、根据权利要求 27~31任一权利要求所述的请求方设备，其特征在于， 所述发送器还用于 向所述被请求方设备发送业务能力查询请求消息， 所述业务能力查询请 求消息的消息体中包含所述请求方设备支持的每个所述媒体业务； 所述接收器还用于 接收所述被请求方设备根据所述业务能力查询请求消息发送的业务能力 查询响应消息， 所述业务能力查询响应消息中包含所述被请求方设备支持的 与每个所述媒体业务对应的媒体信息， 以及将所述被请求方设备支持的与每 个所述媒体业务对应的媒体信息传输给所述发送器； 所述发送器具体用于 根据所述被请求方设备支持的与每个所述媒体业务对应的媒体信息， 向 被请求方设备发送所述业务请求消息。 33、 一种被请求方设备， 其特征在于， 包括： 接收器， 用于接收请求方设备发送的业务请求消息， 以及将所述业务请 求消息传输给处理器， 所述业务请求消息用以指示至少两个媒体业务， 所述 业务请求消息中包含所述请求方设备支持的与每个所述媒体业务对应的媒体 信息； 所述处理器， 用于根据所述请求方设备支持的与每个所述媒体业务对应 的媒体信息和所述被请求方设备支持的与每个所述媒体业务对应的媒体信 息， 进行媒体协商， 以获得协商结果， 以及将所述协商结果传输给发送器； 所述发送器， 用于向所述请求方设备发送业务响应消息， 所述业务响应 消息中包含所述协商结果； 所述处理器， 还用于根据所述协商结果， 执行或不执行与所述请求方设 备传输所述至少两个媒体业务的媒体数据的操作。 34、 根据权利要求 33 所述的被请求方设备， 其特征在于， 所述接收器 接收的所述业务请求消息的消息体中包含所述请求方设备支持的与每个所述 媒体业务对应的媒体信息。 35、 根据权利要求 33或 34所述的被请求方设备， 其特征在于， 所述处 理器具体用于 确定所述业务请求消息所包含的媒体信息中描述的业务信息的数量和所 述业务请求消息的联系方头域中的特征标签的数量； 如果所述业务信息的数量与所述特征标签的数量相等， 根据所述被请求 方设备支持的与每个所述媒体业务对应的媒体信息和所述请求方设备支持的 与每个所述媒体业务对应的媒体信息， 协商出所述请求方设备和所述被请求 方设备均支持的与所述每个所述媒体业务对应的媒体信息， 作为所述协商结 果； 或者 如果所述业务信息的数量与所述特征标签的数量不相等， 判断所述特征 标签所指示的业务是否没有包含相同的媒体类型； 如果所述特征标签所指示 的业务没有包含相同的媒体类型， 根据所述请求方设备支持的每个所述媒体 业务的媒体类型 , 确定所述请求方设备支持的每个所述媒体业务的媒体类型 对应的媒体信息， 根据所述被请求方设备支持的与每个所述媒体业务对应的 媒体信息和所述请求方设备支持的与每个所述媒体业务对应的媒体信息， 协 商出所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体业务 对应的媒体信息， 作为所述协商结果。 36、 根据权利要求 33~35任一权利要求所述的被请求方设备， 其特征在 于， 所述协商结果为所述请求方设备和所述被请求方设备均支持的与所述每 个所述媒体业务对应的媒体信息； 所述处理器具体用于 根据所述请求方设备和所述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息， 与所述请求方设备传输所述至少两个媒体业务的媒体 数据。 37、 根据权利要求 33~35任一权利要求所述的被请求方设备， 其特征在 于， 所述协商结果为协商失败信息； 所述处理器具体用于 根据所述协商失败信息， 不执行与所述请求方设备传输所述至少两个媒 体业务的媒体数据的操作。 38、 根据权利要求 33~37任一权利要求所述的被请求方设备， 其特征在 于， 所述接收器接收的所述业务请求消息包括 SIP消息、 HTTP消息或 XMPP 消息； 所述发送器发送的所述业务响应消息包括 SIP消息、 HTTP消息或 XMPP 消息。 39、 根据权利要求 33~38任一权利要求所述的被请求方设备， 其特征在 于， 所述接收器还用于 接收所述请求方设备发送的业务能力查询请求消息， 以及将所述业务能 力查询请求消息传输给所述发送器， 所述业务能力查询请求消息的消息体中 包含所述请求方设备支持的每个所述媒体业务； 所述发送器还用于 根据所述业务能力查询请求消息， 向所述请求方设备发送业务能力查询 响应消息， 所述业务能力查询响应消息中包含所述被请求方设备支持的与每 个所述媒体业务对应的媒体信息， 以使得所述请求方设备根据所述被请求方 设备支持的与每个所述媒体业务对应的媒体信息， 向被请求方设备发送所述 业务请求消息。 |
技术领域
本申请涉及电信和互联网通信技术，尤其涉及 媒体数据传输方法及设备。 背景技术
现有技术中， 请求方设备与被请求方设备在同一个会话中， 可以发起多 个媒体业务。 请求方设备与被请求方设备通过进行媒体协商 ， 可以传输每个 媒体业务的媒体数据， 以建立对应的媒体通道， 完成每个媒体业务。 例如， 富通信套件（ Rich Communication Suite, RCS )是一种以地址簿为基础， 提供包括即时消息、 文件传输、 视频通话、 视频共享等多种功能的业务集合。 根据当前的会话描述协议 ( Session Description Protocol, 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 的实时通信 ( WEB Real Time Communication ,
WEBRTC ) 中的应用或业务能力发现中的应用等。
另外， 本文中术语"和 /或"， 仅仅是一种描述关联对象的关联关系， 表示 可以存在三种关系， 例如， A和 /或 B, 可以表示： 单独存在 A, 同时存在 A 和 B, 单独存在 B这三种情况。 另外， 本文中字符' 7", —般表示前后关联对 象是一种"或"的关系。
图 1 为本申请一实施例提供的媒体数据传输方法的 流程示意图， 如图 1 所示。
101、请求方设备向被请求方设备发送业务请求 消息，所述业务请求消息 用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持 的与每个所述媒体业务对应的媒体信息。
102、所述请求方设备接收所述被请求方设备发 送的业务响应消息，所述 业务响应消息中包含所述被请求方设备根据所 述请求方设备支持的与每个所 述媒体业务对应的媒体信息和所述被请求方设 备支持的与每个所述媒体业务 对应的媒体信息， 进行媒体协商获得的协商结果。
103、所述请求方设备根据所述协商结果，执行 或不执行与所述被请求方 设备传输所述至少两个媒体业务的媒体数据的 操作。
其中， 所述媒体信息包括媒体流接收的地址和端口号 、 媒体流的采样频 率以及编码格式 （如 H.323、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.323或实 时传输协议 ( Real-Time Transport Protocol, RTP )等）等信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息的消 息体中可以包含所述请求方设备支持的与每个 所述媒体业务对应的媒体信
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中， 所述业务请求消息可以包括但不限于会话初始 化协议（Session Initiation Protocol, SIP )消息、超文体传输协议（ Hypertext Transfer Protocol, HTTP )消息或 ( Extensible Messaging and Presence Protocol, XMPP )消 息； 相应地， 所述业务响应消息可以包括但不限于 SIP消息、 HTTP消息或 XMPP消息。
可选地， 在本实施例的一个可能的实现方式中， 具体可以在所述业务请 求消息的消息体（即 SDP信息）中增加标识媒体业务的参数 "a=: ，，行。 具 体地， 可以为 a=feature tag:或 a=service:等形式， 其取值可以唯一标识一个 媒体业务。 其后的其他媒体行则可以表示所述请求方设备 支持的该媒体业务 对应的媒体信息。
例如， SDP信息可以采用纯文本形式进行描述， 那么， 所述业务请求消 息的 SDP信息可以为如下形式：
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" m=video 49176 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'， m=video 49178 RTP/AVP 31 32
a=rtpmap:31 H264/90000
a=rtpmap:32 VP8/90000
该 SDP 信 息 中 包 括 了 两 个 媒 体 业 务 ， 分 别 是 urn:urn-7:3gpp-application.ims.iari.gsma-vs ( 3GPP 定义的视频共享业务 VS: Video Share )和 um:um-7:3gpp-service.ims.icsi.mmtel.video ( 3GPP 定义的视频通话业务）。在视频共享业务中， 视频流所使用的端口号为 49176, 传输协议为 RTP,可选的编码格式有两种，一种是 H261 (采样频率为 90000), 另一种是 MPV (采样频率为 90000)。 在视频通话业务中， 视频流所使用的端 口号为 49178, 传输协议为 RTP, 可选的编码格式有两种， 一种是 H264(采 样频率为 90000), 另一种是 VP8(采样频率为 90000) 再例如， SDP信息可以采用 JSON ( JavaScript Object Notation )格式 进行描述， 那么， 所述业务请求消息的 SDP信息可以为如下形式：
"SDP"： [7n
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" In
m=video 49170 RTP/AVP 31 32 /n
a=rtpmap:31 H261/90000 /n
a=rtpmap:32 MPV/90000 /n
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'， In
m=video 49172 RTP/AVP 33 34 /n
a=rtpmap:33 H264/60000 /n
a=rtpmap:34 VP8/60000 /n
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel" In m=audio 49174 RTP/AVP 0 8 97 /n
a=rtpmap:0 PCMU/8000 /n
a=rtpmap:8 PCMA/8000 /n
a=rtpmap:97 iLBC/8000 /n"]
该 SDP信息中包括了三个媒体业务（ 2个视频媒体业务和 1个音频媒体 业务） ， 分别是 um:um-7:3gpp-application.ims.iari.gsma-vs ( 3GPP定义的 视 频 共 享 业 务 VS ： Video Share ) 、 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), 第二种是 PCM A (采样频率为 8000), 第三种是 iLBC (采样频率 为 8000)。 从上述例中可以看出， 媒体信息按照媒体业务进行了分隔， 这样则可以 对每个媒体业务对应的媒体信息进行分别描述 ， 即每个 a=feature tag:行后的 媒体信息均是针对于某一特定媒体业务， 由 a=feature tag的取值来标识该媒 体业务。
可选地， 在本实施例的一个可能的实现方式中， 具体可以在所述业务请 求消息的消息体包含多个部分即每一个部分可 以对应一个 SDP信息， 每个 SDP信息对应一个媒体业务对应的媒体信息， 各个 SDP信息可以通过分隔 符隔开。
例如， 所述业务请求消息的多个 SDP信息可以为如下形式：
INVITE sip:to@192.168.105.14 SIP/2.0
From: <sip:from@192.168.105.5>;tag=29244
To: <sip:to@192.168.105.14>
Call-ID: 8103
CSeq: 20 INVITE
Contact: <sip:from@192.168.105.5:5060>; feature tag =
+g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsm a-vs",
+g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.v ideo"
Content-Type: multipart/application; boundary:" -— 000_0009_01 CD06B0.D0D652D0"
—— 000_0009_01 CD06B0.D0D652D0
Content-Type: application/sdp;
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s ; m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 —— 000_0009_01 CD06B0.D0D652D0
Content-Type: application/sdp;
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o" /n m=audio 49172 RTP/AVP 0 8 97 /n
a=rtpmap:0 PCMU/8000 /n
a=rtpmap:8 PCMA/8000 /n
a=rtpmap:97 iLBC/8000 /n
从上述例中可以看出， Content-Type的值是 multipart/application, 表示 消 息 体 中 包 括 多 个 部 分 ， 各 部 分 间 的 分 隔 符 为"—— 000_0009_01 CD06B0.D0D652D0"。 在每一部分前由分隔符开始， 并指出本部分的类型是 application/sdp, 即 SDP信息描述。 可选地， 消息体 中各部分的顺序可以与 Contact头域中 Feature Tag的顺序——对应。 如果 各部分的顺序与 Contact头域中 Feature Tag的顺序不一致， 例如消息体中 的第一部分对应第二个 Feature Tag中的媒体业务， 则需要在每个部分中增 加相应的业务标识进行区分。 例如， 增加标识媒体业务的 "a=: " 行。 具体 地， 可以为 a=feature tag:或 a=service:等形式， 其取值可以唯一标识一个媒 体业务。 其后的其他媒体行则可以表示所述请求方设备 支持的该媒体业务对 应的媒体信息。
具体地， 所述被请求方设备具体可以根据所述业务请求 消息的联系方 ( contact )头域中的特征标签（ Feature Tag ) , 判断所述业务请求消息是否 为多业务请求。 首先， 所述被请求方设备可以确定所述业务请求消息 所包含 的媒体信息中描述的业务信息的数量和所述业 务请求消息的联系方头域中的 特征标签的数量；如果所述业务请求消息为多 业务请求（即请求消息 Contact 头域中的特征标签 Feature Tag的数量大于 1个） ， 则判断媒体信息中描述 的业务信息的数量（即 a=Feature Tag的数量）是否与所述联系方（ contact ) 头域中的特征标签（ Feature Tag )的数量相等。 如果所述业务请求消息不为 多业务请求（即特征标签的数量为 1 ) ， 则执行按照现有技术中的流程， 此 处不再赘述。 如果所述媒体信息 （即所述请求方设备支持的与每个所述媒体 业务对应的媒体信息） 中描述的业务信息的数量与所述请求消息中联 系方 ( contact )头域中的特征标签（ Feature Tag )的数量相等， 所述被请求方设 备则可以根据所述被请求方设备支持的与每个 所述媒体业务对应的媒体信息 和所述请求方设备支持的与每个所述媒体业务 对应的媒体信息， 协商出与每 个所述媒体业务对应的媒体信息发送给所述请 求方设备。 如果所述媒体信息 (即所述请求方设备支持的与每个所述媒体业 对应的媒体信息） 中描述的 业务信息的数量与所述请求消息中联系方 （contact ) 头域中的特征标签 ( Feature Tag )的数量不相等， 所述被请求方设备则再判断所述业务请求消 息中所请求的多个媒体业务是否具有相同的媒 体类型 （例如， 被请求方设备 具体可以根据特征标签， 判断多个媒体业务是否具有相同的媒体类型， 例如： 是否均为视频业务， 或均为音频业务， 或者包括均包括视频和音频业务） 。 如果是， 所述被请求方设备则向请求方设备返回错误响 应。 否则， 所述被请 求方设备则可以根据所述请求方设备支持的每 个所述媒体业务的媒体类型， 确定所述媒体类型对应的媒体信息， 所述被请求方设备则可以根据所述被请 求方设备支持的与每个所述媒体业务对应的媒 体信息和所述请求方设备支持 的与每个所述媒体业务对应的媒体信息， 协商出与每个所述媒体业务对应的 媒体信息发送给所述请求方设备。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为所述请求方设备和所述被请求方设备均支持 的与所述每个所述媒体业务对 应的媒体信息。 例如， 所述业务响应消息的消息体中可以包含所述协 商结果。 具体地， 所述业务响应消息的消息体（SDP信息）的详细 描述可以参见所述 业务请求消息的相关内容， 此处不再赘述。
相应地， 在 103中， 所述请求方设备具体则可以根据所述请求方设 备和 所述被请求方设备均支持的与所述每个所述媒 体业务对应的媒体信息， 与所 述被请求方设备传输所述至少两个媒体业务的 媒体数据。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为协商失败信息。 例如， 所述协商结果为协商失败信息的场景， 可以包括但 不限于以下场景：
场景 1、 被请求方设备接收到业务请求消息之后， 判断该业务请求消息 所请求的媒体业务中至少有一种媒体业务该被 请求方设备不支持， 则向请求 方设备返回所述协商失败信息。 例如， 请求方设备请求视频通话业务和视频 共享业务， 但被请求方设备不支持视频通话业务。
场景 2、 被请求方设备接收到业务请求消息之后， 判断该业务请求消息 所请求的媒体业务对应的全部编码格式该被请 求方设备不支持， 则向请求方 设备返回所述协商失败信息。例如，请求方设 备请求视频通话业务对应的 VP8 或 H.264两种编码格式， 但被请求方设备只支持视频通话业务的 H.261编码 格式。
场景 3、 被请求方设备根据用户设置或指示拒绝请求方 设备所请求的多 个媒体业务。
相应地，在 103中，所述请求方设备具体则可以根据所述协 商失败信息， 不执行与所述被请求方设备传输所述至少两个 媒体业务的媒体数据的操作。
可选地， 在本实施例的一个可能的实现方式中， 在 101之前， 所述请求 方设备还可以进一步向所述被请求方设备发送 业务能力查询请求消息。其中， 所述业务能力查询请求消息的消息体中包含所 述请求方设备支持的每个所述 媒体业务。 然后， 所述请求方设备则可以接收所述被请求方设备 根据所述业 务能力查询请求消息发送的业务能力查询响应 消息。 其中， 所述业务能力查 询响应消息中包含所述被请求方设备支持的与 每个所述媒体业务对应的媒体 信息。
相应地， 在 101 中， 所述请求方设备具体可以根据所述被请求方设 备支 持的与每个所述媒体业务对应的媒体信息， 向被请求方设备发送所述业务请 求消息。
本实施例提供的技术方案可以适用于多种应用 中， 例如， 多业务会话邀 请中的应用、 基于 WEB 的实时通信 ( WEB Real Time Communication, WEBRTC ) 中的应用或业务能力发现中的应用等。
例如， 在多业务会话邀请中的应用中， 即请求方设备向被请求方设备发 起视频共享业务和视频通话业务的多业务会话 邀请。 本实施例中，
" a=feature tag" 的 取值可 以 唯一标识媒体业 务 ， 例 如 ， +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s 代表视频共享业务 , +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o代表视频通话业务； " a=featu re tag"后面的媒体描述行中的信息则为该媒体业 对应的媒体信 息， 包括但不限于 m=行、 a=行等。
具体地，请求方设备向被请求方设备发送的业 务请求消息可以如下所示： INVITE sip:to@192.168.105.14 SIP/2.0
From: <sip:from@192.168.105.5>;tag=29244
To: <sip:to@192.168.105.14>； tag=87963
Call-ID: 8103
CSeq: 20 INVITE
Contact: <sip:from@192.168.105.5:5060>; feature tag =
+g gpp.ian-ref="urn:urn-7:3gpp-application.ims.iari.gsma-vs",
+g.3gppjari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vi deo"
Content-Type: application/sdp
Content-Length: 299 a=feature tag: +g.3gpp.iari-ref=''urn:urn-7:3gpp-application.ims.iari.gsma- vs" m=video 49176 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=feature tag: +g.3gpp.iari-ref="um:um-7:3gpp-service.ims.icsi.mmtel.video" m=video 49178 RTP/AVP 31 32
a=rtpmap:31 H264/90000
a=rtpmap:32 VP8/90000
被请求方设备接收业务请求消息， 首先则可以通过解析所述业务请求消 息的头域， 从而确定邀请中所包含哪些媒体业务， 根据被请求方情况确定是 否支持请求方设备所希望发起的媒体业务， 如果支持， 则可以继续解析所述 业务请求消息的 SDP信息， 并向请求方返回多业务会话响应消息； 如果不支 持， 则向请求方返回错误响应， 表示不支持某种媒体业务。
该多业务会话响应消息可以如下所示：
SIP/2.0 200 OK
From: <sip:from@192.168.105.5>;tag=29244
To: <sip:to@192.168.105.14>
Call-ID: 8103
CSeq: 20 INVITE
Contact: <sip:from@192.168.105.5:5060>; feature tag =
+g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsm a-vs",
+g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.v ideo"
Content-Type: application/sdp
Content-Length: 288 v=0
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" m=video 49176 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'， m=video 49178 RTP/AVP 31 32
a=rtpmap:31 H264/90000
a=rtpmap:32 VP8/90000
可以看出， 以上多业务会话响应消息表示被请求方设备接 收邀请， 该多 业务会话响应消息中包含协商出的与每个所述 媒体业务对应的媒体信息。 其 中， 由于被请求方设备不支持视频共享业务对应的 音乐图片视频 （Music Photo Video, MPV )编码， 因此， 在所述业务响应消息并没有包含视频共享 业务对应的 MPV编码， 说明被请求方设备不支持 MPV编码。
请求方接收业务响应消息， 至此， 请求方设备则可以根据所述业务响应 消息， 执行与被请求方设备建立视频共享业务的媒体 通道和视频通话业务的 媒体通道的操作。
例如， 在 WEBRTC 中的应用中， 即请求方设备向被请求方设备发起屏 幕共享业务和视频通话业务的 HTTP请求。 本实施例中， "a=feature tag"的 取值可以唯一标识媒体业务， 具体可以由开发者统一设置业务标识以唯一标 识媒体业务， 例如， screen-share代表视频共享业务， video-call代表视频通话 业务； "a=feature tag"后面的描述信息则为该媒体业务对应的媒 信息。
具体地， 请求方设备首先可以根据自身情况设置请求方 SDP ( Local-SDP ) 为：
a=feature tag: screen-share
m=video 49170 RTP/AVP 31
a=rtpmap:31 VP8/90000
a=feature tag: video-call
m=video 49172 RTP/AVP 34
a=rtpmap:34 H264/90000
然后， 请求方设备向被请求方设备发送的 HTTP请求消息具体可以包括 请求方设备设置的请求方 SDP ( Local-SDP ) 。
被请求方设备接收 HTTP请求消息， 判断是否支持相应的业务（即 SDP 信息中所描述的 screen-share和 screen-video业务）， 如果支持， 被请求方 设备则可以设置请求方 SDP ( Remote-SDP ) 为：
a=feature tag: screen-share
m=video 49170 RTP/AVP 31
a=rtpmap:31 VP8/90000
a=feature tag: video-call
m=video 49172 RTP/AVP 34
a=rtpmap:34 H264/90000
然后， 被请求方设备根据自身情况设置被请求方的 SDP ( Local-SDP ) 为：
a=feature tag: screen-share
m=video 3566 RTP/AVP 31
a=rtpmap:31 VP8/90000 a=feature tag: video-call
m=video 3568 RTP/AVP 34
a=rtpmap:34 H264/90000
然后， 被请求方设备向请求方设备发送的 HTTP响应消息， 具体可以包 括被请求方设备设置的被请求方的 SDP ( Local-SDP ) 。
请求方设备接收 HTTP 响应消息， 则可以设置被请求方的 SDP ( Remote-SDP ) 为：
a=feature tag: screen-share
m=video 3566 RTP/AVP 31
a=rtpmap:31 VP8/90000
a=feature tag: video-call
m=video 3568 RTP/AVP 34
a=rtpmap:34 H264/90000
至此， 请求方设备则可以根据所述 HTTP响应消息， 执行与被请求方设 备建立屏幕共享业务的媒体通道和视频通话业 务的媒体通道的操作。
例如， 在业务能力发现中的应用 （例如， 请求方设备上线时， 向所有好 友发起业务能力发现， 或者请求方设备想与某好友进行通话之前， 向该好友 发起业务能力发现等） 中， 即请求方设备与被请求方设备通过提供 /应答 ( OFFER/ANSWER )机制， 获取被请求方设备当前所支持的媒体业务对应 的媒体信息。 本实施例中， "a=feature tag"的取值可以唯一标识媒体业务， 例如, +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s代表视频共享业 务 , +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o代表视频通话业 务； "a=feature tag"后面的描述信息则为该媒体业务对应的媒 信息。
具体地， 请求方设备向被请求方设备发送的用以查询业 务能力的 SIP选 项 （SIP OPTIONS )请求消息可以如下所示：
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>; feature tag =
+g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsm a-vs",
+g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.v ideo"
Accept: application/sdp
Content-Length: 0
被请求方设备接收 S I P选项请求消息， 该 S I P选项请求消息中包含请求 方设备的标识， 进一步可以包含请求方设备所支持的媒体业务 。 被请求方设 备根据所述 SIP选项请求消息，向请求方设备返回 SIP选项响应消息，该 SIP 选项响应消息可以如下所示：
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received=192.0.2. 4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710n
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>; feature tag =
+g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsm a-vs",
+g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.v ideo"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 31 1 v=0 a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" m=video 49176 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'， m=video 49178 RTP/AVP 31 32
a=rtpmap:31 H264/90000
a=rtpmap:32 VP8/90000
请求方设备接收 SIP选项响应消息， 该 SIP选项响应消息中包含被请求 方设备的标识和被请求方设备所支持的媒体业 务， 至此， 请求方设备则可以 根据所述 SIP选项响应消息， 获取所述被请求方设备所支持的媒体业务对应 的媒体信息。
进一步地， 还可以进一步在请求方设备向被请求方设备发 送的 SIP选项 ( SIP OPTIONS )请求消息中增加一个头域， 例如 Answer-SDP-Needed头 域， 表示是否需要被请求方设备在返回的 SIP选项响应消息中包含所述被请 求方设备所支持的媒体业务对应的媒体信息。 具体地， 请求方设备向被请求 方设备发送的 SIP选项 （SIP OPTIONS )请求消息还可以如下所示：
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Answer-SDP-Needed: yes
Content-Length: 0
新增加的 Answer-SDP-Needed头域， 其取值为 yes时， 表示需要被请 求方在返回的 SIP选项响应消息中包含所述被请求方所支持的 媒体业务对应 的媒体信息； 其取值为 no时， 表示不需要被请求方在返回的 SIP选项响应 消息中包含所述被请求方所支持的媒体业务对 应的媒体信息。
本实施例中， 由于请求方设备与被请求方设备之间传输的媒 体信息是与 所述请求方设备或所述被请求方设备支持的每 个媒体业务分别对应的， 因此， 当请求方设备发起媒体类型相同的多个媒体业 务， 且请求方设备与被请求方 设备所支持的每个媒体业务的媒体信息不相同 时， 能够实现请求方设备与被 请求方设备进行所述多个媒体业务的媒体数据 的传输， 以建立对应的媒体通 道， 完成每个媒体业务。
图 2为本申请另一实施例提供的媒体数据传输方 的流程示意图， 如图 2所示。
201、被请求方设备接收请求方设备发送的业务 请求消息，所述业务请求 消息用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备 支持的与每个所述媒体业务对应的媒体信息。
202、所述被请求方设备根据所述请求方设备支 持的与每个所述媒体业务 对应的媒体信息和所述被请求方设备支持的与 每个所述媒体业务对应的媒体 信息， 进行媒体协商， 以获得协商结果。
203、所述被请求方设备向所述请求方设备发送 业务响应消息，所述业务 响应消息中包含所述协商结果。
204、所述被请求方设备根据所述协商结果，执 行或不执行与所述请求方 设备传输所述至少两个媒体业务的媒体数据的 操作。
也就是说， 所述请求方设备接收到所述业务响应消息之后 ， 可以根据所 述协商结果， 向所述被请求方设备发起或者不向所述被请求 方设备发起所述 至少两个媒体业务的媒体数据的传输； 相应地， 所述被请求方设备则可以根 据所述协商结果， 响应或者不再响应所述至少两个媒体业务的媒 体数据的传 输。
其中， 所述媒体信息包括媒体流接收的地址和端口号 、 媒体流的采样频 率以及编码格式 （如 H.323、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.323或实 时传输协议 ( Real-Time Transport Protocol, RTP )等）等信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息的消 息体中可以包含所述请求方设备支持的与每个 所述媒体业务对应的媒体信 自
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中， 所述业务请求消息可以包括但不限于会话初始 化协议（Session Initiation Protocol , SIP )消息、超文体传输协议（ Hypertext Transfer Protocol , HTTP )消息或 ( Extensible Messaging and Presence Protocol, XMPP )消 息； 相应地， 所述业务响应消息可以包括但不限于 SIP消息、 HTTP消息或 XMPP消息。
可选地， 在本实施例的一个可能的实现方式中， 具体可以在所述业务请 求消息的消息体（即 SDP信息 )中增加标识媒体业务的参数 "a=: ，，行。 具 体地， 可以为 a=feature tag:或 a=service:等形式， 其取值可以唯一标识一个 媒体业务。 其后的其他媒体行则可以表示所述请求方设备 支持的该媒体业务 对应的媒体信息。
例如， SDP信息可以采用纯文本形式进行描述， 那么， 所述业务请求消 息的 SDP信息可以为如下形式：
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" m=video 49176 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'， m=video 49178 RTP/AVP 31 32
a=rtpmap:31 H264/90000
a=rtpmap:32 VP8/90000
该 SDP 信 息 中 包 括 了 两 个 媒 体 业 务 ， 分 别 是 urn:urn-7:3gpp-application.ims.iari.gsma-vs ( 3GPP 定义的视频共享业务 VS: Video Share )和 um:um-7:3gpp-service.ims.icsi.mmtel.video ( 3GPP 定义的视频通话业务）。在视频共享业务中， 视频流所使用的端口号为 49176, 传输协议为 RTP,可选的编码格式有两种，一种是 H261 (采样频率为 90000), 另一种是 MPV (采样频率为 90000)。 在视频通话业务中， 视频流所使用的端 口号为 49178, 传输协议为 RTP, 可选的编码格式有两种， 一种是 H264(采 样频率为 90000), 另一种是 VP8(采样频率为 90000) 再例如， SDP信息可以采用 JSON ( JavaScript Object Notation )格式 进行描述， 那么， 所述业务请求消息的 SDP信息可以为如下形式：
"SDP"： [7n
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s"
In
m=video 49170 RTP/AVP 31 32 /n
a=rtpmap:31 H261/90000 /n
a=rtpmap:32 MPV/90000 /n
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o'，
In
m=video 49172 RTP/AVP 33 34 /n
a=rtpmap:33 H264/60000 /n
a=rtpmap:34 VP8/60000 In
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel" In m=audio 49174 RTP/AVP 0 8 97 /n
a=rtpmap:0 PCMU/8000 /n
a=rtpmap:8 PCMA/8000 /n
a=rtpmap:97 iLBC/8000 /n"]
该 SDP信息中包括了三个媒体业务（ 2个视频媒体业务和 1个音频媒体 业务 ) , 分别是 urn:urn-7:3gpp-application.ims.iari.gsma-vs ( 3GPP定义的 视 频 共 享 业 务 VS ： Video Share ) 、 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), 第二种是 PCM A (采样频率为 8000), 第三种是 iLBC (采样频率 为 8000)。 从上述例中可以看出， 媒体信息按照媒体业务进行了分隔， 这样则可以 对每个媒体业务对应的媒体信息进行分别描述 ， 即每个 a=feature tag:行后的 媒体信息均是针对于某一特定媒体业务， 由 a=feature tag的取值来标识该媒 体业务。
可选地， 在本实施例的一个可能的实现方式中， 具体可以在所述业务请 求消息的消息体包含多个部分即一个部分可以 对应一个 SDP信息，每个 SDP 信息对应一个媒体业务对应的媒体信息， 各个 SDP信息可以通过分隔符隔 开。
例如， 所述业务请求消息的多个 SDP信息可以为如下形式：
INVITE sip:to@192.168.105.14 SIP/2.0
From: <sip:from@192.168.105.5>;tag=29244
To: <sip:to@192.168.105.14>
Call-ID: 8103
CSeq: 20 INVITE
Contact: <sip:from@192.168.105.5:5060>; feature tag = +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s",
+g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.v ideo"
Content-Type: multipart/application; boundary:" -— 000_0009_01 CD06B0.D0D652D0"
000 0009 01 CD06B0.D0D652D0 Content-Type: application/sdp;
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-application.ims.iari.gsma-v s" m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
—— 000_0009_01 CD06B0.D0D652D0
Content-Type: application/sdp;
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
a=feature tag: +g.3gpp.iari-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel.vide o" /n m=audio 49172 RTP/AVP 0 8 97 /n
a=rtpmap:0 PCMU/8000 /n
a=rtpmap:8 PCMA/8000 /n
a=rtpmap:97 iLBC/8000 /n
从上述例中可以看出， Content-Type的值是 multipart/application, 表示 消 息 体 中 包 括 多 个 部 分 ， 各 部 分 间 的 分 隔 符 为"—— 000_0009_01 CD06B0.D0D652D0"。 在每一部分前由分隔符开始， 并指出本部分的类型是 application/sdp, 即 SDP信息描述。 可选地， 消息体 中各部分的顺序可以与 Contact头域中 Feature Tag的顺序——对应。 如果 各部分的顺序与 Contact头域中 Feature Tag的顺序不一致， 例如消息体中 的第一部分对应第二个 Feature Tag中的媒体业务， 则需要在每个部分中增 加相应的业务标识进行区分， 则需要在每个部分中增加相应的业务标识进行 区分。例如，增加标识媒体业务的 "a=: "行。具体地，可以为 a=feature tag: 或 a=service:等形式， 其取值可以唯一标识一个媒体业务。 其后的其他媒体 行则可以表示所述请求方设备支持的该媒体业 务对应的媒体信息。
具体地， 在 202中， 所述被请求方设备具体可以根据所述业务请求 消息 的联系方（contact )头域中的特征标签（Feature Tag ) , 判断所述业务请求 消息是否为多业务请求。 如果所述业务请求消息为多业务请求（即特征 标签 的数量不为 1 ) , 则判断媒体信息的数量是否与所述特征标签的 数量相等。 如果所述业务请求消息不为多业务请求（即特 征标签的数量为 1 ) , 则执行 按照现有技术中的流程， 此处不再赘述。 如果所述媒体信息 （即所述请求方 设备支持的与每个所述媒体业务对应的媒体信 息） 的数量与所述特征标签的 数量相等， 所述被请求方设备则可以根据所述被请求方设 备支持的与每个所 述媒体业务对应的媒体信息和所述请求方设备 支持的与每个所述媒体业务对 应的媒体信息 , 协商出与每个所述媒体业务对应的媒体信息发 送给所述请求 方设备。 如果所述媒体信息 （即所述请求方设备支持的与每个所述媒体业 务 对应的媒体信息） 的数量与所述特征标签的数量不相等， 所述被请求方设备 则再判断所述业务请求消息中所请求的多个媒 体业务是否具有相同的媒体类 型 （例如， 被请求方设备具体可以根据特征标签， 判断多个媒体业务是否具 有相同的媒体类型） 。 如果是， 所述被请求方设备则向请求方设备返回错误 响应。 否则， 所述被请求方设备则可以根据所述请求方设备 支持的每个所述 媒体业务的媒体类型， 确定所述媒体类型对应的媒体信息， 所述被请求方设 备则可以根据所述被请求方设备支持的与每个 所述媒体业务对应的媒体信息 和所述请求方设备支持的与每个所述媒体业务 对应的媒体信息， 协商出与每 个所述媒体业务对应的媒体信息发送给所述请 求方设备。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为所述请求方设备和所述被请求方设备均支持 的与所述每个所述媒体业务对 应的媒体信息。 例如， 所述业务响应消息的消息体中可以包含所述协 商结果。 具体地， 所述业务响应消息的消息体（SDP信息）的详细 描述可以参见所述 业务请求消息的相关内容， 此处不再赘述。
相应地， 在 204中， 所述被请求方设备具体可以根据所述请求方设 备和 所述被请求方设备均支持的与所述每个所述媒 体业务对应的媒体信息， 与所 述请求方设备传输所述至少两个媒体业务的媒 体数据。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为协商失败信息。 例如， 所述协商结果为协商失败信息的场景， 可以包括但 不限于以下场景：
场景 1、 被请求方设备接收到业务请求消息之后， 判断该业务请求消息 所请求的媒体业务中至少有一种媒体业务该被 请求方设备不支持， 则向请求 方设备返回所述协商失败信息。 例如， 请求方设备请求视频通话业务和视频 共享业务， 但被请求方设备不支持视频通话业务。
场景 2、 被请求方设备接收到业务请求消息之后， 判断该业务请求消息 所请求的媒体业务对应的全部编码格式该被请 求方设备不支持， 则向请求方 设备返回所述协商失败信息。例如，请求方设 备请求视频通话业务对应的 VP8 或 H.264两种编码格式， 但被请求方设备只支持视频通话业务的 H.261编码 格式。
场景 3、 被请求方设备根据用户设置或指示拒绝请求方 设备所请求的多 个媒体业务。
相应地，在 204中，所述被请求方设备具体可以根据所述协 商失败信息， 不执行与所述请求方设备传输所述至少两个媒 体业务的媒体数据的操作。
可选地， 在本实施例的一个可能的实现方式中， 在 201之前， 所述被请 求方设备还可以进一步接收所述请求方设备发 送的业务能力查询请求消息。 其中， 所述业务能力查询请求消息的消息体中包含所 述请求方设备支持的每 个所述媒体业务。 然后， 所述被请求方设备则可以根据所述业务能力查 询请 求消息， 向所述请求方设备发送业务能力查询响应消息 。 其中， 所述业务能 力查询响应消息中包含所述被请求方设备支持 的与每个所述媒体业务对应的 媒体信息， 以使得所述请求方设备根据所述被请求方设备 支持的与每个所述 媒体业务对应的媒体信息， 向被请求方设备发送所述业务请求消息。
本实施例提供的技术方案可以适用于多种应用 中， 例如， 多业务会话邀 请中的应用、 基于 WEB 的实时通信 ( WEB Real Time Communication, WEBRTC )中的应用或业务能力发现中的应用等。 详细描述可以参见图 1对 应的实施例中的相关内容， 此处不再赘述。 本实施例中， 由于请求方设备与被请求方设备之间传输的媒 体信息是与 所述请求方设备或所述被请求方设备支持的每 个媒体业务分别对应的， 因此， 当请求方设备发起媒体类型相同的多个媒体业 务， 且请求方设备与被请求方 设备所支持的每个媒体业务的媒体信息不相同 时， 能够实现请求方设备与被 请求方设备进行所述多个媒体业务的媒体数据 的传输， 以建立对应的媒体通 道， 完成每个媒体业务。
需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表 述为一系列的动作组合， 但是本领域技术人员应该知悉， 本申请并不受所描 述的动作顺序的限制， 因为依据本申请， 某些步骤可以采用其他顺序或者同 时进行。 其次， 本领域技术人员也应该知悉， 说明书中所描述的实施例均属 于优选实施例， 所涉及的动作和模块并不一定是本申请所必须 的。
在上述实施例中， 对各个实施例的描述都各有侧重， 某个实施例中没有 详述的部分， 可以参见其他实施例的相关描述。
图 3为本申请另一实施例提供的请求方设备的结 示意图，如图 3所示， 本实施例的请求方设备可以包括发送单元 31、 接收单元 32和处理单元 33。 其中， 发送单元 31 , 用于向被请求方设备发送业务请求消息， 所述业务请求 消息用以指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备 支持的与每个所述媒体业务对应的媒体信息； 接收单元 32, 用于接收所述被 请求方设备发送的业务响应消息， 以及将所述业务响应消息传输给处理单元 33, 所述业务响应消息中包含所述被请求方设备根 据所述请求方设备支持的 与每个所述媒体业务对应的媒体信息和所述被 请求方设备支持的与每个所述 媒体业务对应的媒体信息，进行媒体协商获得 的协商结果；所述处理单元 33, 用于根据所述协商结果， 执行或不执行与所述被请求方设备传输所述至 少两 个媒体业务的媒体数据的操作。
其中， 所述媒体信息包括媒体流接收的地址和端口号 、 媒体流的采样频 率以及编码格式 （如 H.323、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.323或实 时传输协议（Real-Time Transport Protocol, RTP )等）等信息。 可选地，在本实施例的一个可能的实现方式中 ， 所述发送单元 31发送的 所述业务请求消息的消息体中可以包含所述请 求方设备支持的与每个所述媒 体业务对应的媒体信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中，所述发送单元 31发送的所述业务请求消息可以包括但不限于 话 初始化协议 ( Session Initiation Protocol , SIP ) 消息、 超文体传输协议 ( Hypertext Transfer Protocol, HTTP )消息或 ( Extensible Messaging and Presence Protocol, 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、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.323或实 时传输协议 ( Real-Time Transport Protocol, RTP )等）等信息。
可选地，在本实施例的一个可能的实现方式中 ， 所述接收单元 41接收的 所述业务请求消息的消息体中可以包含所述请 求方设备支持的与每个所述媒 体业务对应的媒体信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中，所述接收单元 41接收的所述业务请求消息可以包括但不限于 话 初始化协议 ( Session Initiation Protocol , SIP ) 消息、 超文体传输协议 ( Hypertext Transfer Protocol, HTTP )消息或 ( Extensible Messaging and Presence Protocol, XMPP )消息； 相应地， 所述发送单元 43发送的所述业 务响应消息可以包括但不限于 SIP消息、 HTTP消息或 XMPP消息。
可选地，在本实施例的一个可能的实现方式中 ， 所述协商单元 42具体可 以确定所述业务请求消息所包含的媒体信息中 描述的业务信息的数量和所述 业务请求消息的联系方头域中的特征标签的数 量； 如果所述业务信息的数量 与所述特征标签的数量相等， 根据所述被请求方设备支持的与每个所述媒体 业务对应的媒体信息和所述请求方设备支持的 与每个所述媒体业务对应的媒 体信息， 协商出所述请求方设备和所述被请求方设备均 支持的与所述每个所 述媒体业务对应的媒体信息， 作为所述协商结果。 或者， 如果所述业务信息 的数量与所述特征标签的数量不相等， 判断所述特征标签所指示的业务是否 没有包含相同的媒体类型； 如果所述特征标签所指示的业务没有包含相同 的 媒体类型， 根据所述请求方设备支持的每个所述媒体业务 的媒体类型， 确定 所述媒体类型对应的媒体信息， 根据所述被请求方设备支持的与每个所述媒 体业务对应的媒体信息和所述请求方设备支持 的与每个所述媒体业务对应的 媒体信息， 协商出所述请求方设备和所述被请求方设备均 支持的与所述每个 所述媒体业务对应的媒体信息， 作为所述协商结果。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为所述请求方设备和所述被请求方设备均支持 的与所述每个所述媒体业务对 应的媒体信息； 相应地， 所述处理单元 44具体可以根据所述请求方设备和所 述被请求方设备均支持的与所述每个所述媒体 业务对应的媒体信息， 与所述 请求方设备传输所述至少两个媒体业务的媒体 数据。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为协商失败信息；相应地，所述处理单元 44具体可以根据所述协商失败信息， 不执行与所述请求方设备传输所述至少两个媒 体业务的媒体数据的操作。 可选地，在本实施例的一个可能的实现方式中 ， 所述接收单元 41还可以 进一步接收所述请求方设备发送的业务能力查 询请求消息， 以及将所述业务 能力查询请求消息传输给所述发送单元 43, 所述业务能力查询请求消息的消 息体中包含所述请求方设备支持的每个所述媒 体业务。所述发送单元 43还可 以进一步根据所述业务能力查询请求消息， 向所述请求方设备发送业务能力 查询响应消息， 所述业务能力查询响应消息中包含所述被请求 方设备支持的 与每个所述媒体业务对应的媒体信息， 以使得所述请求方设备根据所述被请 求方设备支持的与每个所述媒体业务对应的媒 体信息， 向被请求方设备发送 所述业务请求消息。
本实施例提供的请求方设备用于对应执行如图 2所示实施例的方法， 对 于图 2所示实施例已经描述的细节， 此处不再赘述。
本实施例中， 由于请求方设备与被请求方设备之间传输的媒 体信息是与 所述请求方设备或所述被请求方设备支持的每 个媒体业务分别对应的， 因此， 当请求方设备发起媒体类型相同的多个媒体业 务， 且请求方设备与被请求方 设备所支持的每个媒体业务的媒体信息不相同 时， 能够实现请求方设备与被 请求方设备进行所述多个媒体业务的媒体数据 的传输， 以建立对应的媒体通 道， 完成每个媒体业务。
图 5为本申请另一实施例提供的请求方设备的结 示意图，如图 5所示， 本实施例的请求方设备可以包括发送器 51、 接收器 52和处理器 53。 其中， 发送器 51 , 用于向被请求方设备发送业务请求消息， 所述业务请求消息用以 指示至少两个媒体业务， 所述业务请求消息中包含所述请求方设备支持 的与 每个所述媒体业务对应的媒体信息； 接收器 52, 用于接收所述被请求方设备 发送的业务响应消息， 以及将所述业务响应消息传输给处理器 53, 所述业务 响应消息中包含所述被请求方设备根据所述请 求方设备支持的与每个所述媒 体业务对应的媒体信息和所述被请求方设备支 持的与每个所述媒体业务对应 的媒体信息， 进行媒体协商获得的协商结果； 所述处理器 53, 用于根据所述 协商结果， 执行或不执行与所述被请求方设备传输所述至 少两个媒体业务的 媒体数据的操作。
其中， 所述媒体信息包括媒体流接收的地址和端口号 、 媒体流的采样频 率以及编码格式 （如 H.323、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.323或实 时传输协议 ( Real-Time Transport Protocol, RTP )等）等信息。
可选地，在本实施例的一个可能的实现方式中 ， 所述发送器 51发送的所 述业务请求消息的消息体中可以包含所述请求 方设备支持的与每个所述媒体 业务对应的媒体信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中，所述发送器 51发送的所述业务请求消息可以包括但不限于 话初 始化协议（ Session Initiation Protocol, SIP )消息、超文体传输协议（ Hypertext Transfer Protocol, HTTP ) 消息或 ( Extensible Messaging and Presence Protocol, 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、 动态图像专家组 （Moving Pictures Experts Group, MPEG )或 VP8等） ； 此外， 媒体信息还可以包括媒体类型 （如视 频或音频等 )、传输协议 (如传输控制协议（ Transmission Control Protocol, TCP ) 、 用户数据报协议 ( User Datagram Protocol, UDP ) 、 H.523或实 时传输协议 ( Real-Time Transport Protocol, RTP )等）等信息。
可选地，在本实施例的一个可能的实现方式中 ， 所述接收器 61接收的所 述业务请求消息的消息体中可以包含所述请求 方设备支持的与每个所述媒体 业务对应的媒体信息。
可选地， 在本实施例的一个可能的实现方式中， 所述业务请求消息和所 述业务响应消息的消息体可以是通过会话描述 协议 （Session Description Protocol, SDP )协议描述的， 为了简化描述， 可以称其消息体为一个 SDP 信息。
其中，所述接收器 61接收的所述业务请求消息可以包括但不限于 话初 始化协议（ Session Initiation Protocol, SIP )消息、超文体传输协议（ Hypertext Transfer Protocol, HTTP ) 消息或 ( Extensible Messaging and Presence Protocol, XMPP ) 消息； 相应地， 所述发送器 63发送的所述业务响应消息 可以包括但不限于 SIP消息、 HTTP消息或 XMPP消息。
可选地，在本实施例的一个可能的实现方式中 ， 所述处理器 62具体可以 确定所述业务请求消息所包含的媒体信息中描 述的业务信息的数量和所述业 务请求消息的联系方头域中的特征标签的数量 ； 如果所述业务信息的数量与 所述特征标签的数量相等， 根据所述被请求方设备支持的与每个所述媒体 业 务对应的媒体信息和所述请求方设备支持的与 每个所述媒体业务对应的媒体 信息， 协商出所述请求方设备和所述被请求方设备均 支持的与所述每个所述 媒体业务对应的媒体信息， 作为所述协商结果。 或者如果所述业务信息的数 量与所述特征标签的数量不相等， 判断所述特征标签所指示的业务是否没有 包含相同的媒体类型； 如果所述特征标签所指示的业务没有包含相同 的媒体 类型， 根据所述请求方设备支持的每个所述媒体业务 的媒体类型， 确定所述 媒体类型对应的媒体信息， 根据所述被请求方设备支持的与每个所述媒体 业 务对应的媒体信息和所述请求方设备支持的与 每个所述媒体业务对应的媒体 信息， 协商出所述请求方设备和所述被请求方设备均 支持的与所述每个所述 媒体业务对应的媒体信息， 作为所述协商结果。
可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为所述请求方设备和所述被请求方设备均支持 的与所述每个所述媒体业务对 应的媒体信息； 相应地， 所述处理器 62具体可以根据所述请求方设备和所述 被请求方设备均支持的与所述每个所述媒体业 务对应的媒体信息， 与所述请 求方设备传输所述至少两个媒体业务的媒体数 据。 可选地， 在本实施例的一个可能的实现方式中， 所述协商结果具体可以 为协商失败信息； 相应地， 所述处理器 62具体可以根据所述协商失败信息， 不执行与所述请求方设备传输所述至少两个媒 体业务的媒体数据的操作。
可选地，在本实施例的一个可能的实现方式中 ， 所述接收器 61还可以进 一步接收所述请求方设备发送的业务能力查询 请求消息， 以及将所述业务能 力查询请求消息传输给所述发送器 63, 所述业务能力查询请求消息的消息体 中包含所述请求方设备支持的每个所述媒体业 务。所述发送器 63还可以进一 步根据所述业务能力查询请求消息， 向所述请求方设备发送业务能力查询响 应消息， 所述业务能力查询响应消息中包含所述被请求 方设备支持的与每个 所述媒体业务对应的媒体信息， 以使得所述请求方设备根据所述被请求方设 备支持的与每个所述媒体业务对应的媒体信息 ， 向被请求方设备发送所述业 务请求消息。
本实施例提供的请求方设备用于对应执行如图 2所示实施例的方法， 对 于图 2所示实施例已经描述的细节， 此处不再赘述。
本实施例中， 由于请求方设备与被请求方设备之间传输的媒 体信息是与 所述请求方设备或所述被请求方设备支持的每 个媒体业务分别对应的， 因此， 当请求方设备发起媒体类型相同的多个媒体业 务， 且请求方设备与被请求方 设备所支持的每个媒体业务的媒体信息不相同 时， 能够实现请求方设备与被 请求方设备进行所述多个媒体业务的媒体数据 的传输， 以建立对应的媒体通 道， 完成每个媒体业务。
所属领域的技术人员可以清楚地了解到， 为描述的方便和简洁， 上述描 述的系统， 装置和单元的具体工作过程， 可以参考前述方法实施例中的对应 过程， 在此不再赘述。
在本申请所提供的几个实施例中， 应该理解到， 所揭露的系统， 装置和 方法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示 意性的， 例如， 所述单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可 以有另外的划分方式， 例如多个单元或组件可以结合或者可以集成到 另一个 系统， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间 的耦合或直接耦合或通信连接可以是通过一些 接口， 装置或单元的间接耦合 或通信连接， 可以是电性， 机械或其它的形式。 所述作为分离部件说明的单元可以是或者也可 以不是物理上分开的， 作 为单元显示的部件可以是或者也可以不是物理 单元， 即可以位于一个地方， 或者也可以分布到多个网络单元上。 可以根据实际的需要选择其中的部分或 者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可 以集成在一个处理单元中， 也可以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单 元中。 上述集成的单元既可以采用硬件的形式实现， 也可以采用硬件加软件 功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元 ， 可以存储在一个计算机 可读取存储介质中。 上述软件功能单元存储在一个存储介质中， 包括若干指 令用以使得一台计算机设备（可以是个人计算 机， 服务器， 或者网络设备等） 或处理器（processor )执行本申请各个实施例所述方法的部分步骤 而前述 的存储介质包括： U盘、移动硬盘、只读存储器（ Read-Only Memory, ROM ) , 随机存取存储器（ Random Access Memory, RAM ) 、 磁碟或者光盘等各种 可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本申请的技术方案， 而非对其 限制； 尽管参照前述实施例对本申请进行了详细的说 明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案 进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本申请各实施例技术方案的 精神和范围。