W3C home > Mailing lists > Public > public-sysapps@w3.org > October 2012

Re: Telephony API draft

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Mon, 22 Oct 2012 13:23:39 +0300
Message-ID: <CANrNqUeXuvUiyt7+A3wTeqaOh9zPA6gj3Qkdzygn8zaBjLBKaQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: EDUARDO FULLEA CARRERA <efc@tid.es>, "public-sysapps@w3.org" <public-sysapps@w3.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>

On Mon, Oct 22, 2012 at 12:45 PM, Jonas Sicking <jonas@sicking.cc> wrote:

The API as it's currently defined isn't enough to implement a
> recording feature. There's no way to actually access the recorded
> calls and play them to the user, and there's no way to specify the
> file format parameters to be used to record the call.
What do you mean by an API not being enough to implement a functionality?
The API only exposes a functionality.
My assumption was that implementation is native, and below web runtime.
Or, do you want to handle AT commands and PCM interfaces from the web
runtime? Including real-time constraints, security policies, etc?
Where is the limit we define between native middleware territory vs
functionality implemented in HTML5?
I have a certain understanding of where that should be, but it seems it is
different than yours :).
I think in order to build a system which will work in practice, we need to
get this part right, from the beginning.

Then, it is true that recording a call may not be possible in certain
hardware designs, depending on the modem audio path. In those cases this
feature will not be implemented, and an error condition can be raised.

> So I definitely think that we need to change the API from it's current
> state.

It is easy to remove the recording feature, but I would not like to do it
for the wrong reasons.

> > This is not minimalistic, but IMO it's simpler for developers.
> Generally speaking, we should only add features to simplify
> development in cases when it's an operation commonly done by
> developers. We can't ever solve 100% of the things that developers
> might want to do. Especially by adding dedicated APIs for them. It's
> much better to try to build enough primitives that the common use
> cases are easy, and that the unusual ones are possible.

This is usually true, and I agree. But in this case it is a pretty easy
thing, just an optional field in a dictionary.
It is certainly not a dedicated API.

> I must admit to never having seen a phone UI which allows recording a
> call, though I don't doubt that they exist. So my question is how
> common of a requirement this is from users and phone manufacturers.
Many phones do offer call recording, either via the native dialer, or via
an app.
Actually I have got many questions from users about supporting this feature.

Best regards,

> / Jonas
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
Received on Tuesday, 23 October 2012 18:09:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:10 UTC