WO2009117919A1 - 一种内容点播业务的建立方法、系统和装置 - Google Patents
一种内容点播业务的建立方法、系统和装置 Download PDFInfo
- Publication number
- WO2009117919A1 WO2009117919A1 PCT/CN2009/070730 CN2009070730W WO2009117919A1 WO 2009117919 A1 WO2009117919 A1 WO 2009117919A1 CN 2009070730 W CN2009070730 W CN 2009070730W WO 2009117919 A1 WO2009117919 A1 WO 2009117919A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- service
- rtsp
- request
- terminal
- sip
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
Definitions
- the embodiments of the present invention relate to the field of data communications, and in particular, to a method, system, and device for establishing a CoD (Content on Demand) service.
- CoD Content on Demand
- IP based Multimedia Subsystem IP based Multimedia Subsystem
- IMS is a subsystem of the Wideband Code Division Multiple Access (WCDMA) network superimposed on the existing packet domain in the 3GPP R5 phase.
- WCDMA Wideband Code Division Multiple Access
- the packet domain is used as its subsystem. 7-channel channel for upper layer control signaling and media transmission, ?
- Session Initiated Protocol is a service control protocol that separates service control from bearer control and provides rich multimedia services by utilizing the features of SIP, simple extension, and convenient media combination.
- the main functional entities of the IMS include a Call Session Control Function (CSC) that controls user registration and session control functions, and an application server that provides various service logic control functions (Application Server, hereinafter referred to as AS ), a Home Subscriber Server (hereinafter referred to as HSS) that centrally manages user subscription data, and a media network for interworking with the circuit-switched network
- CSC Call Session Control Function
- AS Application Server
- HSS Home Subscriber Server
- media network for interworking with the circuit-switched network
- the Media Gateway Function the following is called: MGCF/IM-MGW), the user accesses the IMS through the current Proxy Call Session Control Function (P-CSCF), session and service trigger control and services with the AS.
- P-CSCF Proxy Call Session Control Function
- S-CSCF Serving Call Session Control Function
- the IMS based IPTV service makes full use of the existing registration, authentication, routing, and session in the IMS network. Control and establishment, service triggering, billing, and end-to-end Quality of Service (QoS) guarantee mechanisms to provide users with streaming services, streaming media, and real-time session services.
- QoS Quality of Service
- IPTV Media Server Media Functions, The following cylinders are called: MF
- MCF Media Control Function
- MDF Media Delivery Function
- SSF Service Selection Function
- SCF Service Control Function
- the service control function and the media control function have the function of dynamically selecting a media server for the IPTV service requested by the user.
- SIP protocol and real-time transport protocol (Realtime Transport Protocol/Real-time Transport Control Protocol, RTP/RTCP), Session Description Protocol (SDP), real-time transport streaming protocol (Real- The Time Streaming Protocol, the following is called: RTSP), the domain name server (the domain name server, the following tube: DNS) and other protocols cooperate to complete the session establishment and media negotiation of the IPTV system.
- the 3GPP has developed the "Transparent End-to-End Packet Switching Streaming Service" specification, which is the PSS (Packet Switched Streaming Service) specification.
- PSS Packet Switched Streaming Service
- the PSS specification adopts the client server mode, and the client (Streaming Client) passes the GSM EDGE Radio Access Network/UMTS Terrestrial Radio Acces Network (hereinafter referred to as GERAN/UTRAN), and the 3GPP Core Network (3GPP Core Network).
- the IP Network IP Network communicates with the Media Servers.
- the client establishes an RTSP session through the RTSP protocol and the media server, negotiates an RTP media delivery channel, and receives media content.
- the client can send fast forward, fast rewind and other operation commands through the RTSP channel to control the transmission of the media stream.
- the control protocol uses RTSP instead of the IMS SIP protocol for service control. Therefore, it is impossible to support the IMS mobile terminal adopting the SIP protocol to effectively enjoy the streaming media service.
- the rich functions provided by the IMS system such as unified user management, QoS control, policy control, charging control, session establishment mechanism, etc., can not be fully utilized to enjoy streaming media services. This increases the operator's business operation costs and reduces the user's business experience. Summary of the invention
- the embodiment of the invention provides a method, a system and a device for establishing a CoD service, which can convert a SIP message and an RTSP message in a CoD establishment process to achieve message interworking, and realize an IMS mobile terminal adopting the SIP protocol to effectively enjoy the streaming media service, and improve User experience, enriching the effects of business types.
- the embodiment of the invention provides a method for establishing a content-on-demand CoD service, including: Receiving a session initiation protocol SIP service request sent by the terminal;
- the embodiment of the present invention further provides a system for establishing a content on-demand CoD service, including a protocol conversion function entity PTF and a content server.
- the PTF is configured to perform a conversion between a session initiation protocol SIP message and a real-time delivery streaming media protocol RTSP message;
- the content server is configured to receive and process an RTSP service message, and send the media stream to the terminal.
- the embodiment of the present invention further provides a protocol conversion function entity PTF, including: an information receiving module, configured to receive a session initiation protocol SIP service request, and a real-time delivery streaming media protocol RTSP service response;
- a protocol conversion function entity PTF including: an information receiving module, configured to receive a session initiation protocol SIP service request, and a real-time delivery streaming media protocol RTSP service response;
- An information conversion module configured to convert the SIP service request and the RTSP service response received by the information receiving module into an RTSP service request and a SIP service response; and an information sending module, configured to send the RTSP converted by the information conversion module Business request and SIP service response.
- An embodiment of the present invention further provides a user equipment UE, including:
- An information receiving module configured to receive a session initiation protocol SIP service response, and extract a real-time transport streaming protocol RSTP change information
- the parameter adjustment module is configured to adjust the RSTP parameter according to the RSTP change information extracted by the information receiving module.
- the technical solution of the embodiment of the present invention has the following advantages, because a method and a device for establishing a CoD service are adopted, and the SIP message and the RTSP message can be converted in the CoD establishment process to achieve message interworking, and the IMS mobile terminal adopting the SIP protocol is effective.
- a method and a device for establishing a CoD service are adopted, and the SIP message and the RTSP message can be converted in the CoD establishment process to achieve message interworking, and the IMS mobile terminal adopting the SIP protocol is effective.
- FIG. 1 is a schematic diagram of an IMS based IPTV service function architecture defined by TISPAN in the prior art
- FIG. 2 is a schematic structural diagram of a system for introducing a protocol conversion function entity according to Embodiment 1 of the present invention
- FIG. 3 is a schematic structural diagram of a system in which a PTF is deployed on an MCF according to Embodiment 2 of the present invention
- FIG. 4 is a schematic structural diagram of a system in which a PTF is deployed on an SCF according to Embodiment 3 of the present invention
- FIG. 5 is a schematic flowchart of a method for establishing a CoD service according to Embodiment 4 of the present invention.
- FIG. 6 is a schematic flowchart of a method for establishing a CoD service according to Embodiment 5 of the present invention.
- FIG. 7 is a schematic flowchart of a method for establishing a CoD service when a user accesses a non-home domain service according to Embodiment 6 of the present invention.
- FIG. 8 is a schematic flowchart of a method for switching a live broadcast LTV to a unicast LTV of a multicast television program according to Embodiment 7 of the present invention
- FIG. 9 is a schematic flowchart of a method for switching a unicast LTV to a multicast LTV according to Embodiment 8 of the present invention.
- FIG. 10 is a schematic flowchart of a method for switching from unicast to unicast according to Embodiment 9 of the present invention. detailed description
- FIG. 2 is a schematic diagram showing the system structure of the protocol conversion function entity in the first embodiment of the present invention.
- a protocol conversion function entity PTF 1 is introduced, which is used to perform conversion between a SIP message and a corresponding RTSP message, and specifically includes:
- the information receiving module 11 is configured to receive a SIP service request, and an RTSP service response, or receive an RTSP PLAY message;
- the information conversion module 12 is configured to convert the SIP service request and the RTSP service response received by the information receiving module 11 into an RTSP service request and a SIP service response;
- the information sending module 13 is configured to send the RTSP service request and the SIP service response converted by the information conversion module 12, or send an RSTP PLAY message, or forward the received RTSP PLAY message.
- the function of receiving the RTSP PLAY message, sending the RSTP PLAY message, and forwarding the received RTSP PLAY message may select whether to implement the above function according to specific settings, and the solution change due to the difference. It also falls within the scope of protection of the present invention.
- the information conversion module 12 includes:
- the server selection sub-module 121 is configured to select a server that provides a service for the terminal according to the SIP service request received by the information receiving module.
- the PTF 1 receives the SIP message from the UE 2 through the A interface, converts it into a corresponding RTSP message, and forwards it to the content server 3 through the B interface.
- the RTSP message is received from the content server 3 through the B interface, converted into a corresponding SIP message, and then forwarded through the A interface and sent to the UE 2.
- the A interface is the SIP protocol and the B interface is the RTSP protocol.
- the UE 2 in the system includes:
- the information receiving module 21 is configured to receive a SIP service response, and extract RSTP change information
- the parameter adjustment module 22 is configured to change according to the RSTP extracted by the information receiving module 21
- the information receiving module 21 includes:
- the information receiving submodule 211 is configured to receive a SIP service response.
- the information extraction sub-module 212 is configured to extract RSTP change information in the SIP service response received by the information receiving sub-module 21.
- the parameter adjustment module 22 includes:
- the instruction execution sub-module 221 is configured to perform an operation corresponding to the operation indication when the RSTP change information included in the SIP service response received by the information receiving module 21 is an operation indication;
- the parameter update sub-module 222 is configured to update the RSTP parameter according to the parameter information when the RSTP change information included in the SIP service response received by the information receiving module 21 is parameter information.
- the content server 3 is used to process RTSP messages, and/or to provide a media valley for UE 2.
- the UE 2 is configured to initiate a SIP service request, receive a service response, and receive media content.
- the PTF can be implemented independently or deployed on other functional entities. As described in the second embodiment of the present invention and the third embodiment of the present invention.
- the content server is a PSS content server in the PSS system.
- the media function entity Media Function is logically divided into a media control function entity MCF and/or a media transfer function entity MDF.
- FIG. 3 it is a schematic diagram of a system structure in which a PTF is deployed on an MCF according to Embodiment 2 of the present invention.
- PTF 1 is deployed on MCF 4, so that MCF 4 performs conversion between SIP messages and corresponding RTSP messages.
- the MCF 4 is used to convert between SIP messages and corresponding RTSP messages.
- the MCF 4 receives the SIP message sent by the UE 2 from the A interface, and converts it into the corresponding RTSP message, and then forwards it to the MDF 5 through the B interface. Otherwise, the RTSP message sent by the MDF 5 is received from the B interface and converted into a corresponding SIP message. Forwarded through the A interface and sent to the UE 2. Therefore, in Figure 3, the A interface is the SIP protocol, and the B interface is the RTSP. protocol.
- the MDF 5 implements the functions of the PSS content server 3.
- the RTSP media control channel established by the UE 2 and the network side for performing VCR control, such as fast forward and fast rewind, can be established between the UE 2 and the MCF 4, as shown by the Xc interface; Established between UE 2 and MDF 5, as shown by Xc.
- FIG. 4 it is a schematic diagram of a system structure in which a PTF is deployed on an SCF according to Embodiment 3 of the present invention.
- PTF 1 is deployed on SCF 6, so that SCF 6 performs conversion between SIP messages and corresponding RTSP messages.
- the SCF 6 receives the SIP message sent by the UE 2 from the ISC interface, converts it into a corresponding RTSP message, and forwards it to the MCF 4 through the B interface.
- the RTSP message sent by the MCF 4 is received from the B interface and converted into a corresponding SIP message, and then forwarded through the ISC interface and sent to the UE 2.
- MCF 4 and MDF 5 together implement the functions of the PSS content server 3.
- FIG. 5 it is a schematic flowchart of a method for establishing a CoD service according to Embodiment 4 of the present invention.
- the system according to the second embodiment of the present invention is selected, the PTF 1 is deployed on the MCF 4, the media control channel is established between the UE 2 and the MCF 4, and the UE 2 initiates the first PLAY message request. Start playing the media stream.
- Step S501 The terminal device UE sends a SIP service request to request a CoD service.
- the terminal device UE sends a SIP service request to request a CoD service. Request after
- the SIP request is a SIP Invite request, or a SIP Reinvite request, or a SIP Update request.
- the request carries CoD content identification information, indicating the content of the CoD program that the user wishes to view, and the identifier may have multiple acquisition methods, such as through an EPG, or a certain medium. Body description file, etc.
- the request carries both SDP information, such as the IP address and port number information of the UE on the RTSP content control channel, and/or the IP address and port information of the UE about the RTP content transmission channel.
- the request may carry the terminal capability information of the UE, such as: the UE's decoding capability, the screen size, the software version, etc.; and/or the user's preference information, if there are multiple MFs satisfying the condition, the preferred price is low, rather than the quality.
- the terminal capability information of the UE such as: the UE's decoding capability, the screen size, the software version, etc.; and/or the user's preference information, if there are multiple MFs satisfying the condition, the preferred price is low, rather than the quality.
- the foregoing terminal capability information and/or user preference information may be stored in a specific functional entity on the network side, so the UE may only carry an identifier of the entity, such as an IP address, or a URI information, and needs to be used in the future.
- the entity is obtained from a specific storage entity based on the identity.
- the "entities that need to use this information in the future" may include SCF, MCF, and these entities can perform necessary business control based on terminal capability information and/or user preference information, such as selecting a suitable media server.
- the routing of the UE's service request to the SCF may be in any of the following ways, or a combination of the two.
- the IFC is routed to the SCF through the initial filtering rule.
- the triggering condition may be a service identifier according to the service request, such as "IPTV service”, or the service identifier may also be divided into a finer granularity, such as a CoD IPTV service, or an LTV IPTV service. Therefore, the service request of the UE may carry the service identifier.
- Method 2 Route to the SCF through PSI.
- the Request URI is a PSI, which follows the routing rules of the PSI.
- the SCF After receiving the service request, the SCF performs business logic processing, such as determining whether the user has the right to access the requested service; and selecting the PSS content server.
- the SCF can select the PSS content server based on different conditions.
- the selection condition may include one or more of the following information: content identification, terminal capability information, user preference information, distribution information of the media content requested by the user in each PSS content server, status information of the PSS content server, such as load status information.
- the SCF performs MCF selection according to one or more of the foregoing information.
- the SCF may determine that the service requested by the user is a service provided by the domain, or a service provided by another domain. If it is a service provided by the local domain, it can be used as a SIP Proxy to process the service and continue to forward the service request; or as a SIP B2B UA, terminate the SIP conversation and initiate a new conversation. If the service requested by the user is a service provided by another domain, possible business logic processing such as service authorization judgment may be performed, and the service request is forwarded.
- Step S505 The SCF forwards the SIP service request to the MCF.
- Step S510 the MCF sends an RTSP SETUP message to the MDF.
- the MCF constructs a corresponding RTSP service request message according to the received SIP service request message, and sends the message to the MDF.
- the RTSP service request message is an RTSP SETUP message; or an RTSP SETUP message and an RTSP PLAY message. If there are multiple media components in the SDP in the SIP service request, the MCF sends multiple RTSP SETUP messages and/or RTSP PLAY messages to the MDF.
- the RTSP PLAY message may have different transmission timings, such as the UE sends, or the MCF sends a SIP ACK acknowledgement, see the following embodiment.
- the RTSP URL can be obtained in multiple ways. If the UE service request carries the RTSP URL parameter information. If the SIP request does not carry the RTSP URL information, the MCF is required to determine the URL information. For example, the MCF performs PSS content server selection according to the content identifier, and determines RTSP URL information.
- the MCF can select the PSS content server according to different conditions.
- the selection condition may include one or more of the following information: content identification, terminal capability information, user preference information, distribution information of the media content requested by the user in each PSS content server, status information of the PSS content server, such as load status information.
- the MCF performs MDF selection according to one or more of the above information, that is, performs selection of the PSS content server.
- the MCF Before sending the SETUP message, the MCF may obtain the content description information by using the RTSP Describe message, and obtain the capability information of the PSS content server by using the RTSP OPTIONS message. In step S520, the MDF returns an RTSP 200 OK response message to the MCF.
- MDF determines the session ID SessionID, source source address information server side
- the OK response message is returned to the SCF.
- the SIP 200 OK response carries SDP response information, such as RTSP content control channel parameter information, such as IP address and / or port number information, and / or RTP content transmission channel parameter information, such as IP address and / or port information.
- the parameter information of the content control channel may be the parameter information of the MCF or the parameter information of the MDF, depending on whether the media control channel is established to the MCF or the MDF. In this implementation, the establishment of the MCF is taken as an example.
- the parameter information of the content delivery channel is the parameter information of the MDF.
- the response carries the relevant parameter information of the RTSP content control channel.
- relevant parameter information of the RTSP content control channel Such as RTSP URL information, SessionID information, etc.
- the specific status information may be any state of the RTSP protocol state machine, such as Init/Ready/Playing/Recording and so on.
- the response may carry related parameter information of the RTSP protocol.
- CSeq information thereby instructing the UE to send the CSeq parameter of the RTSP message in the future. It can be carried by the attributes of the SDP response message.
- the response may carry capability information of the PSS content server, such as whether to support fast content switching, whether to support pipeline Pipeline, and so on. It can be carried by the attribute of the SDP reply message.
- step S530 the SCF forwards 80 ⁇ 200 0 response to 1 ⁇ .
- the SCF forwards the SIP 200 OK to the UE via the Core IMS.
- the P-CSCF interacts with the RACS to reserve resources.
- step S535 and step S540 the UE returns an ACK confirmation.
- the UE sends an ACK message through the Core IMS.
- Step S545 The UE sends an RTSP PLAY message requesting to start playing the media stream.
- the UE sends an RTSP PLAY message requesting to play the requested media content.
- the RTSP media control channel may be established between the UE and the MCF, or between the UE and the MDF, depending on the parameter information of the RTSP media control channel in the response. This embodiment is taken as an example between the UE and the MCF.
- the UE sets the local RTSP protocol status. If the SIP 200 OK response message carries the RTSP protocol status indication information, such as the indication that the network side sends the RTSP PLAY message, the network side has sent the PLAY message; or directly carries the RTSP protocol status. The UE can set the local RTSP protocol status according to the information. If the response message is not carried, the UE can determine the state that should be set according to the service logic.
- the SIP 200 OK response message carries the RTSP protocol status indication information, such as the indication that the network side sends the RTSP PLAY message, the network side has sent the PLAY message; or directly carries the RTSP protocol status.
- the UE can set the local RTSP protocol status according to the information. If the response message is not carried, the UE can determine the state that should be set according to the service logic.
- the UE sets the local RTSP protocol parameters. If the SIP 200 OK response message carries RTSP protocol parameter information, such as CSeq parameter information. The UE can set parameter information corresponding to the local RTSP protocol according to the information. If not carried, the UE can determine the RTSP protocol parameters used by itself.
- RTSP protocol parameter information such as CSeq parameter information.
- the UE establishes a content transmission channel for transmitting and receiving the media stream according to the information of the RTP channel carried in the SIP 200 OK response message, such as an IP address, a port, and the like.
- the UE establishes a content control channel according to the RTSP URL carried in the SIP 200 OK response message and the session identifier SessionID information, and sends an RTSP PLAY message to request to play the media stream.
- the response message carries the capability information of the PSS content server, such as whether to support fast content switching, whether to support pipeline Pipeline, etc. It may be carried by SDP attribute information, or SIP header field.
- the UE can learn the capability information of the PSS content server, so that it can provide reference for the behavior of the UE in the future.
- the UE initiates an RTSP PLAY message requesting to play the media stream, and the message may also be initiated by the MCF/PTF.
- the PTF initiates an RTSP PLAY message is explained.
- Step S550 and step S555 the MCF forwards the RTSP PLAY message to the MDF, Receive RTSP 200 OK response
- This step is optional if the RTSP content control channel is established directly between the UE and the MDF.
- the MCF may terminate the UE's RTSP session and establish a new RTSP session with the MDF; or, as an RTSP proxy, forward the UE's RTSP message to the MDF.
- Step S560 the MCF forwards the RTSP 200 OK response to the UE.
- the session establishment process is completed, and the UE receives the media content.
- terminal capability/user preference the selection of the media server, the service trigger, the RTSP status indication, and the RTSP protocol parameter information mentioned in the foregoing description process are all described in the first embodiment, and are also applicable to other embodiments. Detailed descriptions will not be given in other embodiments.
- FIG. 6 is a schematic flowchart of a method for establishing a CoD service according to Embodiment 5 of the present invention.
- the system according to the third embodiment of the present invention is selected, the PTF 1 is deployed on the SCF 6, the media control channel is established between the UE 2 and the media server 3, and the PTF 1 initiates the first PLAY message. Request to start playing the media stream. Specifically, the following steps are included:
- Step S601 The terminal device UE sends a SIP service request to request a CoD service.
- Step S601 of this embodiment is the same as step S501 in the first embodiment of the present invention.
- Step S605 The SCF sends an RTSP SETUP message to the PSS content server.
- the SCF constructs a corresponding RTSP service request message according to the received SIP service request message, and sends the message to the PSS content server.
- the RTSP service request message is an RTSP SETUP message; or an RTSP SETUP message and an RTSP PLAY message. If there are multiple media components in the SDP in the SIP service request, the SCF sends multiple RTSP SETUP messages and/or RTSP PLAY messages to the PSS content server.
- the RTSP PLAY message may have different transmission timings, such as the UE sends the SIP 200 OK response, as shown in the fourth embodiment; or the SCF sends the SIP ACK acknowledgement, as shown in this embodiment. It can also be sent after sending a SETUP message, such as the Pipeline method. In the RTSP SETUP message, the RTSP URL can be obtained in multiple ways.
- the SCF is required to determine the URL information. For example, the SCF performs PSS content server selection according to the content identifier, and determines RTSP URL information.
- the SCF can select the PSS content server according to different conditions.
- the selection condition may include one or more of the following information: content identification, terminal capability information, user preference information, distribution information of the media content requested by the user in each PSS content server, status information of the PSS content server, such as load status information.
- Step S610 the PSS content server returns an RTSP 200 OK response message to the SCF.
- the PSS content server determines the session ID, the source source address information, and the server port server-por parameters, and returns an RTSP 200 OK message.
- Step S620 the SCF returns a SIP 200 OK response to the UE.
- the SCF constructs a corresponding SIP 200 OK response message and returns it to the UE according to the received RTSP 200 OK response message.
- the response carries SDP response information, such as parameter information of the RTSP content control channel, such as IP address and/or port number information, and/or parameter information of the RTP content delivery channel, such as IP address and/or port information.
- the parameter information of the content control channel and/or the content delivery channel is parameter information of the PSS content server.
- the response carries the relevant parameter information of the RTSP content control channel.
- RTSP RTSP
- the response may carry information indicating that the UE performs RTSP protocol status adjustment: such as carrying some indication information (such as network side Pipeline indication information), or directly carrying the RTSP status information that the terminal should set. It can be carried by the attribute of the SDP reply message.
- the terminal sets the RTSP status to the PLAYing state accordingly. In this state, the UE may choose not to send the RTSP PLAY request to play the media stream. Interest.
- the response may carry related parameter information of the RTSP protocol.
- CSeq information thereby instructing the UE to send the CSeq parameter of the RTSP message in the future. It can be carried by the attributes of the SDP response message.
- the response may carry capability information of the PSS content server, such as whether to support fast content switching, whether to support pipeline Pipeline, and so on. It can be carried by the attribute of the SDP reply message.
- the SCF can obtain the capability information of the PSS content server through the RTSP OPTIONS message.
- the P-CSCF interacts with the RACS to perform resource reservation.
- the UE after receiving the response message, the UE needs to perform corresponding local processing according to the response:
- the UE sets the local RTSP protocol status. If the SIP 200 OK response message carries the RTSP protocol status indication information, such as the indication that the network side sends the RTSP PLAY message, the network side has sent the PLAY message; or directly carries the RTSP protocol status. The UE can set the local RTSP protocol status according to the information. If the response message is not carried, the UE can determine the state that should be set according to the service logic.
- the SIP 200 OK response message carries the RTSP protocol status indication information, such as the indication that the network side sends the RTSP PLAY message, the network side has sent the PLAY message; or directly carries the RTSP protocol status.
- the UE can set the local RTSP protocol status according to the information. If the response message is not carried, the UE can determine the state that should be set according to the service logic.
- the UE sets the local RTSP protocol parameters. If the SIP 200 OK response message carries RTSP protocol parameter information, such as CSeq parameter information. The UE may use the parameter information corresponding to the local RTSP protocol of the information. If not carried, the UE can determine the RTSP protocol parameters used by itself.
- RTSP protocol parameter information such as CSeq parameter information.
- the UE may use the parameter information corresponding to the local RTSP protocol of the information. If not carried, the UE can determine the RTSP protocol parameters used by itself.
- the UE establishes a content transmission channel for transmitting and receiving the media stream according to the information of the RTP channel carried in the SIP 200 OK response message, such as an IP address, a port, and the like.
- the UE may establish a content control channel according to the RTSP URL carried in the SIP 200 OK response message and the session identifier Session1D information, and send an RTSP PLAY message to request to play the media stream.
- the response message carries the capability information of the PSS content server, such as whether to support fast content switching, whether to support pipe Pipeline, etc. It may be carried by SDP attribute information, or SIP header field.
- the UE can know the capabilities of the PSS content server. Force information, which can provide reference for future UE behavior.
- Step S625 the UE returns an ACK confirmation.
- the UE sends an ACK message through the Core IMS.
- Step S630 and step S635 the SCF sends an RTSP PLAY message to the PSS content server to receive the RTSP 200 OK response.
- the SCF sends an RTSP PLAY message to the PSS content server, requests to play the media stream, and receives a 200 OK response message.
- the UE receives the media content through the content delivery channel.
- the step of establishing a content control channel between the UE and the server may be included, and the content control channel may be controlled to transmit the media content through the content control channel.
- the content control channel is established as an optional step and may occur before or after the UE receives the media content through the content delivery channel, the step is not identified in FIG. 6, and the difference in this step is not It affects the scope of protection of the present invention.
- the RTSP PLAY message requesting to play the media stream may be sent by the UE or may be sent by the network side entity PTF.
- the network side initiates RTSP PLAY. There are two cases. One is when the PTF sends an RTSP SETUP message, such as the Pipeline method. The other way is that the PTF sends an ACK message.
- the UE may carry some indication information indicating the network side PTF, or the UE sends an RTSP PLAY message to request to play the media stream.
- the PTF When the PTF processes the SIP service request, it may decide whether to send a PLAY message according to the indication carried by the UE or the local configuration.
- the response may carry an indication that the network side sends an RTSP PLAY message (may not be sent, or has been sent, or etc.)
- the UE sets the local RTSP protocol status to Play after receiving the response, so that the RTSP PLAY message for requesting to play the media stream is not initiated.
- FIG. 7 is a schematic flowchart of a method for establishing a CoD service when a user accesses a non-home domain service according to Embodiment 6 of the present invention.
- the foregoing scenarios include: the user accessing the services of the other domain in the home domain, or the user accessing the roaming domain service in the roaming domain, or the user accessing the services of the non-home domain and the non-roaming domain in the roaming domain.
- Step S701 The terminal device UE sends a SIP service request to request a CoD service.
- the service request is the same as the first embodiment, but the manner in which the SIP service requests routing may be different.
- the Request URI is a PSI.
- S-CSCF1 routes the request to SCF1 through IFC.
- the triggering condition of the IFC is to determine the access to the non-home domain service according to the Request URI or the service identifier.
- SCF1 processes the service request, such as performing business authorization judgment and other possible business logic processing, and forwarding the service request after processing. If there is no non-homed SCF, SCF1 terminates the service request.
- the service request to the non-home SCF route is performed according to the normal PSI routing mode.
- This embodiment only illustrates one of a plurality of P S I routing modes.
- Step S720 The SCF2 performs business logic control, such as obtaining necessary service parameters, or selecting a suitable media server, and returning a service response.
- Step S725 the service response is routed to SCF1.
- SCF1 can remain in the SIP conversation path.
- some service control functions such as statistics on watching programs, duration, etc. of the UE, real-time charging control, and the like.
- a multicast LTV to a unicast LTV is shown. Schematic diagram of the process of switching.
- a typical scenario corresponding to this embodiment is that the multicast television service (LTV) switches to the LTV with Trick Mode, or the multicast television provided by unicast does not have a control mode.
- LTV multicast television service
- Step S801 the multicast service is established, and the multicast service is in progress.
- Step S802a the UE initiates a session change request.
- the UE initiates a VCR operation such as suspending and rewinding, and initiates switching of the multicast channel to the unicast channel.
- the UE sends a session modification Reinvite message, which carries an identifier for establishing a unicast channel (it may also be identified by information required to establish unicast or information required by RTSP control, or may be marked with an XML).
- a session modification Reinvite message which carries an identifier for establishing a unicast channel (it may also be identified by information required to establish unicast or information required by RTSP control, or may be marked with an XML).
- it is also necessary to carry the channel information to be played, the starting point of the playback, the range, and the like.
- the information currently to be unicasted can be carried by SIP messages. It can also be obtained by the SCF, such as through the channel switching result reporting process.
- Step S802b the Core IMS forwards the session modification request to the SCF.
- Step S803a After receiving the session change request, the SCF initiates a unicast service request and establishes a unicast session.
- the SCF After receiving the session change message, the SCF determines that a unicast service needs to be established according to the information in the message. As a B2B UA, the SCF initiates a new unicast service request and associates two SIP conversations.
- Step S803b the PTF establishes an RTSP session through the MCF and the MDF.
- Step S804a the SCF returns the unicast service information in the session modification success response 200 OK.
- Step S804b the Core IMS forwards the session modification success response 200 OK to the UE.
- the UE receives the media stream through the unicast path and can perform VCR operations.
- the PTF is illustrated as an independent logical entity.
- the PTF may be deployed on the SCF or on the MCF.
- the unicast LTV session reuses the multicast LTV session between the original UE and the SCF, while the SCF establishes a SIP session between the SCF and the MCF.
- the unicast LTV session reuses the multicast LTV session between the original UE and the SCF.
- FIG. 9 is a schematic flowchart of a method for switching a unicast LTV to a multicast LTV according to Embodiment 8 of the present invention.
- the typical scenario corresponding to this embodiment is to switch to the multicast TV service (LTV) by using the LTV with Trick Mode provided by unicast or without the control mode.
- LTV multicast TV service
- Step S901 The unicast service is established, and the unicast service is in progress.
- Step S902a the UE initiates a session modification request.
- the UE sends a session modification Reinvite message, which carries necessary information for establishing a multicast service, such as a channel identifier, a multicast address, and the like.
- the information of the multicast service can be carried by the SIP message or by the SCF.
- Step S902b the Core IMS forwards the session modification request to the SCF.
- Step S903 After receiving the session change request, the SCF modifies the unicast session.
- the SCF After receiving the session change message, the SCF judges that it needs to switch to the multicast service according to the information in the message. As the B2BUA, the SCF initiates a session change request, such as invoicing the unicast channel or releasing the unicast channel.
- Step S904a the SCF returns the multicast service information in the session modification success response 200 OK.
- Step S904b the Core IMS forwards the session modification success response 200 OK to the UE.
- Step S905 The UE joins the multicast group to receive the media stream.
- the PTF is illustrated as an independent logical entity.
- the PTF may be deployed on the SCF, or on the MCF.
- the multicast LTV session reuses the unicast LTV session between the original UE and the SCF while releasing or deactivating the SIP session between the SCF and the MCF.
- the multicast LTV session reuses the unicast LTV session between the original UE and the SCF.
- FIG. 10 it is a schematic flowchart of a unicast-to-unicast handover method according to Embodiment 9 of the present invention.
- the first part including step S100a1 to step S1001m, is a normal unicast establishment process, which is the same as Embodiment 5 of the present invention and will not be described in detail.
- the UE sends a handover request to the service control function, and requests to change the content of the access, and the service control function processes the request, which specifically includes the following steps:
- step S1002a the UE sends a SIP handover request message, such as a SIP Re-INVITE message, or a SIP Update message, carrying the content identifier to be handed over by the UE (for example, carried by a header field or carried by a message body), and the UE side transceiver media IP Address and port, as well as codec and other information.
- a SIP handover request message such as a SIP Re-INVITE message, or a SIP Update message, carrying the content identifier to be handed over by the UE (for example, carried by a header field or carried by a message body), and the UE side transceiver media IP Address and port, as well as codec and other information.
- Step S1002b The service control function sends an RTSP TEARDOWN message to the media server, releasing the previously established RTSP session, and terminating the transmission of the previous media content.
- Step S1002c the media server returns an RTSP 200 OK response.
- Step S1002d The service control function sends an RTSP SETUP to the media server, requesting to establish an RTSP session, and carrying information such as the content identifier after the handover, the IP address and port of the UE side transceiver medium, and the codec.
- Step S1002e The media server accepts the request, returns an RTSP 200 OK response, allocates an RTSP session identifier, and carries information such as an IP address and port of the media server and a codec.
- the PTF can modify the parameters of the terminal and the PSS content server through the SETUP message without releasing the original RTSP session.
- step S1002f to step S1002j is the same as the processing of step SlOOld to step SlOOlh.
- the media server sends the switched media content to the UE, and the handover is completed.
- step S1002d, step S1002e, step S1002i, and step S1002j are interactions between the service control function and the another media server.
- the present invention proposes a system and method for enabling mobile terminals to enjoy streaming media services under IMS control.
- the invention enables the IMS system to provide control both as a mobile and fixed terminal, which is a good way to enhance the user's service experience. Not only that, but the program also minimizes the impact on traditional PSS and MBMS systems, thereby protecting the operators' existing investments and saving operators' operating costs.
- the present invention can be implemented by hardware, or can be implemented by means of software plus necessary general hardware platform, and the technical solution of the present invention. It can be embodied in the form of a software product that can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including a number of instructions for making a computer device (may It is a personal computer, a server, or a network device, etc.) that performs the methods described in various embodiments of the present invention.
- a non-volatile storage medium which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.
- a computer device may It is a personal computer, a server, or a network device, etc.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Description
一种内容点播业务的建立方法、 系统和装置 本申请要求于 2008 年 3 月 28 日提交中国专利局, 申请号为 200810090365.2, 发明名称为 "一种 CoD业务的建立方法, 系统和装 置"的中国专利申请的优先权,其全部内容通过引用结合在本申请中。 技术领域
本发明实施例涉及数据通信领域,特别是涉及一种 CoD ( Content on Demand, 内容点播)业务的建立方法、 系统和装置。 背景技术 在通讯和 IT ( Information Technology, 信息技术)技术高度发展 的今天, 随着跨链路层传输介质的 IP ( Internet Protocol,互联网协议) 技术的出现, 互联网 Internet应用的迅速普及, 人们不再满足于单一 的语音通信方式, 而需要全新的多媒体通信方式, 因此, 移动通讯网 络和固定通讯网络的 IP化、 Internet和电信网络的融合已无可争议地 成为业界公认的发展方向。 为满足越来越突出的 IP多媒体应用的普 遍需求,第三代合作伙伴计划( The 3rd Generation Partnership Project, 以下筒称: 3GPP )在分组承载网基础上引入了全 IP业务网络架构的 基于 IP的多媒体子系统( IP based Multimedia Subsystem , 以下筒称: IMS )。
IMS是 3GPP R5阶段增加的宽带码分多址接入系统( Wide-band Code Division Multiple Access, 以下筒称: WCDMA ) 网络中叠加在 已有分组域之上的一个子系统,采用分组域作为其上层控制信令和媒 体传输的 7 载通道, ? I入会话初始化协议 ( Session Initiated Protocol, 以下筒称: SIP )作为业务控制协议, 利用 SIP筒单、 易扩展、 媒体 组合方便的特点, 使业务控制与承载控制分离, 提供丰富的多媒体业 务。
IMS主要的功能实体包括控制用户注册、会话控制等功能的呼叫 控制实体(Call Session Control Function, 以下筒称: CSCF )、 提供各 种业务逻辑控制功能的应用服务器(Application Server, 以下筒称: AS )、 集中管理用户签约数据的归属用户服务器 (Home Subscriber Server, 以下筒称: HSS ) 以及用于实现与电路交换网互通的媒体网
Media Gateway Function, 以下筒称: MGCF/IM-MGW ), 用户通过当 前所在地代理节点 ( Proxy Call Session Control Function , 以下筒称: P-CSCF )接入 IMS,会话和业务触发控制及与 AS的业务控制交互则 由其注册地的归属域服务节点( Serving Call Session Control Function, 以下筒称: S-CSCF ) 完成。
随着 IMS协议的逐步完善, 基于 IP互联网络的电视 IMS based IPTV ( Internet Protocol Television, 互联网协议电视)业务得到快速 发展, IMS based IPTV业务充分利用 IMS网络中已有的注册、 认证、 路由、 会话控制与建立、 业务触发、 计费和端到端服务质量(Quality of Service, 以下筒称: QoS )保证等机制来为用户提供流媒体业务、 融合流媒体和实时会话业务的多媒体业务。
下一代网络通信与因特网融合的服务和协议( Telecommunication and Internet converged Services and Protocols for Advanced Networking , 以下筒称: TISPAN )定义的 IMS based IPTV业务功能 架构如图 1所示, IPTV媒体服务器(Media Functions, 以下筒称: MF ) 负责到 UE ( User Equipment, 用户设备 )媒体流的控制与交付 ( Delivery )。 从功能角度分解为媒体控制功能实体( Media Control Function , 以下筒称: MCF)和媒体交付功能实体 ( Media Delivery Function ,以下筒称: MDF )。业务选择功能( Service Selection Function , 以下筒称: SSF ) 负责提供给用户可用的 IPTV业务信息。 业务控制 功能( Service Control Function, 以下筒称: SCF ) 负责 IPTV的业务 逻辑控制或执行。业务控制功能和媒体控制功能具有动态为用户所请 求的 IPTV业务选择媒体服务器的功能。
SIP协议与实时传输协议(Realtime Transport Protocol/Real-time Transport Control Protocol, 以下筒称: RTP/RTCP )、 会话描述协议 ( Session Description Protocol, 以下筒称: SDP )、 实时传送流媒体协 议 ( Real-Time Streaming Protocol, 以下筒称: RTSP )、 域名服务器 ( Domain Name Server ,以下筒称: DNS )等协议配合,共同完成 IPTV 系统的会话建立及媒体协商。
3GPP制定了 "透明的端到端包交换流媒体业务" 规范, 即 PSS ( Packet Switched Streaming Service, 分组交换流业务)规范。 PSS 规范采用客户端服务器模式, 客户端( Streaming Client )通过无线接 入网 ( GSM EDGE Radio Access Network/ UMTS Terrestrial Radio Acces Network, 以下筒称: GERAN/UTRAN ), 3GPP核心网 ( 3GPP Core Network ), IP 分组网 (IP Network ) 和媒体服务器 (Content Servers )进行通信。 PSS规范中, 客户端通过 RTSP协议和媒体服务 器建立 RTSP会话, 协商 RTP媒体传送通道, 接收媒体内容。 客户端 可以通过 RTSP通道发送快进、快退等操作命令,控制媒体流的传输。
3GPP规范中, 控制协议采用了 RTSP, 而不是 IMS的 SIP协议 进行业务控制。 因而, 无法支持采用 SIP协议的 IMS移动终端有效 的享受流媒体业务。 进而无法充分利用 IMS 系统提供的丰富功能, 如统一的用户管理, QoS控制, 策略控制, 计费控制, 会话建立机制 等等, 来享受流媒体业务。 这样即增大了运营商的业务运营成本, 同 时降低了用户的业务体验。 发明内容
本发明实施例提供一种 CoD业务的建立方法、 系统和装置, 可 以在 CoD建立过程中转换 SIP消息和 RTSP消息以达到消息互通, 实现采用 SIP协议的 IMS移动终端有效的享受流媒体业务, 改善 用户体验, 丰富业务种类的效果。
本发明实施例提出一种内容点播 CoD业务的建立方法,包括:
接收终端发送的会话发起协议 SIP业务请求;
转换所述 SIP业务请求为实时传送流媒体协议 RTSP业务请求, 并发送所述 RTSP业务请求给服务器;
接收所述服务器发送的 RTSP业务响应;
转换所述 RTSP业务响应为 SIP业务响应, 并发送所述 SIP业 务响应给所述终端,以建立所述终端与所述服务器间的 CoD业务。
本发明实施例还提供了一种内容点播 CoD业务的建立系统, 包括协议转换功能实体 PTF和内容服务器,
所述 PTF, 用于进行会话发起协议 SIP消息和实时传送流媒体 协议 RTSP消息之间的转换;
所述内容服务器, 用于接收并处理 RTSP业务消息, 发送媒体 流给终端。
本发明实施例还提供了一种协议转换功能实体 PTF, 包括: 信息接收模块, 用于接收会话发起协议 SIP业务请求, 和实时 传送流媒体协议 RTSP业务响应;
信息转换模块,用于将所述信息接收模块接收的所述 SIP业务 请求和所述 RTSP业务响应转换为 RTSP业务请求和 SIP业务响应; 信息发送模块,用于发送所述信息转换模块转换的 RTSP业务 请求和 SIP业务响应。
本发明实施例还提供了一种用户设备 UE, 包括:
信息接收模块, 用于接收会话发起协议 SIP业务响应, 并提取 实时传送流媒体协议 RSTP变更信息;
参数调整模块, 用于根据所述信息接收模块所提取的 RSTP 变更信息, 调整 RSTP参数。
本发明实施例的技术方案具有以下优点, 因为采用了一种 CoD业务的建立方法和装置, 可以在 CoD建立过程中转换 SIP消 息和 RTSP消息以达到消息互通, 实现采用 SIP协议的 IMS移动 终端有效的享受流媒体业务, 改善用户体验, 丰富业务种类的效 果。
附图说明
图 1为现有技术中, TISPAN定义的 IMS based IPTV业务功能 架构示意图;
图 2 为本发明实施例一中, 引入协议转换功能实体的系统结 构示意图;
图 3为本发明实施例二中, PTF部署在 MCF上的系统结构示 意图;
图 4为本发明实施例三中, PTF部署在 SCF上的系统结构示 意图;
图 5为本发明实施例四中, 一种建立 CoD业务的方法的流程 示意图;
图 6为本发明实施例五中, 一种建立 CoD业务的方法的流程 示意图;
图 7 为本发明实施例六中, 一种用户访问非归属域业务时建 立 CoD业务的方法的流程示意图;
图 8为本发明实施例七中, 一种多播电视节目直播 LTV到单 播 LTV的切换的方法的流程示意图;
图 9为本发明实施例八中,一种单播 LTV到多播 LTV的切换 方法的流程示意图;
图 10为本发明实施例九中, 一种单播到单播的切换方法的流 程示意图。 具体实施方式
本发明实施例在 TISPAN和 3GPP已有规范的基础上, 提出了使 支持 SIP协议的移动终端可以在 IMS控制下享受流媒体类业务的系 统和方法, 从而把 IMS应用到移动终端环境下, 使得移动终端可以 在 IMS控制下享受流媒体类业务。
下面结合附图和实施例,对本发明的具体实施方式作进一步详 细描述: 如图 2 所示, 为本发明实施例一中, 引入协议转换功能 实体的系统结构示意图。
在本系统中, 引入了协议转换功能实体 PTF 1 , 用来进行 SIP 消息和对应 RTSP消息之间的转换, 具体包括:
信息接收模块 11 , 用于接收 SIP业务请求, 和 RTSP业务响应, 或接收 RTSP PLAY消息;
信息转换模块 12, 用于将所述信息接收模块 11接收的所述 SIP 业务请求和所述 RTSP业务响应转换为 RTSP业务请求和 SIP业务响 应;
信息发送模块 13 , 用于发送所述信息转换模块 12转换的 RTSP 业务请求和 SIP业务响应, 或发送 RSTP PLAY消息, 或转发接收到 的 RTSP PLAY消息。
需要进一步指出的是, 上述 PTF 1中, 接收 RTSP PLAY消息, 发送 RSTP PLAY消息,转发接收到的 RTSP PLAY消息的功能可以根 据具体设置而选择是否实现上述功能,由于这种差异而导致的方案变 化也同样属于本发明的保护范围。
其中, 所述信息转换模块 12, 包括:
服务器选择子模块 121 , 用于根据所述信息接收模块接收的 SIP 业务请求, 选择为所述终端提供业务的服务器。
PTF 1通过 A接口从 UE 2接收 SIP消息,转化成对应的 RTSP 消息后, 通过 B接口转发给内容服务器 3。 反之, 通过 B接口从 内容服务器 3接收 RTSP消息, 转化成对应的 SIP消息后, 通过 A 接口转发出去, 发送给 UE 2。
因而在图 2中, A接口为 SIP协议, B接口为 RTSP协议。 其中, 本系统中的 UE 2, 包括:
信息接收模块 21 , 用于接收 SIP业务响应, 并提取 RSTP变更信 息;
参数调整模块 22, 用于根据信息接收模块 21所提取的 RSTP变
其中, 信息接收模块 21 , 包括:
信息接收子模块 211 , 用于接收 SIP业务响应;
信息提取子模块 212, 用于在信息接收子模块 21 所接收的 SIP 业务响应中提取 RSTP变更信息。
其中, 参数调整模块 22, 包括:
指示执行子模块 221 , 用于当信息接收模块 21所接收的 SIP业 务响应中包含的 RSTP变更信息为操作指示时,执行操作指示所对应 的操作;
参数更新子模块 222, 用于当信息接收模块 21所接收的 SIP业 务响应中包含的 RSTP 变更信息为参数信息时, 按照参数信息更新 RSTP参数。
内容服务器 3用来处理 RTSP消息, 和 /或为 UE 2提供媒体内 谷。
UE 2用来发起 SIP业务请求, 接收业务响应, 接收媒体内容。 具体方案中, PTF可以独立实现,或者部署在其他功能实体上。 如本发明实施例二和本发明实施例三所述。
内容服务器在 PSS 系统中, 为 PSS 内容服务器。 在 TISPAN IPTV系统中, 为媒体功能实体 Media Function, 逻辑上分为媒体 控制功能实体 MCF和 /或媒体传送功能实体 MDF。
如图 3所示, 为本发明实施例二中, PTF部署在 MCF上的系 统结构示意图。
在本系统中, PTF 1部署在 MCF 4上, 从而 MCF 4进行 SIP 消息和对应 RTSP消息之间的转换。
MCF 4用来进行 SIP消息和对应 RTSP消息之间的转换。 MCF 4从 A接口接收 UE 2发送的 SIP消息, 转化成对应的 RTSP消息 后, 通过 B接口转发给 MDF 5; 反之, 从 B接口接收 MDF 5发送 的 RTSP消息, 转化成对应的 SIP消息后, 通过 A接口转发出去, 发送给 UE 2。 因而在图 3中, A接口为 SIP协议, B接口为 RTSP
协议。
在本实施例中, MDF 5实现 PSS内容服务器 3的功能。
本发明中, UE 2和网络侧建立的用来进行 VCR控制,如快进, 快退等操作的 RTSP媒体控制通道,可以在 UE 2和 MCF 4之间建 立, 如 Xc接口所示; 也可以在 UE 2和 MDF 5之间建立, 如 Xc, 所示。
如图 4所示, 为本发明实施例三中, PTF部署在 SCF上的系 统结构示意图。
在本系统中, PTF 1部署在 SCF 6上, 从而 SCF 6进行 SIP消 息和对应 RTSP消息之间的转换。
SCF 6从 ISC接口接收 UE 2发送的 SIP消息, 转化成对应的 RTSP消息后, 通过 B接口转发给 MCF 4。 反之, 从 B接口接收 MCF 4发送的 RTSP消息,转化成对应的 SIP消息后, 通过 ISC接 口转发出去, 发送给 UE 2。
本实施例中, MCF 4和 MDF 5一起实现 PSS内容服务器 3的 功能。
下面, 结合本发明实施例一至三中所提供的系统, 提出以下 实施例, 进一步说明建立 CoD业务的具体过程。
如图 5所示, 为本发明实施例四中, 一种建立 CoD业务的方 法的流程示意图。
在本实施例中, 为方便说明, 选择基于本发明实施例二的系 统, PTF 1部署在 MCF 4上, 媒体控制通道建立在 UE 2和 MCF 4 之间, UE 2发起第一个 PLAY消息请求开始播放媒体流。
步骤 S501 , 终端设备 UE发送 SIP业务请求,请求 CoD业务。 终端设备 UE发送 SIP业务请求, 请求 CoD业务。 请求经过
Core IMS , 到达 SCF。 该 SIP请求是 SIP Invite请求, 或者 SIP Reinvite请求, 或者 SIP Update请求。
请求中携带 CoD内容标识信息,指示用户希望观看的 CoD节 目内容, 该标识可以有多种获取方式, 如通过 EPG, 或者某个媒
体描述文件等。
请求中同时携带 SDP信息,如 UE关于 RTSP内容控制通道的 IP地址和端口号信息,和 /或 UE关于 RTP内容传送通道的 IP地址 和端口信息。
请求中可能携带 UE的终端能力信息, 如: UE的便解码能力, 屏幕大小, 软件版本等; 和 /或用户的偏好信息, 如有多个 MF满 足条件, 优先选择价格低的, 而不是质量好的。
上述终端能力信息和 /或用户偏好信息, 可能存储在网络侧的 某个特定的功能实体中, 因而 UE可能只携带一个该实体的标识, 如 IP地址, 或 URI信息等, 将来需要使用这些信息的实体根据标 识从特定的存储实体获取即可。 此处的 "将来需要使用这些信息 的实体" 可能包括 SCF、 MCF, 这些实体可以根据终端能力信息 和 /或用户偏好信息进行必要的业务控制, 如选择合适的媒体服务 器。
UE的业务请求路由到 SCF可以采用以下任何一种方式,或者 两种方式的结合。
方式 1 : 通过初始过滤规则 IFC路由到 SCF, 触发条件可以为 根据业务请求的业务标识, 如 "IPTV业务", 或者业务标识也可以 划分更细的粒度, 如 CoD IPTV业务, 或 LTV IPTV业务。 因而 UE的业务请求中可能携带业务标识。
方式 2: 通过 PSI方式路由到 SCF。 此时 Request URI是一个 PSI, 遵循 PSI的路由规则。
SCF 收到业务请求后, 进行业务逻辑处理, 如判断用户是否 有访问所请求的业务的权限; 进行 PSS 内容服务器的选择。 SCF 可以根据不同的条件进行 PSS 内容服务器的选择。 选择条件可能 包含下述一种或多种信息: 内容标识, 终端能力信息, 用户偏好 信息, 用户请求的媒体内容在各个 PSS 内容服务器的分布信息, PSS内容服务器的状态信息, 如负载状况信息。
本实施例中, SCF根据上述一种或多种信息进行 MCF的选择。
SCF 可能判断用户所请求的业务是本域提供的业务, 或者其 他域提供的业务。 如果是本域提供的业务, 则可以作为 SIP Proxy, 进行业务处理并继续转发业务请求; 或者作为 SIP B2B UA, 终结 SIP对话并发起新的对话。如果用户所请求的业务是其他域提供的 业务, 则可能进行业务授权判断等可能的业务逻辑处理, 并转发 业务请求。
用户访问其他域业务的情况参见实施例六。
步骤 S505 , SCF转发 SIP 业务请求给 MCF。
步骤 S510, MCF发送 RTSP SETUP消息给 MDF。
MCF根据收到的 SIP业务请求消息, 构造对应的 RTSP业务 请求消息, 发送给 MDF。
RTSP业务请求消息为 RTSP SETUP消息; 或者 RTSP SETUP 消息和 RTSP PLAY消息。如果 SIP业务请求中 SDP中有多个媒体 成分, 则 MCF发送多个 RTSP SETUP消息和 /或 RTSP PLAY消息 给 MDF。 RTSP PLAY消息可能有不同的发送时机, 如 UE发送, 或者 MCF收到 SIP ACK确认后发送, 参见后面的实施例。
RTSP SETUP消息中, RTSP URL可以有多种获取方式。 如果 UE业务请求中携带了 RTSP URL参数信息。 如果 SIP请求未携带 RTSP URL信息, 则需要 MCF确定 URL信息。 如 MCF根据内容 标识, 进行 PSS内容服务器选择, 确定 RTSP URL信息。
MCF可以根据不同的条件进行 PSS内容服务器的选择。 选择 条件可能包含下述一种或多种信息: 内容标识, 终端能力信息, 用户偏好信息, 用户请求的媒体内容在各个 PSS 内容服务器的分 布信息, PSS内容服务器的状态信息, 如负载状况信息。 本实施例 中, MCF根据上述一种或多种信息进行 MDF的选择, 即进行 PSS 内容服务器的选择。
MCF发送 SETUP消息之前, 可选通过 RTSP Describe消息获 取内容描述信息, 通过 RTSP OPTIONS消息获取 PSS内容服务器 的能力信息。
步骤 S520, MDF返回 RTSP 200 OK响应消息给 MCF。
OK响应消息返回给 SCF。
SIP 200 OK响应中携带 SDP应答信息, 如 RTSP内容控制通 道的参数信息, 如 IP地址和 /或端口号信息, 和 /或 RTP内容传送 通道的参数信息, 如 IP地址和 /或端口信息。 其中内容控制通道的 参数信息可以是 MCF的参数信息, 也可以是 MDF的参数信息, 取决于媒体控制通道建立到 MCF, 还是 MDF。 本实施中以建立到 MCF为例。 内容传送通道的参数信息是 MDF的参数信息。
响应中携带 RTSP 内容控制通道的相关参数信息。 如 RTSP URL信息, SessionID信息等。
响应中可能携带指示 UE进行 RTSP协议状态调整的信息: 如 携带某个指示信息 (如网络侧 Pipeline指示信息), 或者直接携带 终端应该设置的 RTSP状态信息。 可以通过 SDP应答消息的属性 携带。如 a=fmtp:rtsp h-state=READY。具体的状态信息可能是 RTSP 协议状态机的任何一种状态,如 Init/Ready/Playing/Recording等等。
响应中可能携带 RTSP协议的相关参数信息。 如 CSeq信息, 从而指示 UE将来发送 RTSP消息的 CSeq参数。 可以通过 SDP应 答消息的属性携带。
响应中可能携带 PSS 内容服务器的能力信息, 如是否支持快 速内容切换, 是否支持管道 Pipeline等。 可以通过 SDP应答消息 的属性携带。
步骤 S530, SCF转发 80} 200 0 响应给1^。
SCF经过 Core IMS转发 SIP 200 OK给 UE。 P-CSCF和 RACS 交互, 进行资源预留。
步骤 S535和步骤 S540, UE返回 ACK确认。
UE经过 Core IMS , 发送 ACK消息。
步骤 S545 , UE发送 RTSP PLAY消息,请求开始播放媒体流。 UE发送 RTSP PLAY消息, 请求播放请求的媒体内容。
如上所述, RTSP媒体控制通道可能建立在 UE和 MCF, 或 UE和 MDF之间, 取决于响应中的 RTSP媒体控制通道的参数信 息。 本实施例以建立在 UE和 MCF之间为例。
UE设置本地的 RTSP协议状态。如果 SIP 200 OK响应消息中 携带了 RTSP协议状态指示信息, 如携带网络侧发送 RTSP PLAY 消息的指示, 表明网络侧已经发送了 PLAY 消息; 或者直接携带 RTSP协议状态。 UE可以根据该信息设置本地的 RTSP协议状态。 如果响应消息中没有携带, UE可以根据业务逻辑判断应该设置的 状态。
UE设置本地的 RTSP协议参数。如果 SIP 200 OK响应消息中 携带了 RTSP协议参数信息, 如 CSeq参数信息。 UE可以根据该 信息设置本地的 RTSP协议对应的参数信息。 如果没有携带, UE 可以自己决定所使用的 RTSP协议参数。
UE根据 SIP 200 OK响应消息中携带的 RTP通道的信息, 如 IP地址, 端口等, 建立内容传送通道, 用于传送, 接收媒体流。
UE根据 SIP 200 OK响应消息中携带的 RTSP URL, 以及会话 标识 SessionID信息, 建立内容控制通道, 发送 RTSP PLAY消息 请求播放媒体流。
如果响应消息中携带了 PSS 内容服务器的能力信息, 如是否 支持快速内容切换, 是否支持管道 Pipeline等。 可能通过 SDP属 性信息, 或者 SIP头域等携带。 UE可以获知 PSS内容服务器的能 力信息, 从而可以为将来 UE的行为提供参考。
本实施例中,以 UE发起请求播放媒体流的 RTSP PLAY消息, 该消息也可以通过 MCF/PTF发起。在下面的实施例中,说明了 PTF 发起 RTSP PLAY消息的情况。
步骤 S550和步骤 S555 , MCF转发 RTSP PLAY消息给 MDF,
接收 RTSP 200 OK响应
如果 RTSP内容控制通道直接建立在 UE和 MDF之间, 该步 骤可选。
MCF可能终结 UE的 RTSP会话, 和 MDF建立新的 RTSP会 话; 或者作为 RTSP代理, 转发 UE的 RTSP消息给 MDF。
步骤 S560, MCF转发 RTSP 200 OK响应给 UE。
至此, 完成会话建立过程, UE接收媒体内容。
需要进一步说明的是, 上述说明过程中提及的终端能力 /用户 偏好、 媒体服务器的选择、 业务触发、 RTSP状态指示, RTSP协 议参数信息都放到了实施例一中说明, 同样适用于其他实施例, 其他实施例中不再进行详细说明。
如图 6所示, 为本发明实施例五中, 一种建立 CoD业务的方 法的流程示意图。
在本实施例中, 为方便说明, 选择基于本发明实施例三的系 统, PTF 1部署在 SCF 6上, 媒体控制通道建立在 UE 2和媒体服 务器 3之间, PTF 1发起第一个 PLAY消息请求开始播放媒体流。 具体包括以下步骤:
步骤 S601 ,终端设备 UE发送 SIP业务请求, 请求 CoD业务。 本实施例步骤 S601同本发明实施例一中的步骤 S501。
步骤 S605 , SCF发送 RTSP SETUP消息给 PSS内容服务器。 SCF根据收到的 SIP业务请求消息,构造对应的 RTSP业务请 求消息, 发送给 PSS内容服务器。
RTSP业务请求消息为 RTSP SETUP消息; 或者 RTSP SETUP 消息和 RTSP PLAY消息。如果 SIP业务请求中 SDP中有多个媒体 成分, 则 SCF发送多个 RTSP SETUP消息和 /或 RTSP PLAY消息 给 PSS内容服务器。 RTSP PLAY消息可能有不同的发送时机, 如 UE收到 SIP 200 OK响应后发送, 如实施例四所示; 或者 SCF收 到 SIP ACK确认后发送, 如本实施例所示。 也可以在发送 SETUP 消息后发送, 如 Pipeline方式。
RTSP SETUP消息中, RTSP URL可以有多种获取方式。 如果 UE业务请求中携带了 RTSP URL参数信息。 如果 SIP请求未携带 RTSP URL信息, 则需要 SCF确定 URL信息。 如 SCF根据内容标 识, 进行 PSS内容服务器选择, 确定 RTSP URL信息。
SCF可以根据不同的条件进行 PSS 内容服务器的选择。 选择 条件可能包含下述一种或多种信息: 内容标识, 终端能力信息, 用户偏好信息, 用户请求的媒体内容在各个 PSS 内容服务器的分 布信息, PSS内容服务器的状态信息, 如负载状况信息。
步骤 S610, PSS 内容服务器返回 RTSP 200 OK响应消息给 SCF。
PSS内容服务器确定会话标识 SessionID, 源 source地址信息, 服务器端口 server-por等参数, 返回 RTSP 200 OK消息。
步骤 S620, SCF返回 SIP 200 OK响应给 UE。
SCF根据收到的 RTSP 200 OK响应消息, 构造对应的 SIP 200 OK响应消息返回给 UE。
响应中携带 SDP应答信息, 如 RTSP内容控制通道的参数信 息, 如 IP地址和 /或端口号信息, 和 /或 RTP内容传送通道的参数 信息, 如 IP 地址和 /或端口信息。 本实施例中, 内容控制通道和 / 或内容传送通道的参数信息是 PSS内容服务器的参数信息。
响应中携带 RTSP 内容控制通道的相关参数信息。 如 RTSP
URL信息, SessionID信息等。
响应中可能携带指示 UE进行 RTSP协议状态调整的信息: 如 携带某个指示信息 (如网络侧 Pipeline指示信息), 或者直接携带 终端应该设置的 RTSP状态信息。 可以通过 SDP应答消息的属性 携带。 具体的状态信息可能是 RTSP协议状态机的任何一种状态, :¾口 Init/Ready/Playing/Recording等等。 该实施例中, 该指示, 或者 状态信息的具体内 容和实施例四不 同 , 如 a=fmtp:rtsp h-state=PLAYing。 终端据此设置 RTSP状态为 PLAYing状态。 该 状态下, UE可以选择不再发送请求播放媒体流的 RTSP PLAY消
息。
响应中可能携带 RTSP协议的相关参数信息。 如 CSeq信息, 从而指示 UE将来发送 RTSP消息的 CSeq参数。 可以通过 SDP应 答消息的属性携带。
响应中可能携带 PSS 内容服务器的能力信息, 如是否支持快 速内容切换, 是否支持管道 Pipeline等。 可以通过 SDP应答消息 的属性携带。 SCF可以通过 RTSP OPTIONS消息获取 PSS内容服 务器的能力信息。
P-CSCF和 RACS交互, 进行资源预留。
同本发明实施例四, UE收到响应消息后, 需要根据响应进行 相应的本地处理:
UE设置本地的 RTSP协议状态。如果 SIP 200 OK响应消息中 携带了 RTSP协议状态指示信息, 如携带网络侧发送 RTSP PLAY 消息的指示, 表明网络侧已经发送了 PLAY 消息; 或者直接携带 RTSP协议状态。 UE可以根据该信息设置本地的 RTSP协议状态。 如果响应消息中没有携带, UE可以根据业务逻辑判断应该设置的 状态。
UE设置本地的 RTSP协议参数。如果 SIP 200 OK响应消息中 携带了 RTSP协议参数信息, 如 CSeq参数信息。 UE可以根据该 信息本地的 RTSP协议对应的参数信息。 如果没有携带, UE可以 自己决定所使用的 RTSP协议参数。
UE根据 SIP 200 OK响应消息中携带的 RTP通道的信息, 如 IP地址, 端口等, 建立内容传送通道, 用于传送, 接收媒体流。
UE可能根据 SIP 200 OK响应消息中携带的 RTSP URL , 以及 会话标识 SessionlD信息, 建立内容控制通道, 发送 RTSP PLAY 消息请求播放媒体流。
如果响应消息中携带了 PSS 内容服务器的能力信息, 如是否 支持快速内容切换, 是否支持管道 Pipeline等。 可能通过 SDP属 性信息, 或者 SIP头域等携带。 UE可以获知 PSS内容服务器的能
力信息, 从而可以为将来 UE的行为提供参考。
步骤 S625 , UE返回 ACK确认。
UE经过 Core IMS , 发送 ACK消息。
步骤 S630和步骤 S635 , SCF发送 RTSP PLAY消息给 PSS内 容服务器, 接收 RTSP 200 OK响应。
SCF发送 RTSP PLAY消息给 PSS内容服务器,请求播放媒体 流, 并接收 200 OK响应消息。
UE通过内容传送通道接收媒体内容。
在 UE通过内容传送通道接收媒体内容之前或之后,还可以包 括 UE与服务器间建立内容控制通道的步骤,通过内容控制通道的 建立, 可以实现对内容控制通道传送媒体内容的控制。
需要指出的是, 由于内容控制通道建立为可选步骤, 且可能 发生在 UE通过内容传送通道接收媒体内容之前或之后,所以在图 6中并未标识出该步骤,这一步骤的差别并不影响本发明的保护范 围。
需要进一步指出的是, 在上述的本发明实施例四和实施例五 中, 针对 RTSP PLAY消息的发送情况进行说明如下:
如上所述, 请求播放媒体流的 RTSP PLAY消息可以由 UE发 送, 也可以由网络侧实体 PTF发送。
网络侧发起 RTSP PLAY包含两种情况,一种是 PTF发送 RTSP SETUP消息时发送, 如采取 Pipeline方式; 另一种方式是 PTF收 到 ACK消息后发送。
无论上述哪种情况:
当 UE发送 SIP业务请求时, UE可能携带某个指示信息, 指 示网络侧 PTF, 或者 UE发送 RTSP PLAY消息请求播放媒体流。
当 PTF处理 SIP业务请求时, 可能根据 UE携带的指示, 或 者本地的配置决定是否发送 PLAY消息。
当 PTF返回 SIP 200 OK响应时, 响应中可能携带网络侧发送 RTSP PLAY消息的指示 (可能没有发送, 或者已经发送, 或者等
待收到 ACK后发送), 和 /或直接携带 RTSP协议状态为 Playing, UE收到响应后设置本地的 RTSP协议状态为 Playing,从而不用发 起用来请求播放媒体流的 RTSP PLAY消息。
如图 7 所示, 为本发明实施例六中, 一种用户访问非归属域 业务时建立 CoD业务的方法的流程示意图。
上述场景具体包括: 用户在归属域访问其他域的业务, 或者 用户在漫游域访问漫游域业务, 或者用户在漫游域访问非归属域 和非漫游域的业务。
步骤 S701 , 终端设备 UE发送 SIP业务请求,请求 CoD业务。 业务请求同实施例一,但该 SIP业务请求路由的方式可能有不 同。
该实施例中, Request URI是一个 PSI。此时 S-CSCF1通过 IFC 把请求路由到 SCF1。 IFC的触发条件为, 根据 Request URI, 或者 业务标识触发, 判断访问非归属域业务。
SCF1对业务请求进行处理, 如进行业务授权判断等可能的业 务逻辑处理, 处理后转发业务请求。 如果不存在非归属地的 SCF, SCF1终结业务请求。
业务请求到非归属地 SCF的路由根据正常的 PSI路由方式进 行。
步骤 S705、 步骤 S710和步骤 S715 , 通过 PSI路由方式, SIP 业务请求被路由到 SCF2。
本实施例只示意了多种 P S I路由方式中的一种。
步骤 S720, SCF2进行业务逻辑控制,如获取必要的业务参数, 或选择合适的媒体服务器等, 并返回业务响应。
步骤 S725 , 业务响应路由到 SCF1。
SCF1可以保留在 SIP对话路径中。 以便实现一些业务控制功 能, 如对 UE的观看节目, 时长等进行统计, 实时计费控制等。
步骤 S730和步骤 S735 , SCF1转发业务响应给 UE。
如图 8所示,为本发明实施例七中,一种多播 LTV到单播 LTV
的切换的方法的流程示意图。
该实施例对应的典型场景是多播电视业务( LTV )切换到多播 电视带控制模式 (LTV with Trick Mode ), 或者通过单播提供的多 播电视不带控制模式。
步骤 S801 , 多播业务已经建立, 多播业务进行中。
步骤 S802a, UE发起会话更改请求。
UE发起暂停、 快退等 VCR操作, 发起多播频道到单播频道 的切换。 UE发出会话修改 Reinvite消息, 其中携带建立单播频道 的标识(也可以用建立单播所需的信息或 RTSP控制所需的信息来 标识, 也可带 XML标识)。 直接选择单播频道的情况下还需要携 带播放的频道信息, 播放的起点, 范围等信息。
当前要进行单播频道的信息可以通过 SIP消息携带。也可以由 SCF获取, 如通过频道切换结果上报过程获取。
步骤 S802b, Core IMS转发会话修改请求给 SCF。
步骤 S803a, SCF收到会话更改请求后, 发起单播业务请求, 建立单播会话。
SCF 收到会话更改消息后, 根据消息中的信息判断需要建立 单播业务。 SCF作为 B2B UA, 发起新的单播业务请求, 并关联两 个 SIP对话。
步骤 S803b, PTF经过 MCF和 MDF建立 RTSP会话。
步骤 S804a, SCF在会话修改成功响应 200 OK中返回单播业 务信息。
步骤 S804b, Core IMS转发会话修改成功响应 200 OK给 UE。 UE通过单播路径接收媒体流, 并可以进行 VCR操作。
该实施例中, PTF示意为独立的逻辑实体, 实际上, 如系统架 构所述, PTF可能部署在 SCF上, 或者 MCF上。 当部署在 MCF 上时, 单播 LTV 会话重用原来 UE和 SCF之间的多播 LTV会话, 同时 SCF建立 SCF和 MCF之间的 SIP会话。当部署在 SCF上时, 单播 LTV 会话重用原来 UE和 SCF之间的多播 LTV会话。
如图 9所示,为本发明实施例八中,一种单播 LTV到多播 LTV 的切换方法的流程示意图。
该实施例对应的典型场景是通过单播提供的多播电视带控制 模式 ( LTV with Trick Mode ), 或者不带控制模式, 切换到多播电 视业务(LTV )。
步骤 S901 , 单播业务已经建立, 单播业务进行中。
步骤 S902a, UE发起会话修改请求。
UE发出会话修改 Reinvite消息, 其中携带建立多播业务的必 要信息, 如频道标识, 多播地址等信息。 多播业务的信息可以通 过 SIP消息携带, 也可以由 SCF获取。
步骤 S902b, Core IMS转发会话修改请求给 SCF。
步骤 S903 , SCF收到会话更改请求后, 修改单播会话。
SCF 收到会话更改消息后, 根据消息中的信息判断需要切换 到多播业务。 SCF作为 B2BUA, 发起会话更改请求, 如把单播通 道 Inactive, 或者释放单播通道。
步骤 S904a, SCF在会话修改成功响应 200 OK中返回多播业 务信息。
步骤 S904b, Core IMS转发会话修改成功响应 200 OK给 UE。 步骤 S905 , UE加入多播组, 接收媒体流。
该实施例中, PTF示意为独立的逻辑实体, 实际上, 如系统架 构所述, PTF可能部署在 SCF上, 或者 MCF上。 当部署在 MCF 上时, 多播 LTV 会话重用原来 UE和 SCF之间的单播 LTV会话, 同时释放或者去激活 SCF和 MCF之间的 SIP会话。当部署在 SCF 上时, 多播 LTV 会话重用原来 UE和 SCF之间的单播 LTV会话。
如图 10所示, 为本发明实施例九中, 一种单播到单播的切换 方法的流程示意图。
本实施例以本发明实施例三提出的 PTF部署在 SCF上的系统 为例。
其中, 本实施例划分为两部分:
第一部分、 包含步骤 SlOOla至步骤 SlOOlm, 是正常的单播 建立过程, 同本发明实施例五, 不再详述。
第二部分、 UE向业务控制功能发送切换请求, 要求更改访问 的内容, 业务控制功能处理这一请求, 具体包含以下步骤:
步骤 S1002a, UE发送 SIP 切换请求消息, 如 SIP Re-INVITE 消息, 或者 SIP Update消息, 携带 UE要切换的内容标识(比如通 过一个头域携带, 或通过消息体携带), 以及 UE侧收发媒体 IP地 址和端口以及编解码等信息。
步骤 S1002b , 业务控制功能向媒体服务器发送 RTSP TEARDOWN消息, 释放先前建立的 RTSP会话, 终止先前的媒体 内容的传送。
步骤 S1002c, 媒体服务器返回 RTSP 200 OK响应。
步骤 S1002d, 业务控制功能向媒体服务器发送 RTSP SETUP, 请求建立 RTSP会话, 携带切换后内容标识、 UE侧收发媒体 IP地 址和端口以及编解码等信息。
步骤 S1002e,媒体服务器接受请求,返回 RTSP 200 OK响应, 分配 RTSP会话标识, 携带媒体服务器侧收发媒体 IP地址和端口 以及编解码等信息。
当切换前后的媒体内容在同一个媒体服务器上时, 上述步骤 S 1002b和步骤 S1002c可选。 PTF可以通过 SETUP消息修改终端 和 PSS内容服务器的相关参数, 而不释放原来的 RTSP会话。
步骤 S1002f 至步骤 S1002j 的处理与步骤 SlOOld 至步骤 SlOOlh的处理同理, 步骤 S1002j完成后媒体服务器向 UE发送切 换后的媒体内容, 切换完成。
需要进一步指出的是, 本实施例中, 若切换后的媒体内容在 另外一个媒体服务器上,则步骤 S1002d、步骤 S1002e、步骤 S1002i 和步骤 S1002j 为业务控制功能与所述另外一个媒体服务器的交 互。
另一方面, 本发明所有实施例和具体的接入方式无关, 接入
方式的改变不影响本发明的保护范围。
本发明在 TISPAN和 3GPP已有规范的基础上,提出了使移动 终端可以在 IMS控制下享受流媒体类业务的系统和方法。 本发明 使得 IMS 系统可以同时作为移动和固定终端提供控制, 很好的增 强用户的业务体验。 不仅如此, 本方案还把对传统 PSS、 MBMS 系统的影响减至最少, 从而保护了运营商已有的投资, 节约了运 营商的运营成本。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解 到本发明可以通过硬件实现,也可以可借助软件加必要的通用硬件平 台的方式来实现基于这样的理解,本发明的技术方案可以以软件产品 的形式体现出来, 该软件产品可以存储在一个非易失性存储介质(可 以是 CD-ROM, U盘, 移动硬盘等) 中, 包括若干指令用以使得一 台计算机设备(可以是个人计算机, 服务器, 或者网络设备等)执行 本发明各个实施例所述的方法。
总之, 以上所述仅为本发明的较佳实施例而已, 并非用于限定本 发明的保护范围。 凡在本发明的精神和原则之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护范围之内。
Claims
1、 一种内容点播 CoD业务的建立方法, 其特征在于, 包括: 接收终端发送的会话发起协议 SIP业务请求;
转换所述 SIP业务请求为实时传送流媒体协议 RTSP业务请求, 并发送所述 RTSP业务请求给服务器;
接收所述服务器发送的 RTSP业务响应;
转换所述 RTSP业务响应为 SIP业务响应, 并发送所述 SIP业务 响应给所述终端, 以建立所述终端与所述服务器间的 CoD业务。
2、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 所述 SIP业务请求中携带指示信息,所述指示信息用于指示发送 RTSP播 放 PLAY消息请求播放媒体流。
3、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 当所 述 SIP业务请求为请求所述终端的归属业务时,所述接收终端发送的 SIP业务请求之前, 还包括:
所述 SIP业务请求通过初始过滤规则 IFC或公共业务标识 PSI方 式路由到归属域的业务控制功能实体 SCF;
所述 SCF转发所述 SIP业务请求,或终结所述 SIP业务请求并发 送新的 SIP业务请求。
4、 如权利要求 3所述 CoD业务的建立方法, 其特征在于, 所述 IFC, 具体为, 通过所述 SIP业务请求所对应的业务标识进 行触发;
所述 PSI,具体为,以通用请求资源标识符 Request URI作为 PSI。
5、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 当所 述 SIP业务请求为请求所述终端的非归属业务时,所述接收终端发送 的 SIP业务请求之前, 还包括:
所述 SIP业务请求通过 IFC方式路由到归属域的 SCF;
所述 SCF将所述 SIP业务请求转发到 Core IMS。
6、 如权利要求 5所述 CoD业务的建立方法, 其特征在于, 所述
IFC,具体为,通过所述 SIP业务请求所对应的业务标识或 Request URI 进行触发。
7、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 所述 转换 SIP业务请求为 RTSP业务请求, 并发送 RTSP业务请求给服务 器, 还包括:
根据以下信息中的至少一项, 选择为所述终端提供业务的服务 器: 所述终端的能力信息、 用户偏好信息。
8、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 所述 SIP业务响应, 包括以下信息中的至少一项:
RTSP内容控制信道参数信息、 RTP内容传送信道参数信息、 所 述终端调整 RTSP协议状态指示信息、 RTSP协议状态信息、 所述终 端调整 RTSP协议参数的信息和所述服务器能力信息;
当所述发送给终端的 SIP业务响应中不包含所述终端调整 RTSP 协议状态指示信息, 或不直接携带 RTSP协议状态信息时, 所述终端 按照默认状态配置所述终端的 RTSP协议状态; 或
当所述发送给终端的 SIP业务响应中包含所述终端调整 RTSP协 议状态指示信息时, 所述终端按照所述终端调整 RTSP协议状态指示 信息所指示的操作调整所述终端的 RTSP协议状态; 或
当所述发送给终端的 SIP业务响应中直接携带 RTSP协议状态信 息时, 所述终端按照 RTSP协议状态信息更新所述终端的 RTSP协议 状态。
9、 如权利要求 8所述 CoD业务的建立方法, 其特征在于, 当所 述发送给终端的 SIP业务响应中携带 RTSP协议参数信息时, 所述终 端按照 RTSP协议参数信息更新所述终端的 RTSP协议参数。
10、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 所 述建立终端与所述服务器间的 CoD业务, 还包括:
所述终端, 或协议转换功能实体 PTF 向所述服务器发送 RTSP PLAY消息, 请求所述服务器传送媒体内容。
11、 如权利要求 1所述 CoD业务的建立方法, 其特征在于, 所
述建立终端与所述服务器间的 CoD业务, 还包括:
建立终端与所述服务器间的 CoD业务时, 切换多播电视节目直 播 LTV业务到单播 LTV业务; 或
建立终端与所述服务器间的 CoD业务之后, 切换单播 LTV业务 到多播 LTV业务; 或
建立终端与所述服务器间的 CoD业务之后, 切换单播 CoD业务 到其他单播 CoD业务。
12、 如权利要求 11所述 CoD业务的建立方法, 其特征在于, 所 述切换多播 LTV业务到单播 LTV业务, 具体包括:
当 SCF与 PTF分开部署时, 所述 SCF接收所述终端发送的业务 切换请求, 并向 PTF发送 SIP业务请求, 所述 SIP业务请求被所述 PTF转换为 RSTP业务请求后发送至所述服务器,请求建立单播 LTV 业务; 或
当 SCF与 PTF合并部署时, 所述 SCF接收所述终端发送的业务 切换请求, 并向所述服务器发送 RSTP业务请求, 请求建立单播 LTV 业务。
13、 如权利要求 11所述 CoD业务的建立方法, 其特征在于, 所 述切换单播 LTV业务到多播 LTV业务, 具体包括:
当 SCF与 PTF分开部署时, 所述 SCF接收所述终端发送的业务 切换请求, 并向 PTF发送 SIP业务请求, 所述 SIP业务请求被所述 PTF转换为 RSTP业务请求后发送至所述服务器,请求拆除或去活单 播 LTV业务; 或
当 SCF与 PTF合并部署时, 所述 SCF接收所述终端发送的业务 切换请求, 并向所述服务器发送 RSTP业务请求, 请求拆除或去活单 播 LTV业务。
14、 如权利要求 11所述 CoD业务的建立方法, 其特征在于, 所 述切换单播 CoD业务到其他单播 CoD业务, 具体包括:
当 SCF与 PTF分开部署时, 所述 SCF接收所述终端发送的业务 切换请求, 并向 PTF发送 SIP业务请求, 所述 SIP业务请求被所述
PTF转换为 RTSP 业务释放请求和业务建立请求后发送至所述服务 器, 请求切换单播 CoD业务到其他单播 CoD业务; 或
当 SCF与 PTF合并部署时, 所述 SCF接收所述终端发送的业务 切换请求,并向所述服务器发送 RTSP业务释放请求和业务建立请求, 请求切换单播 CoD业务到其他单播 CoD业务。
15、 一种内容点播 CoD业务的建立系统, 其特征在于, 包括协 议转换功能实体 PTF和内容服务器,
所述 PTF,用于进行会话发起协议 SIP消息和实时传送流媒体协 议 RTSP消息之间的转换;
所述内容服务器, 用于接收并处理 RTSP业务消息, 发送媒体流 给终端。
16、 如权利要求 15所述 CoD业务的建立系统, 其特征在于, 所述 PTF,具体用于将接收到的所述终端发送的 SIP业务请求转 换为 RTSP业务请求, 发送给所述内容服务器;
将接收到的所述内容服务器发送的 RTSP业务响应转换为 SIP业 务响应求, 发送给所述终端。
17、 如权利要求 15所述 CoD业务的建立系统, 其特征在于, 所述 PTF, 还用于接收并转发所述终端发送的 RTSP播放 PLAY 消息给所述内容服务器; 或
发送 RTSP PLAY消息给所述内容服务器。
18、 如权利要求 16所述 CoD业务的建立系统, 其特征在于, 所述 PTF, 还用于根据接收到的所述终端发送的 SIP业务请求, 选择为所述终端提供业务的服务器。
19、 一种协议转换功能实体 PTF, 其特征在于, 包括:
信息接收模块, 用于接收会话发起协议 SIP业务请求, 和实时传 送流媒体协议 RTSP业务响应;
信息转换模块,用于将所述信息接收模块接收的所述 SIP业务请 求和所述 RTSP业务响应转换为 RTSP业务请求和 SIP业务响应; 信息发送模块, 用于发送所述信息转换模块转换的 RTSP业务请
求和 SIP业务响应。
20、 如权利要求 19所述 PTF, 其特征在于,
所述信息接收模块, 还用于接收 RTSP播放 PLAY消息; 所述信息发送模块, 还用于发送 RSTP PLAY消息, 或转发接收 到的 RTSP PLAY消息。
21、 如权利要求 20所述 PTF, 其特征在于, 所述信息转换模块, 包括:
服务器选择子模块,用于根据所述信息接收模块接收的 SIP业务 请求, 选择为所述终端提供业务的服务器。
22、 一种用户设备 UE, 其特征在于, 包括:
信息接收模块, 用于接收会话发起协议 SIP业务响应, 并提取实 时传送流媒体协议 RSTP变更信息;
参数调整模块, 用于根据所述信息接收模块所提取的 RSTP变更 信息, 调整 RSTP参数。
23、 如权利要求 22所述 UE, 其特征在于, 所述信息接收模块, 包括:
信息接收子模块, 用于接收 SIP业务响应;
信息提取子模块,用于在所述信息接收子模块所接收的 SIP业务 响应中提取 RSTP变更信息。
24、 如权利要求 22所述 UE, 其特征在于, 所述参数调整模块, 包括:
指示执行子模块,用于当所述信息接收模块所接收的 SIP业务响 应中包含的 RSTP变更信息为操作指示时,执行所述操作指示所对应 的操作;
参数更新子模块,用于当所述信息接收模块所接收的 SIP业务响 应中包含的 RSTP 变更信息为参数信息时, 按照所述参数信息更新 RSTP参数。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP09724347A EP2262199A4 (en) | 2008-03-28 | 2009-03-11 | METHOD OF MANUFACTURING, SYSTEM AND DEVICE FOR A DEMAND-ORIENTED SERVICE FOR CONTINUOUS DELIVERY |
US12/892,608 US8473621B2 (en) | 2008-03-28 | 2010-09-28 | Method, system, and apparatus for creating content-on-demand service |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810090365.2 | 2008-03-28 | ||
CN2008100903652A CN101547189B (zh) | 2008-03-28 | 2008-03-28 | 一种CoD业务的建立方法,系统和装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/892,608 Continuation US8473621B2 (en) | 2008-03-28 | 2010-09-28 | Method, system, and apparatus for creating content-on-demand service |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2009117919A1 true WO2009117919A1 (zh) | 2009-10-01 |
Family
ID=41112950
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2009/070730 WO2009117919A1 (zh) | 2008-03-28 | 2009-03-11 | 一种内容点播业务的建立方法、系统和装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US8473621B2 (zh) |
EP (1) | EP2262199A4 (zh) |
CN (1) | CN101547189B (zh) |
WO (1) | WO2009117919A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120158993A1 (en) * | 2010-12-16 | 2012-06-21 | Openet Telecom Ltd. | Methods, systems and devices for pipeline processing |
US20120155389A1 (en) * | 2010-12-16 | 2012-06-21 | Openet Telecom Ltd. | Methods, systems and devices for dynamic context-based routing |
CN113329040A (zh) * | 2021-08-03 | 2021-08-31 | 江苏怀业信息技术股份有限公司 | 媒体流转发过程中的协议转换方法、装置 |
Families Citing this family (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7675854B2 (en) | 2006-02-21 | 2010-03-09 | A10 Networks, Inc. | System and method for an adaptive TCP SYN cookie with time validation |
US8312507B2 (en) | 2006-10-17 | 2012-11-13 | A10 Networks, Inc. | System and method to apply network traffic policy to an application session |
US8584199B1 (en) | 2006-10-17 | 2013-11-12 | A10 Networks, Inc. | System and method to apply a packet routing policy to an application session |
BRPI0813429B1 (pt) * | 2007-06-19 | 2020-09-08 | Nokia Technologies Oy | Método de comutação da recepção de fluxos de mídia, aparelho e sistema |
US8560938B2 (en) | 2008-02-12 | 2013-10-15 | Oracle International Corporation | Multi-layer XML customization |
US8875306B2 (en) * | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US8538998B2 (en) | 2008-02-12 | 2013-09-17 | Oracle International Corporation | Caching and memory optimizations for multi-layer XML customization |
US8788542B2 (en) * | 2008-02-12 | 2014-07-22 | Oracle International Corporation | Customization syntax for multi-layer XML customization |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8782604B2 (en) * | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
US8667031B2 (en) * | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US8996658B2 (en) * | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US8271609B2 (en) * | 2008-09-15 | 2012-09-18 | Oracle International Corporation | Dynamic service invocation and service adaptation in BPEL SOA process |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
KR101609219B1 (ko) | 2008-10-29 | 2016-04-06 | 삼성디스플레이 주식회사 | 액정표시장치 및 이의 제조방법 |
US8332654B2 (en) * | 2008-12-08 | 2012-12-11 | Oracle International Corporation | Secure framework for invoking server-side APIs using AJAX |
US8374172B2 (en) | 2009-04-03 | 2013-02-12 | At&T Intellectual Property I, L.P. | Method and apparatus for managing communication sessions |
CN101583018B (zh) * | 2009-06-03 | 2011-05-11 | 中兴通讯股份有限公司 | 流媒体的频道业务和点播业务统一管理的方法及系统 |
US9960967B2 (en) | 2009-10-21 | 2018-05-01 | A10 Networks, Inc. | Determining an application delivery server based on geo-location information |
US8856737B2 (en) | 2009-11-18 | 2014-10-07 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US9781197B2 (en) * | 2009-11-30 | 2017-10-03 | Samsung Electronics Co., Ltd. | Methods and apparatus for selection of content delivery network (CDN) based on user location |
CN102088447A (zh) * | 2009-12-08 | 2011-06-08 | 中国移动通信集团公司 | Ims系统中的媒体控制方法及其系统 |
US9215275B2 (en) | 2010-09-30 | 2015-12-15 | A10 Networks, Inc. | System and method to balance servers based on server load status |
KR20120053608A (ko) * | 2010-11-18 | 2012-05-29 | 삼성전자주식회사 | 광대역 무선 접속 시스템에서 동적 멀티캐스트 경로 할당 장치 및 방법 |
US9609052B2 (en) * | 2010-12-02 | 2017-03-28 | A10 Networks, Inc. | Distributing application traffic to servers based on dynamic service response time |
US8725820B2 (en) | 2010-12-16 | 2014-05-13 | Openet Telecom Ltd. | Methods, systems and devices for horizontally scalable high-availability dynamic context-based routing |
US8725896B2 (en) | 2010-12-16 | 2014-05-13 | Openet Telecom Ltd. | Methods, systems and devices for forked routing |
US8675659B2 (en) | 2010-12-16 | 2014-03-18 | Openet Telecom Ltd. | Methods, systems and devices for multiphase decoding |
CN102186103A (zh) * | 2011-04-20 | 2011-09-14 | 深圳市同洲软件有限公司 | 一种节目点播请求发送方法及系统 |
US9565074B2 (en) | 2011-04-26 | 2017-02-07 | Openet Telecom Ltd. | Systems, devices, and methods of orchestrating resources and services across multiple heterogeneous domains |
US9641403B2 (en) | 2011-04-26 | 2017-05-02 | Openet Telecom Ltd. | Systems, devices and methods of decomposing service requests into domain-specific service requests |
US9130760B2 (en) | 2011-04-26 | 2015-09-08 | Openet Telecom Ltd | Systems, devices and methods of establishing a closed feedback control loop across multiple domains |
US8929859B2 (en) | 2011-04-26 | 2015-01-06 | Openet Telecom Ltd. | Systems for enabling subscriber monitoring of telecommunications network usage and service plans |
US9444692B2 (en) | 2011-04-26 | 2016-09-13 | Openet Telecom Ltd. | Systems, devices and methods of crowd-sourcing across multiple domains |
US9450766B2 (en) | 2011-04-26 | 2016-09-20 | Openet Telecom Ltd. | Systems, devices and methods of distributing telecommunications functionality across multiple heterogeneous domains |
US9565063B2 (en) | 2011-04-26 | 2017-02-07 | Openet Telecom Ltd. | Systems, devices and methods of synchronizing information across multiple heterogeneous networks |
WO2012174355A1 (en) * | 2011-06-15 | 2012-12-20 | Interdigital Patent Holdings, Inc. | Method and apparatus for delivering content to a roaming mobile station using an ims infrastructure |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
US8897154B2 (en) | 2011-10-24 | 2014-11-25 | A10 Networks, Inc. | Combining stateless and stateful server load balancing |
US9386088B2 (en) | 2011-11-29 | 2016-07-05 | A10 Networks, Inc. | Accelerating service processing using fast path TCP |
US9300531B2 (en) | 2011-12-12 | 2016-03-29 | Openet Telecom Ltd. | Systems, devices, and methods of orchestration and application of business rules for real-time control of subscribers in a telecommunications operator's network |
US20130159150A1 (en) * | 2011-12-19 | 2013-06-20 | Verizon Patent And Licensing, Inc. | Mobile device data metering, bandwidth allocation, and traffic control |
US9094364B2 (en) | 2011-12-23 | 2015-07-28 | A10 Networks, Inc. | Methods to manage services over a service gateway |
US9173081B2 (en) | 2012-01-27 | 2015-10-27 | Openet Telecom Ltd. | System and method for enabling interactions between a policy decision point and a charging system |
US10044582B2 (en) | 2012-01-28 | 2018-08-07 | A10 Networks, Inc. | Generating secure name records |
US8782221B2 (en) | 2012-07-05 | 2014-07-15 | A10 Networks, Inc. | Method to allocate buffer for TCP proxy session based on dynamic network conditions |
WO2014052099A2 (en) | 2012-09-25 | 2014-04-03 | A10 Networks, Inc. | Load distribution in data networks |
US10021174B2 (en) | 2012-09-25 | 2018-07-10 | A10 Networks, Inc. | Distributing service sessions |
US10002141B2 (en) | 2012-09-25 | 2018-06-19 | A10 Networks, Inc. | Distributed database in software driven networks |
US9106561B2 (en) | 2012-12-06 | 2015-08-11 | A10 Networks, Inc. | Configuration of a virtual service network |
US9843484B2 (en) | 2012-09-25 | 2017-12-12 | A10 Networks, Inc. | Graceful scaling in software driven networks |
US9338225B2 (en) | 2012-12-06 | 2016-05-10 | A10 Networks, Inc. | Forwarding policies on a virtual service network |
US9531846B2 (en) | 2013-01-23 | 2016-12-27 | A10 Networks, Inc. | Reducing buffer usage for TCP proxy session based on delayed acknowledgement |
KR20140099976A (ko) * | 2013-02-04 | 2014-08-14 | 삼성전자주식회사 | 휴대 단말기의 무선 영상 전송 방법 및 시스템 |
US9900252B2 (en) | 2013-03-08 | 2018-02-20 | A10 Networks, Inc. | Application delivery controller and global server load balancer |
US9992107B2 (en) | 2013-03-15 | 2018-06-05 | A10 Networks, Inc. | Processing data packets using a policy based network path |
US10027761B2 (en) | 2013-05-03 | 2018-07-17 | A10 Networks, Inc. | Facilitating a secure 3 party network session by a network device |
WO2014179753A2 (en) | 2013-05-03 | 2014-11-06 | A10 Networks, Inc. | Facilitating secure network traffic by an application delivery controller |
US10230770B2 (en) | 2013-12-02 | 2019-03-12 | A10 Networks, Inc. | Network proxy layer for policy-based application proxies |
US9942152B2 (en) | 2014-03-25 | 2018-04-10 | A10 Networks, Inc. | Forwarding data packets using a service-based forwarding policy |
US9942162B2 (en) | 2014-03-31 | 2018-04-10 | A10 Networks, Inc. | Active application response delay time |
US9906422B2 (en) | 2014-05-16 | 2018-02-27 | A10 Networks, Inc. | Distributed system to determine a server's health |
US10129122B2 (en) | 2014-06-03 | 2018-11-13 | A10 Networks, Inc. | User defined objects for network devices |
US9992229B2 (en) | 2014-06-03 | 2018-06-05 | A10 Networks, Inc. | Programming a data network device using user defined scripts with licenses |
US9986061B2 (en) | 2014-06-03 | 2018-05-29 | A10 Networks, Inc. | Programming a data network device using user defined scripts |
US10581976B2 (en) | 2015-08-12 | 2020-03-03 | A10 Networks, Inc. | Transmission control of protocol state exchange for dynamic stateful service insertion |
US10243791B2 (en) | 2015-08-13 | 2019-03-26 | A10 Networks, Inc. | Automated adjustment of subscriber policies |
US10909186B2 (en) | 2015-09-30 | 2021-02-02 | Oracle International Corporation | Multi-tenant customizable composites |
US10589406B2 (en) | 2016-08-26 | 2020-03-17 | Cumulus Digital Systems, Inc. | Guidance device and method for installing flanges |
WO2019224574A1 (en) * | 2018-05-21 | 2019-11-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Ims-based streaming framework |
CN110662270B (zh) * | 2018-06-28 | 2021-05-18 | 华为技术有限公司 | 通信方法及装置 |
CN109327435B (zh) * | 2018-09-20 | 2021-05-25 | 安徽云森物联网科技有限公司 | 媒体资源获取方法、装置及网关设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1487700A (zh) * | 2001-03-10 | 2004-04-07 | 华为技术有限公司 | 互通代理装置及不同协议网络之间进行互通的系统和方法 |
US20040125757A1 (en) * | 2002-12-30 | 2004-07-01 | Martti Mela | Streaming media |
CN1741633A (zh) * | 2004-08-27 | 2006-03-01 | 华为技术有限公司 | 实现电路域移动流媒体点播的系统及其方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7680143B2 (en) * | 2002-12-12 | 2010-03-16 | Rpx Corporation | Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration |
US20040184432A1 (en) * | 2003-03-19 | 2004-09-23 | Ralitsa Gateva | Method for controlling streaming services |
CN101026616B (zh) * | 2006-02-18 | 2013-01-09 | 华为技术有限公司 | 基于ip多媒体子系统的交互式媒体会话建立方法 |
GB2452662A (en) * | 2006-06-02 | 2009-03-11 | Ericsson Telefon Ab L M | Method and apparatuses for establishing a session between a client terminal and a media supply system to transport a unicast media stream over an IP network |
CN100553219C (zh) * | 2006-09-22 | 2009-10-21 | 中国移动通信集团公司 | Ims域与cs域消息互通的方法 |
US20080084867A1 (en) * | 2006-09-25 | 2008-04-10 | George Foti | Method and server for transferring a multimedia session from a first terminal to a second terminal |
US20080151918A1 (en) * | 2006-12-22 | 2008-06-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of correlating a media session to a signaling session |
-
2008
- 2008-03-28 CN CN2008100903652A patent/CN101547189B/zh active Active
-
2009
- 2009-03-11 EP EP09724347A patent/EP2262199A4/en not_active Withdrawn
- 2009-03-11 WO PCT/CN2009/070730 patent/WO2009117919A1/zh active Application Filing
-
2010
- 2010-09-28 US US12/892,608 patent/US8473621B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1487700A (zh) * | 2001-03-10 | 2004-04-07 | 华为技术有限公司 | 互通代理装置及不同协议网络之间进行互通的系统和方法 |
US20040125757A1 (en) * | 2002-12-30 | 2004-07-01 | Martti Mela | Streaming media |
CN1741633A (zh) * | 2004-08-27 | 2006-03-01 | 华为技术有限公司 | 实现电路域移动流媒体点播的系统及其方法 |
Non-Patent Citations (1)
Title |
---|
See also references of EP2262199A4 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120158993A1 (en) * | 2010-12-16 | 2012-06-21 | Openet Telecom Ltd. | Methods, systems and devices for pipeline processing |
US20120155389A1 (en) * | 2010-12-16 | 2012-06-21 | Openet Telecom Ltd. | Methods, systems and devices for dynamic context-based routing |
US8824370B2 (en) * | 2010-12-16 | 2014-09-02 | Openet Telecom Ltd. | Methods, systems and devices for dynamic context-based routing |
US8943221B2 (en) * | 2010-12-16 | 2015-01-27 | Openet Telecom Ltd. | Methods, systems and devices for pipeline processing |
CN113329040A (zh) * | 2021-08-03 | 2021-08-31 | 江苏怀业信息技术股份有限公司 | 媒体流转发过程中的协议转换方法、装置 |
CN113329040B (zh) * | 2021-08-03 | 2021-11-02 | 江苏怀业信息技术股份有限公司 | 媒体流转发过程中的协议转换方法、装置 |
Also Published As
Publication number | Publication date |
---|---|
EP2262199A1 (en) | 2010-12-15 |
EP2262199A4 (en) | 2011-08-10 |
CN101547189A (zh) | 2009-09-30 |
CN101547189B (zh) | 2011-08-10 |
US8473621B2 (en) | 2013-06-25 |
US20110023071A1 (en) | 2011-01-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2009117919A1 (zh) | 一种内容点播业务的建立方法、系统和装置 | |
US10778458B2 (en) | Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network | |
CN100579209C (zh) | 基于ngn网络实现时移电视业务的方法及系统、媒体资源设备 | |
US8332527B2 (en) | Streaming media network system, streaming media service realization method and streaming media service enabler | |
US8046479B2 (en) | Media channel management | |
US8307049B2 (en) | Method and device for obtaining media description information of IPTV services | |
WO2010115331A1 (zh) | 内容定位方法及内容分发网络节点 | |
US20090313376A1 (en) | Method and apparatuses for establishing a session between a client terminal and a media supply system to transport a unicast media stream over an ip network | |
WO2008134955A1 (fr) | Procédé, système et appareil pour appliquer des informations de capacité de terminal dans un service iptv | |
WO2008037218A1 (fr) | Procédé, système et serveur multimédia permettant une commutation rapide d'un canal de télévision sur internet (iptv) | |
WO2010022570A1 (zh) | 基于网际协议电视的信息推送方法、装置及系统 | |
WO2009024092A1 (fr) | Procédé et système permettant la commande d'autorisation de ressource de service | |
WO2008110122A1 (fr) | Procédé, système et entité tampon de commutation de chaînes de téléréseau | |
WO2012152223A1 (zh) | 共享内容的方法和设备 | |
WO2011015015A1 (zh) | 内容上行方法及内容交付功能实体 | |
WO2009155770A1 (zh) | 交互式网络电视系统及其内容推播方法 | |
WO2009003408A1 (fr) | Procédé de commutation d'un flux multimédia, système et équipement dans un service de télévision à décalage temporel | |
WO2009049518A1 (fr) | Procédé, système et entité d'établissement de session de système de télévision par internet ip | |
WO2009006820A1 (fr) | Procédé et système pour fournir un flux multimédia durant une commutation de serveurs multimédias | |
WO2009024077A1 (fr) | Procédé et dispositif pour acquérir un paramètre de service iptv | |
WO2010022603A1 (zh) | 附着到对等网络及获取iptv内容的方法、系统和装置 | |
WO2008098504A1 (fr) | Procédé et système pour fournir un service multidiffusion et dispositif pour fournir un paramètre de service multidiffusion | |
WO2009026810A1 (fr) | Procédé, entité et système pour réaliser une commande de distribution de multimédia | |
WO2009012714A1 (fr) | Procédé et dispositif pour commander les médias en flux | |
CN101741509B (zh) | 速率适配方法、装置及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 09724347 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2009724347 Country of ref document: EP |