CN101222418A

CN101222418A - Rtsp客户端访问sip媒体资源的方法、系统及信令网关

Info

Publication number: CN101222418A
Application number: CNA2007100032750A
Authority: CN
Inventors: 魏启坤; 陈建; 管红光
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-01-10
Filing date: 2007-02-02
Publication date: 2008-07-16

Abstract

本发明实施例公开了一种RTSP客户端访问SIP媒体资源的方法，该方法通过建立RTSP(实时流协议)客户端与目的SIP(会话发起协议)媒体设备之间的会话；根据建立的会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端，实现RTSP客户端对SIP媒体资源的访问。本发明实施例还基于上述方法，公开了一种RTSP客户端访问SIP媒体资源的系统及信令网关，以实现RTSP客户端对SIP媒体资源的访问。本发明实施例技术方案的实现，有助于实现IMS与IPTV的融合。本发明实施例提供的技术方案基于现有RTSP协议和SIP协议，能够兼容原有支持RTSP的媒体终端。

Description

RTSP客户端访问SIP媒体资源的方法、系统及信令网关

技术领域

本发明涉及通信技术领域，尤其涉及一种实时流协议(RTSP)客户端访问会话发起协议(SIP)媒体资源的方法、系统及信令网关。

背景技术

RTSP是基于服务器/客户端架构，专用于媒体点播控制的协议。RTSP2.0版本定义了RTSP媒体点播方法(method)，用以表示RTSP控制媒体点播时所需要具备的功能。其中RTSP method包括：建立会话(SETUP)、播放(PLAY)、暂停播放(PAUSE)、媒体描述(DESCRIBE)、获取参数(GET_PARAMETER)、性能查询(OPTIONS)、重定向(REDIRECT)、参数设置(SET_PARAMETER)和会话结束(TEARDOWN)等。RTSP采用上述method来对媒体流传输进行控制时，其控制对象采用代表媒体链接的RTSP统一资源标识符(URI)来标识，如“rtsp://audio.example.com/audioRTSP/2.0”。

SIP是由网络工程任务组(IETF)提出的IP电话信令协议。SIP也定义SIP会话方法method，用以表示SIP控制会话时所需要具备的功能，如注册(REGISTER)、请求(INVITE、)更新(UPDATE)、性能查询(OPTIONS)、重定向(REFER)、确认(ACK)、更改(NOTIFY)、通知(INFO)、MESSAGE(消息)、签约(SUBSCRIBE)和BYE(结束)。SIP的控制对象采用代表客户端的SIP URI标识，如“sips:bob@biloxi.example.comSIP/2.0”。

鉴于RTSP与SIP的method在功能上具有诸多共同点，因此，IETF提出融合RTSP与SIP的设想。但若要实现RTSP与SIP的融合，则需要对该两种协议做较大的改动。由于目前希望实现RTSP与SIP融合的需求尚不足，因此，融合RTSP与SIP的设想尚未能实现。

虽然希望实现RTSP与SIP融合的需求不足，但有时会出现RTSP客户端希望访问SIP客户端或者SIP系统的媒体资源的情况。如RTSP客户端希望浏览SIP移动终端上摄像头采集的图像，但RTSP客户端只支持RTSP，作为SIP客户端的SIP移动终端只支持SIP，因此，RTSP客户端并不能访问SIP客户端上的媒体资源。再如，IPTV中的媒体点播常采用RTSP来实现。而由于IMS具有强大的对用户管理的功能、支持多媒体会话的功能、对业务逻辑控制等功能，可利用IMS的架构来实现IPTV的功能。这种情况下，若RTSP客户端希望访问SIP系统中的媒体资源时，由于IMS的业务控制协议采用SIP协议，并不支持RTSP，因此，RTSP客户端并不能访问SIP系统中的媒体资源。

因此，现有技术存在的问题是，在存在RTSP客户端要求访问SIP媒体资源的需求的情况下，未能实现RTSP客户端对SIP媒体资源的访问。

发明内容

有鉴于此，本发明实施例提供一种RTSP客户端访问SIP媒体资源的方法，实现RTSP客户端对SIP媒体资源的访问。

本发明实施例还提供一种信令网关，实现RTSP客户端对SIP媒体资源的访问。

本发明实施例还提供一种RTSP客户端访问SIP媒体资源的系统，实现RTSP客户端对SIP媒体资源的访问。

一种RTSP客户端访问SIP媒体资源的方法，包括步骤：

建立RTSP客户端与目的SIP媒体设备之间的会话；

根据建立的所述会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端。

一种信令网关，包括：第一接收模块、第一消息转换模块和第一发送模块；其中，

第一接收模块，用于接收RTSP客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息；

第一消息转换模块，用于将所述RTSP消息转换为对应的SIP消息，或将所述SIP响应消息转换为对应的RTSP响应消息；以及

第一发送模块，用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备，或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。

一种RTSP客户端访问SIP媒体资源的系统，包括：

RTSP客户端、目的SIP媒体设备和信令网关；其中，

信令网关，包括：第一接收模块、第一消息转换模块和第一发送模块；其中，

本发明实施例提供RTSP客户端访问SIP媒体资源的方法，通过在RTSP客户端与目的SIP媒体设备之间的建立会话；根据建立的所述会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端，从而实现RTSP客户端对SIP媒体资源的访问。

本发明实施例提供的信令网关能够将RTSP客户端发送的RTSP请求消息转换为对应的SIP请求消息后，发送给SIP媒体设备；也能够将SIP媒体设备返回的响应消息转换为对应的RTSP响应消息后，发送给RTSP客户端；通过该信令网关的消息转换功能，在RTSP客户端与目的SIP媒体设备之间的建立会话，进而实现RTSP客户端对SIP媒体资源的访问。

本发明实施例提供的RTSP客户端访问SIP媒体资源的系统中，包含RTSP客户端、目的SIP媒体设备和上述信令网关，通过该信令网关建立RTSP客户端与目的SIP媒体设备之间的会话，进而实现RTSP客户端对SIP媒体资源的访问。

附图说明

图1是本发明实施例RTSP客户端访问SIP媒体资源的方法总体流程图；

图2是本发明实施例RTSP客户端访问SIP媒体资源的系统结构示意图；

图3是本发明实施例1中RTSP客户端访问SIP客户端的流程图；

图4是本发明实施例2中RTSP客户端访问SIP客户端的流程图；

图5是本发明实施例3中处理暂停媒体播放的流程图；

图6是本发明实施例4中处理重定向SIP客户端的流程图；

图7是本发明实施例5中RTSP客户端请求查询媒体描述的流程图；

图9是本发明实施例7中处理会话结束的流程图；

图8是本发明实施例中处理性能查询的流程图；

图10是本发明实施例8中处理会话结束的流程图；

图11是本发明中的RTSP客户端访问SIP媒体资源方案的应用场景图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图作进一步详细描述。

本发明实施例提供一种RTSP客户端访问SIP媒体资源的方法。参见图1，图1是本发明实施例的方法总体流程图。该流程包括以下步骤：

步骤101、建立RTSP客户端与目的SIP媒体设备之间的会话。

步骤102、根据建立的上述会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端。

其中，目标SIP媒体设备可以是SIP客户端，如：SIP终端或SIP应用服务器，或其他基于SIP协议控制的终端或系统。

本发明实施例基于上述方法，提供一种信令网关。该信令网关用于接收RTSP客户端发送的RTSP消息，将该RTSP消息转换为对应的SIP消息后，发送给目的SIP媒体设备；接收目的SIP媒体设备返回的与该SIP消息对应的SIP响应消息，将该SIP响应消息转换为对应的RTSP响应消息后，发送给RTSP客户端；其中，RTSP请求消息包括在建立RTSP客户端与SIP媒体设备之间的会话时，RTSP客户端发送的RTSP请求建立会话消息。

信令网关可包括：第一接收模块、第一消息转换模块和第一发送模块；其中，

信令网关进一步包括：存储模块，用于存储目前RTSP客户端、RTSPURI、RTSP会话标示符、SIP客户端、SIP URI、SIP会话标识符的对应关系。

信令网关进一步包括：第二接收模块、第二消息转换模块和第二发送模块；其中，

第二接收模块，用于接收目的SIP媒体设备发送的SIP消息以及RTSP客户端返回的RTSP响应消息；

第二消息转换模块，用于将所述SIP消息转换为对应的RTSP消息，或将所述RTSP响应消息转换为对应的SIP响应消息；以及

第二发送模块，用于将经所述第二消息转换模块转换而得的RTSP消息对应发送给所述RTSP客户端，或将经所述第二消息转换模块转换而得的SIP响应消息对应发送给所述目的SIP媒体设备；

上述SIP请求消息包括：要求结束本次会话的SIP请求消息，或，要求将本次会话重定向到另一个SIP媒体设备的SIP请求消息。

参见表1，表1是RTSP method与SIP method的功能对照表。本发明实施例中，为使信令网关能够实现RTSP消息与SIP消息的转换，可将表1存放在信令网关中，信令网关根据该表进行RTSP消息与SIP消息的转换。

RTSP method	SIP method	功能解释
RTSP method	SIP method	功能解释	SETUP	INVITE	建立会话
SETUP	INVITE or UPDATE	添加一条媒体流到已存在的会话	SETUP	INVITE	建立会话
SETUP	INVITE or UPDATE	添加一条媒体流到已存在的会话	PLAY	INVITE or UPDATE	播放(开始媒体流传输)
PAUSE	INVITE or UPDATE	暂停媒体流传输	PLAY	INVITE or UPDATE	播放(开始媒体流传输)
PAUSE	INVITE or UPDATE	暂停媒体流传输	TEARDOWN	BYE	RTSP客户端主动发起的结束会话
REDIRECT	BYE	SIP客户端主动发起的结束会话	TEARDOWN	BYE	RTSP客户端主动发起的结束会话
REDIRECT	BYE	SIP客户端主动发起的结束会话	OPTIONS	OPTIONS	获取对端支持的性能
DESCRIBE	OPTIONS	获取媒体描述信息	OPTIONS	OPTIONS	获取对端支持的性能
DESCRIBE	OPTIONS	获取媒体描述信息	REDIRECT	REFER	SIP客户端要求对端重定向到另外一个位置去获取需要的资源。

表1

由于本发明实施例可实现的是RTSP客户端访问SIP媒体资源，因此，在本发明实施例中，信令网关能够处理RTSP客户端主动发出的信令消息，而对于SIP媒体设备主动发送的部分信令消息，若信令网关不能够支持时，会向SIP媒体设备返回不支持此信令消息功能的消息。

在本发明实施例中，在信令网关与目标SIP媒体设备之间还存在一个现有的SIP代理(Proxy)。通常，现有SIP Proxy是SIP系统中必需的设备，该SIP Proxy用于路由SIP消息到目的地，和用于路由SIP响应到SIP客户端。在信令网关与RTSP客户端之间也可存在一个RTSP Proxy。通常，现有RTSP系统中还可包括RTSP Proxy，该RTSP Proxy用于路由消息到RTSP服务器，和用于路由RTSP响应消息到RTSP客户端。在本发明实施例中，为突出实现本发明实施例目的所采取的措施，在下文的各具体实施例中，将该Proxy忽略，即在具体实现时，信令网关与SIP客户端之间的消息交互可通过SIP Proxy路由到对端。

信令网关可以是一个独立的设备，也可以是一个内嵌于RTSP Proxy或SIP Proxy的功能模块。

本发明实施例还基于上述方法，提供一种RTSP客户端访问SIP媒体资源的系统。参见图2，图2是本发明实施例中该系统的结构示意图，该系统包括RTSP客户端、目的SIP媒体设备和上述信令网关。在该系统中，通过该信令网关建立RTSP客户端与目的SIP媒体设备之间的会话，进而实现RTSP客户端对SIP媒体资源的访问。在RTSP客户端与目的SIP媒体设备之间建立会话后，目的SIP媒体设备可采用实时传输协议(RTP)向RTSP客户端传输媒体流。

实施例1：

参见图3，图3是本发明实施例1中RTSP客户端访问SIP客户端的流程图。该流程包括以下步骤：

步骤301、RTSP客户端发送SETUP请求(Request)消息。

该步骤中，RTSP客户端发送的SETUP Request用于向接收该消息的一方请求建立会话。该SETUP Request消息中包含被点播的第一条媒体流的RTSP URI、传输方式、编解码格式、传输媒体流的IP地址及端口等会话描述信息，该IP地址是RTSP客户端用于接收媒体流的地址。

步骤302、信令网关接收到该RTSP SETUP Request消息后，向SIP客户端发送。

该步骤中，信令网关接收到SETUP Request消息后，查询与RTSP URI对应的SIP URI，如RTSP URI“rtsp://server.chicago.com/carol/audio”对应SIP URI“sip:carol@chicago.com”，再将RTSP SETUP Request消息转换为SIP INVITE Request消息后，向与该SIP URI对应的SIP客户端发送该SIPINVITE Request消息。

本实施例中，可采用常规的查询做法来查询与RTSP URI对应的SIPURI，如到一个专门配置有RTSP URI与SIP URI的对应关系的数据库查询，或者到DNS服务器查询。

将RTSP SETUP Request消息转换为SIP INVITE Request消息的做法可以是：解析RTSP SETUP Request消息的发送者、接收者及消息内容等信息，将该信息填充到，构造该SIP INVITE Request消息。其中，消息内容包括RTSP客户端点播的第一条媒体流的会话描述信息，信令网关将该被点播的第一条媒体流的会话描述信息添加到SIP INVITE Request消息，且将该媒体流的传输属性设置为SIP“非激活状态(Inactive)”，该“Inactive”表示目前只是分配好传输媒体流的资源，暂时不需要传输该媒体流。设置“Inactive”属性的原因是：SIP的INVITE method可以在对话建立之后立即开始向请求的发起方发送媒体流；而RTSP的SETUP method仅用于创建会话，分配媒体传输资源，在会话建立后，并不需要媒体流的发送方立即发送媒体流，等到RTSP的PLAY method时才需要发送方发送媒体流。因此，为了确保RTSP和SIP的兼容，在SIP的INVITE method中，先把媒体流属性置为“inactive”，表示暂不需要媒体流的发送方发送媒体流。

该步骤中，信令网关需要产生一个SIP CALL-ID，该SIP CALL-ID用于唯一标识信令网关与SIP客户端之间的该会话。采用CALL-ID唯一标识会话的技术为可实现的现有技术，其中，信令网关可以依据该会话的某信息如发起会话建立的时间等产生该SIP CALL-ID，或可随机产生该SIP CALL-ID，且将该SIP CALL-ID添加到SIP INVITE Request消息。由于信令网关与SIP客户端之间可能存在多个会话，因此，后续信令网关与SIP客户端之间关于本次会话的所有交互消息中，都需要包含该SIP CALL-ID，以与其他会话相区别。

步骤303、SIP客户端接收到SIP INVITE Request后，回复SIP INVITEResponse。

该步骤中，SIP客户端回复的SIP INVITE Response消息中包含媒体流的传输方式、发送媒体流的源地址及端口等信息，且该消息中，媒体流的传输属性置也被置为“Inactive”，表示会话建立成功后，暂时不传输媒体流。

若SIP客户端不接收该SIP INVITE Request，则会回复表示会话建立失败的消息。

步骤304、信令网关接收到SIP INVITE Response后，向RTSP客户端回复RTSP SETUP Response。

该步骤中，信令网关回复RTSP SETUP Response消息中包含会话建立成功的信息。若信令网关接收到SIP客户端回复的会话建立失败的消息时，信令网关也将向RTSP客户端回复RTSP SETUP Response，该RTSP SETUPResponse中包含会话建立失败的信息。

该步骤中，信令网关需要产生一个RTSP Session ID，该RTSP Session ID用于唯一标识信令网关与RTSP客户端之间的该会话。采用Session ID唯一标识会话的技术为可实现的现有技术，其中，信令网关可以依据该会话的某信息如发起会话建立的时间等产生该RTSP Session ID，或可随机产生该RTSP Session ID，且将该RTSP Session ID添加到RTSP SETUP Response。由于信令网关与RTSP客户端之间可能存在多个会话，因此，后续信令网关与RTSP客户端之间关于本次会话的所有交互消息中，都需要包含该RTSPSession ID，以与其他会话相区别。

步骤305、信令网关向SIP客户端发送SIP ACK消息，确认会话建立。

需要说明的是，在本发明各实施例中，信令网关的存储单元上会存储目前RTSP客户端、RTSP Session ID、SIP客户端、SIPCALL-ID的对应关系，信令网关根据当前RTSP客户端、RTSP会话标识符、SIP客户端、SIP会话标识符的对应关系，确定本次会话所对应的对端及对端的会话标识符。该对应关系可以形成一个会话关系表。每当一个会话成功建立后，都要把相应条目添加到会话关系表。这样从某个RTSP客户端收到了某个会话的消息后，可以对应到某个SIP客户端的某个会话。因为一个RTSP客户端和信令网关之间可能存在多个会话，一个SIP客户端和信令网关之间也可能存在多个会话，所以可用会话关系表来区别具体的会话。

本实施例中，需将本RTSP客户端、RTSP Session ID和SIP客户端、SIP CALL-ID作为一个新增条目放入会话关系表。

上述步骤301至步骤305，是通过信令网关建立RTSP客户端与SIP客户端之间的会话的过程，若本次会话只涉及一条媒体流传输，那么至此会话建立完成，可直接执行步骤310。若本次会话涉及多条媒体流传输，则继续执行步骤306。

步骤306、RTSP客户端发送第二个RTSP SETUP Request消息。

该步骤的执行，表示本次会话中涉及多条媒体流传输。该第二个RTSPSETUP Request消息是RTSP客户端要求添加媒体流的RTSP请求消息，该消息中包含第二条媒体流的RTSP URI、传输方式、目的地址及端口等会话信息，并且，在该第二个RTSP SETUP Request消息中，需要包含步骤304中产生的RTSP Session ID。这样，信令网关在接收到该第二个SETUPRequest后，根据该RTSP Session ID，确定本次SETUP method是请求向已存在的会话中添加媒体流，而不是建立新的会话。

步骤307、信令网关接收到该第二个RTSP SETUP Request消息，向SIP客户端发送SIP UPDATE Request消息。

该步骤中，信令网关即根据该第二个SETUP Request中的RTSP SessionID，确定该SETUP method是请求向已存在的会话中添加媒体流，因此，向SIP客户端发送要求更新会话属性的SIP UPDATE Request。该步骤中，信令网关在将RTSP SETUP Request消息转换为SIP UPDATE Request消息时，要把本次请求添加的媒体流的会话描述信息及之前已添加的媒体流的会话描述信息全部添加到该SIP INVITE Request消息体的描述中，且将消息体中描述的所有媒体流的属性置为“Inactive”，表示目前只分配了传输媒体流的资源，暂时不需要传输媒体流。与执行步骤302类似，该步骤中，考虑到在访问SIP媒体资源时，被访问的SIP客户端可能是一个媒体服务器，因此，信令网关同样需要将每个媒体流的RTSP URI添加到SIP UPDATE Request中，这样，SIP媒体服务器在接收到该SIP UPDATE Request后，就可以确认RTSP客户端希望访问的SIP媒体设备的地址。如本次添加的是第二条媒体流，那么信令网关需要将第一条媒体流的RTSP URI“a＝control:rtsp://server.chicago.com/carol/audio”和第二条媒体流的RTSP URI“a＝control:rtsp://server.chicago.com/carol/video”均添加到该第二条SIPUPDATE Request中。信令网关还需在该SIP UPDATE Request中添加到与执行步骤302时产生的SIP CALL-ID，以标识该SIP UPDATE Request是本次会话中的消息。

步骤308、SIP客户端接收到SIP UPDATE Request后，回复SIP UPDATEResponse。

该步骤中，SIP客户端回复的SIP UPDATE Response消息中，包含已被添加的所有媒体流的传输方式、源地址、端口等信息，且该消息中还包含将所有媒体流属性置为“Inactive”的标识，表示在会话建立成功后，暂不需要发送媒体流。

该步骤中，若SIP客户端不接收SIP UPDATE Request的更新请求，则将回复更新失败的消息。

步骤309、信令网关接收到SIP客户端回复的SIP UPDATE Response后，向RTSP客户端回复RTSP SETUP Response。

该步骤中，信令网关通知RTSP客户端媒体流添加成功。若SIP客户端回复更新失败的消息，那么信令网关也相应地向RTSP客户端返回添加媒体流失败的消息。

步骤310、会话建立成功后，RTSP客户端发送RTSP PLAY Request，请求媒体播放。

若RTSP客户端希望快进或快退媒体，可以在该RTSP PLAY Request消息体中添加相应的控制播放速度的信息头(header)，包括Speed header和Scale header，如“Speed：2.5”表示以正常媒体播放速度的2.5倍速度快进；“Scale：-3.5”，表示以正常媒体播放速度的3.5倍速度快退。Speed和Scale均由现有RTSP协议给出，其中，Speed的值只能取正数，表示快进；Scale的值可以取正数或负数，即可表示快进或快退。

步骤311、信令网关接收到RTSP PLAY Request后，向SIP客户端发送SIP UPDATE Request。

该步骤中，信令网关在发送给SIP客户端的SIP UPDATE Request消息中，将所有被添加的媒体流的属性置为“recvonly”，表示要求开始传送媒体流，且只接收媒体流。若信令网关还从RTSP PLAY Request获取到“Speed”或“Scale”等header信息，则在发送给SIP客户端的SIP UPDATE Request消息体中添加请求快进或快退的信息，如“a＝Speed：2.5”，表示对端要求SIP客户端以正常媒体播放速度的2.5倍速度播放媒体流。

步骤312、SIP客户端接收到SIP UPDATE Request后，回复SIPUPDATE Response。

该步骤中，SIP客户端在SIP UPDATE Response消息体的会话描述中，将上述被添加的所有媒体流的属性置为“发送(sendonly)”，表示SIP客户端只发送媒体流。若SIP客户端功能支持，则可在SIP UPDATE Response消息体的会话描述中，添加一些用于媒体流同步的信息，如ssrc、seq、rtptime等。若SIP客户端能够支持接收到的SIP UPDATE Request中的快进或快退请求，那么SIP客户端根据快进或快退请求，相应地调整传输媒体流的速度；若SIP客户端不能支持快进或快退的功能，则回复表示传输失败的消息。

步骤313、信令网关向RTSP客户端回复RTSP PLAY Response，由RTSP客户端接收该RTSP PLAY Response。

该步骤中，若信令网关从SIP客户端接收到的SIP UPDATE Response消息体的会话描述中包含如ssrc、seq、rtptime等用于媒体流同步的会话描述信息，则将该类信息转换为RTSP能够支持的消息格式，如将该类信息添加到RTSP PLAY Response消息中，发送给RTSP客户端。若SIP客户端返回表示传输失败的消息时，信令网关则向RTSP客户端返回播放请求失败的消息。

本实施例中，上述步骤306至步骤309是添加第二条媒体流的流程，本实施例中，若还需要添加更多条媒体流，那么可重复执行步骤306至步骤309，直至添加完所需要添加的媒体流。

步骤314、根据建立的会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端。

该步骤中，SIP客户端根据与RTSP客户端之间建立的会话，即根据该两端之间的会话协商结果，如媒体流的传输方式等，开始传输媒体流。

该步骤中，SIP客户端采用实时传输协议(RTP)传输媒体流。

上述实施例1中，步骤301至步骤305对应建立RTSP客户端与SIP客户端之间的会话的流程，步骤306至步骤309为可选步骤，是添加多条媒体流的流程，步骤310至步骤313为RTSP客户端请求播放成功的流程，步骤314的执行就开始传输媒体流，即实现了RTSP客户端对SIP客户端媒体资源的访问。

本实施例1至此结束。

实施例2：

实施例2的流程与上述实施例1的流程基本一致，即先建立RTSP客户端与SIP客户端之间的会话，然后在已经建立的会话中添加第二条媒体流，在两端协商成功后，开始传输媒体流。实施例2的流程与实施例1的流程所不同的是，在该实施例2中，当需要继续添加第二条或更多条媒体流时，在与SIP客户端的信令交互过程中，没有采用UPDATE method，而是采用同样具有媒体流更新功能的INVITE method。

参见图4，图4是本发明实施例2中RTSP客户端访问SIP客户端的流程图。该流程包括以下步骤：

步骤401至步骤406的所有描述与步骤301至步骤306的所有描述相同。

步骤407、信令网关接收到该第二个SETUP Request，向SIP客户端发送SIP INVITE Request。

有关该步骤的描述与步骤307的描述类似，所不同的是，需要将有关步骤307的文字描述中的“UPDATE”替换为“INVITE”，并将有关步骤307的文字描述中的“步骤302”替换为“步骤402”。

步骤408、SIP客户端接收到SIP INVITE Request后，回复SIP INVITEResponse。

有关该步骤的描述与步骤308的描述类似，所不同的是，需要将有关步骤308的文字描述中的“UPDATE”替换为“INVITE”。

步骤409、信令网关接收到SIP客户端回复的SIP INVITE Response后，向RTSP客户端回复RTSP SETUP Response。

步骤410、信令网关接收到SIP INVITE Response后，向SIP客户端返回SIP ACK。

该步骤中，信令网关向SIP客户端返回SIP ACK表示确认对端处理了步骤408中SIP客户端回复的SIP INVITE Response。

上述步骤406至步骤410是在同一个会话中添加第二条媒体流的流程，本实施例中，若还需要添加更多条媒体流，那么可重复执行步骤406至步骤410，直至添加完所需要添加的媒体流。

步骤411的所有描述与步骤310的所有描述相同。

步骤412、信令网关接收到RTSP PLAY Request后，向SIP客户端发送SIP INVITE Request。

有关该步骤的描述与步骤311的描述类似，所不同的是，需要将有关步骤311的文字描述中的“UPDATE”替换为“INVITE”。

步骤413、SIP客户端接收到SIP INVITE Request后，回复SIP INVITEResponse。

有关该步骤的描述与步骤312的描述类似，所不同的是，需要将有关步骤312的文字描述中的“UPDATE”替换为“INVITE”。

步骤414、信令网关向RTSP客户端回复RTSP PLAY Response，由RTSP客户端接收该RTSP PLAY Response。

有关该步骤的描述与步骤313的描述类似，所不同的是，需要将有关步骤313的文字描述中的“UPDATE”替换为“INVITE”。

步骤415、信令网关接收到SIP INVITE Response后，向SIP客户端返回SIP ACK。

该步骤中，信令网关向SIP客户端返回SIP ACK表示确认对端处理了步骤413中SIP客户端回复的SIP INVITE Response。

步骤416、SIP客户端根据与对端的协商，开始传输媒体流，本次流程结束。

该步骤中，SIP客户端采用RTP传输媒体流。

本实施例2至此结束。

实施例3：

本实施例将对RTSP客户端主动提出的暂停播放媒体流请求进行处理。“暂停”操作是媒体点播中的常用操作，该操作在RTSP中，由PAUSE method实现。相应地，在SIP中，INVITE或者UPDATE method可实现“暂停”媒体点播的操作。参见图5，图5是本发明实施例3中处理暂停媒体播放的流程图。该流程包括以下步骤：

步骤501、RTSP Client发送RTSP PAUSE Request，请求暂停媒体流传输。

步骤502、信令网关接收到RTSP PAUSE Request后，向SIP客户端发送SIP UPDATE Request。

该步骤中，信令网关根据存储的会话关系表，查询出对应的媒体源SIP客户端，然后向此SIP客户端发送SIP UPDATE Request消息，且信令网关在该消息中将该会话中的所有媒体流属性置为“Inactive”，表示暂停媒体流传输。也就是说，在现有SIP中，通过控制媒体流属性来控制媒体流的传输，即若媒体流属性被置为“inactive”，则表示暂停媒体流传输；若媒体流属性被置为“Sendonly”，则表示开始传输媒体流。

步骤503、SIP客户端接收到SIP UPDATE Request消息后，回复SIPUPDATE Response消息。

该步骤中，SIP客户端接收到上述消息后，将自身的媒体流属性置为“inactive”，停止媒体流传输。

步骤504、信令网关接收到SIP UPDATE Response消息后，向与本会话对应的RTSP Client发送RTSP PAUSE Response消息。

该步骤中，信令网关通知RTSP客户端“暂停”操作成功。若SIP客户端回复暂停操作失败的消息，那么信令网关向RTSP客户端回复相应的“暂停”操作失败的消息。

本实施例中，在SIP中，采用SIP UPDATE method来完成暂停媒体流传输的操作，实际应用中，也可采用具有暂停媒体流传输功能的SIP INVITEmethod来完成该操作。

本实施例3至此结束。

实施例4：

本实施例将对RTSP客户端主动提出的重定向请求进行处理。在讲述本实施例之前，先对相关现有RTSP method及SIP method作简要说明。在如RTSP服务器希望负载均衡等情况下，RTSP服务器会使用RTSP REDIRECTmethod，向RTSP客户端发送重定向消息，通知RTSP客户端从另外一个位置获取需要的资源，如通知RTSP客户端从另外一个媒体服务器点播影片。相应地，在SIP中，SIP REFER method也具有重定向的功能，该重定向通常用于实现呼叫转移，即通知对端将通话从本地客户端转移到另一个客户端上。通常，SIP REFER需要指明重定向的目的地。

由于RTSP的客户端不可能发送重定向消息，所以在本实施中将会出现SIP的客户端主动发送重定向消息的情况。

参见图6，图6是本发明实施例4中处理重定向SIP客户端的流程图。该流程包括以下步骤：

步骤601、SIP客户端发送SIP REFER Request消息。

该步骤中，SIP REFER Request消息用于要求对端把本次会话重定向到另外一个SIP客户端，且该消息中指明重定向的目的地，该目的地通常采用SIP URI格式表示。

步骤602、信令网关接收到SIP REFER Request消息后，向RTSP客户端发送RTSP REDIRECT Request消息。

该步骤中，信令网关根据接收到的消息，解析该消息中包含的重定向目的地的SIP URI。信令网关通过查询，找到与该重定向SIP URI对应的重定向RTSP URI，于是向RTSP客户端发送RTSP REDIRECT Request消息，且将重定向RTSP URI添加到该RTSP REDIRECT Request消息，利用该消息，要求RTSP客户端重定向目的地到映射的RTSP URI获取资源。若信令网关未能根据接收到的消息，找到对应的RTSP URI，则会向SIP客户端回复重定向失败的消息，即在该步骤602之后，执行步骤604。

步骤603、RTSP客户端接收到RTSP REDIRECT Request后，回复RTSPREDIRECT Response消息。

该步骤中，RTSP客户端向对端回复RTSP REDIRECT Response消息，表示结束本次会话，RTSP Client后续将向新的目的地发起建立会话的请求。

步骤604、信令网关接收到RTSP REDIRECT Response消息后，向SIP客户端发送SIP REFER Response，通知SIP客户端本操作完成。

本实施例中，考虑到RTSP客户端不会主动发出重定向的请求，因此，该重定向请求由SIP客户端发出。

本实施例4至此结束。

实施例5：

参见图7，图7是本发明实施例5中RTSP客户端查询媒体描述的流程图。该流程可以在RTSP客户端请求媒体播放之前完成，用于获得目标媒体对象，如SIP客户端的媒体描述信息。该流程包括以下步骤：

步骤701、RTSP客户端发送RTSP DESCRIBE Request。

该步骤中，RTSP通过发送查询媒体描述请求，请求获得所要访问的媒体源的媒体描述信息，常用的SIP媒体描述信息包括：媒体类型、编解码格式、传输方式、传输地址等。

步骤702、信令网关接收到RTSP DESCRIBE Request后，向SIP客户端发送SIP OPTIONS Request。

该步骤中，信令网关根据接收到的RTSP DESCRIBE Request，查询与RTSP URI对应的SIP URI，如“rtsp://server.chicago.com/carol”对应“sip:carol@chicago.com”，信令网关发送的SIP OPTIONS Request消息体的会话描述可以是“OPTIONS sip:carol@chicago.com SIP/2.0”。

步骤703、SIP客户端回复SIP OPTIONS Response。

该步骤中，SIP客户端根据接收到的RTSP DESCRIBE Request，搜集自身的媒体描述信息，将搜集到的媒体描述信息添加到回复给对端的SIPOPTIONS Response中，发送给对端。

步骤704、信令网关接收到RTSP DESCRIBE Response后，向RTSP回复RTSP DESCRIBE Response。

该步骤中，信令网关将接收到的RTSP DESCRIBE Response消息中包含的SIP客户端的媒体描述信息转换成RTSP媒体源的媒体描述格式，回复给RTSP客户端。RTSP客户端默认接收该客户端消息的对端支持RTSP，同样，当RTSP客户端接收到消息时，也默认由支持RTSP的对端发送过来。

本实施例5至此结束。

实施例6：

参见图8，图8是本发明实施例中处理性能查询的流程图。该流程包括以下步骤：

步骤801、客户端向对端发送RTSP OPTIONS Request消息。

该步骤中，若RTSP Client要访问的是媒体服务器，且需要查询该媒体服务器针对具体媒体资源的性能，那么采用OPTIONS method时，需要在RTSP OPTIONS Request消息中添加标识该媒体资源的 URI，如“OPTIONS rtsp://server.chicago.com/carol/audio”；若RTSP Client要访问的是SIP终端，且需要查询该SIP终端的常规性能，即不考虑具体媒体资源的性能时，可采用OPTIONS method，在RTSP OPTIONS Request消息中直接指定对端设备的IP地址，如“OPTIONS 192.168.3.2 RTSP/2.0”。

步骤802、信令网关收到后，向对应的SIP客户端发送。

该步骤中，信令网关根据接收到的RTSP OPTIONS Request消息中包含的RTSP URI或IP地址信息，找出对应的SIP客户端，向对应的SIP客户端发送RTSP OPTIONS Request消息，以查询SIP客户端的常规性能或者具体媒体资源的性能。如“OPTIONS sip:carol@chicago.com SIP/2.0”。

步骤803、SIP客户端接收到SIP OPTIONS Request消息，返回SIPOPTIONS Response消息。

该步骤中，SIP客户端搜集自身支持的性能，如“Allow：INVITE，ACK，CANCEL，OPTIONS，BYE”，回复一个SIP OPTIONS Response消息。若SIP客户端还具有其它性能，可以在该SIP OPTIONS Response消息体的会话描述信息中添加描述，如“a＝Support：play.scale”表示支持快进、快退。

步骤804、信令网关收到SIP OPTIONS Response消息后，向RTSP客户端回复RTSP OPTIONS Response消息。

该步骤中，信令网关将SIP OPTIONS Response消息中包含的SIP的性能描述，映射成RTSP性能描述，如SIP INVITE可以映射成RTSP SETUP、RTSP PLAY、RTSP PAUSE，然后将包含该RTSP性能描述的RTSP OPTIONSResponse消息返回RTSP客户端。

在上述步骤801中，若RTSP客户端只是查询对端设备的常规性能，即只查询SIP客户端的常规性能，那么可采用OPTIONS method，如“OPTIONSRTSP/2.0”；相应地，信令网关接收到该RTSP OPTIONS Request消息后，只需要基于上述表1，将SIP客户端具备的常规功能映射成的RTSP常规性能转发给RTSP Client即可，即在执行步骤801之后，跳转至执行步骤804。

本实施例6至此结束。

实施例7：

本实施例将对RTSP客户端主动提出的结束会话请求进行处理。在会话过程中，RTSP客户端可以使用RTSP TEARDOWN method，向RTSP服务器请求结束某会话，RTSP服务器收到该请求后，会释放分配给本会话的资源，客户端收到服务器的回复后，也会释放本会话所使用的资源，以结束本会话。

参见图9，图9是本发明实施例7中处理会话结束的流程图，该流程包括以下步骤：

步骤901、RTSP客户端发送TEARDOWN Request消息，请求结束本次会话。

步骤902、信令网关收到该消息后，向SIP Client发送SIP BYERequest，请求结束本次会话。

步骤903、SIP客户端回复SIP BYE Response消息，表示同意结束会话。

步骤904、信令网关接收到SIP BYE Response消息后，向RTSP客户端回复RTSP TEARDOWN Response消息，表示结束会话的请求已经处理。

本实施例7至此结束。

实施例8：

本实施例将对SIP客户端主动提出的结束会话请求进行处理。

参见图10，图10是本发明实施例8中处理会话结束的流程图。该流程包括以下步骤：

步骤1001、SIP客户端向对端发送SIP BYE Request消息，请求结束会话。

步骤1002、信令网关接收到SIP BYE Request消息后，向RTSP客户端发送RTSP REDIRECT Request消息。

该步骤中，信令网关发送的RTSP REDIRECT Request消息中并没有指明重定向的目的地，则依据RTSP协议，该RTSP REDIRECT Request消息表示要求RTSP客户端结束本次会话。该做法是可行的，其原因在于，当现有RTSP服务器向RTSP客户端主动发送RTSP REDIRECT Request消息时，若该消息中没有指定重定向的目的地，那么RTSP客户端接收到该消息后，默认需要结束本次会话。因此，在本实施例中，对RTSP客户端而言，获知该消息的发送者并没有实际意义，只要接收到的消息是RTSP客户端支持的RTSP消息，那么RTSP客户端就能够根据现有RTSP协议规定，根据接收到的消息完成相应的操作。

步骤1003、RTSP客户端向信令网关回复RTSP REDIRECT Response消息，表示同意结束本次会话。

步骤1004、信令网关接收到RTSP REDIRECT Response后，向SIP客户端回复SIP BYE Response，表示结束会话的请求执行成功。

本实施例8至此结束。

上述各实施例中，SIP客户端可以是SIP终端，也可以是SIP应用服务器，其中，SIP应用服务器也是利用SIP URI来标识。现有的SIP应用服务器主要提供公共服务功能，如订阅功能、对方会议呼叫中心功能、流媒体服务功能等。

综上所述，本发明实施例提供RTSP客户端访问SIP媒体资源的方法，通过在RTSP客户端与目的SIP媒体设备之间的建立会话；根据建立的所述会话，将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端，从而实现RTSP客户端对SIP媒体资源的访问。

参见图11，图11是本发明中的RTSP客户端访问SIP媒体资源方案的应用场景图，该应用场景为实现IMS与IPTV融合，其中，IMS系统的基本架构遵循现有相关协议，包括：代理呼叫会话控制功能(P-CSCF)、应用服务器(AS)、查询/服务呼叫会话控制功能模块(I/S-CSCF)、多媒体资源功能控制器(MRFC)、多媒体资源功能处理器(MRFP)。该图11所示应用场景也可作为图2所示系统的实施例。对于采用RTSP实现媒体点播的IPTV，与采用SIP控制信令的IMS系统来说，运用本发明实施例提供的上述方法、系统及信令网关，能够实现IPTV的RTSP客户端对IMS系统中媒体资源的访问，因此运用本发明实施例提供的上述技术方案，有助于实现IMS与IPTV的融合。

另外，本发明实施例在实现RTSP客户端访问SIP媒体资源时，并未改动现有RTSP协议，且对SIP协议的改动也很小，即并未改动现有SIP消息头，而只是在一些SIP消息体的会话描述中增加内容，如将RTSP URI添加到SIP INVITE Request消息。因此，本发明实施例提供的技术方案易于实现，且能够兼容原有支持RTSP的媒体终端。

Claims

1.一种RTSP客户端访问SIP媒体资源的方法，其特征在于，包括步骤：

建立实时流协议RTSP客户端与目的会话发起协议SIP媒体设备之间的会话；

2.根据权利要求1所述的方法，其特征在于，所述目的SIP媒体设备包括：SIP终端、SIP应用服务器。

3.根据权利要求1所述的方法，其特征在于，所述建立RTSP客户端与目的SIP媒体设备之间的会话的步骤包括：

根据RTSP客户端发送的RTSP会话建立请求消息，向目的SIP媒体设备发送SIP会话建立请求消息；

在接收到目的SIP媒体设备返回的与所述SIP会话建立请求消息对应的响应消息后，根据该响应消息，向所述RTSP客户端发送与所述RTSP会话建立请求消息对应的响应消息，建立本次会话。

4.根据权利要求3所述的方法，其特征在于，向目的SIP媒体设备发送SIP会话建立请求消息的步骤包括：

根据所述RTSP会话建立请求消息中包含的第一条媒体流的RTSP统一资源标识符URI，查找对应的SIP URI；

将所述RTSP会话建立请求消息转换为对应的SIP会话建立请求消息；

将包含所述SIP URI的SIP会话建立请求消息发送给与该SIP URI对应的所述目的SIP媒体设备。

5.根据权利要求4所述的方法，其特征在于，将所述RTSP会话建立请求消息转换为对应的SIP会话建立请求消息的步骤包括：

将所述RTSP会话建立请求消息中包含的第一条媒体流的会话描述信息添加到所述SIP会话建立请求消息。

6.根据权利要求4所述的方法，其特征在于，向目的SIP媒体设备发送SIP会话建立请求消息的步骤之前进一步包括：

将SIP会话建立请求消息中包含的媒体流传输属性置为非激活状态的步骤。

7.根据权利要求3所述的方法，其特征在于，向目的SIP媒体设备发送SIP会话建立请求消息之前，该方法进一步包括：

产生用于唯一标识本次会话的SIP会话标识符，且将该SIP会话标识符添加到所述SIP会话建立请求消息后，将该SIP会话建立请求消息发送给所述目的SIP媒体设备。

8.根据权利要求7所述的方法，其特征在于，向所述RTSP客户端发送与所述RTSP会话建立请求消息对应的响应消息的步骤包括：

产生用于唯一标识本次会话的RTSP会话标识符，且将该RTSP会话标识符添加到所述响应消息后，将该响应消息发送给所述RTSP客户端。

9.根据权利要求8所述的方法，其特征在于，所述建立本次会话后，该方法进一步包括：

根据RTSP客户端发送的第二条添加媒体流的RTSP请求消息，向目的SIP媒体设备发送更新本次会话的SIP请求消息；

在接收到目的SIP媒体设备返回的与所述SIP请求消息对应的SIP响应消息后，根据所述SIP响应消息，向所述RTSP客户端发送与所述第二条添加媒体流的RTSP请求消息对应的响应消息，更新本次会话。

10.根据权利要求9所述的方法，其特征在于，向目的SIP媒体设备发送用于更新本次会话的SIP请求消息的步骤包括：

将所述RTSP会话建立请求消息中包含的第一条媒体流的会话描述信息，和所述第二条RTSP添加媒体流的请求消息中包含的第二条媒体流的会话描述信息，添加到所述SIP请求消息中，将该SIP请求消息发送给目的SIP媒体设备。

11.根据权利要求10所述的方法，其特征在于，所述会话描述信息包括：

RTSP URI、传输方式、编解码格式、传输媒体流的IP地址和/或端口信息。

12.根据权利要求10所述的方法，其特征在于，向目的SIP媒体设备发送用于更新本次会话的SIP请求消息的步骤进一步包括：

将所述RTSP会话建立请求消息中包含的所述第二条媒体流的传输属性置为非激活状态后，将该SIP请求消息发送给目的SIP媒体设备。

13.根据权利要求9所述的方法，其特征在于，将RTSP客户端请求传输的媒体流传输给该RTSP客户端之前，该方法进一步包括：

根据RTSP客户端的请求传输媒体流的RTSP请求消息，向目的SIP媒体设备发送要求更新会话属性的SIP请求消息；

在接收到目的SIP媒体设备返回的与所述SIP请求消息对应的响应消息后，向RTSP客户端发送与所述RTSP请求消息对应的响应消息。

14.根据权利要求13所述的方法，其特征在于，向目的SIP媒体设备发送要求更新会话属性的SIP请求消息的步骤包括：

将所述SIP请求消息中包含的所有媒体流的传输属性置为发送后，将该SIP请求消息发送给目的SIP媒体设备。

15.根据权利要求3所述的方法，其特征在于，所述目的SIP媒体设备返回的SIP会话建立请求响应消息中，媒体流传输属性被置为非激活状态。

16.根据权利要求1所述的方法，其特征在于，建立RTSP客户端与目的SIP媒体设备之间的会话之前，该方法进一步包括：

根据RTSP客户端要求查询对端性能/对端媒体描述的RTSP请求消息，向目的SIP媒体设备发送要求查询该SIP媒体设备性能/媒体描述的SIP请求消息；

在接收到目的SIP媒体设备返回的与该SIP请求消息对应的响应消息后，向RTSP客户端返回与所述RTSP请求消息对应的响应消息。

17.根据权利要求8所述的方法，其特征在于，建立RTSP客户端与目的SIP媒体设备之间的会话之后，该方法进一步包括：

根据RTSP客户端要求添加媒体流/结束本次会话的RTSP请求消息，向目的SIP媒体设备发送要求更新会话属性/结束本次会话的SIP请求消息；

在接收到目的SIP媒体设备返回的与该SIP请求消息对应的响应消息后，向RTSP客户端返回与所述RTSP请求消息对应的响应消息；

所述更新会话属性的步骤具体包括将所述媒体流传输属性设置为非激活状态。

18.根据权利要求8所述的方法，其特征在于，建立RTSP客户端与目的SIP媒体设备之间的会话之后，该方法进一步包括：

根据目的SIP媒体设备要求结束本次会话的SIP请求消息，向RTSP客户端发送要求结束本次会话的RTSP请求消息；

在接收到返回的与该RTSP请求消息对应的响应消息后，向目的SIP媒体设备返回与所述SIP请求消息对应的响应消息。

19.根据权利要求18所述的方法，其特征在于，所述向RTSP客户端发送要求结束本次会话的RTSP请求消息的步骤具体包括：

向RTSP客户端发送一条不指定目的地的重定向消息。

20.根据权利要求8所述的方法，其特征在于，建立RTSP客户端与目的SIP媒体设备之间的会话之后，该方法进一步包括：

根据目的SIP媒体设备要求对端将本次会话重定向到另一个目的SIP媒体设备的SIP请求消息，向RTSP客户端发送要求重定向本次会话目的地的RTSP请求消息；

21.根据权利要求9、17、18、19或20所述的方法，其特征在于，根据当前RTSP客户端、RTSP会话标识符、SIP客户端、SIP会话标识符的对应关系，确定本次会话所对应的对端及对端的会话标识符。

22.一种信令网关，其特征在于，包括：第一接收模块、第一消息转换模块和第一发送模块；其中，

23.根据权利要求22所述的信令网关，其特征在于，所述信令网关进一步包括：

存储模块，用于存储目前RTSP客户端、RTSP会话标示符、SIP客户端、SIP会话标识符的对应关系。

24.根据权利要求22所述的信令网关，其特征在于，所述信令网关进一步包括：第二接收模块、第二消息转换模块和第二发送模块；其中，

第二发送模块，用于将经所述第二消息转换模块转换而得的RTSP消息对应发送给所述RTSP客户端，或将经所述第二消息转换模块转换而得的SIP响应消息对应发送给所述目的SIP媒体设备。

25.根据权利要求24所述的信令网关，其特征在于，所述SIP请求消息包括：要求结束本次会话的SIP请求消息，或，要求将本次会话重定向到另一个SIP媒体设备的SIP请求消息。

26.一种RTSP客户端访问SIP媒体资源的系统，其特征在于，包括：

RTSP客户端、目的SIP媒体设备和信令网关；其中，