Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate possible compatibility with HbbTV #67

Open
anssiko opened this issue Mar 25, 2015 · 16 comments

Comments

@anssiko
Copy link
Member

commented Mar 25, 2015

We should understand the constraints that a possible compatibility with HbbTV could put on the design of the Presentation API.

Related discussion at: https://lists.w3.org/Archives/Public/public-secondscreen/2015Feb/0102.html

@anssiko anssiko added v2 F2F labels Mar 25, 2015
@anssiko

This comment has been minimized.

Copy link
Member Author

commented Mar 26, 2015

@matt-hammond-bbc will give us a short presentation at F2F on relevant aspects of HbbTV 2.0 and how they may or may not fit with the work of the Second Screen Presentation WG.

@matt-hammond-bbc

This comment has been minimized.

Copy link

commented May 13, 2015

Here is a summary of the behaviour and capabilities of the application launch and communication mechanisms in HbbTV 2.0, with a view to how they relate to the functionality in the presentation API:

HbbTV 2.0 allows another device on the home network to request that the TV launch a URL in the HbbTV engine. This engine is basically a UA with an HbbTV defined profile of HTML5 plus TV specific extensions.

Discovery

  • Begin the same as DIAL (HbbTV 2.0 incorporates DIAL) using SSDP and retrieving the UPnP device description
  • Then query the existence of an "HbbTV" DIAL application to determine if device has HbbTV capabilities.
    • This query also returns the WebSocket URL needed to use the message communication mechanism in HbbTV

Launch:

  • DIAL launch request for "HbbTV" DIAL app. Post body contains HbbTV launch parameters
    • Minimum required is the URL of the HTML page to launch.
    • Must also provide integer appId and orgId if the HTML page wants to use HbbTV broadcast TV features
  • Response codes indicate success/failure of launch

Resumption:

  • Can determine (using DIAL) if the HbbTV engine is running; but not what URL it is presenting.
  • No presentation session identifier provided. Will not be able to tell if HbbTV engine has been re-started (with a different or the same presentation) since the UA last checked

Communication:

  • HbbTV device provides a means of establishing a transparent non-TLS WebSocket connection. Both the Javascript running in the HbbTV engine, and the Javascript in the other device connect to a server built into the TV that relays the messages between paired-up connections.
  • When connecting, URL must be suffixed with an app-endpoint by both parties. Only if they match will the connections be "paired" and start to relay messages. A message is sent to both parties notifying them when pairing takes place.
  • If a connection is not yet paired, it will not be possible to tell which of the following is the reason
    • Presentation on the TV not yet loaded and running
    • The webpage on the TV has chosen not to communicate.
    • Different presentation on the TV from the one we expected
    • No webpage being presented on the TV.
  • The presentation on the TV controls whether it wishes to open/close communication connections, so it cannot be used as a reliable way of determining of the presentation is running/terminated on the TV.

Close/Terminate:

  • No guaranteed support. Stopping the HbbTV engine would be done using DIAL where it is an optional feature.

Resumption/Joining:

  • Can determine in HbbTV engine is running, but not what presentation it is showing
  • Can try to establish communication (using the correct app-endpoint) but can only detect success.

Summary of compatibility:

  • Discovery and launching mechanisms map well to existing availability checking and sessions starting.
  • Message communication mechanism maps to send/post and receive functionality (it is basically WebSockets) but only if the correct app-endpoint string can be provided
  • For the second screen presentation to use broadcast TV functionality specific to HbbTV, additional per URL parameters must be passed in the launch process.
  • Closing/terminating a session can break the communication link, but cannot force the presentation on the TV to be terminated.
  • Resumption/joining a session is possible if the same app-endpoint is used, but this does not guarantee you are communicating with the same presentation as before.
  • Communication is always unencrypted and cannot be trusted as there is no mechanism for the UA to authenticate and trust the actions of the HbbTV device
  • It is possible to successfully start a 2nd screen presentation on an HbbTV device, but to never successfully establish communication with it (e.g. that web app on the TV simply chooses not to communicate). Even if it does, there will be a noticeable and variable delay between successful launch and the communication channel being established (presentation in a started, but not 'connected' state?)
@matt-hammond-bbc

This comment has been minimized.

Copy link

commented May 13, 2015

Some questions that I think arise from this:

Can there be a mechanism to pass additional parameters to the availability checking and/or session starting process? (issue-81 and issue-9)

Does closure/termination just mean disconnection of the communication link with the 2nd screen presentation? or does it mean the 2nd screen presentation must be terminated? (issue-35)

Could a started or resumed session be temporarily or permanently in a disconnected state (no message communication capability)?

Does it matter if the rejoining process cannot guarantee that you are communicating with the same instance of the same URL being presented on the HbbTV device?

Security: given that the HbbTV device cannot be trusted by the UA and the message communication mechanism is non-TLS Websockets, what should happen for secure origins? (issue-45, issue-63)

@matt-hammond-bbc

This comment has been minimized.

Copy link

commented May 18, 2015

Addendum: orgId and appId fields are mandatory in XML AIT.

A UA vendor could register for its own orgId to launch a broadcast-independent app (if the controlling web app does not provide orgId)

@matt-hammond-bbc

This comment has been minimized.

Copy link

commented May 19, 2015

Here is the full set of slides giving overview of relevant HbbTV companion features and my assessment from above:

https://myshare.app.box.com/s/rl2joltd6pyu6hx7flbpc1zu91pbptvu

I'll go through a subset of these (to keep within time) during the WG F2F meeting today (19 May 2015)

@obeletski

This comment has been minimized.

Copy link

commented May 29, 2015

Does HbbTV spec define a way to communicate app-endpoint between companion screen and TV app?
I understand that we need to pass it to startSession call in the originating UA. Additionally, in the presenting UA we also need to pass it to NavigatorPresentation.getSession() call #34 (comment).

@matt-hammond-bbc

This comment has been minimized.

Copy link

commented Jun 2, 2015

HbbTV does not communicate the app-endpoint. Yes, I agree that it would need to be passed by the web app as part of the process of establishing the session.

The solution for this perhaps can also pass other HbbTV specific parameters - such as appId and orgId

@louaybassbouss

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2015

we published today a new Node.js module hbbtv with feature complete Implementation of HbbTV 2.0 CS on github and npm. Please refer to the Readme for more details about how you can install, use and develop applications using this module. We have also clients for other platforms like Android, iOS and Cordova but these are not public yet.

Since there are currently no HbbTV 2.0 TVs available (first TVs or STBs are expected next years), this module opens the door for early proof-of-concept implementation of Presentation API on top of HbbTV 2.0 CS. We already started with a Presentation API HbbTV polyfill for both controlling and presenting browsing contexts.

@matt-hammond-bbc please let me know if we can do together more experimentation on this topic.

@tidoust

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2015

Hi @louaybassbouss

That's excellent, thanks for sharing! I am interested by the development of a Presentation API HbbTV polyfill as well. I'll get in touch.

@louaybassbouss

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2015

Hi @tidoust

Great happy to work with you on this topic :)

@tidoust

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2015

FYI, thanks to @louaybassbouss' node-hbbtv implementation, I experimented support for HbbTV 2.0 support, or rather support limits, in an updated version of my Presentation API polyfill:
https://mediascape.github.io/presentation-api-polyfill/

The polyfill does not attempt to create a communication channel since my goal was to see what an HbbTV 2.0 device would support out of the box without software updates. As noted by @matt-hammond-bbc, athough relatively easy to do since there will be a Websocket server available, such a device would not establish the communication channel on behalf of the receiving application.

@louaybassbouss

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

Thx @tidoust. I just published a Cordova plugin that implements the HbbTV 2.0 CS Client features (Discover HbbTV Terminals, Launch HbbTV App and Open App2App WebSocket Channel) on GitHub [1] and npm 2]. these are the features relevant for the Presentation API. A Cordova Demo Application that uses the Plugin is also published on GitHub [3]. The Plugin supports Android for now, iOS is work in progress. You can use the plugin with real HbbTV 2.0 Terminals (expected next year) or with the Node.js hbbtv module [4] started in terminal mode on a PC. Your feedback and comments are welcome.

@tidoust

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2016

For reference, see related discussion at TPAC

@mfoltzgoogle

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2017

Bumping this up for consideration at TPAC during rechartering discussions.

Based on discussions with partners, interoperability with HbbTV 2.0 and related, shipped protocols would be an incentive to adopt the Open Screen Protocol (and the APIs it supports). I don't think this is an easy problem to solve, but it would be worth pursuing, and could require API and spec changes to get there.

@mfoltzgoogle mfoltzgoogle added P1 and removed P2 labels Nov 1, 2017
@chrisn

This comment has been minimized.

Copy link
Member

commented Nov 2, 2017

Thanks, Mark. We're certainly interested in pursuing this for V2.

@mfoltzgoogle

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2017

From https://www.w3.org/2017/11/06-webscreens-minutes.html#x18:

ACTION: @louaybassbouss to investigate how to do HbbTV scheme with parameters, and look into HbbTV privacy aspects

ACTION: @mfoltzgoogle to look into HbbTV communication channel requirements in general

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.