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