专利名称::Rtsp客户端访问sip媒体资源的方法、系统及信令网关的制作方法
技术领域:
:本发明涉及通信
技术领域:
,尤其涉及一种实时流协议(RTSP)客户端访问会话发起协议(SIP)媒体资源的方法、系统及信令网关。
背景技术:
:RTSP是基于服务器/客户端架构,专用于媒体点播控制的协议。RTSP2.0版本定义了RTSP媒体点播方法(method),用以表示RTSP控制媒体点播时所需要具备的功能。其中RTSPmethod包括建立会话(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的控制对象采用代表客户端的SIPURI标识,如"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客户端对SIP4某体资源的访问。本发明实施例还提供一种信令网关,实现RTSP客户端对SIP媒体资源的访问。本发明实施例还提供一种RTSP客户端访问SIP媒体资源的系统,实现RTSP客户端对SIP媒体资源的访问。一种RTSP客户端访问SIP媒体资源的方法,包括步骤建立RTSP客户端与目的SIPi某体设备之间的会话;根据建立的所迷会话,将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端。一种信令网关,包括第一接收模块、第一消息转换模块和第一发送模块;其中,第一接收模块,用于接收RTSP客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息;第一消息转換模块,用于将所述RTSP消息转换为对应的SIP消息,或将所述SIP响应消息转换为对应的RTSP响应消息;以及第一发送模块,用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备,或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。一种RTSP客户端访问SIP媒体资源的系统,包括RTSP客户端、目的SIP媒体设备和信令网关;其中,信令网关,包括第一接收模块、第一消息转换模块和第一发送模块;其中,第一接收模块,用于接收RTSP客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息;第一消息转换模块,用于将所述RTSP消息转换为对应的SIP消息,或将所述SIP响应消息转换为对应的RTSP响应消息;以及第一发送模块,用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备,或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。本发明实施例提供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是本发明实施例中处理性能查询的流程图;图IO是本发明实施例8中处理会话结束的流程图;图11是本发明中的RTSP客户端访问SIP媒体资源方案的应用场景图。具体实施方式为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图作进一步详细描述。本发明实施例提供一种RTSP客户端访问SIP媒体资源的方法。参见图1,图1是本发明实施例的方法总体流程图。该流程包括以下步骤步骤101、建立RTSP客户端与目的SIP媒体设备之间的会话。步骤1似、根据建立的上述会话,将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客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息;第一消息转换模块,用于将所述RTSP消息转换为对应的SIP消息,或将所述SIP响应消息转换为对应的RTSP响应消息;以及第一发送模块,用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备,或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。信令网关进一步包括存储模块,用于存储目前RTSP客户端、RTSPURI、RTSP会话标示符、SIP客户端、SIPURI、SIP会话标识符的对应关系。信令网关进一步包括第二接收模块、第二消息转换模块和第二发送模块;其中,第二接收模块,用于接收目的SIP媒体设备发送的SIP消息以及RTSP客户端返回的RTSP响应消息;第二消息转换模块,用于将所述SIP消息转换为对应的RTSP消息,或将所述RTSP响应消息转换为对应的SIP响应消息;以及第二发送模块,用于将经所述第二消息转换模块转换而得的RTSP消息对应发送给所述RTSP客户端,或将经所述第二消息转换模块转换而得的SIP响应消息对应发送给所述目的SIP媒体设备;上述SIP请求消息包括要求结束本次会话的SIP请求消息,或,要求将本次会话重定向到另一个SIP媒体设备的SIP请求消息。参见表1,表1是RTSPmethod与SIPmethod的功能对照表。本发明实施例中,为^:信令网关能够实现RTSP消息与SIP消息的转换,可将表l存放在信令网关中,信令网关根据该表进行RTSP消息与SIP消息的转换。<table>tableseeoriginaldocumentpage13</column></row><table>表1由于本发明实施例可实现的是RTSP客户端访问SIP媒体资源,因此,在本发明实施例中,信令网关能够处理RTSP客户端主动发出的信令消息,而对于SIP媒体设备主动发送的部分信令消息,若信令网关不能够支持时,会向SIP媒体设备返回不支持此信令消息功能的消息。在本发明实施例中,在信令网关与目标SIP媒体设备之间还存在一个现有的SIP代理(Proxy)。通常,现有SIPProxy是SIP系统中必需的设备,该SIPProxy用于路由SIP消息到目的地,和用于路由SIP响应到SIP客户端。在信令网关与RTSP客户端之间也可存在一个RTSPProxy。通常,现有RTSP系统中还可包括RTSPProxy,该RTSPProxy用于路由消息到RTSP服务器,和用于路由RTSP响应消息到RTSP客户端。在本发明实施例中,为突出实现本发明实施例目的所采取的措施,在下文的各具体实施例中,将该Proxy忽略,即在具体实现时,信令网关与SIP客户端之间的消息交互可通过SIPProxy路由到对端。信令网关可以是一个独立的设备,也可以是一个内嵌于RTSPProxy或SIPProxy的功能模块。本发明实施例还基于上述方法,提供一种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客户端发送的SETUPRequest用于向接收该消息的一方请求建立会话。该SETUPRequest消息中包含被点播的第一条媒体流的RTSPURI、传输方式、编解码格式、传输纟某体流的IP地址及端口等会话描述信息,该IP地址是RTSP客户端用于接收媒体流的地址。步骤302、信令网关接收到该RTSPSETUPRequest消息后,向SIP客户端发送。该步骤中,信令网关接收到SETUPR叫uest消息后,查询与RTSPURI对应的S!PURI,如RTSPURI"rtsp:〃server.chicago.com/carol/audio"对应SIPURI"sip:earol@chicago.com,,,再将RTSPSETUPRequest消息转换为SIPINVITERequest消息后,向与该SIPURI对应的SIP客户端发送该SIPINVITERequest消息。本实施例中,可采用常规的查询做法来查询与RTSPURI对应的SIPURI,如到一个专门配置有RTSPURI与SIPURI的对应关系的数据库查询,或者到DNS服务器查询。将RTSPSETUPRequest消息转换为SIPINVITER叫uest消息的做法可以是解析RTSPSETUPR叫uest消息的发送者、接收者及消息内容等信息,将该信息填充到,构造该SIPINVITERequest消息。其中,消息内容包括RTSP客户端点播的第一条媒体流的会话描述信息,信令网关将该被点播的第一条々某体流的会话描述信息添加到SIPINVITERequest消息,且将该媒体流的传输属性设置为SIP"非激活状态(Inactive)",该"Inactive"表示目前只是分配好传输媒体流的资源,暂时不需要传输该媒体流。设置"Inactive"属性的原因是SIP的INVITEmethod可以在对话建立之后立即开始向请求的发起方发送媒体流;而RTSP的SETUPmethod仅用于创建会话,分配媒体传输资源,在会话建立后,并不需要媒体流的发送方立即发送媒体流,等到RTSP的PLAYmethod时才需要发送方发送媒体流。因此,为了确保RTSP和SIP的兼容,在SIP的INVITEmethod中,先把媒体流属性置为"inactive",表示暂不需要媒体流的发送方发送媒体流。该步骤中,信令网关需要产生一个SIPCALL-ID,该SIPCALL-ID用于唯一标识信令网关与SIP客户端之间的该会话。采用CALL-ID唯一标识会话的技术为可实现的现有技术,其中,信令网关可以依据该会话的某信息如发起会话建立的时间等产生该SIPCALL-ID,或可随机产生该SIPCALL-ID,且将该SIPCALL-ID添加到SIPINVITER叫uest消息。由于信令网关与SIP客户端之间可能存在多个会话,因此,后续信令网关与SIP客户端之间关于本次会话的所有交互消息中,都需要包含该SIPCALL-ID,以与其他会话相区别。步骤303、SIP客户端接收到SIPINVITER叫uest后,回复SIPINVITEResponse。该步骤中,SIP客户端回复的SIPINVITEResponse消息中包含媒体流的传输方式、发送媒体流的源地址及端口等信息,且该消息中,媒体流的传输属性置也被置为"Inactive",表示会话建立成功后,暂时不传输媒体流。若SIP客户端不接收该SIPINVITERequest,则会回复表示会话建立失败的消息。步骤304、信令网关接收到SIPINVITEResponse后,向RTSP客户端回复RTSPSETUPResponse。该步骤中,信令网关回复RTSPSETUPResponse消息中包含会话建立成功的信息。若信令网关接收到SIP客户端回复的会话建立失败的消息时,信令网关也将向RTSP客户端回复RTSPSETUPResponse,该RTSPSETUPResponse中包含会话建立失败的信息。该步骤中,信令网关需要产生一个RTSPSessionID,该RTSPSessionID用于唯一标识信令网关与RTSP客户端之间的该会话。采用SessionID唯一标识会话的技术为可实现的现有技术,其中,信令网关可以依据该会话的某信息如发起会话建立的时间等产生该RTSPSessionID,或可随机产生该RTSPSessionID,且将该RTSPSessionID添加到RTSPSETUPResponse。由于信令网关与RTSP客户端之间可能存在多个会话,因此,后续信令网关与RTSP客户端之间关于本次会话的所有交互消息中,都需要包含该RTSPSessionID,以与其他会话相区别。步骤305、信令网关向SIP客户端发送SIPACK消息,确认会话建立。需要说明的是,在本发明各实施例中,信令网关的存储单元上会存储目前RTSP客户端、RTSPSessionID、SIP客户端、SIPCALL-ID的对应关系,信令网关根据当前RTSP客户端、RTSP会话标识符、SIP客户端、SIP会话标识符的对应关系,确定本次会话所对应的对端及对端的会话标识符。该对应关系可以形成一个会话关系表。每当一个会话成功建立后,都要把相应条目添加到会话关系表。这样从某个RTSP客户端收到了某个会话的消息后,可以对应到某个SIP客户端的某个会话。因为一个RTSP客户端和信令网关之间可能存在多个会话,一个SIP客户端和信令网关之间也可能存在多个会话,所以可用会话关系表来区别具体的会话。本实施例中,需将本RTSP客户端、RTSPSessionID和SIP客户端、SIPCALL-ID作为一个新增条目放入会话关系表。上述步骤301至步骤305,是通过信令网关建立RTSP客户端与SIP客户端之间的会话的过程,若本次会话只涉及一条媒体流传输,那么至此会话建立完成,可直接执行步骤310。若本次会话涉及多条々某体流传输,则继续执行步骤306。步骤306、RTSP客户端发送第二个RTSPSETUPRequest消息。该步骤的执行,表示本次会话中涉及多条媒体流传输。该第二个RTSPSETUPRequest消息是RTSP客户端要求添加媒体流的RTSP请求消息,该消息中包含第二条媒体流的RTSPURI、传输方式、目的地址及端口等会话信息,并且,在该第二个RTSPSETUPRequest消息中,需要包含步骤304中产生的RTSPSessionID。这样,信令网关在接收到该第二个SETUPRequest后,根据该RTSPSessionID,确定本次SETUPmethod是请求向已存在的会话中添加媒体流,而不是建立新的会话。步骤307、信令网关接收到该第二个RTSPSETUPR叫uest消息,向SIP客户端发送SIPUPDATER叫uest消息。该步骤中,信令网关即根据该第二个SETUPR叫uest中的RTSPSessionID,确定该SETUPmethod是请求向已存在的会话中添加媒体流,因此,向SIP客户端发送要求更新会话属性的SIPUPDATERequest。该步骤中,信令网关在将RTSPSETUPR叫uest消息转换为SIPUPDATER叫uest消息时,要把本次请求添加的媒体流的会话描述信息及之前已添加的媒体流的会话描述信息全部添加到该SIPINVITERequest消息体的描述中,且将消息体中描述的所有媒体流的属性置为"Inactive",表示目前只分配了传输媒体流的资源,暂时不需要传输媒体流。与执行步骤302类似,该步骤中,考虑到在访问SIP媒体资源时,被访问的SIP客户端可能是一个媒体服务器,因此,信令网关同样需要将每个媒体流的RTSPURI添加到SIPUPDATERequest中,这样,SIP媒体服务器在接收到该SIPUPDATER叫uest后,就可以确认RTSP客户端希望访问的SIP媒体设备的地址。如本次添加的是第二条媒体流,那么信令网关需要将第一条i某体流的RTSPURI"a=control:rtsp:〃server.chicago.com/carol/audio,,和第二条媒体流的RTSPURI"a=control:rtsp:〃server.chicago.com/carol/video"i匀添力口至lU亥第二条SIPUPDATER叫uest中。信令网关还需在该SIPUPDATER叫uest中添加到与执行步骤302时产生的SIPCALL-ID,以标识该SIPUPDATERequest是本次会话中的消息。步骤308、SIP客户端接收到SIPUPDATERequest后,回复SIPUPDATEResponse。该步骤中,SIP客户端回复的SIPUPDATEResponse消息中,包含已被添加的所有媒体流的传输方式、源地址、端口等信息,且该消息中还包含将所有媒体流属性置为"Inactive"的标识,表示在会话建立成功后,暂不需要发送媒体流。该步骤中,若SIP客户端不接收SIPUPDATER叫uest的更新请求,贝'J将回复更新失败的消息。步骤309、信令网关接收到SIP客户端回复的SIPUPDATEResponse后,向RTSP客户端回复RTSPSETUPResponse。该步骤中,信令网关通知RTSP客户端媒体流添加成功。若SIP客户端回复更新失败的消息,那么信令网关也相应地向RTSP客户端返回添加媒体流失败的消息。步骤310、会话建立成功后,RTSP客户端发送RTSPPLAYR叫uest,请求媒体播放。若RTSP客户端希望快进或快退媒体,可以在该RTSPPLAYRequest消息体中添加相应的控制播放速度的信息头(header),包括Speedheader和Scaleheader,如"Speed:2.5"表示以正常媒体播放速度的2.5倍速度快进;"Scale:-3.5",表示以正常媒体播放速度的3.5倍速度快退。Speed和Scale均由现有RTSP协议给出,其中,Speed的值只能取正数,表示快进;Scale的值可以取正数或负数,即可表示快进或快退。步骤311、信令网关接收到RTSPPLAYR叫uest后,向SIP客户端发送SIPUPDATER叫uest。该步骤中,信令网关在发送给SIP客户端的SIPUPDATER叫uest消息中,将所有被添加的媒体流的属性置为"recvonly",表示要求开始传送媒体流,且只接收媒体流。若信令网关还从RTSPPLAYRequest获取到"Speed"或"Scale"等header信息,则在发送给SIP客户端的SIPUPDATER叫uest消息体中添加请求快进或快退的信息,如"a=Speed:2.5",表示对端要求SIP客户端以正常媒体播放速度的2.5倍速度播放媒体流。步骤312、SIP客户端接收到SIPUPDATER叫uest后,回复SIPUPDATEResponse。该步骤中,SIP客户端在SIPUPDATEResponse消息体的会话描述中,将上述被添加的所有媒体流的属性置为"发送(sendonly)",表示SIP客户端只发送媒体流。若SIP客户端功能支持,则可在SIPUPDATEResponse消息体的会话描述中,添加一些用于媒体流同步的信息'如ssrc、s叫、rtptime等。若SIP客户端能够支持接收到的SIPUPDATER叫uest中的快进或快退请求,那么SIP客户端根据快进或快退请求,相应地调整传输媒体流的速度;若SIP客户端不能支持快进或快退的功能,则回复表示传输失败的消息。步骤313、信令网关向RTSP客户端回复RTSPPLAYResponse,由RTSP客户端接收该RTSPPLAYResponse。该步骤中,若信令网关从SIP客户端接收到的SIPUPDATEResponse消息体的会话描述中包含如ssrc、seq、rtptime等用于媒体流同步的会话描述信息,则将该类信息转换为RTSP能够支持的消息格式,如将该类信息添加到RTSPPLAYResponse消息中,发送给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客户端媒体资源的i方问。本施例1至此结束。实施例2:实施例2的流程与上述实施例1的流程基本一致,即先建立RTSP客户端与SIP客户端之间的会话,然后在已经建立的会话中添加第二条媒体流,在两端协商成功后,开始传输媒体流。实施例2的流程与实施例1的流程所不同的是,在该实施例2中,当需要继续添加第二条或更多条媒体流时,在与SIP客户端的信令交互过程中,没有采用UPDATEmethod,而是采用同样具有i某体流更新功能的INVITEmethod。参见图4,图4是本发明实施例2中RTSP客户端访问SIP客户端的流程图。该流程包:fe以下步骤步骤401至步骤406的所有描述与步骤301至步骤306的所有描述相同。步骤407、信令网关接收到该第二个SETUPR叫uest,向SIP客户端发送SIPINVITER叫uest。有关该步骤的描述与步骤307的描述类似,所不同的是,需要将有关步骤307的文字描述中的"UPDATE"替换为"INVITE",并将有关步骤307的文字描述中的"步骤302"替换为"步骤402"。步骤408、SIP客户端接收到SIPINVITERequest后,回复SIPINVITEResponse。有关该步骤的描述与步骤308的描述类似,所不同的是,需要将有关步骤308的文字描述中的"UPDATE"替换为"INVITE"。步骤409、信令网关接收到SIP客户端回复的SIPINVITEResponse后,向RTSP客户端回复RTSPSETUPResponse。该步骤中,信令网关通知RTSP客户端々某体流添加成功。若SIP客户端回复更新失败的消息,那么信令网关也相应地向RTSP客户端返回添加媒体流失败的消息。步骤410、信令网关接收到SIPINVITEResponse后,向SIP客户端返回SIPACK。该步骤中,信令网关向SIP客户端返回SIPACK表示确认对端处理了步骤408中SIP客户端回复的SIPINVITEResponse。上述步骤406至步骤410是在同一个会话中添加第二条^(某体流的流程,本实施例中,若还需要添加更多条媒体流,那么可重复执行步骤406至步骤410,直至添加完所需要添加的媒体流。步骤411的所有描述与步骤310的所有描述相同。步骤412、信令网关接收到RTSPPLAYRequest后,向SIP客户端发送SIPINVITERequest。有关该步骤的描述与步骤311的描述类似,所不同的是,需要将有关步骤311的文字描述中的"UPDATE"替换为"INVITE"。步骤413、SIP客户端接收到SIPINVITER叫uest后,回复SIPINVITEResponse。有关该步骤的描述与步骤312的描述类似,所不同的是,需要将有关步骤312的文字描述中的"UPDATE"替换为"INVITE"。步骤414、信令网关向RTSP客户端回复RTSPPLAYResponse,由RTSP客户端接收该RTSPPLAYResponse。有关该步骤的描述与步骤3D的描述类似,所不同的是,需要将有关步骤313的文字描述中的"UPDATE"替换为"INVITE"。步骤415、信令网关接收到SIPINVITEResponse后,向SIP客户端返回SIPACK。该步骤中,信令网关向SIP客户端返回SIPACK表示确认对端处理了步骤413中SIP客户端回复的SIPINVITEResponse。步骤416、SIP客户端根据与对端的协商,开始传输媒体流,本次流程结束。该步骤中,SIP客户端采用RTP传输媒体流。本实施例2至此结束。实施例3:本实施例将对RTSP客户端主动提出的暂停播放媒体流请求进行处理。"暂停"操作是媒体点播中的常用操作,该操作在RTSP中,由PAUSEmethod实现。相应地,在SIP中,INVITE或者UPDATEmethod可实现"暂停"媒体点播的操作。参见图5,图5是本发明实施例3中处理暂停媒体播放的流程图。该流程包括以下步骤步骤501、RTSPClient发送RTSPPAUSER叫uest,请求暂停媒体流传输。步骤502、信令网关接收到RTSPPAUSER叫uest后,向SIP客户端发送SIPUPDATERequest。该步骤中,信令网关根据存储的会话关系表,查询出对应的媒体源SIP客户端,然后向此SIP客户端发送SIPUPDATERequest消息,且信令网关在该消息中将该会话中的所有媒体流属性置为"Inactive",表示暂停媒体流传输。也就是说,在现有SIP中,通过控制媒体流属性来控制媒体流的传输,即若媒体流属性被置为"inactive",则表示暂停媒体流传输;若媒体流属性被置为"Sendonly",则表示开始传输媒体流。步骤503、SIP客户端接收到SIPUPDATER叫uest消息后,回复SIPUPDATEResponse消息。该步骤中,SIP客户端接收到上述消息后,将自身的媒体流属性置为"inactive",4f止々某体流传车lr。步骤504、信令网关接收到SIPUPDATEResponse消息后,向与本会话对应的RTSPClient发送RTSPPAUSEResponse消息。该步骤中,信令网关通知RTSP客户端"暂停"操作成功。若SIP客户端回复暂停操作失败的消息,那么信令网关向RTSP客户端回复相应的"暂停"操作失敗的消息。本实施例中,在SIP中,采用SIPUPDATEmethod来完成暂停4某体流传输的操作,实际应用中,也可采用具有暂停媒体流传输功能的SIPINVITEmethod来完成该搡作。本实施例3至此结束。实施例4:本实施例将对RTSP客户端主动提出的重定向请求进行处理。在讲述本实施例之前,先对相关现有RTSPmethod及SIPmethod作简要说明。在如RTSP服务器希望负载均衡等情况下,RTSP服务器会使用RTSPREDIRECTmethod,向RTSP客户端发送重定向消息,通知RTSP客户端从另外一个位置获取需要的资源,如通知RTSP客户端从另外一个媒体服务器点播影片。相应地,在SIP中,SIPREFERmethod也具有重定向的功能,该重定向通常用于实现呼叫转移,即通知对端将通话从本地客户端转移到另一个客户端上。通常,SIPREFER需要指明重定向的目的地。由于RTSP的客户端不可能发送重定向消息,所以在本实施中将会出现SIP的客户端主动发送重定向消息的情况。参见图6,图6是本发明实施例4中处理重定向SIP客户端的流程图。该流程包括以下步骤步骤601、SIP客户端发送SIPREFERRequest消息。该步骤中,SIPREFERRequest消息用于要求对端把本次会话重定向到另外一个SIP客户端,且该消息中指明重定向的目的地,该目的地通常采用SIPURI格式表示。步骤602、信令网关接收到SIPREFERR叫uest消息后,向RTSP客户端发送RTSPREDIRECTRequest消息。该步骤中,信令网关根据接收到的消息,解析该消息中包含的重定向目的地的SIPURI。信令网关通过查询,找到与该重定向SIPURI对应的重定向RTSPURI,于是向RTSP客户端发送RTSPREDIRECTR叫uest消息,且将重定向RTSPURI添加到该RTSPREDIRECTR叫uest消息,利用该消息,要求RTSP客户端重定向目的地到映射的RTSPURI获取资源。若信令网关未能根据接收到的消息,找到对应的RTSPURI,则会向SIP客户端回复重定向失败的消息,即在该步骤602之后,执行步骤604。步骤603、RTSP客户端接收到RTSPREDIRECTRequest后,回复RTSPREDIRECTResponse消息。该步骤中,RTSP客户端向对端回复RTSPREDIRECTResponse消息,表示结束本次会话,RTSPClient后续将向新的目的地发起建立会话的请求。步骤604、信令网关接收到RTSPREDIRECTResponse消息后,向SIP客户端发送SIPREFERResponse,通知SIP客户端本操作完成。本实施例中,考虑到RTSP客户端不会主动发出重定向的请求,因此,该重定向请求由SIP客户端发出。本实施例4至此结束。实施例5:参见图7,图7是本发明实施例5中RTSP客户端查询媒体描述的流程图。该流程可以在RTSP客户端请求媒体播放之前完成,用于获得目标媒体对象,如SIP客户端的媒体描述信息。该流程包括以下步骤步骤701、RTSP客户端发送RTSPDESCRIBERequest。该步骤中,RTSP通过发送查询媒体描述请求,请求获得所要访问的媒体源的媒体描述信息,常用的SIP媒体描述信息包括媒体类型、编解码格式、传输方式、传输地址等。步骤702、信令网关接收到RTSPDESCRIBER叫uest后,向SIP客户端发送SIPOPTIONSR叫uest。该步骤中,信令网关根据接收到的RTSPDESCRIBERequest,查询与RTSPURI对应的SIPURI,如"rtsp:〃server.chicago.com/caro1"对应"sipxarol@chicago.com",信令网关发送的SIPOPTIONSR叫uest消息体的会话描述可以是"OPTIONSsip:carol@chicago.comSIP/2.0"。步骤703、SIP客户端回复SIPOPTIONSResponse。该步骤中,SIP客户端根据接收到的RTSPDESCRIBERequest,搜集自身的媒体描述信息,将搜集到的媒体描述信息添加到回复给对端的SIPOPTIONSResponse中,发送给对端。步骤704、信令网关接收到RTSPDESCRIBEResponse后,向RTSP回复RTSPDESCRIBEResponse。该步骤中,信令网关将接收到的RTSPDESCRIBEResponse消息中包含的SIP客户端的媒体描述信息转换成RTSP媒体源的媒体描述格式,回复给RTSP客户端。RTSP客户端默认接收该客户端消息的对端支持RTSP,同样,当RTSP客户端接收到消息时,也默认由支持RTSP的对端发送过来。本实施例5至此结束。实施例6:参见图8,图8是本发明实施例中处理性能查询的流程图。该流程包括以下步骤步骤801、客户端向对端发送RTSPOPTIONSRequest消息。该步骤中,若RTSPClient要访问的是媒体服务器,且需要查询该媒体服务器针对具体媒体资源的性能,那么采用OPTIONSmethod时,需要在RTSPOPTIONSRequest消息中添加标识该媒体资源的URI,如"OPTIONSrtsp:〃server.chicago.com/carol/audio";若RTSPClient要访问的是SIP终端,且需要查询该SIP终端的常规性能,即不考虑具体媒体资源的性能时,可采用OPTIONSmethod,在RTSPOPTIONSR叫uest消息中直接指定对端设备的IP地址,如"OPTIONS192.168.3.2RTSP/2.0"。步骤802、信令网关收到后,向对应的SIP客户端发送。该步骤中,信令网关根据接收到的RTSPOPTIONSRequest消息中包含的RTSPURI或IP地址信息,找出对应的SIP客户端,向对应的SIP客户端发送RTSPOPTIONSRequest消息,以查询SIP客户端的常规性能或者具体媒体资源的性能。如"OPTIONSsip:carol@chicago.comSIP/2.0"。步骤803、SIP客户端接收到SIPOPTIONSRequest消息,返回SIPOPTIONSResponse消息。该步骤中,SIP客户端搜集自身支持的性能,如"Allow:INVITE,ACK,CANCEL,OPTIONS,BYE",回复一个SIPOPTIONSResponse消息。若SIP客户端还具有其它性能,可以在该SIPOPTIONSResponse消息体的会话描述信息中添力口描述,如"a=Support:play.scale"表示支持快进、快退。步骤804、信令网关收到SIPOPTIONSResponse消息后,向RTSP客户端回复RTSPOPTIONSResponse消息。该步骤中,信令网关将SIPOPTIONSResponse消息中包含的SIP的性能描述,映射成RTSP性能描述,如SIPINVITE可以映射成RTSPSETUP、RTSPPLAY、RTSPPAUSE,然后将包含该RTSP性能描述的RTSPOPTIONSResponse消息返回RTSP客户端。在上述步骤801中,若RTSP客户端只是查询对端设备的常规性能,即只查询SIP客户端的常规性能,那么可采用OPTIONSmethod,如"OPTIONSRTSP/2.0";相应地,信令网关接收到该RTSPOPTIONSRequest消息后,只需要基于上述表1,将SIP客户端具备的常规功能映射成的RTSP常规性能转发给RTSPClient即可,.即在执行步骤801之后,跳转至执行步骤804。本实施例6至此结束。实施例7:本实施例将对RTSP客户端主动提出的结束会话请求进行处理。在会话过程中,RTSP客户端可以使用RTSPTEARDOWNmethod,向RTSP服务器请求结束某会话,RTSP服务器收到该请求后,会释放分配给本会话的资源,客户端收到服务器的回复后,也会释放本会话所使用的资源,以结束本会话。参见图9,图9是本发明实施例7中处理会话结束的流程图,该流程包括以下步骤步骤901、RTSP客户端发送TEARDOWNRequest消息,请求结束本次会话。步骤卯2、信令网关收到该消息后,向SIPClient发送SIPBYERequest,请求结束本次会话。步骤903、SIP客户端回复SIPBYEResponse消息,表示同意结束会话。步骤904、信令网关接收到SIPBYEResponse消息后,向RTSP客户端回复RTSPTEARDOWNResponse消息,表示结束会话的请求已经处理。本实施例7至此结束。实施例8:参见图10,图10是本发明实施例8中处理会话结束的流程图。该流程包括以下步骤步骤IOOI、SIP客户端向对端发送SIPBYER叫uest消息,请求结束会话。步骤1002、信令网关接收到SIPBYERequest消息后,向RTSP客户端发送RTSPREDIRECTRequest消息。该步骤中,信令网关发送的RTSPREDIRECTR叫uest消息中并没有指明重定向的目的地,则依据RTSP协议,该RTSPREDIRECTR叫uest消息表示要求RTSP客户端结束本次会话。该做法是可行的,其原因在于,当现有RTSP服务器向RTSP客户端主动发送RTSPREDIRECTRequest消息时,若该消息中没有指定重定向的目的地,那么RTSP客户端接收到该消息后,默认需要结束本次会话。因此,在本实施例中,对RTSP客户端而言,获知该消息的发送者并没有实际意义,只要接收到的消息是RTSP客户端支持的RTSP消息,那么RTSP客户端就能够根据现有RTSP协议规定,根据接收到的消息完成相应的操作。步骤1003、RTSP客户端向信令网关回复RTSPREDIRECTResponse消息,表示同意结束本次会话。步骤1004、信令网关接收到RTSPREDIRECTResponse后,向SIP客户端回复SIPBYEResponse,表示结束会话的请求执行成功。本实施例8至此结束。上述各实施例中,SIP客户端可以是SIP终端,也可以是SIP应用服务器,其中,SIP应用服务器也是利用SIPURI来标识。现有的SIP应用服务器主要提供公共服务功能,如订阅功能、对方会议呼叫中心功能、流媒体服务功能等。综上所述,本发明实施例提供RTSP客户端访问SIP媒体资源的方法,通过在RTSP客户端与目的SIP媒体设备之间的建立会话;根据建立的所述会话,将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端,从而实现RTSP客户端对SIP媒体资源的访问。本发明实施例提供的信令网关能够将RTSP客户端发送的RTSP请求消息转换为对应的SIP请求消息后,发送给SIP媒体设备;也能够将SIP媒体设备返回的响应消息转换为对应的RTSP响应消息后,发送给RTSP客户端;通过该信令网关的消息转换功能,在RTSP客户端与目的SIP媒体设备之间的建立会话,进而实现RTSP客户端对SIP媒体资源的访问。本发明实施例提供的RTSP客户端访问SIPi某体资源的系统中,包含RTSP客户端、目的SIP媒体设备和上述信令网关,通过该信令网关建立RTSP客户端与目的SIP媒体设备之间的会话,进而实现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消息体的会话描述中增加内容,如将RTSPURI添加到SIPINVITERequest消息。因此,本发明实施例提供的技术方案易于实现,且能够兼容原有支持RTSP的媒体终端。权利要求1.一种RTSP客户端访问SIP媒体资源的方法,其特征在于,包括步骤建立实时流协议RTSP客户端与目的会话发起协议SIP媒体设备之间的会话;根据建立的所述会话,将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端。2、根据权利要求1所述的方法,其特征在于,所述目的SIP媒体设备包括SIP终端、SIP应用服务器。3、根据权利要求1所述的方法,其特征在于,所述建立RTSP客户端与目的SIP媒体设备之间的会话的步骤包括根据RTSP客户端发送的RTSP会话建立请求消息,向目的SIP媒体设备发送SIP会话建立请求消息;在4姿收到目的SIP媒体设备返回的与所述SIP会话建立请求消息对应的响应消息后,#4居该响应消息,向所述RTSP客户端发送与所述RTSP会话建立请求消息对应的响应消息,建立本次会话。4、根据权利要求3所述的方法,其特征在于,向目的SIP媒体设备发送SIP会话建立请求消息的步骤包括根据所述RTSP会话建立请求消息中包含的第一条媒体流的RTSP统一资源标识符URI,查找对应的SIPURI;将所述RTSP会话建立请求消息转换为对应的SIP会话建立请求消息;将包含所述SIPURI的SIP会话建立请求消息发送给与该SIPURI对应的所述目的SIP士某体设备。5、根据权利要求4所述的方法,其特征在于,将所述RTSP会话建立请求消息转换为对应的SIP会话建立请求消息的步骤包括将所述RTSP会话建立请求消息中包含的第一条媒体流的会话描述信息添加到所述SIP会话建立请求消息。6、根据权利要求4所述的方法,其特征在于,向目的SIP媒体设备发送SIP会话建立请求消息的步骤之前进一步包括将SIP会话建立请求消息中包含的媒体流传输属性置为非激活状态的步骤。7、根据权利要求3所述的方法,其特征在于,向目的SIP媒体设备发送SIP会话建立请求消息之前,该方法进一步包括产生用于唯一标识本次会话的SIP会话标识符,且将该S1P会话标识符添加到所述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所述的方法,其特征在于,所述会话描述信息包括rtspuri、传输方式、编解码格式、传输媒体流的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客户端与目的SIP4某体设备之间的会话之后,该方法进一步包括根据目的SIP媒体设备要求结束本次会话的SIP请求消息,向RTSP客户端发送要求结束本次会话的RTSP请求消息;在接收到返回的与该RTSP请求消息对应的响应消息后,向目的SIP媒体设备返回与所述SIP请求消息对应的响应消息。19、根据权利要求18所述的方法,其特征在于,所述向RTSP客户端发送要求结束本次会话的RTSP请求消息的步骤具体包括向RTSP客户端发送一条不指定目的地的重定向消息。20、根据权利要求8所述的方法,其特征在于,建立RTSP客户端与目的SIP々某体设备之间的会话之后,该方法进一步包括根据目的SIP媒体设备要求对端将本次会话重定向到另一个目的SIP媒体设备的SIP请求消息,向RTSP客户端发送要求重定向本次会话目的地的RTSP请求消息;在接收到返回的与该RTSP请求消息对应的响应消息后,向目的SIP媒体设备返回与所述SIP请求消息对应的响应消息。21、根据权利要求9、17、18、19或20所述的方法,其特征在于,根据当前RTSP客户端、RTSP会话标识符、SIP客户端、SIP会话标识符的对应关系,确定本次会话所对应的对端及对端的会话标识符。22、一种信令网关,其特征在于,包括第一接收模块、第一消息转换模块和第一发送模块;其中,第一接收模块,用于接收RTSP客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息;第一消息转换模块,用于将所述RTSP消息转换为对应的SIP消息,或将所述SIP响应消息转换为对应的RTSP响应消息;以及第一发送模块,用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备,或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。23、根据权利要求22所述的信令网关,其特征在于,所述信令网关进一步包括存储模块,用于存储目前RTSP客户端、RTSP会话标示符、SIP客户端、SIP会话标识符的对应关系。24、根据权利要求22所述的信令网关,其特征在于,所述信令网关进一步包括第二接收模块、第二消息转换模块和第二发送模块;其中,第二接收模块,用于接收目的SIP媒体设备发送的SIP消息以及RTSP客户端返回的RTSP响应消息;第二消息转换模块,用于将所述SIP消息转换为对应的RTSP消息,或将所述RTSP响应消息转换为对应的SIP响应消息;以及第二发送模块,用于将经所述第二消息转换模块转换而得的RTSP消息对应发送给所述RTSP客户端,或将经所述第二消息转换模块转换而得的SIP响应消息对应发送给所述目的SIP媒体设备。25、根据权利要求24所述的信令网关,其特征在于,所述SIP请求消息包括要求结束本次会话的SIP请求消息,或,要求将本次会话重定向到另一个SIP媒体设备的SIP请求消息。26、一种RTSP客户端访问SIP媒体资源的系统,其特征在于,包括RTSP客户端、目的SIP媒体设备和信令网关;其中,信令网关,包括第一接收模块、第一消息转换模块和第一发送模块;其中,第一接收模块,用于接收RTSP客户端发送的RTSP消息以及目的SIP媒体设备返回的SIP响应消息;第一消息转换模块,用于将所述RTSP消息转换为对应的SIP消息,或将所述SIP响应消息转换为对应的RTSP响应消息;以及第一发送模块,用于将经所述第一消息转换模块转换而得的SIP消息对应发送给所述目的SIP媒体设备,或将经所述消息转换模块转换而得的RTSP响应消息对应发送给所述RTSP客户端。全文摘要本发明实施例公开了一种RTSP客户端访问SIP媒体资源的方法,该方法通过建立RTSP(实时流协议)客户端与目的SIP(会话发起协议)媒体设备之间的会话;根据建立的会话,将RTSP客户端请求传输的媒体流从目的SIP媒体设备传输给该RTSP客户端,实现RTSP客户端对SIP媒体资源的访问。本发明实施例还基于上述方法,公开了一种RTSP客户端访问SIP媒体资源的系统及信令网关,以实现RTSP客户端对SIP媒体资源的访问。本发明实施例技术方案的实现,有助于实现IMS与IPTV的融合。本发明实施例提供的技术方案基于现有RTSP协议和SIP协议,能够兼容原有支持RTSP的媒体终端。文档编号H04L12/56GK101222418SQ20071000327公开日2008年7月16日申请日期2007年2月2日优先权日2007年1月10日发明者管红光,建陈,魏启坤申请人:华为技术有限公司