[push-api] comments on incoming call scenario

[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