RE: [EME] Heartbeat support

>From specification, the heartbeat is between CDM and its server(license server? CDM server?),
Are sure that application (javascript) has API to control the heartbeat between them.

Yang
Huawei

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Tuesday, July 10, 2012 6:00 AM
To: Yang Sun
Cc: Mark Watson; Martin Soukup; public-html-media@w3.org
Subject: Re: [EME] Heartbeat support

It seems the application can handle this without any additional specification. Since the application is responsible for network traffic, it can handle retries, etc. MEDIA_KEYERR_HEARTBEAT would be reported when by the CDM when the behavior is no longer within the heartbeat policy (i.e. the expiration was exceeded).

On Tue, Jun 26, 2012 at 6:49 AM, Yang Sun <sun.yang.nj@gmail.com<mailto:sun.yang.nj@gmail.com>> wrote:
Do we have a restore or try another time mechanism to restore the heartbeat?
There is always some error in network connections, if each time the heartbeat error occurs and UA does nothing to minimum the impact to application, i think it may be not application friendly or error resistant.

Can we hold a period of time, to wait the heartbeat to return to normal? then we may report MEDIA_KEYERR_HEARTBEAT to application, and application may control the UA stop fetching the data .

On Sat, Jun 23, 2012 at 8:21 AM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:
One other issue to consider is whether to allow the CDM to inform the application that a heartbeat-related failure has occurred. For example, we may want to add a new MediaKeyError value (i.e. MEDIA_KEYERR_HEARTBEAT) that indicates that decryption stopped because of a heartbeat failure. Examples causes include missing or invalid responses/ACKs.

While this adds a heartbeat-specific value to the proposal, it is very minimal and there is already one similarly use case-specific error defined.

On Fri, Jun 22, 2012 at 5:12 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:
One issue with reuse of keymessage for heartbeat^ is that the application cannot differentiate a heartbeat message from any other message^^. While the hope is that it wouldn't need to, one use case might be to use a different server/URL for heartbeats than licenses. For example, a content provider might wish to use a different server for the frequent - and therefore high QPS on the server - heartbeats than the initial license request. I can't say whether supporting this is necessary, but it would be unfortunate to essentially force the same URL to be used.

To address this and enable other potential use cases, I propose the following:

  *   Change the "defaultUrl" attribute of MediaKeyMessageEvent to "url".
  *   Allow "url" for every keymessage event.
  *   If specified in a keymessage event, applications should but are not required to send the message to the value of the "url" attribute.

     *   (In most cases, applications will want to respect the "url" - it may have even been set via the license from the content provider or application. However, there might be scenarios where an application wants to override it, and I don't think there is a reason to specify that it can't. This doesn't seem to affect user agent implementations at all. If the application does something it shouldn't have, playback may stop.)
I think this is a better solution than adding a separate "heartbeat" event, adding a flag, or requiring that all messages be sent to the same URL or processed in the same way.

^ This same issue could also affect other non-key request uses of keymessage, but I'm not aware of any other concrete examples. Heartbeat is also a frequent message that might lend itself to a separate URL.
^^ There are a variety of ways that this could be worked around, but they don't seem very clean. Similarly, a front end server may be key system-independent and thus unable to differentiate messages to send to various backend servers.

On Wed, Jun 13, 2012 at 9:39 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jun 13, 2012, at 7:39 AM, Yang Sun wrote:


The idea of single key single session

I don't think anyone is assuming a one-to-one relationship between keys and sessions. Are you proposing that ?


only has meaning when the key is used for the encrypted media, but the keep-alive message really does not need a key used for the encrypted media, so we should differentiate the keep-alive message with "real" key.

Why ?



For the key rotation, I do not know for the keep-alive message, there will be a new key or using existing key in the keymessage().

If using existing key, why key rotation happnes?
If usinga new key, can we using a temporary namespace key,since it has nothing relationship with CDM.
Does the key in keymessage will have something relative with CDM on device?

I didn't understand these last two sentences - could you elaborate ?

What we're trying to achieve here is an API where the purpose of the message exchanges is well-defined as being to establish the necessary state in the CDM to decrypt the media. But the actual contents of that state: keys, key metadata, licenses, how many, whether they expire, whether they rotate etc. is all up to the keysystem. There's no real reason for the script to know why the CDM wants to exchange messages with its peer server - other than the 'to establish decryption state' - the script just facilitates the exchange.

...Mark



On Wed, Jun 13, 2012 at 12:03 AM, Martin Soukup <martin.soukup@irdeto.com<mailto:martin.soukup@irdeto.com>> wrote:
I think Option 1 is simpler for the application developer and is consistent with the idea that a single key has a single session. If the rotation of keys will generate new sessions, however, I believe that the heartbeat mechanism should be consistent and be treated as a new key request since as an application developer I shouldn't need to differentiate between what kind of requests are being made.

Similar to the question that came up on the call, how does the keymessage identify the media element?

Martin

From: David Dorwin [mailto:ddorwin@google.com<mailto:ddorwin@google.com>]
Sent: June-12-12 2:12 AM
To: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: [EME] Heartbeat support

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16738

Some content providers require a heartbeat from the client device. Implementations often involve a message being generated by the decryption module and being ACK'd by the server. The APIs in the proposal were designed to allow such additional features without requiring API changes. However, there are multiple ways heartbeat might be implemented, and it probably makes sense to provide guidance to avoid fragmentation.

The current draft mentions two potential implementations at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#faq-heartbeat:
 1) Use keymessage to continue the current session
 2) Start a new message exchange procedes in exactly the same way as the initial message exchange, with the exception that the Key System and Session ID are known when the needkey event is sent.

In option 1, keymessage would be used to provide the heartbeat, which must be ACK'd by the server. The thought is that this ACK would be provided via addKey(). Assuming we make the change in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16548,  addKey() is always a response to a keymessage event, so that is somewhat consistent with existing use cases.

Option 2 is very consistent with the initial key request, but seems overly complex for a periodic heartbeat related to the same license.

If we feel heartbeat is common enough, another option would be to add explicit support for heartbeat, as is the case for key release. However, unlike key release, heartbeat can be handled within the existing APIs, and we want to avoid adding specific features to the API as much as possible.

Mark has provided his input in the bug. Does anyone else have a preference?



--
Yang
Huawei







--
Yang
Huawei