Investigate possible compatibility with HbbTV

[anssiko]

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]

@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-001]

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-001]

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-001]

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-001]

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]

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 https://github.com/w3c/presentation-api/issues/34#issuecomment-103532501.

[matt-hammond-001]

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]

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]

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]

Hi @tidoust

Great happy to work with you on this topic :)

[tidoust]

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]

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]

For reference, see related discussion at TPAC

[markafoltz]

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.

[chrisn]

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

[markafoltz]

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