Abstract:
A method of synchronising streaming media between a plurality of UEs connected to a communications network, wherein the UEs are involved in a SIP-enabled voice session over said communications network. A timestamp is provided to each of the UEs. Each of the UEs then sends a request for streamed media to an IPTV service, receives streamed media from the IPTV service, and commences playout of the streamed media in dependence upon the timestamp.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to the fields of video on demand services and communications. More particularly, the invention relates to synchronising IPTV streams for participants in a voice session. 
       BACKGROUND 
       [0002]    Social TV has been increasing in popularity over the last few years. Social TV is the combination of television and social media, with people communicating with each other over communications networks while watching a TV show or video on demand (VoD) stream. Social TV allows users to have the experience of chatting to a friend while watching TV without the need to be in the same physical location. 
         [0003]    Many new “smart TVs” now include communications (e.g. VOIP) clients in their TV sets, and other devices such as video game consoles and media centres support communications services in parallel with video streaming. Currently, there is little integration between the communications services and the video stream—the two applications run separately, sharing space on the screen, but with no interaction between the services. For example, a user of the Xbox One™ video games console can watch a video stream while engaging in a video call with another user via Skype™ but there is no mechanism for ensuring that the video stream is synchronised for both users. This leads to undesirable situations such as hearing a friend&#39;s reaction to a goal in a football game before seeing the goal being scored. It also requires careful timing if you wish to watch content delivered by unicast streams with a friend, especially since differing download rates may cause your device to take longer to buffer the content than your friend&#39;s device. These problems are made worse when attempting to coordinate more than two people for a social TV experience. 
         [0004]    Previous attempts have been made to coordinate voice services and VoD services, for example “Network implemented PVR and chase-play combined with IMS services”—WO2007/101473, but these have been focussed on use cases where only a single user is watching the VoD stream, or focussed on closer integration of IPTV services within the network used for voice calling (e.g. IMS integration of IPTV services). 
       SUMMARY 
       [0005]    According to a first aspect of the invention, there is provided a method of synchronising streaming media between a plurality of UEs connected to a communications network, wherein the UEs are involved in a SIP-enabled voice session over said communications network. A timestamp is provided to each of the UEs. Each of the UEs then sends a request for streamed media to an IPTV service, receives streamed media from the IPTV service, and commences playout of the streamed media in dependence upon the timestamp. 
         [0006]    According to a second aspect of the invention, there is provided a method in a first UE of synchronising streaming media between the first UE and one or more further UEs connected to a communications network, wherein the first UE and the one or more UEs are involved in a SIP-enabled voice session over said communications network. The first UE receives a SIP message associated with the voice session and containing a play media command, the play media command comprising a timestamp. The first UE sends a request for streamed media to an IPTV service, and receives streamed media from the IPTV service either before or after receiving the play media command. Following receipt of the play media command, the first UE commences playout of the streamed media in dependence upon the timestamp of the play media command. 
         [0007]    According to a third aspect of the invention, there is provided a method in an application server of synchronising streaming media between a first UE and one or more further UEs connected to a communications network. The application server is also connected to the communications network and the application server handles a SIP-enabled voice session over the communications network. The application server receives a SIP message associated with the voice session and containing a synchronisation request from the first UE via a control channel of the voice session. The application server then sends a SIP message associated with the voice session and containing a play media command to each of the one or more further UEs via the control channel of the voice session, the play media command comprising a timestamp. 
         [0008]    According to a fourth aspect of the invention, there is provided a method in a first UE of synchronising streaming media between the first UE and one or more further UEs connected to a communications network, wherein the first UE and the one or more further UEs are involved in a SIP-enabled voice session over said communications network. The first UE sends a SIP message associated with the voice session and containing a play media command to an application server or each of the one or more further UEs via a control channel of the voice session, the play media command comprising a timestamp. The first UE sends a request for streamed media to an IPTV service and receives streamed media from the IPTV service either before or after sending the play media command. The first UE commences playout of the streamed media in dependence upon the timestamp of the play media command. 
         [0009]    According to a fifth aspect of the present invention, there is provided an apparatus configured to operate as a UE in a SIP-enabled communications network. The apparatus comprises a first transceiver, a second transceiver and a processor. The first transceiver is configured to send and receive signalling from other entities in the communications network. The second transceiver is configured to send and receive signalling from an IPTV service. The processor is configured to:
       receive, via the first transceiver, a SIP message associated with a voice session involving the UE and one or more further UEs, the SIP message containing a play media command comprising a timestamp;   cause the second transceiver to send a request for streamed media to the IPTV service;   receive, via the second transceiver, streamed media from the IPTV service; and   commence playout of the streamed media in dependence upon the timestamp of the play media command.       
 
         [0014]    According to a sixth aspect of the present invention, there is provided an apparatus configured to operate as an application server in a communications network. The apparatus comprises a transceiver configured to send and receive signalling from other entities in the communications network. The transceiver is further configured to receive a SIP message associated with a voice session involving a first UE and one or more further UEs, the SIP message containing a synchronisation request from the first UE; and send a SIP message associated with the voice session and containing a play media command to each of the one or more further UEs, the play media command comprising a timestamp. 
         [0015]    According to a seventh aspect of the invention, there is provided an apparatus configured to operate as a UE in a communications network. The apparatus comprises a first transceiver, a second transceiver and a processor. The first transceiver is configured to send and receive signalling from other entities in the communications network. The second transceiver is configured to send and receive signalling from an IPTV service. The processor is configured to:
       send, via the first transceiver a SIP message associated with a voice session involving the UE and one or more further UEs, the SIP message containing a play media command to an application server or to each of the one or more further UEs, the play media command comprising a timestamp;   send a request for streamed media to an IPTV service via the second transceiver;   receive streamed media from the IPTV service via the second transceiver;   commence playout of the streamed media in dependence upon the timestamp of the play media command.       
 
         [0020]    According to an eighth aspect of the invention, there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method of any of the above aspects. The computer program may be contained in a carrier such as an electronic signal, optical signal, radio signal, or a non-transitory computer readable storage medium. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0021]      FIG. 1  is a schematic diagram of a communications network and IPTV service; 
           [0022]      FIG. 2  is a flowchart of a method according to on embodiment; 
           [0023]      FIG. 3  is a flowchart of a method according to a further embodiment; 
           [0024]      FIG. 4  is a flowchart of a method according to a further embodiment; 
           [0025]      FIG. 5  shows the signalling according to a further embodiment; 
           [0026]      FIG. 6  shows the signalling according to a further embodiment; 
           [0027]      FIG. 7  shows the signalling according to a further embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0028]    A method will now be described for providing a synchronised social TV experience to users engaged in a voice or video call. The description below relies on the setup shown in  FIG. 1 . Each user has a UE  100 / 200 / 300 , which contains a first transceiver  101 / 201 / 301  for communicating with a communications network  600 , a second transceiver  102 / 202 / 302  for communicating with an IPTV service  500 , and a processor  103 / 203 / 303  configured to implement the methods described below. In some of the below embodiments, there is also an application server (AS)  400  which handles social TV synchronisation connected to the network  600 . The AS  400  comprises a transceiver  401  for communicating with the UEs. For simplicity, only three UEs are shown, but the method described below may be extended to more or fewer UEs. 
         [0029]    As a prerequisite for the methods described below, it is assumed that the UEs are already engaged in a voice or video session over the network  600 , and that there is an available control channel for that session. The voice or video session may be, for example, a VOIP session, an MMTel conference call, or a videoconferencing session. It is also assumed that the users have agreed on what to watch, and that they all have access to the content on the IPTV server. In the case of a conference call, the AS  400  may also be the AS which handles the conference call (e.g. an MMTel conference AS). 
         [0030]    The basic premise of the invention is to provide each of the UEs with a timestamp for use in synchronising the playout of the media stream. For example, the timestamp may represent a time at which a specified portion of the media stream should be played (e.g. the time at which the start of the media stream should be played). If the UE commences playout of the media stream after the timestamp, then playout is initiated at a point such that the content being played is the same as if the specified portion of the media stream had been played at the timestamp. For example, if the UE initiates playout 10 seconds after the timestamp, the UE will seek to a point in the media stream 10 seconds after the specified portion. In this way, playout of the media stream is synchronised between all of the UEs. 
         [0031]      FIG. 2  shows a flowchart of a method according to one embodiment, where the AS  400  is not involved. The UE  100  sends a play media command to the UEs  200  and  300  (S 101 ). The play media command comprises a timestamp, and may further comprise an identification of the media to be streamed and/or an offset corresponding to a specified portion of the media. The UE  200  receives the play media command (S 107 ). Each of the UEs  100 ,  200  and  300  then sends a request for streamed media to the IPTV service, and receives the streamed media from the IPTV service (S 105 , S 108 ). Each UE then commences playout of the streamed media in dependence upon the timestamp (S 106 , S 109 ), e.g. as described previously. 
         [0032]    As an alternative, the synchronisation may be handled by an AS  400 . In this case, either the AS  400  or the UE  100  may generate the timestamp used for synchronisation. The case where the AS  400  generates the timestamp is shown in  FIG. 3 . The UE  100  sends a synchronisation request to the AS  400  (S 111 , S 112 ). The AS then sends a play media command comprising a timestamp to all UEs in the voice session (e.g. UEs  100   200  and  300 ) over a control channel of the voice session (S 113 ). Each UE receives the play media command (S 114 , S 117 ), sends a request for streamed media to the IPTV service and receives the streamed media (S 105 , S 108 ). Each UE then commences playout of the streamed media in dependence upon the timestamp (S 106 , S 109 ) e.g. as described previously. 
         [0033]    The case where the UE  100  generates the timestamp is shown in  FIG. 4 . The UE  100  sends a synchronisation request comprising a timestamp to the AS  400  (S 121 , S 122 ). The AS then sends a play media command comprising the timestamp to all the other UEs in the voice session (e.g. UEs  200  and  300 ) over a control channel of the voice session (S 123 ). Each other UE receives the play media command (S 117 ), and the UE  100  and each other UE send a request for streamed media to the IPTV service and receive the streamed media (S 105 , S 108 ). Each UE then commences playout of the streamed media in dependence upon the timestamp (S 106 , S 109 ) e.g. as described previously. 
         [0034]    In each case, the signalling from UE to UE or UE to AS is performed via control signalling of the voice session, e.g. by SIP messages associated with the voice session. 
         [0035]    A signalling diagram of the embodiments including the AS  400  is shown in  FIG. 5 . The play media commands may be sent approximately simultaneously by the AS  400 , to ensure that all the UEs begin playout as close to the same time as possible (as well as the content being synchronised). 
         [0036]      FIG. 6  shows a signalling diagram for a possible improvement. After receiving the synchronisation request, the AS  400  sends a buffer media command to each UE. Alternatively, in embodiments which do not involve the AS  400 , the buffer media command may be sent by the UE  100  prior to sending the play media command. Each of the UEs then buffers the streamed media from the IPTV service, and once enough of the media has been buffered, sends a buffering complete notification to the AS  400  (or the UE  100 ), which then sends a play media command comprising a timestamp, as before. This avoids the potential situation where a user with a slow internet connection may miss a portion of the start of the media stream as their UE is unable to buffer enough media to begin playout when the timestamp occurs. 
         [0037]      FIG. 7  shown a signalling diagram for a method of adding a participant to an ongoing social TV session. UEs  100 ,  200  and  300  are involved in an ongoing conference voice call and TV sharing session, with the current position in the media stream being synchronised by the AS  400  (or the UE  100  in embodiments not involving the AS). The UE  700  is added to the conference. The AS  400  (or UE  100 ) sends a play media command to the UE  700 , the play media command comprising a timestamp and an offset. The timestamp and offset are chosen such that the synchronised media stream would reach or has reached the offset at the time indicated by the timestamp, e.g. a timestamp of 18:44:42.12 and offset of 160.62s would indicate that each of the UEs  100 ,  200  and  300  was (or would be expected to be) 160.62s from the start of the media stream at 18:44:42.12. The UE  400  plays the streamed media from the IPTV service after seeking to an offset such that the media stream will reach or would have reached the offset at the time indicated by the timestamp. 
         [0038]      FIG. 8  illustrates how a timestamp and an offset may be used to synchronise the media streams. The play media command  1000  is received by each of the UEs  100 ,  200  and  300 , and comprises a timestamp and an offset  1001 . Alternatively, the play media command may only comprise the timestamp, and the offset may be predefined (e.g. always the start of the media). Each UE begins to buffer the media stream content (slanted lines). The UE  100  finishes buffering at such a time that in order to play the media so that the offset specified in the play media command occurs at the time represented by the timestamp, the UE  100  would need to start playout before the start of the media. Therefore, the UE  100  pauses the media stream until a time where it is possible to play the media such that the offset specified in the play media command occurs at the time represented by the timestamp  1100 . In this case, the UE  100  subtracts the specified offset from the timestamp to obtain a start time, and begins playout at an offset of zero at the start time. 
         [0039]    The UE  200  finishes buffering the media stream before the time represented by the timestamp of the play media command, but at a time where it is possible to start playout of the media such that the offset specified in the play media command occurs at the time represented by the timestamp. The UE  200  compares the current time to the timestamp, and determines the difference. The UE  200  then begins playout at an offset equal to the offset specified in the play media command minus the difference between the current time and the timestamp. 
         [0040]    The UE  200  finishes buffering the media stream after the time represented by the timestamp of the play media command. The UE  300  compares the current time to the timestamp, and determines the difference. The UE  300  then begins playout at an offset equal to the offset specified in the play media command plus the difference between the current time and the timestamp. 
         [0041]    In this way, all three UEs are playing the media stream in a synchronised fashion. Alternative methods may be used to synchronise the media streams from the timestamp, e.g. the timestamp may correspond to the start of the media stream (and therefore only the cases of UE  100  and UE  300  above are possible). 
         [0042]    If the users wish to seek (e.g. “fast forward” or “rewind”) to other locations in the media stream during playout, or pause the playout, the synchronisation process will need to be repeated to ensure that the streams are still synchronised after the seek is complete or once playout resumes. The UE performing the seek operation would record a timestamp and offset corresponding to the state of the media stream after the sync (or the expected state), and send a synchronisation command as previously depicted 
         [0043]    In the case where the network  600  is an IMS network, the AS  400  may be an IMS application server. The “play media command” and “synchronisation request” may be implemented as SIP requests, e.g. SIP MESSAGE. The buffer media command may also be implemented as a SIP request, with the buffering complete notification being implemented as either a further SIP request, or a SIP response (e.g.  200  OK or another suitable response code). The communication with the IPTV service may be implemented over the IMS or, alternatively, it may be via a different network route. Where the voice or video call is a conference call, the AS  400  may be an MMTel conference call AS. Alternatively, the messages described above may be implemented as media messages within a conference service (e.g. sent over Realtime Transfer Protocol, RTP, or Message Session Relay Protocol, MSRP). In this case, the AS may implement a Media Resource Function (MRF) including media proxy functionality. The MRF is configured to distribute requests to the UEs based on incoming requests from one of the UEs. 
         [0044]    Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.