Re: Telephony API draft

On Sat, Oct 20, 2012 at 2:31 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> Hello,
>
> The record feature in this API only mirrors that the dialer UI has to know
> whether the user wants the call recorded from the beginning, or not. It was
> meant as a UI option which is then conveyed to the implementation.
>
> About accessing the streams... The Telephony API currently only handles
> signaling.
> [ Next, we planned to add conference support.
> Next, I wish to support for handsfree gateways, multiple SIM cards and
> different telephony services. I have a draft prepared for discussion.
> Although this could handle most VoIP use cases too, let's discuss that later
> and separately. ]
>
> Next, stream support may be added. Note that this is missing from telephony
> middleware such as oFono, but it is present in VoIP middleware like
> Telepathy/Farstream. For telephony, we arguably don't really need access to
> the streams, except for toggling eventual local recording - and only this is
> supported for now.
>
> For VoIP, I was thinking to use MediaStream. However, there are some audio
> management details to be sorted out before I'd make a proposal.
> Once we add support for accessing the streams, then yes, recording could be
> supported via the MediaStream interface.
>
> 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.

> 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.

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.

/ Jonas

Received on Monday, 22 October 2012 09:46:15 UTC