Re: Telephony API draft updated

On Fri, Nov 30, 2012 at 2:08 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>> If nothing
>> else it would create a much more complex security model since of
>> course the WebRTC-based application shouldn't have access to the
>> telephony hardware.
>
> Why should it access the telephony HW?
> For setting volume on WebRTC we could use a similar MediaControl
> object I drafted in the last email, but which would be connected by
> the implementation to a different backend.

The proposals so far (or at least my understanding of them, though
given that I appear to have missed a couple of emails it might be an
inaccurate understanding) all suggest that the audio controls for
telephony live on telephony-related objects. Be those the Telephony
object or the TelephonyCall object.

My WebRTC-based dialer wants to perform the same actions such as "use
the speaker for telephony-like sound" and "mute the microphone".

It's entirely possible to design the APIs such that the WebRTC app
uses the Telephony or even the TelephonyCall objects to perform these
actions. Without automatically giving that app the permission to
perform other actions on those objects, such as place or receive phone
calls.

However doing so creates a somewhat complex security model since it
means that certain properties on the Telephony/TelephonyCall object
would use different policies than other properties on the
Telephony/TelephonyCall. Totally implementable but confusing to use.
And likely easier to have security bugs in the implementation of.

>> The API is still in early stages and I wouldn't recommend removing the
>> audio features on the Telephony API for now since we don't yet have a
>> full replacement. But I think it's something that we should keep in
>> mind as we're talking about audio features for telephony.
>>
>> Here is what the API looks like so far:
>>
>> https://wiki.mozilla.org/WebAPI/AudioChannels
>
> What you seem to be doing there is
> - correctly identified some mobile use cases
> - suggested a solution which looks simple to spec an API for,
> cooperative audio policy management among applications, and using some
> patterns like wake-up locks (similar to what Android uses).
> The cooperative application-level policy management proved to be a
> fundamentally broken idea in the past I have seen.
>
> A better approach would be to let device makers specify their audio
> policy (which can be wildly different case by case), implement a
> central policy decision with distributed enforcement, and define an
> API for apps so that they can request what they would like to do - but
> which may be overridden by the system, in which case the app should be
> notified about it.
> Also, notifications should be handled in relation with this, e.g. when
> there is an incoming call, depending on the policy, the profile, and
> the user settings, the phone may beep, vibrate, flash the screen, ring
> a generic tone, ring a contact-specific tone, etc.
> Or, should phone calls be notified during camera recording (and if
> yes, how). Or, if and how map navigation happens during a phone call.
> Or, how alarms are handled during a call (and depending on which audio
> route is active). And all stacked combinations of the above. Locks
> cannot handle that in a generic way, you'll see races, livelocks and
> deadlocks in a short blink.
>
> This is a bit off topic, but no wonder we ended up discussing it,
> since all dialer developers will face these issues. So we should
> monitor/discuss also the related API developments.
> I wonder how is it supposed to happen in this work group.

It is a bit off-topic indeed, but definitely relevant because it might
be an alternative approach to solving audio control for the Telephony
API.

What you describe is similar to what we are trying to build. It's very
much designed with un-cooperative applications in mind. Though I admit
that application have to cooperate a bit more than I'd like.

But I prefer to talk in concrete proposals so if you have one I'd be
very interested to see it.

I also don't see how the API that we're working on could result in
deadlocks/livelocks, but I'd be very interested to know if I'm wrong.

/ Jonas

Received on Friday, 30 November 2012 11:10:05 UTC