Re: change proposal for Telephony API

Hi Hsin-Yi,

I hear your point. I think it is possible to retrieve the calls at
service level too, and at manager level, too.

In order to be on the same page, the best is to spend some time with
the use cases and build up the API from there. I will enumerate some
key use cases and requirements, then I try to separate some concerns.
Please ack/nack/comment these.

A. Telephony Resources
1. All telephony services use some sort of network connectivity: one
or multiple cellular radios/modems (providing also internet
connectivity), or wireless connectivity (internet)
2. All telephony services use audio resources (microphone, speaker,
audio HW). Audio HW architecture may vary a lot (done on DSP, inside
or outside the modem/network processor, or done on application
processor, etc)
3. Some telephony services may use video resources (camera, screen) if
available.
4. Some resources (microphone, headset, camera, screen) can be
external, and can be plugged in and out any time. This involves
showing the user how audio/video input and output is routed (e.g. by
icons), and provide means the user to change the audio/video routing
(e.g. by settings and/or buttons on the dialer UI).
5. There are real-time constraints imposed by the telephony service on
the total system latency for handling incoming calls, otherwise calls
can be missed without even noticing them as a missed call. So
processor load and system latency is also a telephony resource.

B. Telephony Services
1. There may be platforms supporting multiple types of telephony
services, each using the same telephony resources.
2. In the first version of the API it is fine to implement only
cellular support. However, the API could and should be forward
compatible with expected changes in telephony standardization,
concerning the affected telephony technologies (especially IMS). From
experience, it is possible to make the API compatible with the
telephony protocols known today (cellular, SIP, XMPP).
3. Different telephony services may involve different connectivity,
authentication, signaling, audio management technologies.
4. However, user experience of telephony applications can be unified,
i.e. built around similar principles: dial, receive a call, manage
contacts, presence, add and remove call participants, put calls on
hold, handle other calls and later retrieve the held calls, disconnect
calls, send DTMF tones, etc. This permits the design of a telephony
API which can be used for all telephony services today, with the
differences handled by parametrization (e.g. dictionaries).

C. Applications
1. There may be platforms with a single system dialer, which can be
replaced by the used with another app, handling all supported
telephony services. Even in this case, telephony resources may
conflict with other apps (e.g. navigator, music player, etc).
2. There may be platforms with multiple dialer apps, each handling
different telephony services. The problem here is that all of them
have to deal with the same shared telephony resources. Therefore in
this case central arbitration is needed for incoming, and outgoing
calls. This cannot be managed by the apps in a cooperative manner,
since there must be one single enforcement point for each resource
type (audio, video, network, processor). However, platforms are free
to decide the type of resource management they implement. The API must
be compatible with these.
3. There may be platforms with multiple dialer apps, each handling the
same telephony services (alternative apps). The user should select one
of the apps for handling incoming calls on those services.

D. Separation of concerns in the Telephony API design
- telephony services are best handled by separate objects
- there should be an object managing the telephony services
- telephony resource policy should be transparent to the telephony
API, except when it involves user input (in which case is preferably
deferred from the telephony API).

These are the design points against which we should measure the API. I
think you tried to express similar things in your email below, but I
want to be sure we understand things the same way. If not, we should
get to an agreed set of use cases and requirements.

So would you be fine with a design which handles incoming calls at
service level, too, but an event is also sent to the telephony
manager? Also, if the calls belonging to a given service would be
enumerable at service level, would it be fine? Are there other
concerns?

Thanks,
Zoltan


On Mon, Apr 22, 2013 at 6:42 AM, Hsin-Yi Tsai <htsai@mozilla.com> wrote:
>
> On 2013年04月18日 17:16, Kis, Zoltan wrote:
>> Hi Hsin-Yi,
>>
>> Thank you for looking through the proposal.
>>
>> On Thu, Apr 18, 2013 at 11:58 AM, Hsin-Yi Tsai <htsai@mozilla.com> wrote:
>>> I am not sure I got a clear difference between the interfaces
>>> TelephonyManager and TelephonyService. I am a little confused at the purpose
>>> and definition of TelephonyManager in this proposal. For example, I am
>>> wondering shouldn't onincoming and oncallschanged be exposed on
>>> TelephonyService since we can't receive any calls without telephony service,
>>> and since you propose a separate API for that service. It seems not
>>> intuitive to me that we use TelephonyService to make an outgoing call but
>>> receive incoming calls via TelephonyManager.
>> In telephony domain all the incoming calls should be handled by one
>> object, since only one call will get resources (e.g. audio, video), so
>> arbitration is needed - as opposed to messaging, where each messaging
>> service can independently receive messages.
>>
>> For dialed calls, the given service can be used, or by enumerating the
>> services through the manager and using them.
>
> Hi Zoltan,
>
> Agree that in terms of arbitration, we need calls being handled by one
> object; however that doesn't necessarily imply that TelephonyManager
> should be that object nor that we should dispatch incoming events to
> TelephonyManager, unless you are talking about letting app handle
> arbitration. Otherwise, IMHO arbitration is implementation issue. And
> since the position of TelephonyService object is to provide telephony
> service, I still think that user should be able to receive incoming
> calls via TelephonyService object. It looks incomplete and inconsistent
> that a service object provides functionality for outgoing calls only,
> excluding incoming calls.
>
>>> Also, shouldn't each telephony service contain its calls?
>> It could, but not much use. The dialer is interested to resynchronize
>> itself with the list of current calls on startup (since perhaps it has
>> crashed). This is easier to do with one call list, then to list all
>> services, then list all calls from them. The calls themselves can be
>> managed by their TelephonyCall or ConferenceCall  objects, and they
>> keep track on which service they are (by the serviceId).
>
> I am not sure if it is expected behaviour that calls are provided by a
> service but user cannot get the calls via the corresponding service
> object. I am not against having one call list in the manager object;
> contrarily, it could be more user-friendly with one call list exposing
> to the manager object I believe. However, I feel if we want to have a
> separate object for each service, then the service object shall behave
> more naturally, as it is a real service, even having separate service
> objects might lead to some incapability of exposing central information
> or lead to acceptable cost to implementation. The proposal right now
> seems not natural enough IMHO.
>
> Best regards,
> Hsinyi
>
> --
> Hsin-Yi Tsai 蔡欣宜
> Mozilla Taiwan
> T: +886-2-87861100 ext:312
> htsai@mozilla.com
>

Received on Monday, 22 April 2013 08:04:08 UTC