<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hey, <blockquote type="cite" cite="mid:1497287030.14157.1.camel@redhat.com"> <pre wrap="">On Fri, 2017-05-05 at 18:56 +0200, Riccardo Vangelisti wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">On Fri, 2017-05-05 at 16:40 +0200, Riccardo Vangelisti wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, </pre> <blockquote type="cite"> <pre wrap="">On Thu, 2017-05-04 at 16:30 +0200, Riccardo Vangelisti wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, sorry for late reply but we took some time to test this branch using these Huawei modems: +-------------------+-----------------+-------------------- ---- --+--- ----+ </pre> <blockquote type="cite"> <pre wrap="">Modem | Firmware | ^CVOICE Support | Voice | </pre> </blockquote> <pre wrap=""> +-------------------+-----------------+-------------------- ---- --+--- ----+ </pre> <blockquote type="cite"> <pre wrap="">Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16, 20 </pre> <blockquote type="cite"> <pre wrap=""> </pre> </blockquote> <pre wrap=""> Yes | Huawei MU709s-2 | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16, 20 </pre> <blockquote type="cite"> <pre wrap=""> </pre> </blockquote> <pre wrap=""> Yes | Huawei E1150 | 11.609.18.00.00 | ^CVOICE:0,8000,16,20 | Yes | </pre> </blockquote> <pre wrap=""> +-------------------+-----------------+-------------------- ---- --+--- ----+ 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. </pre> </blockquote> <pre wrap=""> So for these devices, they don't implement CVOICE, but do support voice via non-host-routed mechanisms, is that correct? </pre> </blockquote> <pre wrap=""> Yes, I don't know why manufacturer disable CVOICE command in these modems. </pre> </blockquote> <pre wrap=""> OK. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> Yes, they have a PCM audio interface (data in, data out, clk and sync on Mini-PCI express) connected to an external audio codec like TLV320AIC3204. </pre> </blockquote> <pre wrap=""> Ok. The problem is that ModemManager should only enable the Voice API when it knows the modem has audio hardware or an audio interface, which most devices like USB sticks and lots of PCIE modems don't. So we'll probably need to use udev rules too. </pre> </blockquote> <pre wrap=""> Ok. </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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 ? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> After a quick search I cannot find a specific command that can be used to check if modem+firmware supports voice. I think that manufacturer deploy a general purpose firmware in most of their modems. I've attached a text file with some test that show voice related at command can't be used to check if voice is supported or not. In particular Huawei E172 make voice call but voice related AT commands return an error. </pre> </blockquote> <pre wrap=""> I know many modems support the generic voicecall commands, but most don't have audio hardware at all. I wasn't aware the E172 had that voice capabilities in any firmware version, are you sure it has the USB PCM audio capability like others? </pre> </blockquote> <pre wrap=""> E172 makes call but don't have an audio jack, maybe with a little hack with opening the case or something else it can be connected an audio jack. </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">If we cannot, then I think we have to fall back to udev tags or something. </pre> </blockquote> <pre wrap=""> Right, if CVOICE is not supported we can enable voice capability from udev specifying the audio mode, for example external PCM audio or CVOICE mode. Also when CVOICE is supported we could use external PCM audio using udev tags. Something like ID_MM_HUAWEI_FORCE_EXTAUDIO=1 </pre> </blockquote> <pre wrap=""> Since CVOICE only works on Huawei, and only works on some Huawei devices, obviously we'd need to find other AT commands for other manufacturers, and/or use udev tags. I would suggest ID_MM_VOICE_SUPPORTED=1 or something like that, and make it available to all devices not just Huawei. </pre> </blockquote> <pre wrap=""> Perfect ! </pre> <blockquote type="cite"> <pre wrap=""> The next question is whether these devices should provide anything in the "Audio Format" and "Audio Port" properties. I would say no, since it's very hardware specific and not generally applicable. </pre> </blockquote> <pre wrap=""> Ok, I would suggest "Audio Port" something like "forced" or "User request" if voice was enabled by udev tags and all "Audio Format" fields set to unknown. </pre> <blockquote type="cite"> <pre wrap=""> So I will modify the branch to add the ID_MM_VOICE_SUPPORTED tag, and have that override the CVOICE check in the Huawei plugin. I just don't want MM to say "this modem supports voice!" for a device that clearly has no way to get voice out (like many USB sticks). I think the combination of udev tags and plugin-specific probing would make us all happy. What do you think? </pre> </blockquote> <pre wrap=""> Ok, it's correct. </pre> </blockquote> <pre wrap=""> One last question; do the Huawei modems that you have which do not support "^CVOICE:0" return "^CVOICE:1"? Or do you have some that *do* support voice, but return ERROR to the ^CVOICE query?</pre> </blockquote> Both case, for example Huawei USB Stick E3276 4G support voice call but returns '^CVOICE: 1, 8000, 16, 20' (voice disabled) and Huawei USB Stick E172 3G support voice but returns ERROR on AT^CVOICE? command. (see attached file in date Fri, 5 May 2017 16:40:29 +0200) <blockquote type="cite" cite="mid:1497287030.14157.1.camel@redhat.com"> <pre wrap="">What I'm trying to figure out is if we can use ^CVOICE (any return value) to automatically figure out if the Huawei modem supports voice calls (either USB PCM or hardwired headset), or if there indeed are devices that somehow support voice but don't implement any ^CVOICE return. Supposedly, ^CVOICE:0 = "PC voice", ^CVOICE:1 = "headset". Which would mean that yes the modem supports voice, just not on a USB port. And hopefully an ERROR return means it doesn't support *any* kind of voice. Do you think that would be true for Huawei devices? Obviously for other devices, we probably have to have a udev tag.</pre> </blockquote> For us the easy way is to use udev tags. <blockquote type="cite" cite="mid:1497287030.14157.1.camel@redhat.com"> <pre wrap=""> Dan</pre> </blockquote> Riccardo <blockquote type="cite" cite="mid:1497287030.14157.1.camel@redhat.com"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">Thank you, Riccardo </pre> <blockquote type="cite"> <pre wrap=""> dan </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Actually master don't check if modem has voice capabilities but simply returns an error when you try to make a call. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> Actually master don't check if modem has voice capabilities because all generic modem that support voice audio interface could make call. In the branch only Huawei modem (with CVOICE or with udev tags) will support voice call. To me it seems to be a regression from master. Can be udev tags made with global scope ? So users can enable it as they want. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> 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? </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> encoding: 'unknown' resolution: 'unknown' rate: 'unknown' </pre> </blockquote> <pre wrap=""> 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 ? </pre> </blockquote> <pre wrap=""> 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 </pre> <blockquote type="cite"> <pre wrap="">Thanks, Riccardo Il 18/04/2017 12:29, Aleksander Morgado ha scritto: </pre> <blockquote type="cite"> <pre wrap="">On Mon, Apr 17, 2017 at 7:08 PM, Dan Williams <a class="moz-txt-link-rfc2396E" href="mailto:dcbw@redhat.com"><dcbw@redhat. com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Riccardo, Marco, could you guys also review Dan's branch? </pre> </blockquote> <pre wrap=""> _______________________________________________ ModemManager-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:ModemManager-devel@lists.freedesktop.org">ModemManager-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/modemmanager-d">https://lists.freedesktop.org/mailman/listinfo/modemmanager-d</a> evel </pre> </blockquote> <pre wrap=""> _______________________________________________ ModemManager-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:ModemManager-devel@lists.freedesktop.org">ModemManager-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/modemmanager-dev">https://lists.freedesktop.org/mailman/listinfo/modemmanager-dev</a> el </pre> </blockquote> <pre wrap=""> _______________________________________________ ModemManager-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:ModemManager-devel@lists.freedesktop.org">ModemManager-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel">https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel</a> </pre> </blockquote> <pre wrap=""> _______________________________________________ ModemManager-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:ModemManager-devel@lists.freedesktop.org">ModemManager-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel">https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>