Internet Protocol (IP) Multimedia Subsystem (IMS) based IP Television (IPTV) is a new service that is currently being introduced within a service layer of an IMS network. An IMS specification ‘3GPP TS 23.228 v7.4.0 (2006-06) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7)”’ provides service descriptions for the IMS core network. The IMS core network in turn includes elements necessary to support IP multimedia services. Another IMS specification ‘3GPP TS 33.203 v7.2.0 (2006-06) “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Access security for IP-based services (Release 7)” provides authentication mechanisms that are useful in ensuring validity of requests received from terminals for obtaining multimedia services such as IPTV.
FIG. 1 illustrates a high-level view of a typical IMS network architecture for supporting IPTV and other multimedia applications. A service network 100 is shown comprising a first terminal 110 and a second terminal 120, both capable of being used by end-users to enjoy IPTV and other multimedia contents. Contents are provided to the terminals 110, 120 by a content server 130. The content server 130 acts as an aggregator of information and may comprise video, audio, games, photos, text, etc. These different types of media are generally stored on a hard drive at the content server 130. In the service network 100, contents are sent by the content server 130 by use of Real-Time Streaming Protocol (RTSP) media flows 140. RTSP is used in this exemplary architecture for media manipulation and control, while SIP is used for session setup. RTSP is defined by the Internet Engineering Task Force (IETF) in ‘Request For Comments (RFC) 2326 “Real Time Streaming Protocol (RTSP)”, April 1998’. Multimedia sessions are set up between the terminals 110, 120 and the content server 130 by use of an application server 150. The application server (AS) 150 runs software functions to control setting up of sessions between the terminals 110, 120 and the content server 130. For example, the AS 150 maps SIP to the appropriate RTSP message for RTSP session set up. Additionally, among other things, the AS 150 may handle authentication of users, billing of sessions, selection of one amongst several content servers 130 based on performance parameters, and the like. Set up of sessions is made by use of SIP messages exchanged on signaling links 160. The IETF defines SIP messages in ‘RFC 3261 “SIP: Session Initiation Protocol”, June 2002’.
One anticipated usage for the system shown in FIG. 1 involves transferring a multimedia session from one terminal to the other. Suppose, for example, that a user is watching a video-on-demand (VOD) program on terminal 110 in his or her living room, and wants to relocate to the kitchen to prepare a meal and continue watching the same VOD program on terminal 120. In that case, it would be desirable to have a mechanism for pausing the VOD program on the server side and providing a multimedia session on terminal 120 which enables the user to restart that VOD program at the point in time at which it was paused.
One solution for addressing this situation is described in U.S. Patent Publication No. 2008/0084867, the disclosure of which is incorporated herein by reference. Therein, in FIG. 2 (replicated herein) a sequence diagram illustrating a method for transferring a session from a first terminal 110 to a second terminal 120 is illustrated. In this exemplary sequence diagram, a session has been set up by a service network 100 between the first terminal 110 and a Content Serving Function (CSF) 132 located in the content server 130. At the time of setting up the session, a session identity has been stored in the first terminal 110.
As mentioned above, assume that a VOD program (or some other content) is being transmitted from the CSF 132 to the first terminal 110 at step 200, and that the end user wants to transfer that session to second terminal 120. At step 202, responsive to a user input, the first terminal 110 sends a pause message towards the CSF 132. The pause message may preferably comprise the session identity. The CSF 132 pauses transmission of the media stream at step 204, using the session identity to specifically pause one session where more than one session is currently active for the same user. The first terminal then sends, at step 206, a correlation message comprising the session identity for the session currently being paused, towards the ASF 152. At step 208, the ASF 152 stores the session identity, if not already known to the ASF 152, and takes note that the session is currently being paused by storing a session status set to inactive. Where more than one session is currently active for the same user, the session identity received in the correlation message is used by the ASF 152 to specifically point to the session that is being paused.
Thereafter, responsive to an input from the user, the second terminal 120 sends a context request message towards the ASF 152 at step 210. The ASF 152 replies at step 212 by sending a context response message comprising one or more session identities towards the second terminal 120. At step 210, the ASF 152 may have session identities corresponding to one or more sessions for the user of the first and second terminals 120, each session having been paused in a manner similar to that shown at steps 202-208. In that case, the context response message sent at step 212 may comprise session identities for all sessions related to the user. At step 214, the user may optionally select to resume the paused session from the second terminal 120. This step may comprise selection by the user of one or more sessions to be resumed, based on session information received in the context response message. At step 216, the second terminal sends a resume message towards the CSF 132. The resume message comprises RTSP session identities for one or more sessions selected by the user or automatically selected by the second terminal 120. At step 218, the CSF 132 resumes sending the content towards the second terminal 120.
In addition to the solution described in this U.S. Patent Publication, it would further be desirable to be able to transfer multimedia sessions between, or resume a multimedia session at, terminals which are connected to IMS gateways or which have their own IMS software stacks.
USPTO Backgrounds
USPTO Backgrounds