Re: Telephony API draft

On Tue, Oct 23, 2012 at 12:37 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> On Tue, Oct 23, 2012 at 5:46 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>>
>> 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.
>>
>
> I agree this feature is valuable, and indeed it is better to remove it until
> we figure out streaming.
> However, recording is not possible to implement on all platforms. WebRTC /
> MediaStream can be used in VoIP, but audio for telephony is more complex, it
> depends on modem + HW design, and audio SW stack. It is not clear what it is
> assumed. Bluetooth profiles (HFP, including hands-free gateway) have to be
> supported, preferably an all telephony services. Audio management wrt
> resources and accessories has some tricky issues which would be worth
> discussing since it leads into middleware details.

One thing to keep in mind is that we don't have to support all
features on all hardware. First of all, the APIs that we are designing
here are unlikely to be implemented on hardware that was released even
just a month ago. But I know very little about HW and SW stacks for
audio drivers on phones, so this might not make a difference.

Second, recording still seems to me to be somewhat of a fringe
feature. It seems to me like it would be ok if the standardized API
doesn't support recording on all hardware devices. But maybe I'm
biased by not being in markets where people use such a feature a lot.

Third, on hardware where it's hard to get access to the audio stream,
it might be just as hard to implement recording even if the API is a
simple record() function.

I know very little in this area so people telling me that I'm wrong is
very welcome. But my main point is that we shouldn't try to anticipate
possible problems too much. It's very easy for that to cause
overengineering of APIs. The implementation phase of a W3C draft is
specifically there to see if the spec is implementable.

> Does our work group have a wiki page for use cases and requirements?

Not that I know. Such a page would be great.

/ Jonas

Received on Tuesday, 23 October 2012 23:01:08 UTC