Re: Telephony API draft

On Mon, Oct 22, 2012 at 1:39 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

>
>
> 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.
>>
>> So I definitely think that we need to change the API from it's current
>> state.
>>
>>
> There is 2 ways forward:
> 1. remove the recording feature for now
> 2. add playback interface.
>
>
Here I want to add that the recorded call playback feature belongs to the
call history interface, which has not yet been defined (although I have a
draft for it).

Speaking about call history, there are opinions that the dialer should
track the calls and manage its own call history.  I do not agree with this
for cellular calls (may be OK for VoIP, though). It is not the HTML5 dialer
which should track call history, but the telephony middleware does it.
Otherwise you may lose logging incoming calls under heavy system load (yes,
I have seen that). Until you add real-time capabilities to web runtimes,
this will not change.

It is true that the telephony middleware often does not deal with
databases, but usually has an interface for accessing call history (e.g. a
temporary cache, which is erased after read, like oFono does). In other
cases a database is used, e.g. by Skype.

In summary, there tends to be one call history database per call service
(cellular, XMPP, SIP, Skype, etc), usually managed from middleware, with an
API to access it. It does not mean all call history has to be in one system
DB, but does not exclude it either. There will be examples for both. The
dialer apps should only access this call history - but of course anyone is
free to screw up and pretend maintaining their own.

Regardless whether call history is accessed through an API, or from a
system database, or from IndexedDB, we need to specify the schema of it.

One field may be the recording, with value being the file URI for the
recording. The format is default one on the given platform (AMR, AAC, etc).

Now what is better, an API or a data interface?

Regards,
Zoltan


> About choosing file formats... isn't the default format good enough to
> store and play back? The systems have the codecs anyway if you can make a
> call. I think that specifying transcoding formats is the 0.5% use case
> which we shouldn't go into in this API. There can be a separate app or API
> for it.
>
> I think we spent too much time on this minor feature, and there are far
> more important thing ahead, so I can accept removing this feature for now,
> in order to move on.
>
> Eduardo, Jose, your call :).
>
> Nevertheless, I am very interested to get the assumptions/requirements
> aligned about where is the limit between native vs. web implementations
> (see previous email).
>
> Regards,
> Zoltan
>