CN101453459A - 一种实现媒体协商的方法和装置 - Google Patents

Abstract

本发明实施例公开了一种实现媒体协商的方法，包括以下步骤：主叫方设置媒体等级，并向被叫方发送携带所述媒体等级的请求；所述主叫方接收到所述被叫方返回的响应，所述响应中携带有所述被叫方依据所述媒体等级选择的媒体，并根据所述被叫方选择的媒体做相应的处理。通过使用本发明实施例提供的方法，可以在媒体协商过程中由主叫方设置主副媒体类型，明确各媒体类型之间的等级关系，这种增加媒体信息的方式有助于更加高效地进行会话的媒体协商。

Description

一种实现媒体协商的方法和装置

技术领域

本发明涉及通信技术领域，尤其涉及一种实现媒体协商的方法和装置。

背景技术

随着移动通信网络与IP(Internet Protocol，互联网协议)网络的融合和下一代网络的发展，所有的会话服务都将支持多媒体会话。在多媒体会话中实体之间的媒体协商是必不可少的，通过媒体协商，实体之间就本次会话中使用的媒体类型组合以及各媒体使用哪种编码方案等达成一致。

实体之间可以通过SDP(Session Description Protocol，会话描述协议)提供/应答机制实现媒体协商，SDP是一个用来描述多媒体会话的应用层协议，SDP的提供/应答机制被实体用来为一个特定会话描述达成一致。

在SDP的提供/应答机制中，当一个实体希望创建一个会话时，可以产生一个SDP会话描述，该会话描述即构成一个提供，在这个提供中包含提供者所希望使用的媒体流的集合和编码方案的集合，以及提供者想用来发送媒体的目的IP地址和目的端口。应答者产生一个SDP应答与其接收到的提供相对应，该应答携带是否接受媒体流、将要使用的编码方案以及应答者想用来发送媒体的目的IP地址和目的端口。在接收到第一个请求的应答之后，提供者可以同样依据这样的问答方法产生后续的请求，但是只能在接收到每一个请求的应答之后才能发起下一个请求，双方按照上述提供/应答模式进行协商，直至本次会话中使用的媒体类型组合以及各媒体使用哪种编码方案等达成一致，会话成功建立。

现有的SIP(Session Initiation Protocol，会话初始协议)多媒体会话的媒体协商过程如图1所示，具体步骤如下：

步骤S101、主叫方向被叫方发送INVITE请求，该INVITE请求中携带第一个SDP提供给被叫方。该SDP提供通过一系列的媒体描述行列出本次会话中主叫方希望使用的所有媒体类型，以及对这些不同的媒体所支持的编码类型。

其中，SDP消息包括三级信息：会话级描述、时间级描述以及媒体级描述。媒体描述行属于媒体级描述。一个会话描述可能包括多个媒体描述行，一个媒体描述行包括四个子字段：媒体类型、端口号、传输协议以及格式列表。

步骤S102、被叫方接收到INVITE请求后，根据INVITE请求中携带的SDP提供返回第一个SDP应答。该SDP应答中可能拒绝一些被建议的媒体类型，还可能会缩减编码方案的列表，省略掉不能支持的类型，仅保存双方都支持的编码方式。另外，主叫方和被叫方的媒体描述必须完全一致，即主叫方会话描述中的第n个媒体描述行与被叫方会话描述中的第n个媒体描述行一一对应。如果被叫方既不想发送也不想接收主叫方提出的某个媒体流，则在其会话描述中将该媒体流的端口号置为零。例如：主叫方在INVITE请求中包含的媒体描述行如下所示：

m＝audio 49170 RTP/AVP 0

m＝video 51372 RTP/AVP 31

m＝video 53000 RTP/AVP 32

该媒体描述行表示主叫方希望以一个音频流与两个视频流的方式与被叫方进行会话。被叫方接收到主叫方发送的INVITE请求后，返回的应答消息中SDP部分中的媒体描述行如下所示：

m＝audio 47920 RTP/AVP 0

m＝video 0 RTP/AVP 31

m＝video 53000 RTP/AVP 32

被叫方将第二行的媒体描述行的端口号置为零，表示被叫方不接受该视频流。

步骤S103、主叫方接收到第一个SDP应答后，判断是否接受被叫方选择的媒体类型，如果接受，转步骤S104，否则转到步骤S105。

步骤S104、如果主叫方接受被叫方选择的媒体类型，则双方的媒体类型协商成功，会话建立成功。

步骤S105、如果主叫方不接受被叫方选择的媒体类型，则主叫方可能继续发起一个提供重新与被叫方协商媒体类型。

在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：现有的媒体协商方式仅仅是由主叫方将希望使用的媒体类型罗列出来供被叫方参考并进行选择，这样的媒体协商方式没有显示出主叫方提供的媒体类型之间的主次关系，被叫方无法判断主叫方提供的媒体类型中哪些是主叫方最希望的会话方式，被叫方可能没有选择主叫方最希望使用的媒体类型，由此将导致以下三种情况：(1)主叫方勉强接受了被叫方选择的媒体类型，然而因为会话无法达到主叫方预期设想的效果，主叫方很有可能在会话过程中发起修改媒体类型的请求，需要重新进行媒体协商，引起资源的重新分配，(2)主叫方不接受被叫方的选择，主叫方再次发起媒体协商请求，这也会消耗额外的会话建立时间；(3)主叫方直接取消与被叫方建立会话的请求。

发明内容

本发明实施例提供一种实现媒体协商的方法和装置，以解决在媒体协商过程中被叫方无法判断主叫方最希望使用的媒体类型的问题。

为达到上述目的，本发明实施例提供一种实现媒体协商的方法，包括以下步骤：

主叫方设置媒体等级，并向被叫方发送携带所述媒体等级的请求；

所述主叫方接收到所述被叫方返回的响应，所述响应中携带有所述被叫方依据所述媒体等级选择的媒体，并根据所述被叫方选择的媒体做相应的处理。

本发明实施例还提供一种终端，包括：

设置单元，用于设置媒体等级，并发送所述媒体等级给发送单元；

发送单元，用于发送携带所述媒体等级的请求；

处理单元，用于接收响应，根据所述响应中被选择的媒体做相应的处理。

与现有技术相比，本发明的实施例具有以下优点：

可以在媒体协商过程中由主叫方设置媒体等级，明确各媒体之间的等级关系，这种增加媒体等级信息的方式有助于更加高效地进行会话的媒体协商。

附图说明

图1是现有技术中一种实现媒体协商的方法流程图；

图2是本发明实施例一的一种实现媒体协商的方法流程图；

图3是本发明实施例二的一种实现媒体协商的方法流程图；

图4是本发明实施例三的一种实现媒体协商的方法流程图；

图5是本发明实施例四的一种终端示意图。

具体实施方式

本发明实施例要解决的问题是提供一种实现媒体协商的方法和装置，通过在会话建立初始阶段主叫方在SDP消息中设置媒体等级，并提供给被叫方进行媒体协商，让被叫方明确主叫方最希望使用的媒体，可以更加高效和有效地建立会话，节省不必要的媒体协商时间。

本发明实施例中将主叫方提供给被叫方进行媒体协商的媒体等级可通过以下两种方式实现，

方式一：媒体等级包括主媒体类型与副媒体类型，其中主媒体类型是主叫方最希望使用的媒体类型，它的主要目的是让被叫方明确主叫方更倾向于使用哪种媒体类型进行通信，从而使被叫方在明确主叫方意愿的情况下作出选择。主叫方通过设置主副媒体类型向被叫方传达需要进行协商的媒体类型之间的主次关系，其中副媒体类型是主媒体类型的补充和辅助，能够让会话达到更好的效果。

若在会话建立之前能够预计到某些媒体类型会一直贯穿于整个会话之中，则有必要将这些媒体类型设置为主媒体类型，对于主叫方对会话媒体类型有特别要求的情况下也可以设置主副媒体类型，例如：主叫方希望与被叫方同时进行视频和音频交流，则可以将视频与音频都指定为主媒体类型；另外在一些场景下，设置主副媒体是必要的，例如：视频会议中，与会者必须支持视频媒体流才能保证会议的正常进行，这是最基本的条件，因此可以将该视频流指定为主媒体类型。

方式二：媒体等级通过所述媒体对应的优先级体现，优先级高的媒体所述媒体等级也较高，这样对媒体的等级就不会局限于主副媒体两种类型，主叫方可根据自己的喜好或条件，依次设置不同的优先级，这样被叫方也会依据优先级依次选择其能够接受的媒体，这样能够进一步提高媒体协商的效率。

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。

本发明的实施例一中，一种实现媒体协商的方法如图2所示，具体步骤如下：

步骤S201、主叫方设置媒体等级，并向被叫方发送携带该媒体等级的会话请求。具体的，通过扩展会话请求中的SDP消息携带设置的媒体等级。具体包括两种方式，一种是仅设置主副媒体两种类型，另一种是通过所述媒体对应的优先级体现媒体等级。设置主副媒体两种类型可采用以下方式：

SDP消息包括三级信息：会话级描述、时间级描述以及媒体级描述。媒体描述行属于媒体级描述，一个会话描述可能包括多个媒体描述行，一个媒体描述行又包括四个子字段：媒体类型、端口号、传输协议以及格式列表。可以通过扩展SDP消息中的会话级描述、媒体描述行、端口号的分配来实现主副媒体。

(1)定义一个会话级属性行(即主副媒体属性行)实现设置主副媒体类型。主副媒体属性行中包括两个属性值：主媒体类型和副媒体类型。

(2)在媒体描述行中定义一个主副媒体标识子字段实现设置主副媒体类型。通过在媒体描述行中定义一个主副媒体标识子字段用来说明某个媒体描述行中的媒体类型是主媒体类型或副媒体类型。

进一步，在同一个媒体类型对应多个媒体描述行的情况下(即多个相同类型的媒体流)，可以通过主副媒体标识子字段指明某个媒体流是主媒体类型或副媒体类型。

(3)定义一个会话级属性行——主媒体端口号属性行，主媒体端口号属性行指出所有主媒体类型在各自的媒体描述行中对应的端口号，即如果该主媒体端口号属性行对应的端口号值为51372，则该端口(51372)对应的媒体就为主媒体类型。该端口号为发送媒体的目的端口号(即被叫方端口号)，该端口号取决于网络信息以及传输协议。

进一步，该种扩展方法不适用于IP地址不同而端口号相同的情况，适用于SDP消息中仅有会话级连接状态行的情况。

进一步，对于一个媒体行中设置多个端口的情况下，应当在主媒体端口号属性行中列出所有这些端口号。

进一步，由于端口号和媒体描述行中的媒体类型对应，因此在同一个媒体类型对应多个媒体描述行的情况下(即多个相同类型的媒体流)，可以通过主媒体端口号属性行指明某个媒体流是主媒体类型或副媒体类型。

设置媒体优先级可采用以下方式：定义一个媒体级属性行——媒体优先级属性行，给定某种媒体类型的优先级。主叫方为其在本次会话中希望使用的各媒体类型赋予优先级来设置媒体等级。

步骤S202、被叫方接收到主叫方的会话请求后，识别会话请求中携带的媒体等级，并进行选择。

步骤S203、被叫方向主叫方发送一个临时响应，该临时响应中包含被叫方对主叫方设置的媒体等级作出的选择。

步骤S204、主叫方接收到被叫方的临时响应后，判断被叫方是否接受媒体等级高的媒体，如果接受，转步骤S205，否则转步骤S206。

步骤S205、如果被叫方接受主叫方设置的等级高的媒体，则主叫方向被叫方返回OK响应，会话成功建立，主叫方与被叫方按照协商好的媒体进行会话。

步骤S206、如果被叫方不接受主叫方设置的等级高的媒体，则主叫方根据不同的需求进行相应的处理，如下所示：

(1)返回OK响应，会话成功建立，主叫方与被叫方按照协商好的媒体进行会话；

(2)重新设置媒体等级继续与被叫方进行媒体协商；

(3)取消与被叫方建立会话连接。

以上步骤中描述的会话可能是一对一的CPM多媒体会话，也可能是CPM多媒体预定义群组会话，下面分别以具体实施例对本发明进行说明。为了能够更加详细地理解本发明实施例，该实施例采用方式一主副媒体两种类型进行描述，采用优先级方式与采用主副媒体的方式流程近似，在此不在赘述。

本发明的实施例二中，以一对一的CPM(Converaged IP Message，融合IP消息)多媒体会话为例，一种实现媒体协商的方法如图3所示，具体步骤如下：

步骤S301、UE A设置主副媒体类型，并向UE B发送携带该主副媒体类型的INVITE请求。

具体的，用户A和用户B均为签约的CPM用户，归属网络相同，且在同一域内，可以通过扩展SDP消息中的会话级属性行a、媒体描述行m、端口号的分配来实现上述会话建立时的主副媒体类型设置，进行媒体协商。

(1)定义会话级属性a实现媒体协商。定义SDP消息的会话级属性如下所示：

Inviting-mediatypes＝a＝inviting:primary-types SP optional-types其中：

Primary-types＝(“audio”|“video”|“application”|“message”|“text”)

Optional-types＝(“audio”|“video”|“application”|“message”|“text”|“none”)

Inviting-mediatypes表示UE A可提供的所有媒体类型，其中primary-types与optional-types分别表示UE A指定的主媒体类型与副媒体类型；

进一步，INVITE请求中的SDP消息如下所示，其中a＝inviting:video表示指定视频为主媒体类型：

v＝0

o＝Alice 2890844526 2890842807 IN IP 410.47.16.5

s＝My holiday

i＝Pictures of my holiday

e＝Alice@example.com(Alice)

c＝IN IP4 10.47.16.5

t＝2873397496 2873404696

a＝inviting:video

a＝sendrecv

m＝audio 49170 RTP/AVP 0

m＝video 51372 RTP/AVP 99

a＝rtpmap:99 h263-1998/90000

其中，上述实施例为对主媒体类型的举例描述，在上述例子中第1～6行为会话描述，v行表示协议版本，o行表示所有者/创建者和会话标识符，s行表示会话名称，i行表示会话信息，e行表示Email地址，c行表示连接信息——如果包含在所有媒体中，则不需要该字段；第7行为时间描述，t行表示会话活动时间；第8～12行为媒体描述，m行表示媒体名称和传输地址，a行表示0个或多个会话属性行。

(2)定义媒体描述行m实现媒体协商。m行携带媒体和传输的信息，包括媒体的类型(如音频、视频等)、发送媒体的目的端口号、传输协议以及格式列表，其语法如下：

m＝<media><port><transport><fmtlist>

本实施例中，在m行中增加一个标识type-tag来指示每个m行中的媒体类型是主媒体类型还是副媒体类型，即：

m＝<media><port><transport><fmt list><type-tag>

其中type-tag＝(“primary”|“optional”)，即primary与optional分别表示该媒体行中的媒体类型为主媒体或副媒体。

进一步，INVITE请求中的SDP消息如下所示，其中视频为主媒体类型，音频为副媒体类型，：

v＝0

o＝Alice 2890844526 2890842807 IN IP4 10.47.16.5

s＝My holiday

i＝Pictures of my holiday

e＝Alice@example.com(Alice)

c＝IN IP4 10.47.16.5

t＝2873397496 2873404696

a＝sendrecv

m＝audio 49170 RTP/AVP 0 optional

m＝video 51372 RTP/AVP 99 primary

a＝rtpmap:99 h263-1998/90000

(3)定义端口号的分配实现媒体协商。如上所述，媒体行m＝<media><port><transport><fmt list>中端口port表示发送媒体的目的端口号。为了让UEB明确所有m行中的媒体类型哪些是主媒体哪些是副媒体，定义以下会话级属性：

Primary-ports＝a＝port:<主媒体端口号>

即通过主媒体端口号指出所有m行包含的媒体类型中哪些端口号对应的媒体类型是主媒体类型。

进一步，INVITE请求中的SDP消息如下所示，其中a＝port:51372表示指定端口号51372对应的视频为主媒体类型：

v＝0

o＝Alice 2890844526 2890842807 IN IP4 10.47.16.5

s＝My holiday

i＝Pictures of my holiday

e＝Alice@example.com(Alice)

c＝IN IP4 10.47.16.5

t＝2873397496 2873404696

a＝port:51372

a＝sendrecv

m＝audio 49170 RTP/AVP 0

m＝video 51372 RTP/AVP 99

a＝rtpmap:99h263-1998/90000

需要说明的是，如果在该实施例中选用设置优先级的方式来声明媒体类型之间的主次关系，具体可采用如下方式：

定义以下媒体级属性来设定各媒体类型的优先级：

Media-pri＝a＝pri:privalue

其中，privalue＝(“inessential”|“non-urgent”|“normal”|“urgent”|“emergency”)

privalue表示某个媒体类型的优先级数值，这五个取值从inessential到emergency优先级依次增加，本实施例中定义五个取值，与五个媒体类型对应。

进一步，INVITE请求中的SDP消息如下所示，其中a＝pri:emergency表示该音频流具有最高优先级，该视频流具有一般优先级：

v＝0

o＝Alice 2890844526 2890842807 IN IP4 10.47.16.5

s＝My holiday

i＝Pictures of my holiday

e＝Alice@example.com(Alice)

c＝IN IP4 10.47.16.5

t＝2873397496 2873404696

a＝sendrecv

m＝audio 49170 RTP/AVP 0

a＝pri:emergency

m＝video 51372 RTP/AVP 99

a＝rtpmap:99 h263-1998/90000

a＝pri:normal

步骤S302、SIP/IP Core接收到INVITE请求后，由于运营商往往在网络中定义不同用户的用户配置，如媒体配置等，其中包括SDP参数，SIP/IP Core可能会检测UE A的SDP参数设置是否在运营商允许的媒体类型范围内，如果在则SIP/IP Core将INVITE请求发送至CPM Conversation Server X，否则SIP/IPCore发送415应答给UE A。

具体的，SIP/IP Core逐个检测网络中与用户A相关的应用服务器的初始过滤准则，当发现INVITE请求中的信息与CPM Conversation Server X匹配时，SIP/IP Core将INVITE请求发送给CPM Conversation Server X。

步骤S303、CPM Conversation Server X对接收到的INVITE请求进行解析，由于服务供应者策略以及用户的个人喜好设置中可能会包含媒体限制，因此CPM Conversation Server X会根据这些信息检测用户A的INVITE请求中的SDP参数是否符合要求，如果符合，则CPM Conversation Server X将INVITE请求路由回SIP/IPCore，如果不符合，可能的操作是CPM Conversation Server X发送415应答给UE A。

步骤S304、SIP/IP Core根据解析出的UE B的地址，将INVITE请求发送到UE B。

步骤S305、UE B接收到INVITE请求后，识别出INVITE请求中携带的主副媒体类型，对媒体类型进行选择。

步骤S306、UE B向UE A发送183响应，183响应中包含UE B对UE A设置的主副媒体类型的选择。

其中，UE B在183响应中将其拒绝的媒体类型对应的媒体描述行中的端口号置为零。

步骤S307、SIP/IP Core接收到183响应后，由于运营商往往在网络中定义不同用户的用户配置，如媒体配置等，其中包括SDP参数，因此SIP/IP Core可能会检测UE B发送的183响应中的SDP参数设置是否在运营商允许的媒体类型范围内，如果在，则SIP/IP Core根据183响应中的Via字段将183响应路由到CPM Conversation Server X，否则SIP/IP Core发送415应答给UE B。。

步骤S308、CPM Conversation Server X接收到183响应后，由于服务供应者策略以及用户的个人喜好设置中可能会包含媒体限制，因此CPMConversation Server X会根据这些信息检测用户B的响应中的SDP参数是否符合要求，如果符合，则CPM Conversation Server X根据183响应中的Via字段将183响应路由回SIP/IP Core，如果不符合，可能的操作是CPM ConversationServerX发送415应答给UE B。

步骤S309、SIP/IP Core根据Via字段将183响应发送至UE A。

步骤S310、UE A根据UE B对主媒体的选择情况做相应的处理。

具体的，根据UE B对主媒体的选择情况，UE A做如下处理：

(1)若UE A接受UE B的选择的媒体类型，则UE A发送200 OK响应给UEB，媒体协商成功，双方按照协商的媒体类型进行会话；

(2)若UE A不接受UE B的选择的媒体类型，则UE A可能取消INVITE请求，或者重新设置主副媒体类型与UE B进行再次的媒体协商，或者返回200OK与UE B进行会话。

本发明的实施例三中，以CPM多媒体预定义群组会话为例，一种实现媒体协商的方法如图4所示，具体步骤如下：

步骤S401、UE A设置主副媒体类型，发送INVITE请求到预定义群组的地址，该INVITE请求中除了包括预定义群组的信息外，还包含设置的主副媒体类型。

具体的，UE A为CPM用户，且是群组创建者或者群组授权用户。可以通过如实施例二中描述的方法设置主副媒体类型或优先级，在此不再赘述。

步骤S402、SIP/IP Core接收到INVITE请求后，由于运营商往往在网络中定义不同用户的用户配置，如媒体配置等，其中包括SDP参数，SIP/IP Core可能会检测UE A的SDP参数设置是否在运营商允许的媒体类型范围内，如果在则SIP/IP Core将INVITE请求发送至CPM Conversation Server X，否则SIP/IPCore发送415应答给UE A。

具体的，SIP/IP Core逐个检测网络中与用户A相关的应用服务器的初始过滤准则，当发现INVITE请求中的信息与CPM Conversation Server X匹配时，SIP/IP Core将INVITE请求发送给CPM Conversation Server X。

步骤S403、CPM Conversation Server X对接收到的INVITE请求进行解析，由于服务供应者策略以及用户的个人喜好设置以及群组会话规则中可能会包含媒体限制，因此CPM Conversation Server X会检测该群组会话请求中的SDP参数是否满足条件，如果符合，则CPM Conversation Server X将INVITE请求路由回SIP/IP Core，如果不符合，可能的操作是CPM Conversation Server X发送415应答给UE A。除此之外，它会根据请求消息中包含的群组的信息向存储装置发起获取群组成员列表的请求，并解析得到的群组成员列表，然后根据解析的结果向其他群组成员发起群组会话请求。这里的存储装置是存储与特定业务相关的文件和数据的服务器或者存储多个业务公用的公共信息的服务器，在这里具体指的是XDMS(XML Document Management Server，XML文档管理服务器)其中XML(Extensible Markup Language)是可扩展标记语言。

步骤S404、其他群组成员接收到INVITE请求后，对主副媒体类型进行选择，并且回复临时响应183响应到CPM Conversation Server X。

步骤S405、CPM Conversation Server X根据183响应的Via字段将响应发送给SIP/IP Core，每个群组成员的响应包含了他们各自对主副媒体的选择。

步骤S406、SIP/IP Core根据183响应的Via字段将响应发送给UE A。

步骤S407、UE A接收到某个群组成员的响应后，判断该群组成员是否接受主媒体类型，如果是，则UE A批准该成员加入本次群组会话中，否则UE A发送CANCEL取消会话请求。

其中，优选地，在上述三个实施例中，主叫方还可在会话过程中，通过re-INVITE请求来修改已发送给被叫方的媒体等级，以设定的主副媒体类型为例进行描述。并且还需要说明的是在上述实施例中仅在主叫方设置相应的媒体等级，然而本发明实施例并不限于在会话的一方(主叫方或被叫方)，在会话过程中，会话的双方都可以根据需要重新设定其需要的媒体等级。

对于已发送至对方的媒体可通过发送一个包含新媒体属性描述的re-INVITE请求来进行更新，在re-INVITE请求中也是通过上述三种方案声明主副媒体类型的。这个re-INVITE是捆绑在一个现有的会话上，对方收到这个re-INVITE请求后，会发送一个200(OK)应答表示接受这个更新。请求方通过一个ACK来表示接受了对方的这个200(OK)应答。如果对方不同意这个媒体属性变化，则会返回一个错误的应答，比如488(暂时不能进行)，这个也会收到发起者的一个ACK响应。re-INVITE的协商结果不会影响到现有的会话，即原有的会话仍然可以按照原来的媒体属性继续进行。

通过以上实施例提供的方法，可以在媒体协商过程中由主叫方设置主副媒体类型，明确各媒体类型之间的等级关系，这种增加媒体信息的方式有助于更加高效地进行会话的媒体协商。

本发明实施例四中，一种终端如图5所示，包括：

设置单元11，用于设置媒体等级，并发送给发送单元12。

发送单元12，用于向被叫方发送携带媒体等级的会话请求。具体的，通过扩展会话请求中的SDP消息携带设置单元11设置的媒体等级。

处理单元13，用于接收被叫方发送的会话响应，根据被叫方选择的媒体等级做相应的处理。

其中，终端还包括：

响应单元14，用于对携带所述媒体等级的会话请求进行响应，将选择的媒体在会话响应中返回。

具体的，扩展会话请求中的SDP消息携带设置的媒体等级的方法如实施例一中所描述的方法，在此不再赘述。

通过以上实施例提供的系统，可以在媒体协商过程中由主叫方设置主副媒体类型，明确各媒体类型之间的等级关系，这种增加媒体信息的方式有助于更加高效地进行会话的媒体协商。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该获取机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备执行本发明各个实施例所述的方法。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (12)

1、一种实现媒体协商的方法，其特征在于，包括以下步骤：

主叫方设置媒体等级，并向被叫方发送携带所述媒体等级的请求；

所述主叫方接收到所述被叫方返回的响应，所述响应中携带有所述被叫方依据所述媒体等级选择的媒体，并根据所述被叫方选择的媒体做相应的处理。

2、如权利要求1所述实现媒体协商的方法，其特征在于，所述主叫方向被叫方发送携带所述媒体等级的会话请求的方法具体为：

所述主叫方通过在所述请求中的会话描述协议SDP消息携带所述设置的媒体等级。

3、如权利要求2所述实现媒体协商的方法，其特征在于，所述媒体等级具体包括主媒体类型和副媒体类型，所述主媒体类型的等级高于副媒体类型的等级。

4、如权利要求3所述实现媒体协商的方法，其特征在于，所述SDP消息携带所述主媒体类型和副媒体类型具体为：

在所述SDP消息中定义一个主副媒体属性行携带所述设置的主副媒体类型，所述主副媒体属性行中包括两个属性值：主媒体类型和副媒体类型。

5、如权利要求3所述实现媒体协商的方法，其特征在于，所述SDP消息携带所述主媒体类型和副媒体类型具体为：

在在所述SDP消息的媒体描述行中定义一个主副媒体标识子字段携带所述设置的主副媒体类型。

6、如权利要求3所述实现媒体协商的方法，其特征在于，所述SDP消息携带所述主媒体类型和副媒体类型具体为：

在所述SDP消息中定义一个主媒体端口号属性行，所述主媒体端口号属性行中所携带的端口号值对应的媒体即为主媒体类型，其他媒体为副媒体类型。

7、如权利要求6所述实现媒体协商的方法，其特征在于，还包括：一个媒体描述行中设置多个端口时，则在主媒体端口号属性行中列出所有这些端口号。

8、如权利要求2所述实现媒体协商的方法，其特征在于，所述媒体等级通过所述媒体对应的优先级体现，优先级高的媒体所述媒体等级也较高，所述主叫方通过扩展所述请求中的会话描述协议SDP消息携带所述设置的媒体等级具体为：

定义一个媒体优先级属性行携带所述设置的媒体等级，所述媒体优先级属性行中给定某种媒体类型的优先级。

9、如权利要求1所述实现媒体协商的方法，其特征在于，所述主叫方接收到所述被叫方返回的响应，所述响应中携带有所述被叫方依据所述媒体等级选择的媒体，并根据所述被叫方选择的媒体做相应的处理具体为：

所述主叫方返回响应消息，会话成功建立，所述主叫方与被叫方按照所述被叫方协商的媒体进行会话；或，

所述主叫方重新设置媒体等级继续与所述被叫方进行媒体协商；或，

所述主叫方取消与被叫方建立会话连接。

10、如权利要求1所述实现媒体协商的方法，其特征在于，还包括：

通过re-INVITE请求中携带新的媒体等级更新已向会话对方发送的媒体等级。

11、一种终端，其特征在于，包括：

设置单元，用于设置媒体等级，并发送所述媒体等级给发送单元；

发送单元，用于发送携带所述媒体等级的请求；

处理单元，用于接收响应，根据所述响应中被选择的媒体做相应的处理。

12、如权利要求12所述终端，其特征在于，所述终端还包括：

响应单元，用于对携带所述媒体等级的请求进行响应，将选择的媒体在响应中返回。

Images