[review] dcbw/huawei-voice

[Riccardo Vangelisti]

Hi,
sorry for late reply but we took some time to test this branch using 
these Huawei modems:

+-------------------+-----------------+--------------------------+-------+
| Modem             | Firmware        | ^CVOICE Support          | Voice |
+-------------------+-----------------+--------------------------+-------+
| Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16, 20 | Yes  |
| Huawei MU709s-2   | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16, 20 | Yes  |
| Huawei E1150      | 11.609.18.00.00 | ^CVOICE:0,8000,16,20     | Yes  |
+-------------------+-----------------+--------------------------+-------+

First of all, when ^CVOICE command is not supported by the modem all of 
voice capabilities are disabled.
For example, ME909s and MU709s modems have voice capabilities supported 
by the firmware but voice is disabled anyway.

Our proposal is to use ^CVOICE command only for checking PCM audio port 
capabilities and not for all voice capabilities.
Can voice capabilities be enabled or not using ATH or AT+CHUP command ? 
Actually master don't check if modem has voice capabilities but simply 
returns an error when you try to make a call.

Aleksander, did you check if this branch works on your MU709 dev board ?

Second, we tried to start and receive voice's calls using E1150 (CVOICE 
supported) but no audio coming from /dev/ttyUSB1 (qcdm).
# mmcli -m 0 -o 0

|    encoding: 'unknown'
|  resolution: 'unknown'
|        rate: 'unknown'

If we make calls using mmcli --command in debug mode and enabling CVOICE 
support (AT^CVOICE=0) and the audio port (AT^DDSETEX=2) all works 
correctly and audio coming from /dev/ttyUSB1.
Example: # cat /dev/ttyUSB1 | aplay -f S16_BE

Dan, could you indicate the correct sequence to make a call when CVOICE 
is supported ? How ModemManager tells me what is the correct device used 
by audio stream ?

Thanks,
Riccardo


Il 18/04/2017 12:29, Aleksander Morgado ha scritto:
> On Mon, Apr 17, 2017 at 7:08 PM, Dan Williams <dcbw at redhat.com> wrote:
>> Reworked the audio format stuff and added mmcli support.
>>
>> Removed the 'blocked' stuff and started using 'connected' instead.
>>
>> Now the larger change: call state handling in mm-base-call.c.  I
>> removed most of the base class call state setting for the MO (mobile-
>> originated, eg outgoing) call stuff.  I think the call state handling
>> there was wrong; only the subclasses know when the call is ringing and
>> has been picked up (answered) on the remote end through unsolicited
>> notifications.  So the subclasses must be the ones to update the call
>> state when they get these notifications, not the base call class.
>> Huawei calls will now go through UNKNOWN -> DIALING -> RINGING_OUT ->
>> ACCEPTED, where previously they went UNKNOWN -> RINGING_OUT -> ACTIVE
>> and at the wrong times.
>>
>> Eventually we should implement +CLCC (list current calls) polling in
>> the base class and then we can get this information generically for
>> subclasses that don't implement unsolicited notifications.  Newer
>> devices may have support for +CMCCS/+CMCCSI unsolicited notifications
>> which could also be used in a generic implementation.
> Riccardo, Marco, could you guys also review Dan's branch?
>