[review] dcbw/huawei-voice

Thu May 4 18:50:26 UTC 2017

On Thu, 2017-05-04 at 16:30 +0200, Riccardo Vangelisti wrote:
> 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.

So for these devices, they don't implement CVOICE, but do support voice
via non-host-routed mechanisms, is that correct?

eg, they have pins for I2C audio or something like that?  How do we
know that these devices support voice, can we tell from firmware
commands?

> 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
> ? 

No, because most modems support these commands, but do not include
voice capabilities because they have no mechanism to get audio in/out
of the device.  Only modems with specific voice routing (I2C, USB, PCM
etc) actually have the voice capabilitiy, and I don't think we should
enable the interface unless we know.

Ideally we can use some other firmware commands to detect that voice is
possible on devices that do not support CVOICE.

If we cannot, then I think we have to fall back to udev tags or
something.

> Actually master don't check if modem has voice capabilities but
> simply 
> returns an error when you try to make a call.

Right, I changed the check on master to make the CVOICE call for Huawei
to ensure the modem had voice capability.  Since I only know the voice
checks for Huawei, that's the only plugin that (in the branch) exhibits
voice capability.

I also have a Sierra 860 PCMCIA card with voice capability (has a
headset jack on the card itself) that I was going to improve the branch
with.  But I know there are Sierra-specific commands that would allow
me to check whether the modem supports voice calls or not.

> 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

This would be a bug if incoming calls are not correctly handled.  I
will investigate and fix it.  Did outgoing calls work on the E1150?

> >    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 ?

At the moment with the branch, only Huawei supports voice calls, and
the code currently assumes that any detected QCDM port (there is almost
always only one) is also the audio port.  I was unable to find
documentation that described what the value returned from "AT^DDSETEX?"
 actually means, though perhaps it means the USB interface # or
something.  But the only usage I can find is for "2", so it's unclear.

Is there any way with the MU709 and ME909 to determine conclusively
that they support voice or not, via AT commands if possible?

Thanks for testing!!

Dan

> 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?
> > 
> 
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel