Re: [EME] Heartbeat support

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> 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> 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
>> > 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]
>>> *Sent:* June-12-12 2:12 AM
>>> *To:* 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
>>
>>
>>
>