API Call proposal

Wed Apr 22 08:36:25 PDT 2015

Hi all,

I attach'd a new patch and schema with your latest suggestions.

Note that Voice.StateChanged signal has "reason" argument but, by the 
way, I had to create the MMCallStateChangedReason property in order to 
permits user to retrieve that information also from the call object.
This property is the same that indicates why and how a call terminates. 
So, I've created an enum for each state trasition.

Also, I've removed Audio property as Aleksander suggested.

If you doesn't have any other suggestions, my colleague and I start to 
develop in our branch: 
https://bitbucket.org/riccardovangelisti/modemmanager/branch/voicecall

Riccardo Vangelisti - Sadel SpA
Software Development
Via Serenari 1, Castel Maggiore (BO)

Il 22/04/2015 11:23, Aleksander Morgado ha scritto:
> 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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-Modem.Voice-and-Call-interfaces-for-voice-call.patch
Type: text/x-patch
Size: 9207 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20150422/94f96849/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modemmanager_call_voice.jpg
Type: image/jpeg
Size: 45649 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20150422/94f96849/attachment-0001.jpg>