API Call proposal

[Riccardo Vangelisti]

We added on voicecall branch a working version of mm that implements all 
voice call functionalities.

The voice capability is implemented on mm core but the only state 
permitted on an outgoing call is MM_CALL_STATE_ACTIVE because 
MM_CALL_STATE_DIALING and MM_CALL_STATE_RINGING_OUT states are not 
handled by generic modem.

In Huawei module there are custom commands (^ORIG, ^CONF, ^CONN) that 
permits to differentiate dialing, ringing and active states, so we've 
implemented it.
There is an another custom command (^CEND) that indicates the call 
termination with a duration field.
This information is not handled but is only printed in debug message.

We also added a DTMF interface in Call object that permits to send and 
receive tone on active call.
The send capability is a standard AT command, the receive action 
(^DDTMF) is a specific function implemented by Huawei modules (and many 
other modems).

For now we assume that could be one call at time as we decided.

We have tested new mm with these modems:
  * Simcom SIM7250E
  * Telit GT863-PY
  * Falcom Twist
  * Huawei MU709S-2

all modems works ! :)

So, could you check these commits ?

Regards,

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

Il 27/04/2015 16:17, Dan Williams ha scritto:
> On Mon, 2015-04-27 at 16:07 +0200, Aleksander Morgado wrote:
>> On Mon, Apr 27, 2015 at 12:36 PM, Riccardo Vangelisti
>> <riccardo.vangelisti at sadel.it> wrote:
>>> Dear everyone,
>>> we've pushed on our branch (
>>> https://bitbucket.org/riccardovangelisti/modemmanager/branch/voicecall )
>>> these features:
>>>
>>>   * Proposal of call api in introspection (xml and enums)
>>>   * Added Modem.Voice and Call support in libmm-glib library
>>>   * Added Modem.Voice and Call support in mmcli tool
>>>
>>> What do you think ?
>>> The hard part was choosing the option of the call that interact on it in
>>> mm-cli :)
>>>
>>> If you agree with this implementation we can go ahead with the next steps.
>> It looks good to me. I'd suggest you go on now and we'll just polish
>> the details once ready. Also, it may likely be that you'll end up
>> needing to update the API once you're implementing the support, so I'd
>> just not assume the API as totally fixed for now.
> +1 from me now too.
>
> Dan
>
>