WO2009052650A1

WO2009052650A1 - Method and terminal for forwarding an iptv program to an sip terminal

Info

Publication number: WO2009052650A1
Application number: PCT/CN2007/003044
Authority: WO
Inventors: Xin Wang
Original assignee: Lucent Technologies Inc.
Priority date: 2007-10-26
Filing date: 2007-10-26
Publication date: 2009-04-30
Also published as: CN101836417A

Abstract

The present invention provides a method and a terminal for forwarding an IPTV program to an SIP terminal. According to an aspect of the present invention, there is provided a method for forwarding an IPTV program to an SIP terminal comprising: receiving data for said IPTV program; establishing an SIP call to said SIP terminal; and transferring the data of said IPTV program to said SIP terminal.

Description

METHOD AND TERMINAL FOR FORWARDING AN IPTV PROGRAM TO AN

SIP TERMINAL

TECHNICAL FIELD

The present invention relates to technology of information processing, more particularly to technology for forwarding an IPTV program to an SIP terminal.

TECHNICAL BACKGROUND

An IPTV (Internet Protocol Television) network is a network for transmitting television programs via an IP (Internet Protocol) network, as shown in Fig. 1. It utilizes digital video compression techniques (typically MPEG-2 (Moving Picture Experts Group), MPEG-4, H.263, H.264 or Windows Media Video 9 encoding, Real Media, etc) to generate an array of video channels. These are sent through a Digital Subscriber Line (DSL) or Fiber-to-theΗome (FTTH) connection, which are encapsulated in IP packets.

The two-way communication inherent to such connections allows a user to select each video stream "on demand" and have the stream dynamically switched onto their broadband connection. An array of different content is provided, ranging from live TV channels, to Video on Demand (VoD), Pay-Per-View and the ability to record content in more personalised and flexible ways such as network Personal Video Recorder (nPVR) or Time-shifted TV services. The content is selected by means of an Electronic Program Guide (EPG) that resides on a Set Top Box (STB), which also acts as the decoder for the video streams to permit display on conventional TVs with analogue inputs.

Users request content to be viewed using an IPTV remote control and on-screen menus in the Electronic Program Guide. Each button pressed on the user's remote control is translated into the appropriate video protocol commands by the Set Top Box. These protocols are typically Internet Group Management Protocol (IGMP) for multicast, and Real Time Streaming Protocol (RTSP) for VoD/nPVR. These video protocol command messages are processed by the service provider's network. An IP Multimedia Subsystem (IMS) is a standardized "next generation" networking architecture for providing multimedia services in mobile/wireless and fixed/wire-line communication networks, as shown in Fig. 2. The IMS system uses the Internet protocol (IP) for packet-data communications generally, and Voice over IP (VoIP) for voice communications, based on a 3GPP/3GPP2 standardized implementation of SIP (Session Initiation Protocol). SIP is a signaling protocol used for establishing sessions, such as a two-way telephone call or multi-party phone conference, in an IP network. The IMS system works with any packet switched network, both wire-line based and wireless, such as GPRS, UMTS, CDMA2000, and WiMAX. Legacy circuit-switched phone systems and similar networks (e.g., POTS, GSM) are supported through gateways. The IMS system includes session control, connection control, and an application services framework along with subscriber and services data. It enables the use of new converged voice and data services, while facilitating the interoperability of these converged services between subscribers.

In addition to transferring data for voice communication purpose, e.g., VoIP data packets, IMS systems are increasingly used to provide communication services to IPTV users. For example, user may desire to use the TV set as a video phone terminal, calls from IMS systems could be directly displayed on the TV set. In addition, applications that come from the IMS space — instant messaging, e-mail or buddy-list based systems — can be made available on TV. The IPTV-IMS blended network seamlessly blends communication and entertainment services into a simple and convenient experience that consumer values, it will be the next generation communication and entertainment service pattern.

With current IPTV solution, IPTV user doesn't have the choice to forward the TV program in progress to anybody who maybe interesting in this TV program, as such program in progress, IPTV user can only use another communication means (instance message, phone call, short message, email, etc.) to inform the other party about the information (which channel for live TV channels, program description for VoD programs), so the other party can turn on the TV and watch the same program.

With current IPTV-IMS blended solution, since IMS system has the network convergence functionality, as such program is in progress, IPTV user can initiate a communication session (instance message, phone call, short message, email) with the other party right via the IPTV STB, to inform the other party about the TV program information (which channel for live TV channels, program description for VoD programs), so the other party can turn on the TV and watch the same program.

But still, the IPTV user doesn't have the choice to directly forward the TV program in progress to anybody who maybe also interested in, especially to an SIP terminal.

Further, it is inconvenient to initiate a new communication session to pass the TV program information to the called party, and it takes time for the called party to answer the communication, note down the information, turn on TV and switch to the channel. Most possibly the interesting part of the program is already passed after the called party starts to watch at the program, and no chance to rewind and playback.

SUMMARY OF THE INVENTION

In order to solve the above-mentioned problems in the prior art, the present invention provides a method and a terminal for forwarding an IPTV program to an SIP terminal.

According to an aspect of the present invention, there is provided a method for forwarding an IPTV program to an SIP terminal comprising: receiving data for said IPTV program; establishing an SIP call to said SIP terminal; and transferring the data of said IPTV program to said SIP terminal.

According to another aspect of the present invention, there is provided a terminal for forwarding an IPTV program to an SIP terminal comprising: a receiving unit configured to receive data for said IPTV program; an establishing unit configured to establish an SIP call to said SIP terminal; and a transferring unit configured to transfer the data of said IPTV program to said SIP terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

It is believed that through the following detailed description of the embodiments of the present invention, taken in conjunction with the drawings, the above-mentioned features, advantages, and objectives will be better understood.

Fig. 1 is a schematic diagram showing a IPTV network of the prior art;

Fig. 2 is a schematic diagram showing a IMS system of the prior art;

Fig. 3 is a flowchart showing a method for forwarding an IPTV program to an SIP terminal according to an embodiment of the present invention!

Fig. 4 is a schematic diagram showing IPTV and IMS networks of the prior art;

Fig. 5 is a schematic diagram showing a window which is displayed to the called party according to the embodiment of the present invention;

Fig. 6 is a schematic diagram showing an IPTV program which will be forwarded to the called party according to the embodiment of the present invention;

Fig. 7 is a schematic diagram showing a synchronous TV call according to the embodiment of the present invention;

Fig. 8 is a schematic diagram showing an asynchronous TV call according to the embodiment of the present invention! and

Fig. 9 is a block diagram showing a terminal forwarding an IPTV program to an SIP terminal according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Next, a detailed description of each embodiment of the present invention will be given in conjunction with the accompany drawings.

Method for forwarding an IPTV program to an SIP terminal Fig. 3 is a flowchart showing a method for forwarding an IPTV program to an SIP terminal according to an embodiment of the present invention. As shown in Fig. 3, first at Step 101, data for the IPTV program is received from an IPTV network, wherein the data can be received through a data stream such as MPEG-2, MPEG-4, H.263, H.264, Windows Media Video 9, or any other media stream known by those skilled in the art or developed in the future. Optionally, the data stream may be received by a terminal such as an IPTV terminal or the like and the IPTV terminal can be any one in the IPTV network, such as an Set Top Box (STB) etc.

In the embodiment, the SIP terminal can be any one which can be used to display a media program, such as an IPTV terminal, a Wireline SIP (Session Initiation Protocol) terminal, a Wireless SIP terminal, a GSM (Global System for Mobile) terminal, a UMTS (Universal Mobile Telecommunications System) terminal, a 802.11 terminal, a Bluetooth terminal, a DSL terminal, a FTTP (Fiber To The Premises) terminal, etc.

Next, at Step 102, an SIP call to the SIP terminal is established. Session Initiation Protocol (SIP) is a signaling protocol used for establishing sessions, such as a two-way telephone call or multi-party phone conference in an IP network, and the invention has no limitation to this.

In Step 102, a register request is sent to an IMS switch to register the IPTV terminal as a SIP terminal in the IMS network. After registered, the IPTV terminal is also an SIP terminal which can be communicated with other SIP terminals by SIP protocol. Further, in Step 102, an invite message is sent to the IMS switch, IMS switch will route the call request to the called SIP terminal, and the called SIP terminal will negotiate the media parameters with calling IPTV terminal using SIP message flow through IMS switch. The specific details of the SIP call and the invite message will be described in the following with reference to Example 1.

Last, at Step 103, the data of the IPTV program is transferred from the IPTV terminal to the SIP terminal related to the SIP call.

Optionally, the data stream of the IPTV program may be stored before it is transferred to the SIP terminal. For example, the data stream can be stored in the hard disk or memory of the IPTV terminal such as STB.

The specific details of the method according to the embodiment of the invention will be described in the following with respect to Example 1.

Example 1

In Example 1, generally, the method of the embodiment enables the IPTV user to make a TV call to other party (whose communication terminal has the video display capability) in the IMS network, by transferring the TV program to the called party in a media stream form. The calling party of the TV call could decide how to play the interested TV program, in asynchronous play or synchronous play styles. Asynchronous play needs the calling party STB store the TV program locally and start the data transferring from the start of the stored media file when the call is answered by the called party. Synchronous play will not store the media, the IPTV STB will transfer the TV program media stream to the called party synchronously, the calling and called user will enjoy the same TV program at the same time. After the called party previews or answers the call, there will be a notice displayed at the TV screen with the called party information to notify calling party a TV call is still in progress. The calling party could decide to release the call at anytime he/she wants, and the called party could decide to release the call once find the content of the TV call is not interesting anymore.

In Example 1, the method of the embodiment reuses the existing IPTV functionalities and IMS call processing procedures, as show in Fig. 4, wherein the IPTV and IMS networks of the prior art are shown. It enhances the IPTV STB at each end to be able to communicate with the IMS, it also enables the IPTV STB at each end to setup Internet connection for media stream transferring after the TV call is answered, disconnect the TV call at any point of the call procedure. Most important, it enhances the IPTV STB to be a sender instead of a receive-only terminal of video media stream.

In Example 1, the main enhancements to IPTV STB include:

1) IPTV STB will communicate with IMS using SIP messages.

2) IPTV STB will be registered to IMS network.

3) IPTV STB could initiate a TV call request towards IMS using INVITE message with "user=IPTV in the SIP URI (Uniform Resource Identifier), and "a=sendonly" in the SDP (Session Description Protocol) body.

4) IPTV STB could negotiate the call parameters with called party for the TV call.

5) IPTV STB could start/stop storing media stream received to a local file on its hard disk or memory per user's will via the remote control.

6) IPTV STB could fork the media stream towards called party. 7) IPTV STB could encode the media file saved to media stream towards called party.

8) IPTV STB could release the TV call at any point of the call. The main enhancements to IMS include :

1) Receive SIP REGISTER message from IPTV STB.

2) IMS will handle this call as a normal video call to the called party.

3) IMS could know it is a TV call, and charge the calling IPTV subscriber differently according to the user=IPTV parameter.

The above-mentioned synchronous play and asynchronous play will be described in details in the following with reference to Figs. 7 and 8 respectively.

Synchronous TV call

Fig. 7 is a schematic diagram showing a synchronous TV call according to the embodiment of the present invention.

First, when the IPTV user turns on the IPTV STB, IPTV STB will send a Register message to IMS to register to IMS network.

Then, the IPTV user initiates a TV call. When IPTV user (referred to A hereinafter) watches the TV program (e.g., movie Madagascar as shown in Fig. 6) and notices the TV program is interested to somebody (referred to B hereinafter), A will choose to make a TV call towards B by press the "menu" button on the IPTV STB remote control, and scroll to Place a Call item.

With A dials B's phone number and scrolls to the "make a TV call" box on the screen, and pushes the OK button on the remote control, an INVITE message will be sent out from IPTV STB to IMS, with "user=IPTV in the SIP URI, and "a^sendonly" lines for media descriptions in SDP body, and a new MIME body in it.

INVITE sip:8705057@10.86.7.17;usei=IPTV SIP/2.0

Via: SIP/2.0/UDP 10.86.0.105:5060;branch=z9hG4bK386f8b890000026c00201c0b08d3

From: <sip:8705287@iptv.net;user=IPTV>;tag=981c08bb

To: <sip:8705057@ims.net;usei=phone>

Call-ID: 00972b2ee410184c97e300201cl0088c@10.86.0.105

CSeq: 116 INVITE

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, DSfFO, REGISTER, UPDATE, PRACK

Supported: lOOrel, timer Expires: 3600

Max-Forwards: 70

P-Asserted-Identity: "Matrix Wang" <sip:8705287@iptv.net;user=ffTV>

Contact: <sip: 8705287® 10.86.0.105 :5060;user=phone>

Content-Type: multipart/mixed;boundary="lucent-boundary-delim"

MIME-Version: 1.0

Content-Length: 517

—lucent-boundary-delim Content-Type: application/sdp Content-Transfer-Encoding: 7bit Content-Length: 250

v=0 o=- 149513149513 IN IP4135.252.30.108

S=-

C=IN IP4135.252.30.108 t=00 m=audio 40000 RTP/AVP 8 c=IN IP4 135.252.30.108 a=sendonly a=rtpmap:8 PCMA/8000 m=video 40002 RTP/AVP 34

C=DSf IP4 135.252.30.108 a=sendonly a=rtpmap:34 H263/90000

--lucent-boundary-delim Content-Type: application/string; Content-Disposition: display; handling=required Content-Transfer-Encoding: 8bit Content-Length: 14

Movie: Madagascar

--lucent-boundary-delim

With the "user=IPTV" in the SIP URI, and the "string" "content-type" in the MIME body, IMS will know this is a TV call, and the calling party wants to play a TV program to the called party.

With the "a=sendonly" lines for media descriptions in the SDP body, IMS and the called party endpoint will know this TV call only has a single direction media stream, which is from the calling party IPTV STB to the called party endpoint.

Then, when the called party endpoint receives the INVITE message, it will select an audio codec and a video codec listed in the SDP body, respond a 180 Alerting message back, with "a=recvonly" lines for media descriptions in SDP body, and start to ring the called user, with the strings in the "content-type" in the MIME body. v=0 o=- 77050 77050 IN IP4 135.252.30.10

S=- c=IN IP4 135.252.30.10 t=00 m=audio 40000 RTP/AVP 8 c=IN IP4 135.252.30.10 a=recvonly a=rtpmap:8 PCMA/8000 m=video 40002 RTP/AVP 34 c=IN IP4 135.252.30.10 a=recvonly a=rtpmap:34 H263/90000

Based on different endpoint types, different views will be displayed to the called party user B. Commonly the calling party information and the call content information will be displayed to the called party user B, while if the called party endpoint is another IPTV STB, there will be an extra option "Preview Call" for called party user B to preview the TV program in a small window on the TV screen, as shown in Fig. 5.

After noticing the call information, if the called party user B feels the TV program is not interesting, he/she could choose reject call to drop the TV Call, a BYE message will be sent back to the calling party IPTV STB via IMS, IPTV STB will close the socket to transmit the media stream and display a "Called Party Rejected" message on the TV screen for 1 second and switch the display back to the TV program in progress with full screen display.

On the other hand, after noticing the call information, if the called party user B feels the TV program is interesting, he/she could choose preview (IPTV user) or answer the TV Call, a 200OK message will be sent back to the calling party IPTV STB via IMS, IMS will generate the call answer time for this TV call. IPTV STB will start to transmit the media stream to the called party endpoint socket (The socket information is carried back in the 180 Alerting message SDP), the display on calling party user TV screen will switch back to full screen display for the TV program in progress, and with a small window on a screen corner notifying user there is a TV call in progress.

Further, on the called party user endpoint, if called party user chooses preview (IPTV user), a preview window will display to called party user with no audio playing, and an option to switch to full screen play the TV program. If called party user chooses answer the TV call, the TV program media stream will be displayed on the called party endpoint with full screen display.

Further, users may release the TV Call. Several actions will cause the TV Call been released:

The calling party user changes the TV program in progress (for synchronous mode)

The calling party user chooses to release the TV call The called party user chooses to release the TV call

An SIP BYE message will be sent to remote party via IMS to tear down the media and signaling path.

Asynchronous TV Call

Asynchronous TV Call is almost same as synchronous TV call, and they have same SIP message flow between endpoints and IMS. The only difference is in asynchronous mode, the calling party user could choose to play the TV program to called party asynchronously. Synchronous TV Call media stream is forked from the real time media stream from IPTV server to calling IPTV STB, no need to store the media file in the STB.

However, in asynchronous TV Call mode, once the calling IPTV user notices the TV program in progress is interesting to the called party, he/she could choose to store the TV program, and then start to make the TV call towards called party. By pushing the "menu" button on the IPTV remote control, and choose the store option, the TV program media stream starts to be stored at the calling party IPTV STB, then the calling IPTV user could choose to make a TV Call to the called party follow the procedures described above. The TV program media stream will be stored until the calling party user chooses to stop recording, or the current TV program finishes, or the IPTV STB storage is used up.

The TV call will start to play the TV program from the beginning of the stored file, until calling party or called party choose to release the TV call, or the stored file is over.

Though the specific details of the method of the embodiment is described above with reference to Example 1, wherein, the TV Call is illustrated as a SIP call, and the TV call is forwarded to the called party connected by the IMS system, it should be understood that the SIP call established in the embodiment may be any call used for forwarding an IPTV program to an SIP terminal, and the IPTV program may be transferred to any SIP terminal as described above.

Through the method for forwarding an IPTV program to an SIP terminal according to the embodiment of the invention, the following advantages comparing to the prior arts of VoIP solutions are obtained:

IPTV network and communication network can be seamlessly blended. The TV program can be shared real time with friends, families, etc. The traffic from IPTV server to user endpoints can be reduced. IPTV users do not need to inform the called party via another communication session about the TV program.

The calling party could store the TV program and then playback the program to the called party, and therefore there is no need to play it synchronously. Terminal for forwarding an IPTV program to an SIP terminal

Under the same inventive conception, Fig. 9 is a flowchart showing a terminal for forwarding an IPTV program to an SIP terminal according to another embodiment of the present invention. Next, the present embodiment will be described in conjunction with Fig. 9. For those same parts as the above embodiments, the description of which will be appropriately omitted.

As shown in Fig. 9, the terminal 200 of the embodiment comprises a receiving unit 201 configured to receive data for the IPTV program; an establishing unit 202 configured to establish an SIP call to the SIP terminal; and a transferring unit 203 configured to transfer the data of the IPTV program to the SIP terminal.

In the embodiment, for example, the terminal 200 may be an IPTV terminal or the like, wherein the data can be received through a data stream such as MPEG-2, MPEG-4, H.263, H.264, Windows Media Video 9 or any other media stream known by those skilled in the art or developed in the future, and the IPTV terminal can be any one in the IPTV network, such as a Set Top Box (STB) etc.

In the embodiment, the SIP terminal can be any one which can display a media program, such as an IPTV terminal, a Wireline SIP (Session Initiation Protocol) terminal, a Wireless SIP terminal, a GSM (Global System for Mobile) terminal, a UMTS (Universal Mobile Telecommunications System) terminal, a 802.11 terminal, a Bluetooth terminal, a DSL terminal, a FTTP terminal, etc.

Further, the terminal 200 may comprise a sending unit, by which a register request can be sent to an IMS switch to register the IPTV terminal as a SIP terminal in the IMS network. After registered, the IPTV terminal is also an SIP terminal which can be communicated with other SIP terminals by SIP protocol. Further, an invite message can be sent by the sending unit to the IMS switch, IMS switch will route the call request to the called SIP terminal, and the called SIP terminal will negotiate the media parameters with calling IPTV terminal using SIP message flow through IMS switch. The specific details of the SIP call and the invite message is described above with reference to Example 1, and omitted here for clarity.

Optionally, the terminal 200 may further comprise a storing unit, which is configured to store the data stream of the IPTV program before it is transferred to the SIP terminal. For example, the data stream can be stored in the hard disk or memory of the terminal such as STB.

Further, the terminal 200 may allow said SIP terminal to reject, preview or accept said IPTV program and further allow to be notified that said SIP call is in progress after the IPTV program is previewed or accepted by said SIP terminal.

In the embodiment, the terminal 200 and said SIP terminal are allowed to release said SIP call at any time when said SIP call is in progress. Optionally, said terminal and said SIP terminal is connected by an IMS system. The specific details of the terminal 200 are same with that of the method described with reference to Example 1, and omitted here for clarity.

Through the terminal for forwarding an IPTV program to an SIP terminal according to the embodiment of the invention, the following advantages comparing to the prior arts of VoIP solutions are obtained^:

IPTV network and communication network can be seamlessly blended.

The TV program can be shared real time with friends, families, etc.

The traffic from IPTV server to user endpoints can be reduced.

IPTV users do not need to inform the called party via another communication session about the TV program.

The calling party could store the TV program and then playback the program to the called party, and therefore there is no need to play it synchronously.

Though a method and an a terminal for forwarding an IPTV program to an SIP terminal have been described in details with some exemplary embodiments, these above embodiments are not exhaustive. Those skilled in the art can make various variations and modifications within the spirit and the scope of the present invention. Therefore, the present invention is not limited to these embodiments; rather, the scope of the present invention is only defined by the appended claims.

Claims

1. A method for forwarding an IPTV program to an SIP terminal comprising: receiving data for said IPTV program; establishing an SIP call to said SIP terminal; and transferring the data of said IPTV program to said SIP terminal.

2. The method according to claim 1, wherein said data is received through a data stream.

3. The method according to claim 2, wherein said data stream comprises MPEG-2, MPEG-4, H.263, H.264, Windows Media Video or Real Media.

4. The method according to any one of claims 1-3, wherein said data is received by an IPTV terminal.

5. The method according to claim 4, wherein said establishing an SIP call to said SIP terminal comprises: sending a register request to register said IPTV terminal to an IMS switch.

6. The method according to claim 5, wherein said establishing an SIP call to said SIP terminal further comprises: sending an invite message to said SIP terminal via the IMS switch.

7. The method according to claim 6, wherein said invite message comprises "user=IPTV in an SIP URI.

8. The method according to any one of claims 1-7, wherein said method further comprises: storing said data before transferring the data of said IPTV program to said SIP terminal.

9. The method according to claim 4, wherein said IPTV terminal comprises a Set Top Box (STB).

10. The method according to claim 4, further comprising: allowing said SIP terminal to reject, preview or accept said IPTV program.

11. The method according to claim 10, further comprising: notifying said IPTV terminal that said SIP call is in progress after the IPTV program is previewed or accepted by said SIP terminal.

12. The method according to claim 10 or 11, further comprising: allowing said IPTV terminal and said SIP terminal to release said SIP call when said SIP call is in progress.

13. The method according to claim 4, wherein said IPTV terminal and said SIP terminal is connected by an IMS system.

14. A terminal for forwarding an IPTV program to an SIP terminal comprising: a receiving unit configured to receive data for said IPTV program; an establishing unit configured to establish an SIP call to said SIP terminal; and a transferring unit configured to transfer the data of said IPTV program to said SIP terminal.

15. The terminal according to claim 14, wherein said data is received through a data stream.

16. The terminal according to claim 15, wherein said data stream comprises MPEG-2, MPEG-4, H263, H.264, Windows Media Video or Real Media.

17. The terminal according to any one of claims 14-16, wherein said terminal comprises an IPTV terminal.

18. The terminal according to claim 14, wherein said establishing unit comprises: a sending unit configured to send a register request to register said terminalto an IMS switch.

19. The terminal according to claim 18, wherein said sending unit is further configured to send an invite message to said SIP terminal via the IMS switch.

20. The terminal according to claim 19, wherein said invite message comprises "user=IPTV" in an SIP URI.

21. The terminal according to any one of claims 14-20, further comprising: a storing unit configured to store said data before the data of said IPTV program is transferred to said SIP terminal by said transferring unit.

22. The terminal according to claim 17, wherein said IPTV terminal comprises a Set Top Box (STB).

23. The terminal according to claim any one of claims 14-22, wherein said terminal allows said SIP terminal to reject, preview or accept said IPTV program.

24. The terminal according to claim 23, wherein said terminal further allows to be notified that said SIP call is in progress after the IPTV program is previewed or accepted by said SIP terminal.

25. The terminal according to claim 24, wherein said terminal and said SIP terminal are allowed to release said SIP call when said SIP call is in progress.

26. The terminal according to any one of claims 14-25, wherein said terminal and said SIP terminal is connected by an IMS system.