- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Tue, 28 Oct 2014 21:07:23 +0200
- To: public-webapps <public-webapps@w3.org>
[re-sent with corrected subject line] Hello, Concerning the Push API and service workers, I have a few comments on the incoming call scenario: 1. Dialer apps (and eventually users) should be able to configure a delay (e.g. 1-3 seconds) between first presenting the visual, then the audible notification for incoming call. Therefore the same entity which receives the incoming call event and triggers user notifications, should handle both types of notifications. This goes against the latency tendencies, since audio/ringing usually comes up much faster, and needs to be delayed in the platform if this use case needs to be fulfilled. 2. Dialer apps should be able to use contact specific ring tones, so we either need a mechanism to configure this, or it should be in the control of the dialer app _when_ to trigger auditive and visual notifications and _what_ should they contain. So far, 1. and 2. are optimally handled either by a headless dialer process in the user agent (offering an API to dialer apps), or part of the dialer app, deployed together with the app. 3. The end-to-end latency for processing cellular telephony signaling from the modem hardware to the dialer app, i.e. the appearance of UI dialog should optimally be less than 3-400 ms, otherwise in certain network conditions and implementations incoming call signaling may be lost (go down unnoticed). I know this goes far and hopefully will be encapsulated/fixed in modems, and even when it's not it will just end up in the need of repeating the dialing from the other end, but let's just try to target this latency class/keep this figure in mind when we design solutions. 4. In order to ensure latency limits, the dialer app or the headless dialer should be possible to be tagged (e.g. as type "telephony") so that the platform could consider it a member of a high priority process chain designed to handle telephony calls even during high system load scenarios (e.g. using cgroups). Likely this is a manifest issue, not an API issue, but keep in mind. Also, the consequence for architecture is the need to pull minimal amount of dependencies for handling calls. 5. There may be clients for multiple telephony systems (e.g. cellular, skype, SIP, XMPP, WebRTC letc), all of which compete on the same resources (audio, ringtones, etc). Therefore we need an entity for arbitrating resource allocation policy, and notification policy. We could also define a default policy for handling this in user agents (e.g. mixing all notifications and let the user arbitrate), and hopefully also a mechanism by which implementations can configure the policies they want. This is a bit out of scope too, just keep in mind that in this respect telephony handling is special in that it needs audio resource arbitration which may have effect in handling signaling. In generic messaging we can handle multiple types of messaging systems in parallel (unless they clash on ports, which are resources too). These considerations may also lead to leaving out the telephony domain from the scope of a generic, much simpler mechanism to handle push events. Therefore scoping the use cases would be important. Best regards, Zoltan
Received on Tuesday, 28 October 2014 19:07:52 UTC