CN101714924A

CN101714924A - 媒体服务能力协商的方法和装置

Info

Publication number: CN101714924A
Application number: CN200810168255A
Authority: CN
Inventors: 钟剑锋; 王啸; 王耕; 李金成; 成淑敏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-10-06
Filing date: 2008-10-06
Publication date: 2010-05-26

Abstract

本发明实施例公开了一种媒体服务能力协商的方法，包括：网络控制实体通过SIP会话发起协议，与用户终端协商媒体服务能力；根据协商结果，确定初始RTSP播放消息的发送端。还公开了一种媒体服务能力协商的用户终端和网络控制实体及系统。利用本发明实施例能够实现在移动电视业务中实现媒体服务能力协商。

Description

媒体服务能力协商的方法和装置

技术领域

本发明涉及通信技术领域，特别是涉及媒体服务能力协商的方法和装置。

背景技术

IPTV(Internet Protocol Television，互联网协议电视)是一种利用宽带有线电视网，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以使用计算机或者网络机顶盒+普通电视机方式享受IPTV业务，也可以通过移动终端享受IPTV业务。IPTV使用TCP/IP(Transfer control protocol/Internet protocol，传输控制协议和网际协议)作为承载协议进行单播、广播或组播视频业务，有效地将电视网、电话网和互联网三个领域结合在一起，是三网融合最具代表性的业务，正受到业界越来越多的关注。

IMS(IP Multimedia Subsystem，IP多媒体子系统)是3GPP(3rd GenerationPartnership Project，第三代移动通信标准化伙伴项目)在Release 5版本(发布的第五版本)中提出的支持IP多媒体业务的子系统。IMS是一个独立于接入技术的基于IP的标准体系，它与现存的语音和数据网络都可以互通。不论是固定网络用户还是移动用户。IMS的体系使得通过各种类型的客户端都可以建立对等的IP通信，并可以获得所需要的服务质量。除会话管理之外，IMS体系还涉及完成服务提供所必须的功能(例如注册、安全、计费、承载控制、漫游)。总之，IMS形成了IP核心网的心脏。

在3GPP中，已经实现了基于PSS的单播流媒体服务，以及基于MBMS的多播流媒体服务。但未对基于IMS的IPTV进行研究。为了充分利用IMS丰富的业务能力，给用户提供更好的业务体验。Mobile TV(移动电视)是3GPP正在开发的一种技术，是基于IMS使用原有的PSS(Packet-switched StreamingService，基于包交换的流服务)、MBMS(Multimedia Broadcast/MulticastService，基于多媒体广播多播服务)业务来提供IPTV业务。而在Mobile TV项目中，需要实现用户终端与网络服务器间协商媒体服务能力，包括：初始RTSP(Real-Time Streaming Protocol，实时流协议)PLAY(播放)消息的发送者，PSS快速内容切换能力协商。

发明人在实现本发明的过程中，发现现有技术中至少存在如下问题：现有技术中不能实现在移动电视业务中进行媒体服务能力协商。

发明内容

有鉴于此，本发明一个或多个实施例的目的在于提供一种媒体服务能力协商的方法和装置，以实现在移动电视业务中实现媒体服务能力协商。

为解决上述问题，本发明实施例提供了一种媒体服务能力协商的方法，包括：

网络控制实体通过SIP会话发起协议，与用户终端协商媒体服务能力；

根据协商结果，确定初始RTSP播放消息的发送端。

还提供了一种媒体服务能力协商的用户终端，包括：

第一协商单元，用于通过SIP会话发起协议，与网络控制实体协商媒体服务能力；

第一设置单元，用于根据第一协商单元的协商结果，确定初始RTSP播放消息的发送端。

还提供了一种媒体服务能力协商的网络控制实体，包括：

第二协商单元，用于通过SIP会话发起协议，与用户终端协商媒体服务能力；

第二设置单元，用于根据协商结果，确定初始RTSP播放消息的发送端。

一种媒体服务能力协商的系统，包括：

用户终端和网络控制实体，其中，所述用户终端包括：

第一设置单元，用于根据第一协商单元的协商结果，确定初始RTSP播放消息的发送端；

所述网络控制实体包括：

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

本发明实施例能够在移动电视业务中实现媒体服务能力协商。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1所示，是本发明的媒体服务能力协商的方法实施例一的流程图；

图2所示，是本发明的媒体服务能力协商的方法实施例二的流程图；

图3所示，是本发明的媒体服务能力协商的方法实施例三的流程图；

图4所示，是移动电视标准项目结构图；

图5所示，是本发明的一种PSS Adapter作为代理模式的流程图；

图6所示，是图5方案的问题一的方案二的结构示意图；

图7所示，是图5方案的问题二的方案一的结构示意图；

图8所示，是本发明的实施例四的流程图；

图9所示，是本发明的用户终端的实施例一的框图；

图10所示，是本发明的网络控制实体的实施例一的框图；

图11所示，是本发明的网络控制实体的实施例一的框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参考图1所示，是本发明的媒体服务能力协商的方法实施例一，包括步骤：

S101、网络控制实体通过SIP(Session Initial Protocol，会话发起协议)，与用户终端协商媒体服务能力；

其中，所述网络控制实体通过会话发起协议，与用户终端协商媒体服务能力包括：

网络控制实体收到SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP(Real-TimeStreaming Protocol，实时流协议)播放消息的指示；

根据预置协商规则处理所述会话请求消息和会话响应消息，得到协商结果；或

用户终端收到SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP播放消息的指示；

根据预置协商规则处理所述会话请求消息和会话响应消息，得到协商结果。

其中，所述协商规则至少包括如下之一或其任意组合：

A、如果会话请求消息携带发送初始RTSP播放消息的指示，会话响应消息携带不发送初始RTSP播放消息的指示，则协商结果为：由所述会话请求消息发送端(网络控制实体或用户终端)发送所述初始RTSP播放消息；或

B、如果会话请求消息携带不发送初始RTSP播放消息的指示，会话响应消息中携带发送初始RTSP播放消息的指示，则协商结果为：由所述会话响应消息发送端(网络控制实体或用户终端)发送所述初始RTSP播放消息；或

C、如果会话请求消息携带允许发送或不发送初始RTSP播放消息的指示，且

会话响应消息中携带发送所述初始RTSP播放消息的指示，则协商结果为：由所述会话响应消息发送端(网络控制实体或用户终端)发送所述初始RTSP播放消息；或

会话响应消息中携带不发送所述初始RTSP播放消息的指示，则协商结果为：由所述会话请求消息发送端(网络控制实体或用户终端)发送所述初始RTSP播放消息。

通过上述的协商规则，可以实现在会话请求消息和会话响应消息交互完成之后，协商得出初始RTSP播放消息的发送端。

上述协商规则可以包括A、B、C之一，及其任意两两或全部三个的组合。

S102、根据协商结果，确定初始RTSP播放消息的发送端。

其中，所述根据协商结果，确定初始RTSP播放消息的发送端包括：

如果协商结果由所述用户终端发送所述初始RTSP播放消息，将用户终端的RTSP状态设置为初始状态；

如果协商结果由所述网络控制实体发送所述初始RTSP播放消息，则将所述用户终端的RTSP状态设置为播放状态。

其中，与前述由网络控制实体与用户终端进行协商不同，也可以由网络控制实体来决定是由网络控制实体或用户终端来发送初始RTSP播放消息，则：

所述网络控制实体通过会话发起协议，与用户终端协商媒体服务能力包括：

网络控制实体向所述用户终端发送SIP会话请求消息或返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带由网络控制实体或用户终端发送初始RTSP播放消息的指示，所述指示用于确定所述协商结果。

如果确定由所述用户终端发送所述初始RTSP播放消息，设置用户终端的RTSP状态为初始状态；

如果确定由所述网络控制实体发送所述初始RTSP播放消息，则将所述用户终端的RTSP状态设置为播放状态。

其中，所述初始RTSP播放消息包含在S IP消息头域内，或包含在SIP消息体内，或包含在扩展SDP属性内，或包含在XML格式的消息体内。

利用本发明实施例一，通过由网络控制实体和用户终端通过会话发起协议协商媒体服务能力后，确定由网络控制实体或用户终端发送初始RTSP播放消息。从而实现了在移动电视中进行媒体服务能力协商的机制。

如图2所示，是本发明的实施例二，实施例二所公开的协商机制，用于实现用户终端与网络控制实体间协商初始RTSP PLAY消息的发送权。包括：

201、用户终端向网络控制实体发送SIP会话请求消息；

用户终端或网络控制实体通过SIP会话请求消息携带Init_play_ind信息，Init_play_ind取值为：send_play、nosend_play或either；各个取值的意义如下：

send_play：发送初始RTSP PLAY消息；

nosend_play：不能发送初始RTSP PLAY消息；

either：可以发送或不发送初始RTSP PLAY消息。

202、网络控制实体向用户终端返回SIP响应消息，用户终端和网络控制实体根据请求消息和响应消息进行媒体能力协商。

用户终端与网络控制实体间的协商规则如下：

A、请求消息中Init_play_ind＝send_play，响应消息中Init_play_ind＝nosend_play，协商结果是初始RTSP PLAY消息由请求消息发送端发送；

B、请求消息中Init_play_ind＝nosend_play，响应消息中Init_play_ind＝send_play，协商结果是初始RTSP PLAY消息由响应消息发送端发送；

C、请求消息中Init_play_ind＝either，响应消息中Init_play_ind＝send_play/nosend_play，协商结果由响应消息中Init_play_ind值决定，当Init_play_ind＝send_play时，初始RTSP PLAY消息由响应消息发送端发送，当Init_play_ind＝nosend_play时，初始RTSP PLAY消息由请求消息发送端发送；

当然，在协商规则中也可以只有A和B两个规则，Init_play_ind的取值为send_play或nosend_play，这样也能满足用户终端与网络控制实体间协商发送初始RTSP PLAY消息的要求。

具体的，上述发明中的协商机制可以通过扩展定义一个SDP的媒体级别的属性实现。扩展方式可以是以下方式，但不限于如下形式：

initplay-attribute＝“a＝rtsp_initplay:”operation

operation ＝“send_play”/“nosend_play”/“either”

取值的意义如下：

send_play：发送初始RTSP Play消息；

nosend_play：不能发送初始RTSP Play消息；

either：可以发送或不发送初始RTSP Play消息。

在上述实施例中，还可以通过已有的SIP头域，或定义新的SIP头域来进行发送机制协商。下面是一个新的头域示例：

Send-Init-Play＝send-value

send-value ＝“send_play”/”nosend_play”/”either”

通过已有的SIP头域协商与定义新头域的实现方式相类似，不再重复描述。

如果协商结果是用户终端发送初始RTSP PLAY消息，那么用户终端的初始RTSP状态就是Init状态(初始状态)；如果协商结果是网络控制实体发送初始RTSP PLAY消息，那么用户终端的初始RTSP状态就是Playing状态(播放状态)。

如图3所示，是本发明的实施例三，与实施例二中的协商方式不同，网络控制实体具有发送初始RTSP PLAY消息的控制权，可以决定由网络控制实体或用户终端发送初始RTSP PLAY消息。包括：

301、网络控制实体在向用户终端发送的会话请求消息或会话请求的响应消息中插入Init_rtsp_status_ind(初始RTSP状态)指示信息或Send_rtsp_play_ind(发送初始RTSP播放消息)指示信息；初始RTSP状态指示信息和发送初始RTSP播放消息可以统称为RTSP播放消息的指示信息。在实际的运用中，还可以使用其他形式的指示信息，只要能起到指示用户终端是否发送RTSP播放消息即可，具体形式不限。

302、用户终端接收网络控制实体发送的会话请求消息或会话请求的响应消息，根据消息中的Init_rtsp_status_ind指示信息或Send_rtsp_play_ind指示信息来设置用户终端初始RTSP状态和用户终端是否发送初始RTSP PLAY消息。

Init_rtsp_status_ind指示信息是用户终端的初始RTSP状态，包括：为Init状态，或Playing状态。用户终端将其初始RTSP状态设置为Init_rtsp_status_ind指示信息中所指示的状态。

如果用户终端设置为Init状态，则用户终端需要发送初始RTSP PLAY消息；如果用户终端设置为Playing状态，用户终端不能发送初始RTSP PLAY消息。

Send_rtsp_play_ind指示信息是初始RTSP PLAY消息的发送指示，包括uesend和netsend两个值。uesend表示初始RTSP PLAY消息由用户终端发送，netsend表示初始RTSP PLAY消息由网络发送。当Send_rtsp__play_ind携带值是uesend时，用户终端上的初始RTSP状态就设置为Init状态；当Send_rtsp_play_ind携带值是netsend时，用户终端上的初始RTSP状态就设置为Playing状态。

Init_rtsp_status_ind和Send_rtsp_play_ind可以通过SIP消息头域携带，也可以通过SIP消息体携带，如：通过扩展SDP的属性行携带，或XML格式的消息体携带。

Init_rtsp_status_ind和Send_rtsp_play_ind是网络控制实体控制终端发送或不发送初始RTSP PLAY消息的两种实现方式，可以通过Init_rtsp_status_ind来控制，也可以通过Send_rtsp_play_ind来控制。

下面是关于PSS切换能力协商的描述：PSS规范定义了PSS Server(PSS服务器)的媒体能力(如：快速内容切换)，在Mobile TV(移动电视)架构中，UE(用户终端)需要先获知PSS Server的媒体能力才能发起相应的操作，如：UE在发起快速内容切换请求前，需要先获知网络是否具备PSS快速内容切换能力。本发明提供如下两种方式使UE获知PSS Server的媒体能力。

1、SIP方式

在SIP会话建立过程中，网络控制实体在向终端发送的INVITE消息，或INVITE消息的响应消息中插入Supported头域，携带PSS Server的媒体能力标识，这些媒体能力标识在PSS规范中有定义，包括3gpp-pipelined，3gpp-switch，3gpp-switch-req-sdp，3gpp-switch-stream。Supported(注：3gpp-pipelined，3gpp-switch，3gpp-switch-req-sdp，3gpp-switch-stream和Supported这些专业术语出自3GPP 26.234-740标准，目前尚无通用的中文译名)头域可以携带其中的部分或全部。

另一种方法是，网络控制实体在INVITE(请求)消息或INVITE消息的响应消息的Contact(联系)头域中携带PSS Server的媒体能力标识。

2、SDP方式

在SIP会话建立过程中，网络控制实体在向终端发送的SDP Offer(SDP提供)或Answer(应答)中携带PSS快速内容切换能力的标识，可通过扩展一个SDP的媒体级别属性行携带，如：

a＝fmtp:pss ability＝<*pss_ability>

pss_ability代表PSS的能力，采用PSS已经定义的媒体能力标识，包括：3gpp-pipelined，3gpp-switch，3gpp-switch-req-sdp，3gpp-switch-stream。pss_ability中可以带多个能力标识，通过逗号分隔。

如：a＝pss ability:3gpp-pipelined，3gpp-switch

下面是关于PSS Adapter(PSS适配器)问题的描述：

在Mobile TV标准项目中，PSS Adapter代理用户终端与PSS Server进行RTSP交互过程，可以参考图4所示。

而基于上述架构的流程Mobile TV标准中目前还没有定义。下面本发明给出一种PSS Adapter作为代理模式的流程。

如图5所示，基于上述架构用户终端通过SIP与PSS Server协商建立RTSP会话的流程如下：

501～502、用户终端发送INVITE消息，经过SCF(Sevice Control Function，服务控制功能)路由到PSS Adapter；

503、PSS Adapter根据INVITE消息的内容构造RTSP SETUP消息，发送给PSS Server；

504、PSS Server接收PSS Adapter的RTSP SETUP消息，创建RTSP会话，通过RTSP 200OK响应消息向PSS Adapter返回RTSP Session ID(实时流协议会话号)；

505～506、PSS Adapter通过SIP 200OK响应消息将RTSP Session ID带回给用户终端，同时在SIP 200OK的SDP中指示用户终端RTSP会话的建立的目标地址为PSS Adapter；

507～508、用户终端返回ACK确认200OK响应消息；

509、用户终端向PSS Adapter发送RTSP消息携带RTSP Session ID；

510、PSS Adapter收到用户终端的RTSP消息，根据消息中的RTSP SessionID转发给PSS Server；

511～512、PSS Server处理PSS Adapter发送的RTSP消息，返回RTSP响应消息由PSS Adapter转发给用户终端；

在上述流程的步骤503中，PSS Adapter向PSS Server发送SETUP消息中Cseq(序号)头域值通常为1，而步骤509中，用户终端发送RTSP消息的Cseq头域值也可能是1，这样就可能会与SETUP消息中的Cseq值重复，会导致用户终端发送的RTSP消息失败。

为此，可以进行以下三种方案的优化：

1、方案一

PSS Adapter在步骤505～506向用户终端返回的SIP 200OK响应消息中携带用户终端发送RTSP消息的初始Cseq值，该值大于PSS Adapter发送SETUP消息使用的Cseq值，可以是SETUP消息使用的Cseq值加N，N为PSS Adapter向用户终端返回SIP 200OK响应消息前，PSS Adapter基于SETUP消息创建的RTSP Session ID向PSS Server发送的RTSP消息个数。例如：PSSAdapter发送SETUP的Cseq值是1，在向用户终端返回的SIP 200OK前，又代表用户终端向PSS Server发送了RTSP PLAY消息，那么PSS Adapter向用户终端返回的SIP 200OK响应消息中携带用户终端发送RTSP消息的初始Cseq值应该是1+1＝2。

PSS Adapter向用户终端返回的SIP 200OK响应消息中携带用户终端发送RTSP消息的初始Cseq值可以通过SIP头域或SDP携带。例如：通过Contact头域携带(也可以通过其它头域携带，在此就不一一举例)，定义Contact头域的参数rcseq携带；通过SDP携带，定义一个媒体级别的属性行a＝rtsp_init_cseq:<number of cseq>。

需要说明的是，上述流程505～506步骤中是SIP 200OK响应消息，实际流程中也可能是SIP 180或183等响应消息，本发明并不限定在何种响应消息中携带。

2、方案二

可以如图6所示，增强PSS Adapter的功能：PSS Adapter收到用户终端发送的RTSP消息，保存RTSP消息中的Cseq值，并替换为PSS Adapter与PSS Server间对应RTSP会话的正确的Cseq的值，将修改后的RTSP消息转发给PSS Server。PSS Adapter收到PSS Server返回RTSP响应消息，将响应消息中的Cseq值替换为保存的Cseq值。

3、方案三

增强用户终端的功能：用户终端产生的RTSP消息的Cseq初始值为一个较大值，该较大值定义为大于N的值，N为PSS Adapter向用户终端返回SIP200OK响应消息前，PSS Adapter基于SETUP消息创建的RTSP Session ID向PSS Server发送的RTSP消息个数。比如说，实际组网应用中，N值不会大于10，那么这个较大值可以定义为10或大于10的数。

PSS Adapter可以连接多个PSS Server，而多个PSS Server产生的RTSPSession ID(RTSP会话标识)可能会相同，会导致PSS Adapter无法正确转发用户终端发送的RTSP消息给PSS Server。

为此，可以进行以下两种方案的改进：

1、方案一

可以如图7所示，增强PSS Adapter的功能：PSS Adapter向PSS Server发送SETUP消息建立RTSP会话，收到PSS Server返回的200OK响应消息，携带RTSP Session ID，PSS Adapter产生一个新的ID(标识)，定义为PA ID，并保证PA ID值在PSS Adapter上是唯一的，PSS Adapter保存并关联PA ID和200OK带回来的RTSP Session ID，PSS Adapter将PA ID返回给用户终端。用户终端发送RTSP消息时携带PA ID，PSS Adapter收到用户终端的RTSP消息时，根据消息中的PA ID匹配到本地关联的RTSP Session ID，PSS Adapter向PSS Server转发RTSP消息时，将PAID替换成RTSP Session ID。PSS Adapter收到PSS Server返回的RTSP响应消息时，将响应消息中的RTSP Session ID替换成PA ID，再将响应消息转发给用户终端。

2、方案二

增强PSS Adapter的功能：PSS Adapter收到用户终端发送的RTSP消息时，需要增加对RTSP消息中的rtsp url(rtsp资源定位标识)进行消息转发的判断，也就是PSS Adapter根据RTSP消息中的rtsp url判断RTSP消息转发给哪个PSS Server。

综合上述解决方案，如图8所示，是本发明的实施例四，本实施例中，由用户终端通过SIP SDP协商初始RTSP PLAY消息发送，通过SIP协商快速内容切换。包括：

801～802、用户终端发送INVITE消息，经过SCF路由到PSS Adapter，SDP Offer中rtsp_initplay值填either，表示初始RTSP PLAY消息的发送权由PSS Adapter决定；

SDP Offer:

v＝0

o＝Bob 40000000 40000001 IN IP4 Ue.example.com

s＝

c＝IN IP4Ue.example.com

t＝00

m＝video 40100RTP/AVP 3132

a＝rtpmap:31 H261/90000

a＝label:1

m＝application 9TCP/RTSP rtsp

a＝fmtp:rtsp version:2.0

a＝fmtp:rtsp h-accept-ranges:NPT

a＝connection:new

a＝setup:active

a＝rtspid m-stream:1

a＝rtsp_initplay:either

803、PSS Adapter根据INVITE消息的内容构造RTSP SETUP消息Cseq取值为1，发送给PSS Server；

804、PSS Server接收PSS Adapter的RTSP SETUP消息，创建RTSP会话，通过RTSP 200OK响应消息向PSS Adapter返回RTSP Session ID；

805～806、PSS Adapter收到PSS Server的RTSP 200OK响应消息，保存消息中的RTSP Session ID值(114554544)，产生一个唯一的PA ID值(32524545)保存并与RTSP Session ID关联，PSS Adapter决定发送初始RTSPPLAY消息，将SDP Answer中的rtsp_initplay值填send_play，rtsp_init_cseq值填3；PSS Adapter通过SIP Supported头域向用户终端返回PSS Server的媒体能力；PSS Adapter构造SIP 200OK响应消息通过SCF路由到用户终端；

SIP/2.0 200OK

...

Supported:3gpp-pipelined，3gpp-switch

Content-Type:application/sdp

Content-Length:...

v＝0

o＝adapter 20000000 20000001 IN IP4 adapter.example.com

s＝

c＝IN IP4 adapter.example.com

t＝00

m＝video 50100RTP/AVP 3132

a＝rtpmap:31 H261/90000

a＝label:1

m＝application 60000TCP/RTSP rtsp

a＝fmtp:rtsp version:2.0

a＝fmtp:rtsp h-accept-ranges:NPT

a＝connection:new

a＝setup:passive

a＝rtspid m-stream:1

a＝fmtp:rtsp h-session:32524545 /*RTSP Session ID被替换成

PA ID＝32524545*/

a＝rtsp_initplay:send_play

a＝rtsp_init_cseq:3

807～808、用户终端返回ACK确认200OK响应消息；

809、PSS Adapter向PSS Server发送初始PLAY消息携带RTSP Session ID(114554544)，Cseq值为2；

810、PSS Server接收PSS Adapter的RTSP PLAY消息，返回200OK响应消息，向用户终端发送媒体流；

811、用户终端向PSS Adapter发送RTSP PAUSE消息携带PA ID(32524545)，Cseq填3；

812、PSS Adapter收到用户终端的RTSP PAUSE消息，根据消息中的PA ID(32524545)值匹配到关联的RTSP Session ID(114554544)值，用RTSP SessionID替代RTSP PAUSE消息中的PAID，将RTSP PAUSE消息转发给PSS Server；

813、PSS Server执行RTSP PAUSE的请求，返回200OK响应；

814、PSS Adapter收到200OK响应，将响应消息中的RTSP Session ID(114554544)替换成PA ID(32524545)，转发修改后的响应消息给用户终端；

上述实施例中，Cseq是采用透传的方式，采用问题一方案二中PSS Adapter代理Cseq的方式在该实施例中也是可行的，在此就不再重复。

本实施例还解决了以下两个问题：

Cseq重复问题和RTSP会话标识重复问题，出现Cseq重复会导致消息发送失败；出现RTSP会话标识重复会导致会话建立失败。实施例四能够避免消息发送失败和会话建立失败。

如图9所示，是本发明的媒体服务能力协商的用户终端，包括：

第一协商单元901，用于通过SIP会话发起协议，与网络控制实体协商媒体服务能力；

第一设置单元902，用于根据第一协商单元的协商结果，确定初始RTSP播放消息的发送端。

其中，所述第一协商单元包括：

第一返回模块，用于收到网络控制实体的SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP播放消息的指示；

第一确定模块，用于根据预置协商规则处理所述会话请求消息和会话响应消息，确定所述初始RTSP播放消息的发送端。

其中，所述协商规则至少包括如下之一或其任意组合：

A、会话请求消息携带发送初始RTSP播放消息的指示，会话响应消息携带不发送初始RTSP播放消息的指示，所述协商结果为：由所述会话请求消息发送端发送所述初始RTSP播放消息；或

B、会话请求消息不携带发送初始RTSP播放消息的指示，会话响应消息中携带发送初始RTSP播放消息的指示，所述协商结果为：由所述会话响应消息发送端发送所述初始RTSP播放消息；或

C、会话请求消息携带允许发送或不发送初始RTSP播放消息的指示，且会话响应消息中携带发送所述初始RTSP播放消息的指示，所述协商结果为：由所述会话响应消息发送端发送所述初始RTSP播放消息；或

会话响应消息中携带不发送所述初始RTSP播放消息的指示，所述协商结果为：由所述会话请求消息发送端发送所述初始RTSP播放消息。

其中，所述第一确定单元包括：

第二确定模块，用于如果协商结果由所述用户终端发送所述初始RTSP播放消息，将用户终端的初始RTSP状态设置为初始状态；

第三确定模块，用于如果协商结果由所述网络控制实体发送所述初始RTSP播放消息，则将所述用户终端的初始RTSP状态设置为播放状态。

其中，所述第一协商单元还包括：

第一接收模块，用于接收网络控制实体的会话请求消息或会话响应消息，所述会话请求消息和会话响应消息都携带由网络控制实体或用户终端发送初始RTSP播放消息的指示，所述指示用于确定所述协商结果；

第四确定模块，用于根据所述初始RTSP播放消息的指示，确定由网络控制实体或用户终端发送所述初始RTSP播放消息。

其中，所述第四确定模块包括：

第一确定子模块，用于如果确定由所述用户终端发送所述初始RTSP播放消息，设置用户终端的RTSP状态为初始状态；

第二确定子模块，用于如果确定由所述网络控制实体发送所述初始RTSP播放消息，则将所述用户终端的RTSP状态设置为播放状态。

这样能够使终端的RTSP状态与网络服务器侧的RTSP状态保持一致，如果终端状态与网络服务器侧状态不一致会导致终端媒体流播放失败。

如图10所示，是本发明的媒体服务能力协商的网络控制实体，包括：

第二协商单元1001，用于通过SIP会话发起协议，与用户终端协商媒体服务能力；

第二设置单元1002，用于根据协商结果，确定初始RTSP播放消息的发送端。

其中，所述第二协商单元包括：

第二返回模块，用于收到SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP播放消息的批示；

第五确定模块，用于根据预置协商规则处理所述会话请求消息和会话响应消息，得到协商结果。

其中，所述协商规则至少包括如下之一或其任意组合：

其中，所述第二协商单元包括：

第一发送模块，用于向用户终端发送SIP会话请求消息或返回会话响应消息，所述会话请求消息和会话响应消息都携带由网络控制实体或用户终端发送初始RTSP播放消息的指示；

第六确定模块，用于根据所述初始RTSP播放消息的指示，确定协商结果。

如图11所示，是本发明的媒体服务能力协商的系统，包括：

用户终端1101和网络控制实体1102，其中，所述用户终端包括：

第一设置单元902，用于根据第一协商单元的协商结果，确定初始RTSP播放消息的发送端；

所述网络控制实体包括：

第二设置单元1002，用于根据协商结果，确定是否由网络控制实体发送初始RTSP播放消息。

利用本发明的系统和装置实施例，能够实现在移动电视系统中进行媒体服务能力协商。

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

以上所述的本发明实施方式，并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims

1.一种媒体服务能力协商的方法，其特征在于，包括：

根据协商结果，确定初始RTSP播放消息的发送端。

2.如权利要求1所述的方法，其特征在于，所述网络控制实体通过会话发起协议，与用户终端协商媒体服务能力包括：

网络控制实体收到SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP播放消息的指示；

3.如权利要求2所述的方法，其特征在于，所述协商规则至少包括如下之一或其任意组合：

会话请求消息携带发送初始RTSP播放消息的指示，会话响应消息携带不发送初始RTSP播放消息的指示，所述协商结果为：由所述会话请求消息发送端发送所述初始RTSP播放消息；或

会话请求消息不携带发送初始RTSP播放消息的指示，会话响应消息中携带发送初始RTSP播放消息的指示，所述协商结果为：由所述会话响应消息发送端发送所述初始RTSP播放消息；或

会话请求消息携带允许发送或不发送初始RTSP播放消息的指示，且会话响应消息中携带发送所述初始RTSP播放消息的指示，所述协商结果为：由所述会话响应消息发送端发送所述初始RTSP播放消息；或

4.如权利要求2所述的方法，其特征在于，所述根据协商结果，确定初始RTSP播放消息的发送端包括：

5.如权利要求1所述的方法，其特征在于，所述网络控制实体通过会话发起协议，与用户终端协商媒体服务能力包括：

6.如权利要求5所述的方法，其特征在于，所述根据协商结果，确定初始RTSP播放消息的发送端包括：

7.如权利要求5所述的方法，其特征在于，所述初始RTSP播放消息包含在SIP消息头域内，或包含在SIP消息体内，或包含在扩展SDP属性内，或包含在XML格式的消息体内。

8.一种媒体服务能力协商的用户终端，其特征在于，包括：

9.如权利要求8所述的用户终端，其特征在于，所述第一协商单元包括：

10.如权利要求9所述的用户终端，其特征在于，所述协商规则至少包括如下之一或其任意组合：

11.如权利要求9所述的用户终端，其特征在于，所述第一确定单元包括：

第二确定模块，用于如果协商结果由所述用户终端发送所述初始RTSP播放消息，将用户终端的RTSP状态设置为初始状态；

第三确定模块，用于如果协商结果由所述网络控制实体发送所述初始RTSP播放消息，则将所述用户终端的RTSP状态设置为播放状态。

12.如权利要求9所述的用户终端，其特征在于，所述第一协商单元还包括：

13.如权利要求12所述的用户终端，其特征在于，所述第四确定模块包括：

14.一种媒体服务能力协商的网络控制实体，其特征在于，包括：

15.如权利要求14所述的网络控制实体，其特征在于，所述第二协商单元包括：

第二返回模块，用于收到SIP会话请求消息后，返回SIP会话响应消息，所述会话请求消息和会话响应消息都携带是否发送初始RTSP播放消息的指示；

16.如权利要求15所述的网络控制实体，其特征在于，所述协商规则至少包括如下之一或其任意组合：

17.如权利要求15所述的网络控制实体，其特征在于，所述第二协商单元包括：

第六确定模块，用于根据所述RTSP播放消息的指示，确定协商结果。

18.一种媒体服务能力协商的系统，其特征在于，包括：

用户终端和网络控制实体，其中，所述用户终端包括：

所述网络控制实体包括：