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 #34 (comment).

[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 :)