The present invention generally related to IPTV and IMS, and in particular to providing such IPTV and IMS functionality and capability to a set top box.
Internet Protocol (IP) multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. Having different available applications and media types makes it possible to increase the number of services offered to the end users, and thus to enrich the inter-personal communication experience. This enables personalized, rich multimedia communication services.
IP Television (IPTV) is an emerging system where digital television and multimedia services are delivered to set top boxes present in a home environment using IP over a network infrastructure. Today, IPTV is most often associated with Video on Demand (VoD) and live TV services. However, IPTV can also provide Internet services, such as web access and Voice over IP (VoIP). Another feature of IPTV is the opportunity for integration and convergence with other multimedia services. This opportunity is affected mainly by the IP Multimedia Subsystem (IMS), providing an architectural framework for delivering IP multimedia serves in the IPTV environment. Such IMS-based services that can be used with the set top boxes include chats, presence services, contact list services and different messaging services, such as instant messaging, allowing IPTV users to communicate with each other.
IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardized IMS service enablers, which facilitate new rich person-to-person, i.e. client-to-client, communication services as well as person-to-content, i.e. client-to-server, services over IP-based networks.
Generally an IP-based network providing IPTV services to end users can be in the form of a managed network or so-called open Internet or unmanaged network. The latter provides IPTV services through the Internet, without quality of service guarantees. Examples of the former are radio-based communication networks managed by a network operator and which can provide IPTV services at guaranteed quality of service levels.
User terminals, so-called set top boxes (STBs), present in the home environment for affecting the IPTV services are generally of different types depending on whether used in a managed network or the open internet. For instance, a set top box for use in a managed network may be manufactured to comprise embedded or native functionality, i.e. computer program code, for enabling IMS services. The set top box consequently comprises native logics locally installed and/or hardware elements that are needed for setting up and manage an IMS session, including capability of using the Home Network Interface-IMS Gateway Interface (HNI-IGI) between the native or embedded IMS application and a remote IMS Gateway (IG). The set top box also has an implemented IMS stack code defining how such IMS-related communication is performed.
However, set top boxes, TVs and other IPTV terminals are quite cost sensitive, in terms of being quite expensive for buying users, when it comes to new functionality. This means that in order to be able to implement IMS services, the user has to replace its existing set top box with one that is pre-configured to include the necessary logics and applications to enable IMS services. Such a solution is, however, both costly and inflexible for the user.
There is, thus, a need for enabling usage of managed IPTV and IMS services in set top boxes that are not manufactured with implemented native or embedded IMS functionality.
It is a general object to enable IMS services to set top boxes.
It is a particular object to provide IMS functionality at set top boxes.
Briefly, the present invention discloses the provision of IMS functionality and application in a browser environment in a set top box and consequently does not need to have any native, i.e. pre-installed and configured, support for IMS at the set top box. A script-based IMS application run in a web browser in a declarative application environment is designed to take on the role of an IMS application in the set top box and perform the necessary data processing and IPTV session signaling with external units.
In more detail, an aspect of the embodiments relates to an IMS application configured to be implemented in a set top box within a home network. The IMS application comprises a signal generator configured to generate IPTV session signals destined to an IMS gateway on behalf of the set top box to set up and control an IPTV session. An address provider of the IMS application is configured to provide address information to an embedded or native Open IPTV Terminal Function (OITF) system implemented in the set top box. The address information is associated with media data available from a media server in a global network connected to the home network and the media data is to be rendered during the IPTV session at the set top box. The received address information originates from the IMS gateway. The IMS application of this aspect is a script-based IMS application configured to be run by a web browser implemented in the set top box and can therefore be used in a set top box that is not manufactured or otherwise configured to comprise pre-installed embedded or native IMS functionality.
A further aspect relates to a set top box comprising the script-based IMS application and a communication interface configured to enable communication with the IMS gateway. A web browser provides a so-called declarative application environment in which the scrip-based IMS application is run to generate a web page displayable to a user on a display screen of or connected to the set top box. An embedded OITF system is implemented in the set top box connected to the communication interface and is configured to generate a media request based on the address information provided by the script-based IMS application. This media request is communicated by means of the communication interface to a media server in the global network to request media data for rendering at the set top box within the ongoing IPTV session.
Another aspect relates to an IMS gateway that comprises a communication interface configured to enable communication with the set top box in the home network and servers in the global network. A register processor is configured to generate a register request comprising a user identifier of a user of the set top box and destined to an IMS server in the global network. A subscribe processor of the IMS gateway is configured to generate a subscribe request destined to an IPTV service provider in the global network. The IMS gateway thereby handles the registration and service discovery and selection on behalf of the set top box. An address converting processor is configured to map, for each IPTV service available to the user from the global network, address information received in response to the subscribe request to converted address information associated with the respective IPTV services but pointing towards the IMS gateway. The IMS gateway further comprises a page building processor configured to generate a web page comprising the converted address information and destined to the script-based IMS application in the set top box for display by means of the web browser on the display screen.
A method of setting up an IPTV session comprises, according to an aspect, running the script-based IMS application in a web browser implemented in the set top box. The script-based IMS application generates IPTV session set up signals based on activation of a user input of or connected to the set top box. The IPTV session set up signals are communicated to the IMS gateway, which in turn transmits address information that is received by the script-based IMS application. The address information that is associated with media data available from a media server is forwarded by the script-based IMS application to the embedded OITF system of the set top box to trigger generation of a media request for the media data within the IPTV session.
In another aspect the method of setting up an IPTV session comprises transmission by the IMS gateway of a register request comprising a user identifier of a user of the set top box to the IMS server. The IMS gateway also transmits a subscribe request destined to an IPTV service provider, which responds by returning address information to the IMS gateway. This address information is associated with the available IPTV services and is mapped by the IMS gateway into converted address information pointing towards the IMS gateway. The converted address information is employed for compiling a web page that is transmitted to the script-based IMS application of the set top box.
The protocols and logics required for conducting the IPTV and IMS session communication with the IMS gateway therefore do not need to be pre-installed at the set top box but can instead be handled by the browser-implemented script-based IMS application. This means that IMS services can be provided to all set top boxes having a web browser implementing a declarative application environment.
The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:
Throughout the drawings, the same reference numbers are used for similar or corresponding elements.
Embodiments relates to provision of Internet Protocol (IP) Multimedia Subsystem (IMS) services to user terminals and set top boxes without the need for any preconfigured IMS applications present in the set top boxes as installed embedded or native applications.
The media is generally available to the home network 1 through one or more IPTV providers or IPTV application servers 80 and one or more access providers 90. The former represents the network-implemented entity that provides IPTV services to the users of the IPTV system, whereas the latter provides the actual transport and access to the provided services to the home network 2.
The global network 2 illustrated in
The home network 1, sometimes denoted as residential network or consumer network, can, in some embodiments, be based on Ethernet or one of the existing wire home networking technologies, such as Home Phoneline Networking Alliance (HomePNA) or the Telecommunication Standardization Sector (ITU-T) G.hn standard, which provides a possibility of creating high-speed local area network using existing home wiring. Other examples include different Local Area Network (LAN) solutions. This means that IPTV-related services, including IMS services, can be delivered over IP and the customer's broadband connection, such as Asymmetric Digital Subscriber Line (ADSL), Very high-rate Digital Subscriber Line (VDSL), Public Ethernet, etc. Also wireless network solutions can be used to establish the local network, including combinations of wired and wireless techniques.
The devices 20-50 of the home network 1 are generally interconnected to the global network 2 through a gateway (GW) 10 providing an interface between the two networks 1, 2. This gateway 10 operates in a similar way to a router in terms of forwarding data from the home network 1, such as user generated IPTV service requests, to the global network 2 and forwarding data from the global network 2, such as IPTV services and associated media, to the home network 1.
In the embodiment illustrated in
The IG 20 can be a stand-alone device that is connected to the GW 10 as is illustrated in the figure. Alternatively, the functionality of the IG 20 can be provided in the same physical device as the GW 10, thereby basically combining the IMS gating and the network interconnection and gating in single device. Such a device could then be a modem or other gateway unit.
Although the IG 20 is illustrated as forming part of the home network 1 in the figure, this should merely be seen as an illustrative embodiment. Also network-implemented IG solutions are possible and within the scope of the embodiments, wherein the IG 20 is instead fully or at least partly implemented in the global network 2. In such a case, the IG 20 is advantageously implemented in a network node and can be co-arranged with other functionalities of the global network 2, such as IPTV provider 80 and/or access provider 90.
The home network 1 typically comprises one or more set top boxes 50 that are devices capable of processing and rendering the IPTV media. There is a vast number of different user equipment, terminals and devices that can take the role of a set top box 50 in the home network 1. Some non-limiting examples include a decoder, computer, etc. having the capability of receiving media data from the IPTV provider 80 and gateway 10 and processing, i.e. decoding and rendering, the media data on an included or connected display screen 60. In contrast to traditional decoders and set top boxes in digital TV systems, in an IPTV system, the set top box 50 provides two-way communications on an IP network and allows for decoding streamed media. Also mobile devices 30, 35, wirelessly communicating with the gateway 10 optionally through the IG 20, can operate as set top boxes according to the embodiments. Thus, the mobile telephone 30 and computer/laptop 35 illustrated in the figure can be regarded as set top boxes. The set top box can also be integrated in the display device, e.g. an IPTV enabled TV.
In the following, set top box is used to denote any user equipment, terminal or device capable of being provided in a home network and running applications for the purpose of providing IPTV services to one or more users and having functionality of processing IPTV-related media for display on a connected display screen, such as for the media form of video, images, text, etc., and/or play back by a connected loudspeaker, such as for the media form of audio.
In the art, Open IPTV Terminal Function (OITF) or IPTV Terminal Function (ITF) are sometimes employed to denote the set top box and the functionalities therein needed for setting up and managing an IPTV session. However, in the present document set top box is consistently used to denote the device designed to be provided in the home network and provide IPTV services, including IMS services, to users. The expression “set top box” therefore also encompasses those devices or device-implemented functionalities that are denoted OITF and ITF in the art.
IPTV should be interpreted broadly to encompass multimedia services, such as television, video, audio, text, graphics, data delivered over IP based networks to user equipment in a home network, where local processing, i.e. rendering and/or play back of the media is effected.
A set top box generally comprises or is capable of running various IPTV-related applications providing IPTV services to the users. In traditional IPTV systems, these IPTV-related applications and in particular IMS applications have mainly been in the form of embedded or native applications. Such embedded applications are locally installed in and run at the set top box. The set top box can then be pre-equipped with such installed embedded applications. In the following “embedded OITF system” denotes those parts of the OITF functionality of a set top box that are embedded and native to the set top box. This means that this embedded OITF system is locally installed in and run at the set top box and is typically pre-installed therein upon sale. The set top box thereby comprises the hardware structures and/or program code elements for effectuating, when being run by a general processor of the set top box, the functionalities of the OITF system. The embedded OITF system therefore has its own direct user interaction, such as remote control, keyboard, mouse, etc., and audio/video rendering and, optionally grabbing functionalities, such as display, speakers, cameras, microphones, or can be directly connected with other audio/video rendering/grabbing devices without passing through home network communication.
HTTP POST <IG URI>/<HNI-IGI message type>
<HTTP headers>
<X-OITF extension headers> or <X-HNI-IGI extension headers>
Content-Type: < . . . >
Content-Length: <Number>
<Message body>
HTTP/1.1 <HTTP response>
<HTTP headers>
<X-OITF extension headers> or <X-HNI-IGI extension headers>
Content-Type: < . . . >
Content-Length: <Number>
<Message body>
A HNI-IGI message can by of SIP type, in which the message is an HNI-IGI message corresponding to a SIP message. The IG 20 translates this into a corresponding SIP message by adding and changing the relevant headers. A HNI-IGI message of AUX type is an HNI-IGI message that does not translate to a SIP message. The IG 20 instead processes this message and responds accordingly. For more information of HNI-IGI messaging and the communication between the OITF and the IG, reference is made to Open IPTV Forum—Release 1 Specification, Volume 4—Protocols, V1.0, Jan. 6, 2009, the teaching of which is hereby fully incorporated by reference and in particular section 5.5 relating to Protocols System Infrastructure Functions and 5.5.1 relating to OITF-IG Interface (HNI-IGI).
This means that set top boxes 50 not having such locally installed IMS applications and the logics for conducting communication with the IG 20 cannot take advantage of the vast amount of available IMS services that are currently available in IPTV systems or will be designed in the future. The set top box 50 then lacks the necessary functionality for communicating with the IG 20 for the purpose of requesting, setting up and managing IPTV and IMS sessions.
Embodiments as disclosed herein replace the traditional native or embedded IMS applications with a script- and browser-based IMS application. Such script-based applications to be run in a web browser environment are sometimes denoted web applications in the art and in particular Declarative Application Environment (DAE) applications within the field of IPTV. In clear contrast to an embedded IMS application, a script-based IMS application is accessed via a web browser over a network, such as the Internet or an intranet. The script-based application is generally a software application coded in a browser-supported language. The script-based application is reliant on a web browser to render the application executable.
The script-based IMS application 40 is provided in the DAE environment, i.e. browser-run, and preferably uses an HTTP interface to the IG 20. This means that the script-based IMS application 40 can use the standardized HTTP-based interface, i.e. HNI-IGI, to effectuate the signaling with the IG 20 on behalf of the set top box 50.
As is seen by comparing
Generally, the IMS signaling functionality is thus moved from the native or embedded code or structures of the set top box 50 to the script-based IMS application 40. This means that functionality for service discovery, subscription and registration is advantageously provided in the IG 20 instead of the embedded OITF system. However, it is not the intention of the embodiments to limit where these functions are performed. In general all or only some of them can be performed in the IG 20. This if further described in more detail herein.
The initiation procedure generally begins by starting up the embedded OITF system if this is not already done. This is conducted according to prior art procedures. Correspondingly, the IG conducts provisioning of user identifiers and startup, such as using Dynamic Host Configuration Protocol (DHCP), which is a network application protocol used to obtain configuration information for operation in an IP network. It is particularly preferred if the IG can implement DHCP options 124 and 125 relating to retrieval of service discovery information.
Once the embedded OITF system has been started it preferably automatically launches a start-up request that is an internal call to direct the script-based IMS application or more correctly the web browser to a certain address, such as http://IG.fixed.local, of the IG. The IG then preferably has a fixed fully qualified domain name (FQDN) sometimes referred to as an absolute domain name. A FQDN is a domain name that specifies its exact location in the tree hierarchy of the Domain Name System (DNS). This fixed FQDN points to the IG so that the IG acts as a DNS server itself to point that FQDN to itself. The FQDN is preferably fixed implying that it can be coded or stored into the embedded OITF system code or structure without the need for the IG to inform the embedded OITF system of the FQDN each and every time an initiation procedure is conducted. Alternatively, the embedded OITF system then has to request this FQDN from the IG using the script-based IMS application or from some other unit.
The above described method of routing messages to the IG has the added value that if there is no IG, the access network provider, which is responsible for the DNS server, can resolve the IG FQDN and point it to a web server. This web server can e.g. display commercial information how the subscriber can subscribe to IPTV service.
Based on the received start-up request, the IG provides a user selection page that is returned to the script-based IMS application for display to the user. This user selection page can be pre-installed in the IG or the IG generates in on demand based on the reception of the start-up request. The user selection page comprises at least one user identifier of available users that can use the set top box in which the embedded OITF system is provided. The user identifier(s) can be any identifier(s) or information allowing identification of the user(s). Non-limiting examples include user name, given name and optionally family name, computer-generated user identifier selected by the IMS, etc.
The script-based IMS application then presents the received user selection page by means of the web browser on a display screen of or connected to the set top box. The user can then select among the different users that are provisioned at the IG. For instance, a family consisting of a father, mother and two kids can have five different provisioned users, including the default user profile, which is not personalized. The user clicks or otherwise selects the particular user identifier or name that he/she would like to use. The activation of the user input, such as mouse key, touch sensitive screen or keyboard key, generates a user selection command comprising the user identifier associated with the selected user. Optionally, an authentication procedure is initiated, in which the user is urged to enter a password or PIN code in order to get access to the selected user profile. This authentication procedure can be conducted by the generation and transmission of a HTTP: 401 UNAUTHORIZED message to the script-based IMS application, urging the user to enter a password or PIN code that is returned to the IG.
Once the selected user has been notified to the IG, a register request relating to the selected user is composed by the IG. The register request is preferably a SIP: REGISTER message comprising the user identifier of the selected user. The IG transmits this register request to the IMS. The IMS returns an acknowledge message in the form of SIP: 200 OK. This signaling is conducted as in the prior art but with a significant difference. It is the IG that conducts the user registration to the IMS instead of the embedded OITF system as in the prior art.
Correspondingly, a subscribe procedure involving the generation and transmission by the IG of a subscribe request, typically in the form of a SIP: SUBSCRIBE message followed by the return of an acknowledgement, SIP: 200 OK from the IPTV AS is performed. The IPTV AS also transmits a SIP: NOTIFY message relating to Service Discovery and Selection (SD&S), which the IG responds to by transmitting a SIP: 200 OK. The novel feature here is that the IG and not the embedded OITF system that is involved in the subscription and SD&S communication with the IPTV AS.
The IG then creates a web page comprising information of the IPTV services, including IMS services, available to the subscribed and registered user and notified from the service provider, i.e. the IPTV AS, through the SD&S notification. The IG further translates or converts the address information received in response to the subscribe request to converted address information pointing towards the IG. For instance, the IG advantageously map each universal resource locator (URL) received from the IPTV AS to point at the IG instead. This can be conducted by mapping each notified URL to a local URL in the IG or by actually rewriting the URLs.
The IG may optionally also associate the IPTV service choice from the IPTV AS with the real IPTV provider in order to handle Transport Layer Security (TLS) and authentication as a proxy.
An advantage of composing and providing a service provider selection page at the IG, is that the IG can add IPTV service choices from not only a single IPTV service provider or IPTV AS but actually from different IPTV service providers. For example, the IG may be installed or connected to a traditional ADSL-modem. In such a case, the IG may actually communicate not only with the IPTV AS but also, for instance, with a cable TV provider that can provide media services to the user inside the IPTV session. The means that the IG can collect information of services available from multiple different service providers, including different technologies, and compose this information into a single presentation page that is displayed for the user using his/her web browser.
The created service provider selection page is transmitted to the script-based IMS application to be displayed for the user in the web browser on a display screen of or connected to the set top box. The displayed web page lists the IPTV service choices provided by the IPTV AS based on the SD&S procedure. Optionally, TLS and/or authentication can also be handled. The displayed web page lists different service provider identifiers, names or information that allows the user to identify and select among the available service providers. These service provider identifiers can be the converted address information generated by the IG or other information or data provided in the service provider selection page and provided by the IG based on the data received in the SD&S procedure.
An advantage of this embodiment is that the IG can present service providers and selection information that is not of IPTV nature. The non-IPTV data may be e.g. cable, digital terrestrial or satellite TV. When the user of the set top box selects these services they are converted from their original nature into IPTV format, in order to execute service at a standard IPTV terminal and inside an IPTV session.
The user then selects one of the service providers by activating a user input of or connected to the set top box. The user input activation triggers the script-based IMS application to generate a service provider command comprising the provider identifier of the selected service provider. In a preferred embodiment, the service provider command is generated by the script-based IMS application based on the converted or rewritten URLs provided with the service provider selection page. Since these converted URLs point back to the IG and not the original IPTV application server, the service provider command will be destined to the IG.
The IG returns data relating to the selected service provider in the form of a service selection message. The service selection message preferably comprises address information of the IPTV services available at the selected service provider. The service selection message is transmitted to the script-based IMS application, which generates and forwards a service description load command to the embedded OITF system. This service description load command includes, for instance, the URL of the service provider and type information. The embedded OITF system preferably returns an acknowledgement or OK message. The embedded OITF system also launches an HTTP request to get discovery data from the IPTV AS. This discovery data can, for instance, be in the form of an Electronic Program Guide (EPG)—listing IPTV content and media available from the service provider, allowing a user to navigate, select and discover media content, for instance, by time, title, channel, genre, etc. Also other types of descriptive information informing the user of the available IPTV services at the IPTV AS can be used. The IPTV AS returns an acknowledgment with the discovery data, such as in the form of a HTTP: 200 OK message.
Alternatively, if the IG has added another service provider to the service provider selection page, such a cable TV distributor or Digital Video Broadcasting (DVB) content, the HTTP get discovery data is transmitted to the IG as the IG then points discovery to itself. The IG will then return the acknowledgement with the discovery data to the embedded OITF system.
In an embodiment, the script-based IMS application generates and transmits a portal communication message to the IG to load the portal page, i.e. service provider data, provided in the service provider command sent to the IG. The IG proxies this request and may convert the HTTP portal message to a HTTP Secure (HTTP(S)) portal communication that is sent to the IPTV AS. Optional Generic Bootstrapping Architecture (GBA) can be used to provide security mechanism. The IPTV AS then returns a HTTP(S): 401 UNAUTHORIZED message to the IG, followed by the return of credential information if the GBA security mechanisms are used. The IPTV AS also confirms reception of the HTTP(S) portal communication by a response acknowledgement, HTTP(S): 200 OK, to the IG. This acknowledgement is forwarded to the script-based IMS application by the IG to notify that the initiation procedure has been successful.
The script-based IMS application preferably returns a so-called pending command, such as in the form of a HNI-IGI PENDING_IG message, which is a pending HTTP request. This request allows the IG to respond when it needs to contact the embedded OITF system as a result of an incoming request from the network, such as the IPTV AS.
The above described signal procedure, which is illustrated in
The procedure starts with the startup of the embedded OITF system and provisioning and startup of the IG in similarity to
After the embedded OITF system has discovered the IG it still knows very little about the IG. In order to learn more about the IG and its capability, or to interact with it, the embedded OITF system retrieves the description of the IG from the URL provided in the discovery message, typically in the form of a HTTP: GET message. The IG returns the requested method, such as supported methods and its URL (IG URL) in the form of a HTTP: 200 OK response. A HTTP GET message with the informed IG URL is sent to the script-based IMS application and forwarded to the IG.
The following procedure involving the registration, subscription and SD&S procedure is conducted in the same way as was discussed above in connection with
The IG then compiles and presents the compiled service provider selection page to the user in the web browser by means of the script-based IMS application. The information of the selected service provider is returned to the IG in the service provider command. In this embodiment, the IG then compiles and transmits service provider data, such as in the form of a HTTP: REDIRECT message to a web offering or offering page provided based on the SD&S and presented by the script-based IMS application on the web browser. The following communication in
Thus, in the disclosed signal diagrams the IG will handle the managed support, such as register procedure, and no native HNI-IGI support is required. The SD&S data received for the IPTV AS is parsed by the IG and is used for generating a web page that is presented to the user by means of the script-based IMS application and the web browser of the set top box.
In
In an alternative approach, the embedded OITF system can conduct the service discovery. In such a case, the service discovery can be conducted with DHCP and without IMS. The IG will then respond to DHCP from the embedded OITF system and present service provider discovery information without the IMS. Today there are three options in DHCP option 124/125: IP address, DNS name or IMS, the latter is being used for managed networks. This means that in this embodiment no IMS is needed but other options for DHCP can be used instead.
In an optional step, the script-based IMS transmits a HNI-IGI: REGISTER message comprising an identifier of the relevant user, if there is a need to change user. The IG converts the HNI-IGI message to a corresponding SIP: REGISTER message comprising the user identifier and transmits it to the IMS. If there is no need to change the registered user this signaling can be omitted.
The script-based IMS application compiles a HNI-IGI: OPTIONS request to ask for server capabilities of the IPTV AS. The OPTIONS request typically originally comes from the web server or from the local script-based IMS application. The OPTIONS request preferably comprises an identifier of the requested VoD data, such as in the form of an URL or other address information. The IG receives the HNI-IGI messages and processes it into a traditional SIP: OPTIONS request and replaces the included identifier with an identifier URL2. The SIP: OPTIONS request is transmitted to the IPTV AS that returns a response message, SIP: 200 OK comprising information, SDP1, utilized by the script-based IMS application to initiate an IPTV session. The attached information includes a session description preferably in the Session Description Protocol (SDP) format. The response is returned to the IG, which maps the SIP response to a corresponding HNI-IGI response and forwards the message to the script-based IMS application.
The script-based IMS application requests information of the video and preferably audio ports to be used in the VoD session from the embedded OITF system with a port request. The embedded OITF system returns a response message with the requested information, i.e. at least one port identifier of the relevant video and audio ports.
The script-based IMS application generates and transmits an HNI-IGI: INVITE message, preferably with a SDP offer including information of the video and audio ports to which the media data should be sent. This invite message represents a request for an IPTV session. The IG processes the invite message and transforms it into a SIP: INVITE message that is sent to the IPTV AS. A response message, SIP: 200 OK, comprising a preferred SDP answer, including address information (URL2) of the requested media, is returned to the IG. The IG converts the response message into a HNI-IGI: 200 OK response before transmission to the script-based IMS application.
The script-based IMS application now has access to the address information associated with the media data as received from the HNI-IGI: 200 OK response. The script-based IMS application therefore preferably generates a play request with the address information, i.e. URL2, and sends it to the embedded OITF system to cause it to request the desired media stream, i.e. VoD media stream, from the media server (MS). This play request preferably includes an indication that no setup procedure should be performed by the embedded OITF system since the script-based IMS application has already conducted such a setup procedure with the IG and IPTV AS.
A media request in the form of a Real Time Streaming Protocol (RTSP) PLAY request is then composed and transmitted by the embedded OITF system to the media server dentified by URL2. The media server returns the requested unicast stream of VoD data to the embedded OITF system, where the data is decoded and rendered to display the video on an included or connected display screen and play back audio on an included or attached loudspeaker.
If the user elects to stop the VoD session, he/she activates a stop function on the web page presented on the web browser by means of the script-based IMS application, causing generation of a stop message that is forwarded to the embedded OITF system to stop the rendering of the media data. A request for terminating the session in the form of a HNI-IGI: BYE message is also composed and sent to the IG that transforms it to a SIP: BYE message that is sent to the IPTV AS to terminate the session and stop the delivery of the media data. A SIP: 200 OK response is returned to the IG and translated into a HNI-IGI: 200 OK message that is forwarded to the script-based IMS application to indicate that the session has been terminated.
The script-based IMS application running in the web browser, thus, conducts all the HNI-IGI signaling with the IG in clear contrast to the prior art. It also effectuates port pre-fetching to forward this information to the IPTV AS via the IG. The script also generates an indication of RTSP signaling with a preferred indication that no RTSP: SETUP procedure should be initiated by the embedded OITF system.
The procedure starts with the optional user registration procedure, if necessary.
In this example, the available media channels are known in advance by the script-based IMS application either through notification by the IG, the network, i.e. IPTV AS or a local DAE interface. The script-based IMS application compiles and transmits a HNI-IGI: INVITE message with a preferred SDP offer to the IG that transforms it into a corresponding SIP: INVITE message destined to an IPTV AS. The IPTV AS generates, based on the received message, a SIP: 200 OK response with a preferred SDP answer. This response is processed into a corresponding HNI-IGI response by the IG and is sent to the script-based IMS application.
The session description message received from the IG is used by the script-based IMS application to provide address information associated with the media data from the media source. In this embodiment, the relevant address information is the desired media channel, preferably in the form of a an Internet Group Management Protocol (IGMP) address of the media channel. The relevant media channel address is communicated to the embedded OITF system with a set channel command. The embedded OITF system uses this information for compiling and transmitting a media request, here represented by an IGMP: JOIN request, to the multicast source, i.e. media server. The set top box housing the embedded OITF system thereby joins the multicast or broadcast channel and starts receiving media data of the multicast stream. This received data is decoded and then rendered for display and play back to the user.
If the user would like to change channel during the media session, the user simply selects, on the web page presented in the web browser by means of the script-based IMS application, one of the other available media channels. The script-based IMS application then compiles and transmits a new set channel command to the embedded OITF system comprising the IGMP address of the new media channel. A combined IGMP: LEAVE/JOIN message or separate IGMP: LEAVE and IGMP: JOIN messages are then compiled and sent to the multicast source to cause the source to stop delivery of media data of the old channel and instead start delivery of media data of the new channel.
If the user then would like to stop the media session, he/she activates a stop function on the web page causing the generation and transmission of the HNI-IGI: BYE message as described above in
In the above described embodiment, media channel is set based on IGMP address. In such a case, necessary data and parameters can be fetched from a Broadcast Discovery Record. This can be done through reading an XML-document by the script-based IMS application.
The script-based IMS application may optionally also request, from the embedded OITF system, information of bandwidth characteristics of the desired channel. The embedded OITF system preferably returns such bandwidth information, such as maximum bit rate (MBR) and target transmission rate (TTR).
The remaining procedure is then the same as discussed above in connection with
The above described embodiments disclosed in the signal diagrams of
Thus, in a general embodiment of setting up an IPTV session the method involves running a script-based IMS application in a web browser implemented in a set top box. The script-based IMS application generates IPTV session set-up signals based on activation of user input of or connected to the set top box. The session set-up signals are communicated to the IG connected to the set top box present in the home network. The script-based IMS application further receives, from the IG, address information associated with media data available from a media server in the global network connected to the home network. This address information is forwarded from the script-based IMS application to the embedded OITF system of the set top box to thereby trigger generation, within the IPTV session, of a media request for the media data and destined to the media server.
In a particular embodiment the script-based IMS application receives a start-up request from the embedded OITF system as illustrated in
The method preferably also comprises receiving, at the script-based IMS application and from the IG, a service provider selection page comprising respective provider identifiers associated with the service providers available to the user from the global network. These provider identifiers are, however, designed by the IG to point towards the IG instead of the service providers. The script-based IMS application transmits a service provider command comprising a provider identifier of a selected service provider. This service provider command is generated based on activation of a user input of the set top box and is transmitted to the IG.
The method preferably further comprises receiving, at the script-based IMS application and from the IG, a service selection message comprising the address information of the IPTV services available at the selected service provider. The script-based IMS application compiles and transmits a service description load command comprising the address information to the embedded OITF system.
Further preferred method step includes the transmission of a pending command comprising a pending HTTP request from the script-based IMS application to the IG to enable the IG to forward any incoming requests from the global network to the embedded OITF system.
If the particular IPTV session involves media on demand, such as VoD, the method further comprises transmitting a port request from the script-based IMS application to the embedded OITF system and transmitting an invite message comprising a port identifier of at least one media port of the set top box to the selected service provider, where this invite message has been generated by the script-based IMS application based on a response message comprising the at least one port identifier from the embedded OITF system.
In this case the forwarding of the address information by the script-based IMS application involves the transmission, to the embedded OITF system, of a play request comprising the address information associated with the requested media data available at the media server. The play request further comprises an indication that an IPTV session has already been set up by the script-based IMS application and, hence, no set-up procedure should be performed by the embedded OITF system.
In an alternative embodiment directed towards an IPTV session involving scheduled content as an illustrative example of media data type, the script-based IMS application receives a session description message from the IG and comprising the address information in the form of multicast or broadcast channel information. The forwarding of the address information to the embedded OITF system then involves transmitting the multicast or broadcast channel information to trigger the embedded OITF system to join the multicast or broadcast media channel.
The operation steps conducted by the IG in a general method of setting up an IPTV session involves transmitting a register request comprising a user identifier of the user of the set top box to the IMS. The IG also transmits a subscribe request destined to the IPTV service provider and receives address information in response thereto, where the address information relates to IPTV services available to the user from the global network. The IG maps the address information to converted address information associated with the services but pointing towards the IG. This means that generating and transmitting a service request based on converted address information will guide the service request to the IG and not to the IPTV service provider. The converted address information is compiled into a web page that is transmitted by the IG to the script-based IMS application running in the web browser at the set top box.
In a particular embodiment, the IG also adds auxiliary address information associated with at least so-called one auxiliary service provider to the address information from the IPTV service provider. This enables the IG to present further services to the user that can be selected and run within the current IPTV session as previously described. The auxiliary address information is converted or mapped into converted auxiliary address information associated with the auxiliary service provider(s) but pointing towards the IG. The converted auxiliary address information is then combined with the converted address information when generating the web page to be transmitted to the script-based IMS application.
In a particular embodiment the method further involves the IG generating a web page comprising user identifiers of multiple users potentially available for the set top box in response to a user selection request from the set top box. The IG then returns the web page comprising the user identifiers for display by the script-based IMS application using the web browser.
Furthermore, once the IG receives a pending command comprising a pending HTTP request from the set top box as previously described, the IG will transmit any incoming requests from the global network to the embedded OITF system of the set top box.
In a particular embodiment the script-based IMS application 40 comprises the functionality of a signal generator 42 configured to generate IPTV session signals that are destined to the IG to set-up and control an IPTV session. The signal generator 42 is preferably configured to conducts such IPTV session signaling using the HTTP signal protocol and in particular the HTTP-based HNI-IGI signal protocol defined for IPTV sessions.
The script-based IMS application 40 also comprises the functionality of an address provider 44 configured to provide address information to the embedded OITF system in the set top box. This address information is associated with requested media data available from a media server in the global network and has been received from the IG.
The set top box 50 also comprises a script-based IMS application 40, preferably as defined in
The communication interface 52 is in particular configured to conduct HTTP-based communication with the IG and preferably HTTP-based HNI-IGI communication between the script-based IMS application 40 of the set top box 50 and the IG.
The communication interface 52 is preferably arranged for receiving, from the IG, the script, such as a HTTP/JS page, that provides the necessary functionalites for enabling IMS and IPTV sessions, i.e. the script-based IMS application 40. The received script data is forwarded to the web browser 54 or DAE application, where it is implemented and run in a browser environment resulting in the display, in the web browser 54, of information relating to the IPTV session to the user.
The script-based IMS application 40 is typically configured to receive a start-up request from the embedded OITF system 56 once it becomes activated. The script-based IMS application 40 then forwards the start-up request, such as the fixed FQDN pointing towards the IG, to initiate, at the IG, generation of a user selection page. Once the communication interface 52 receives this user selection page from the IG, it is presented to the script-based IMS application 40 for display by means of the web browser 54 on the display screen of or connected to the set top box 50. The user then activates a user input in wired connection or wirelessly connected to the communication interface 52 to indicate an intended user. This user input activation triggers the script-based IMS application 40 to generate a user selection command comprising the user identifier of the selected user. This user selection command is transmitted to the IG by the communication interface 52.
The script-based IMS application 40 further preferably receives a service provider selection page from the communication interface 52 and originating from the IG. The service provider selection page comprises respective provider identifiers of the service providers present in the global network. These provider identifiers are associated with the respective service providers but are designed by the IG to instead point towards the IG. The service provider selection page is displayed to the user in similar way as the user selection page. Activation of a connected user input triggers the generation by the script-based IMS application 40 of a service provider command destined to the IG and comprising the provider identifier of the selected service provider.
The script-based IMS application 40 also preferably receives a service selection message comprising address information of the IPTV services available at the selected service provider. The service selection message originates from the IG and is employed by the script-based IMS application 40 for generating a service description load command comprising the relevant address information of the IPTV services. This service description load command is forwarded to the embedded OITF system 56.
Once the IPTV session has been set-up the script-based IMS application 40 preferably generates and transmits a pending command comprising a pending HTTP request to the IG. The IG will then forward, based on the pending HTTP request, any incoming requests originating from the global network to the embedded OITF system 56.
The script-based IMS application 40 is preferably configured to generate and transmit, during an ongoing IPTV session and particularly a media on demand IPTV session, a port request to the embedded OITF system 56. The OITF system 56 responds with a response message comprising the requested port identifier(s) of at least one media port of the set top box 50. The script-based IMS application (40) then generates an invite message comprising the port identifier(s) and that is transmitted to the selected service provider by means of the communication interface 52 and the IG.
Once the script-based IMS application 40 has got access to the address information associated with the media data available from the media server it, during a media on demand IPTV session, generates and transmits a play request to the embedded OITF system 56. The play request comprises the address information and preferably an indication that no setup procedure should be performed by the embedded OITF session 56 since that setup procedure has already been conducted between the script-based IMS application (40) and the IPTV service provider.
In a scheduled content IPTV session or similar session involving multicasting or broadcasting of media data, the script-based IMS application 40 is configured to receive, from the IG, a session description message comprising the address information of the media data. In this case, the address information is in the form of address information of a multicast or broadcast media channel available from the media server. The address information is transmitted to the embedded OITF system 56 to trigger the embedded OITF system 56 to join the multicast or broadcast media channel.
In an alternative embodiment, though generally less preferred, the web browser application 54 and the embedded OITF system 56 can be implemented in different set top boxes, which then are wired or wirelessly connected to each other through the communication interface 52.
Additionally, the set top box 50 may comprise or be wired or wirelessly connected to a media processor having functionality for decoding and rendering received media content. The set top box or media processor then preferably comprises or is connected to a display screen and preferably a loudspeaker to display and play back the media.
In fundamentally different implementation approach, the IG 20 is not implemented in the home network but rather in the global network, for instance, in connection with the access provider or IPTV provider or as a separate network-entity or server of the global network. Regardless of being implemented in the home network or the global network the IG 20 still provides functionality for translating between HTTP and SIP communications and is capable of communicating with the IMS and the IPTV application server. When implemented in the home network, the IG 20 terminates the HTTP signaling and sets up SIP signaling as if it is the originator. This hides the fact that the script-based IMS application is behind a network address translation (NAT) unit. An IG 20 implemented in the network operates as a proxy and keeps routing information to and from the script-based IMS application. The IMS can then deal with NAT issues.
The IG 20 comprises a unit or functionality for communicating with other devices in the home network, in particular the set top box, and preferably also, optionally through the gateway, with units or servers in the global network. This unit is represented as a communication interface 21 operating as a general I/O unit in the figure. In practice, the communication interface 21 could be a general input and output interface for a wired connection with external and remote devices or in the form of a receiver/transmitter or transceiver for wireless connection.
The IG comprises a register processor 22 configured to generate a register request comprising a user identifier of a selected user of the set top box. This register request is destined to the IMS and is transmitted thereto by means of the communication interface 21. A subscribe processor 23 is configured to generate a subscribe request destined to a selected IPTV service provider in the global network. This subscribe request enable the IG 20 to receive address information of IPTV service provider, preferably in the form of SD&S data. This address information is employed by an address converting processor 24 of the IG 20 to map the received address information to converted address information associated with the IPTV service provider but instead pointing towards the IG 20. A page building processor 25 uses the converted address information to generate a web page, i.e. service provider selection page that is transmitted by the communication interface to the set top box and the script-based IMS application run therein.
In a particular embodiment, the address converting processor 24 is configured to also map auxiliary address information associated with other service providers that has media services that potentially can be run and provided inside the IPTV session. The address converting processor 24 thereby generates converted auxiliary address information associated with such other service provider(s) but pointing towards the IG 20. The page building processor 25 then also uses this converted auxiliary address information when generating the web page.
An optional but preferred HTTP-SIP converting processor 26 is implemented in the IG 20 and configured to convert a HTTP-based message originating from the set top box, including a HNI-IGI message from the script-based IMS application, into a corresponding SIP-based message destined to the IMS or the IPTV service provider. Correspondingly, the HTTP-SIP converting processor 26 is configured to convert an incoming SIP-based message originating from the global network into a corresponding HTTP-based message destined to the set top box.
The page building processor 25 is preferably also configured to generate a web page or user selection page comprising user identifiers of multiple users potentially available for the set top box in response to a user selection request originating from the set top box. In such a case, the IG 20 preferably comprises a memory (not illustrated) housing user identifiers of previously registered users of the home network. The page building processor 25 then simply retrieves these stored user identifiers from the memory upon reception of the user selection request. In an alternative approach, the IG retrieves the user identifiers from another source, such as the IMS. The communication interface 21 then forwards the user selection request to the IMS together with an identifier of the home network or the IG 20 to allow the IMS to identify previously registers users of that home network or the IG 20. The user identifiers are then returned to the communication interface 21 and forwarded to the page building processor 25.
The communication interface 21 is preferably configured to receive a pending command comprising a pending HTTP request from the set top box. This pending command triggers the communication interface 21 to transmit any incoming requests originating from the global network, such as IMS or IPTV application server, to the set top box.
Any functionalities of the set top box or IG as illustrated in
The embodiments described above are to be understood as a few illustrative examples of the present invention. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the scope of the present invention. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible. The scope of the present invention is, however, defined by the appended claims.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/SE2010/050533 | 5/17/2010 | WO | 00 | 5/27/2011 |
Number | Date | Country | |
---|---|---|---|
61179300 | May 2009 | US |