[SPAM] Re: API Call proposal

[Aleksander Morgado]

Hey Dan & Riccardo,

Some comments from my side.

> For states:
>
> + * MM_CALL_STATE_UNKNOWN: default state for a new outgoing call
>
> Should we have a MM_CALL_STATE_DIALING in between here for outgoing
> calls?  The call isn't really RINGING until the dialing request is
> complete, and that can sometimes take 10 seconds or more while network
> capacity is being allocated and the circuit set up, especially in busy
> cells.
>

Is this worth? I think it could be cleaner to have DIALING state
applicable only to ongoing calls (i.e. you ATD... and you wait for the
OK/NOCARRIER/BUSY/NODIALTONE response), and then RINGING only for
incoming calls (i.e. you're receiving a new call and the device should
ring).

> I think we also need STATE_HELD to indicate when the call is on hold
> (see +CHLD docs), and STATE_WAITING (+CCWA).
>
> Ok, I ignored these command! I'll add these states in the next patch.
>

I actually would only add these whenever we support holding/waiting the call...

> The "Call.Audio" property concerns me a bit, I don't think it provides
> enough detail.  What is /dev/ttyUSB3 supposed to be as the "Audio"
> value?  I know on the one Huawei that I have that supports voice, the
> serial device just spits out and accepts 16-bit PCM frames, but how
> would that be indicated here?  I don't think apps should require a
> parallel database of modem voice details.  Also, what does "analog"
> actually mean?  Where does the audio come from or go to?  I think this
> part needs more specification and possibly more detail in the API.
>
> I will reply to this as soon as possible. In the meanwhile, what are your
> suggestions?
> Note that in my case the modem provides an analog output that must not be
> handled by software.
>

I would try to avoid guessing; and therefore I would just target for
now the specific device that is going to be supported first. If this
device for now doesn't need anything software-wise (i.e. the audio
circuit is totally independent), then either we add a property showing
a value which says "external" or the like, or even, we completely
ignore this and we don't even add a property. Whenever new
implementations that require other info are implemented, then we can
add new properties. What do you guys think? I'm just trying to keep it
simple.

> On to Voice...
>
> There are also some meta operations that can be done, like call
> transfer, join, multiparty, etc.  Ofono created a VoiceCallManager API
> for that purpose, which might be useful to review for .Voice API
> additions.
>
> It's true, but maybe these methods could be added later.
> My goal is to start a call as soon as possible...
>

I also agree with this. We should write a minimal API for now, not
targeting transfer/join/multiparty...

But looking at Ofono's API is also something that would be valuable.
Riccardo, could you take a look at this API and compare it with the
proposal we're discussing to see if there are inconsistencies?
Android's API would also be interesting to check.

>
> DeleteCall needs more explanation; obviously it will terminate (hang up,
> disconnect) the call and release any resources.  Basically it's just
> like Hangup() right?
>
> I thought to use "DeleteCall" in order to remove a terminated call from the
> Voice list property.
> Obviously if the call is active, this method should also terminate the call.
>

Yeah, so the thing here is that we'd be leaving in the list of calls
managed by the Voice API all the call objects that have been generated
in this session, and this includes calls that have been terminated
with a HangUp. So, to let the users of the API clear the list or
specific objects from DBus, the DeleteCall() method would be available
(same as we do e.g. in Messaging API with non-stored sent SMS
messages).

> For CallAdded, instead of a boolean, how about just re-using
> MM_CALL_DIRECTION?  Also, is the direction argument that interesting
> here?  eg, what would a client do when it receives the CallAdded signal
> + direction, if it *doesn't* retrieve the call object properties?
> Possibly the argument could be removed if we expect clients to get all
> the properties, since eventually we'll have CLIP, phone number,
> multiparty, emergency indicator, etc.
>
> Direction is more correct than the bool value, but I prefer to remove the
> property and force user to read the call object properties.
>

Yes, the signal should only expose the path of the new call object
being exposed in DBus. Clients should load the properties they are
interested in, and that would include the direction.

-- 
Aleksander
https://aleksander.es