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

Re: Telephony API draft

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Tue, 23 Oct 2012 14:46:04 +0000
CC: "Poussa, Sakari" <sakari.poussa@intel.com>, Jonas Sicking <jonas@sicking.cc>, "Kis, Zoltan" <zoltan.kis@intel.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
Message-ID: <4835F56E-A4E3-4576-8DDA-428F449A29BA@att.com>
I suggest if the feature (which I do think is valuable) is removed for now we should think about specifying it somehow for compatibility with the media stream objects being used in WebRTC and the getUserMedia API. Piping two media streams (mic and other party audio) into a mixer object and then to a file should I hope be possible using the basic objects and interfaces being defined for this. Having a convenience function (like a call log API) is useful but we should also look at the other work that's underway with similar objectives.

Bryan Sullivan

On Oct 23, 2012, at 9:23 AM, "EDUARDO FULLEA CARRERA" <efc@tid.es> wrote:

On 23 oct 2012 at 09:13:29, Poussa, Sakari wrote:
> On 10/22/12 12:45 PM, "Jonas Sicking" <jonas@sicking.cc> wrote:
>> On Sat, Oct 20, 2012 at 2:31 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>>> Do you think we should take out for now the recording feature? It
>>> could be seen as a convenience function for the developers. My
>>> thinking was that the Telephony API should facades most means to
>>> dialer developers supporting the typical dialer UI designs, and the
>>> binding implementations would connect the dots.
>> 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.
> I agree. That is, I don't see the need for the record functionality in
> this API. Or in any API for this purpose.
> BR; Sakari

I agree it does not make sense to have the recording feature unless we specify the API to access the recordings. So I am fine with removing the feature for now, and actually I can implement this change in the next version of the draft.

Best regards,


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
Received on Tuesday, 23 October 2012 14:47:35 UTC

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