Re: Telephony API draft updated

On Fri, Nov 30, 2012 at 1:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Yes, but in my view all these objects control the same central
representation of volumes/other settings, which lives in the
implementation/system. Remember that I have the hybrid native/web apps
model in mind, too :).

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

My point is you don't need that. It is easier to expose a similar
object on the other interface, which would talk to the same
implementation. (Depending on your audio stack, your design may be
different.
BTW what do you use? pulseaudio/gstreamer? or still libmediaplayerservice?)
Both ways you'd need the permissions, but it's cleaner to handle them
via the platform/implementation, rather than between apps,  although
having app-to-app services may have their own appeal.

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

Yes, see above, IMO it is cleaner to (allow me an allegory) go through
the main secured door, rather than maintaining small service doors,
which tend to be the weakest points of any secured building.

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

OK, then it's the same thinking, good.

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

We are indeed working on this, currently on native middleware, but
also with web runtime/ web app scenarios in mind, so both a native and
a web API are on the way. This is a new design, although the team has
done multiple working solutions in the same area before.
I am not sure which way should we handle this, within this working
group or not, but here is some information.

The project home:
http://01.org/murphy/
There are some docs, and the source, which is moving fast, so doesn't
tell much yet.
We may need to expose some use cases there (both for mobile and
automotive use), will try to address that.

Related materials:
http://arunraghavan.net/2012/11/pulseconf-2012-report/
which refers to these slides:
http://arunraghavan.net/downloads/janos-pulseaudio-copenhagen.pdf

I have only done the telephony plugin for it (and I am mostly familiar
with the telephony use cases), so I suggest asking questions on this
mailing list:
https://lists.01.org/mailman/listinfo/murphy-dev

For what concerns the Telephony API and this working group, let's move
on by keeping the proposed [Telephony]MediaControl object (without the
"for future use" part) on the Telephony interface, until we come up
with a better idea.

Best regards,
Zoltan

Received on Friday, 30 November 2012 12:04:54 UTC