Re: [EME] Heartbeat support

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