The present invention relates to establishing and controlling an IP unicast service and is applicable in particular, though not necessarily, to video-on-demand services.
IP television or IPTV is the name given to a range of services which allow television to be delivered over an IP network. Due to the flexible nature of an IP network, IPTV will allow for a much more personalised service to users, e.g. video-on-demand, with information delivered to users over unicast IP streams. However, to order and control these user specific services, the user would normally be expected to use his or her remote control whilst sitting in front of a Set-Top-Box/TV. Currently the predominant way of controlling these unicast streams is to use the real time streaming protocol (RTSP). RTSP does not specify a transport protocol but may be used, for example, to establish and control real-time transport protocol (RTP) media streams. RTSP is in many ways similar to the HTTP protocol used to request and exchange information over the WWW, but is tailored for streaming media such as audio and video. RTSP allows for a client to request particular media streams from a streaming server, and specifies commands such as PLAY and PAUSE. RTSP is well suited to the conventional set-top-box use case.
It is expected that users of mobile terminals such as mobile telephones will wish to avail themselves of IPTV services. Indeed, this is probably key to the business models of network operators currently installing high capacity cellular networks such as 3G networks. Within cellular networks, IPTV is a service which will likely be facilitated by the so-called IP Multimedia Subsystem (IMS). IMS is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7), although the IMS architecture is such that its services can be accessed and controlled via other interfaces, for example the Internet. IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals, or user terminals and application servers. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
It will be appreciated that IMS and RTSP can be considered as alternative approaches to the establishment and control of unicast streaming sessions. Whilst IMS provides a mechanism for controlling QoS and charging, as well as transcoder negotiation, RTSP supports trickplay and basic video-oriented commands.
According to a first aspect of the present invention there is provided a method of setting up a session between a client terminal and a media supply system in order to transport a unicast media stream from the media supply system to the client terminal over an intervening IP network, the media supply system implementing the Real Time Streaming Protocol, the method comprising:
The media supply system may be implemented as one or more control servers plus one or more media unicast servers. In the case of video-on-demand, the former are video-on-demand control servers whilst the latter are video unicast servers.
Preferably, the IP Multimedia Subsystem network comprises a Proxy Call/Session Control Function (P-CSCF) allocated to the client terminal and through which all IMS/SIP signalling is routed.
Where the media supply system does not directly interface to the IP Multimedia Subsystem network, said negotiation may be carried out via a SIP application server of the IP Multimedia Subsystem network. The SIP application server provides for the translation of SIP messages received from the client terminal into Real Time Streaming Protocol messages for transmission to the media supply system.
Preferably, the IP Multimedia Subsystem network uses the identified source and destination IP addresses and port numbers to allocate resources for the unicast media stream. This will typically involve a Proxy Call/Session Control Function instructing a Border Gateway Function to open up a pinhole in respect of a media stream flowing between the source and destination IP addresses and port numbers.
The invention is applicable in particular to the case where the client terminal is a mobile terminal, for example a cellular telephone.
According to one embodiment of the present invention, the message flow associated with the negotiation step comprises:
A SIP INVITE sent from the client terminal to the SIP application server via a Proxy Call/Session Control Function;
An RTSP DESCRIBE sent from the SIP application server to the media supply system;
A 200 OK returned from the media supply system via the application server and the Proxy Call/Session Control Function.
In the case where the 200 OK identifies the source IP address and port number for the media source, this exchange completes the negotiation over the IMS. However, if this information is not contained in the 200 OK, the client terminal may send a SIP reINVITE to the application server via the Proxy Call/Session Control Function. The application server translates the reINVITE into an RTSP SETUP message and sends this to the media supply system. The media supply system returns a further 200 OK to the client terminal, via the application server and the Proxy Call/Session Control Function. The 200 OK contains the required address information which is observed by the Proxy Call/Session Control Function.
In certain embodiments of the invention, the media supply system has an interface to the IP Multimedia Subsystem, in which case the SIP INVITE, and optionally SIP reINVITE, messages are sent directly to the media supply system.
According to a second aspect of the present invention there is provided a Session Initiation Protocol application server having an interface to an IP Multimedia Subsystem network and comprising:
Said Session Initiation Protocol request may be a Session Initiation Protocol INVITE, said means for processing being arranged to translate the message into a Real Time Streaming Protocol DESCRIBE.
The server may further comprise means for receiving a 200 OK response to said Real Time Streaming Protocol message from the media supply system, modifying the SDP of the response to include the source IP address and port number of a requested media stream, and sending the modified 200 OK to the client terminal.
Alternatively, the server may comprise means for receiving a 200 OK response to said Real Time Streaming Protocol message from the media supply system, for responding to the media supply system with a request for further information, for receiving a further 200 OK message containing the requested information and modifying the response before forwarding it to the client terminal.
Said Session Initiation Protocol request may be a Session Initiation Protocol reINVITE, said means for processing being arranged to translate the message into a Real Time Streaming Protocol SETUP.
According to a third aspect of the present invention there is provided a media supply system having an interface to an IP Multimedia Subsystem network and comprising:
In an embodiment of the invention, the media supply system is a video-on-demand system.
According to a fourth aspect of the present invention there is provided a client terminal comprising:
The client terminal may be a mobile terminal, for example a cellular telephone, or a fixed terminal.
A brief description of the architecture and operation of the IP Multimedia Subsystem (IMS) will aid in understanding embodiments of the present invention.
Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP client (typically residing in a user terminal); the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the (IP) address at which a SIP user identity can be reached. The user receives a unique Uniform Resource Identifier (URI) from the S-CSCF to be used when it initiates a dialog. In 3GPP, when a SIP client performs a registration, the IMS authenticates the user (using the AKA procedure), and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating a S-CSCF is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if one is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. (It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.) When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides (of the IMS). (For the terminating call the request will include the P-CSCF address and the User Equipment (UE) address.)
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. ASs provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFCs) are used by a S-CSCF to determine which ASs should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile (UP). Certain ASs will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the AS). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded.
MTRX—Media Transmission/Reception Part 8,9; The “traditional” Set Top Box functionalities in an IMS enabled Set Top Box 10, for example reception of MPEG2 and/or MPEG4 streams and conversion of such streams for delivery to a TV 11.
IMOD—Identity and IMS Module 12,13; The part of an IMS enabled Set Top Box that contains the basic IMS service logic and the ISIM. The IMOD could also be implemented in other devices in the home, e.g. the Residential Gateway (RGW) 14. The IMOD could also be implemented in a mobile phone, enabling remote access to TV services.
IPTV MW AS—IPTV Middleware SIP Application Server 15; The function that interacts between the IMS enabled STB and MS (and other IMS user devices) and the IPTV video servers. The IPTV MW AS also receives and processes HTTP and RTSP messages.
Video Unicast—the video unicast servers 16. These are the sources of unicast (streaming) media and are distributed across the IP network. In particular, video unicast servers are located in the primary and transit network and in the central office and secondary site.
VoD—Video-on-demand (control) server 17. This server controls access to and playout from the distributed video unicast servers.
MTRX and the IMOD entities will be present within STBs that are used to access the IPTV service via the IMS. In addition, and as illustrated in the
The procedure can be broken down into the following stages:
The client terminal includes a web browser, and knows the web address (URL) of the VoD system. Using the browser interface, the client acquires from the VoD system an electronic programming guide (EPG) detailing available streamed programs, as well as pricing information for a selected program.
Using the SIP INVITE method, the client terminal invites the VoD system to join a SIP session. [It is assumed that the client terminal has previously registered with the IMS.]
The client terminal reverts to RTSP to reserve resources for the streaming session at the VoD system, and to cause the VoD system to play out the streamed media.
Streamed media and control signals are played out over the established session.
Using RTSP, the session is terminated, and resources released at the VoD system.
The SIP session is terminated and resources released.
As already mentioned, the procedure of
The procedure of
In the procedure of
It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2006/062880 | 6/2/2006 | WO | 00 | 6/22/2009 |