Re: [EME] Heartbeat support

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