|
Next revision
|
Previous revision
|
misc:huaweii-voice [2020/07/08 18:39]
prppedro created |
misc:huaweii-voice [2020/07/11 22:26] (current)
prppedro [Unlocking voice function] |
| Okay, so you may want to use voice on Linux **and** without using the Partner software (whose Linux version seems to be crappy). Well, you're out of luck if you want an out of the box solution. But there's an way. You can pretty much do it using a couple of UNIX and AT ([[wp>wp>Hayes_command_set|Hayes]]) commands. | Okay, so you may want to use voice on Linux **and** without using the Partner software (whose Linux version seems to be crappy). Well, you're out of luck if you want an out of the box solution. But there's an way. You can pretty much do it using a couple of UNIX and AT ([[wp>wp>Hayes_command_set|Hayes]]) commands. |
| |
| ===== Unlocking voice function ===== | ===== On locked/unlocked voice function ===== |
| |
| I don't remember how to check for it, but there's a custom command for querying voice stuff which works on most 3G dongles: ''AT^CVOICE?''. Under normal circunstances, this command should give you audio format information. If it does not, either your 3G dongle doesn't support it at all or it's simply unlocked. | I don't remember how to check for it, but there's a custom command for querying voice stuff which works on most 3G dongles: ''AT^CVOICE?''. Under normal circunstances, this command should give you audio format information. If it does not, either your 3G dongle doesn't support it at all or it's simply unlocked. |
| ===== How it works ===== | ===== How it works ===== |
| |
| //tl;dr: see the next sessions for practical usage// | **tl;dr:** //see the next sessions for practical usage// |
| |
| Well, there were, in fact, a way to use the voice function under Linux. But it was cumbersome. Asterisk had a module called "chan_dongle" which allowed those dongles to be used as trunk lines. If you just want to place a goddam call on your dongle, it's way to much work, I think. But it was the very existence of this module which proved to me it was possible to get the voice data without needing aditional crapware. | Well, there were, in fact, a way to use the voice function under Linux. But it was cumbersome. Asterisk had a module called "chan_dongle" which allowed those dongles to be used as trunk lines. If you just want to place a goddam call on your dongle, it's way to much work, I think. But it was the very existence of this module which proved to me it was possible to get the voice data without needing aditional crapware. |
| |
| So, let me explain briefly how this voice stuff works in this kind of dongle: there's three serial ports (MODEM, DIAG and PCUI), and you talk to the modem via the MODEM port (generally is the first serial device, like /dev/ttyUSB0, but not always) or the PCUI port (which tends to be last one). The PCUI port isn't exactly useful because it outputs a lot of information which is only useful to the Partner Software | So, let me explain briefly how this voice stuff works in this kind of dongle: there's three serial ports (MODEM, DIAG and PCUI), and you talk to the modem via the MODEM port (generally is the first serial device, like /dev/ttyUSB0, but not always) or the PCUI port (which tends to be last one). The PCUI port isn't exactly useful because it outputs a lot of information which is only useful to the Partner Software. Then there are the middle one: DIAG. This pors seems to <del>serve no purpose</del> lack the hability to reply to AT commands. In the Huawei AT Command reference (cf. [2], p. 113 -- PDF p. 111), though, there's a command (''AT^DDSETEX=2'') which lets you route the audio data through this DIAG port. |
| | |
| | Typically, it shows up at ''/dev/ttyUSB1''. But, as I said before, maybe you should test each port to find out which is which. To sumarize: DIAG port won't do anything, MODEM port replies to AT commands and PCUI does that and also prints some information from time to time, autoissuing some AT commands. |
| | |
| | <code> |
| | AT+CSQ |
| | +CSQ: 11,99 |
| | |
| | OK |
| | AT^SYSINFOEX |
| | ^SYSINFOEX:2,1,0,1,,3,WCDMA,41,WCDMA |
| | |
| | OK |
| | </code> |
| | |
| | I won't go into details over this, however. I can think of some reasons for it to happen, but they're not really important for us, right now. Hypothesis: has something to do with keeping the network/signal status updated on whatever program uses it. |
| | |
| | There's also a fourth port, mentioned in this document [idem, ibid] only once: PCVOICE. This is a hell of an unknown interface. From what I could tell, has something to do with HiLink devices, but doesn't apply to us. Even on Windows I saw the Partner Software send an ''AT^DDSETEX=2'' when dialing. So, the DIAG port is, as far we know, the most important piece to this puzzle. |
| | |
| | **tl;dr:** //The audio PCM data goes through the DIAG port and you need to do is pipe it out through aplay as well as pipe it in via arecord, for the microphone to work//. |
| | |
| | ===== In practice ===== |
| | |
| | Now, it's time to get practical. I won't absolutely dive into details here because the main reason I'm writing this is for myself, in the future. But, if you're not me, doesn't hurt to Google it up or read some of the references I left down below. |
| | |
| | First thing, ''screen /dev/ttyUSB0'', which is, mostly likely, the MODEM port (you might be in for some trial and error, here, as I already said enough times). Query it up: send in an simple ''AT'' commando. It should reply with ''OK''. If it doesn't do this, this is the DIAG port, which is important but not yet. |
| | |
| | Next, you need to find out if your dongle supports voice, so do as follows: |
| | <code> |
| | AT^CVOICE? <- The command you should send |
| | ^CVOICE: 0, 8000, 16, 20 <- The answer |
| | |
| | OK <- The standard answer to any successful command |
| | </code> |
| | |
| | Write down the second and the third numbers. They'll be important very soond. |
| | |
| | At this point, you are pretty much all set to place a call (given it's registered on the network, which you can check by UNIX cli: ''mmcli -m 0'' -- not always 0, but you can check with ''mmcli -l''). But, first, you need to make sure this audio hits your ears, so, according to [3], do this: |
| | |
| | * ''sudo cat /dev/ttyUSB1 | aplay -f S16_LE'' |
| | * ''sudo arecord -f S16_LE /dev/ttyUSB1'' |
| | |
| | Both of those commands hangs the terminal, so you may want to open two terminals, use screen or whatever. Too lazy to explain. Also, running as root, you may run into a issue with the audio input/output. In this case, maybe it's sufficient to specify the device, like ''-D "hw:1,0"'' or whichever seems to be the right one. |
| | |
| | Then, you come back to the MODEM port console. The important commands are: |
| | |
| | * ''AT^DDSETEX=2'', which you need to issue everytime you call (because, by default, it routes the PCM data to the oblivion or the non-working mysterious PCVOICE port, //dunno//); |
| | * ''ATD[phonenumber];'' (the semicolon is very important, trust me... Otherwise you get ''NO CARRIER'' answers) |
| | * ''AT+CHUP'' to hang up on the call. |
| | |
| | FIXME I'll get this tutorial done later, because my aunt is calling me to help her with the groceries. |
| | |
| | ===== References ===== |
| | |
| | * [1] [[wp>Hayes_Command_Set|Hayes Command Set on Wikipedia]] |
| | * [2] {{ :huaweicdma_at.pdf |Huawei CDMA Datacard AT Command Interface}} (Really important document about special commands for most 3G Huawei cards) |
| | * [3] https://askubuntu.com/questions/464661/way-to-call-through-huawei-modem-in-14-04-e303 |
| | * [4] https://stackoverflow.com/questions/8367864/how-make-use-of-the-voice-api-to-make-calls-using-huawei-3g-modems |
| |
| |
