On 02/01/2020 22:56, Harald Welte wrote:

This is pretty much what I had in mind, too - although not specifically for wardialing, but simply for any use case.

Yes, we also realized that focusing our current and past effort on trying to get a working "voip-modem" is much helpful than making a "voip wardialer" (because, for example, beave's iWas could work fine exposing a pty with basic AT emulation).

...

The design is a bit "creative" but it's done a way to make the "Software DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a local asterisk).

As you can see at http://osmocom.org/projects/linmodem/issues I had the plan to do this based on the linmodem code from Fabrice Bellard (who needs no introduction). The code implements more different modems/standards than the asterisk code, and it's not really tied to the winmodem hardware - it simply consumes and produces 16bit samples, so all that's needed to attach it to RTP is to do the aLaw/uLaw table lookup.

I think that yours is "the right approach" from a technical standpoint of view.

What we tried to achieve is "something working" by gluing together all of the pieces, leaving for another pizza-hackaton improvements and stabilization.

It's *likely* that Asterisk-Softmodem doesn't provide the performance and stability we want (sometime is connect, sometime it does not connect, sometime it gives your garbage, anyhow still missing CONNECT and reporting of negotiated carrier speed).

So the world still miss the missing piece of a features voip-modem that also provide a pty.

I added osmcom linmodem to the "Software Modem" section https://github.com/x25today/voipwardialer#software-modem .

But hey, my approach is still vapourware and yours is implemented, so who am I to make suggestions.

We're working to try to make this working with a commandline and extendit piece by piace, but really without the real telecommunication-grade effort-and-skills to fix the DSP problem properly, assuming that someone with that knowledge will help in hooking one of the cool and complete softmodem.

Linmodem is surely a way to go, we also spotted this nice soft-modem that by reading the specs seems very very interesting for it's integration opportunity (connecting pty and audio i/o) and the careful timing consideration https://github.com/randyrossi/fisher-modem .

Did you ever saw / considered this?

-naif

Hi Harald,

while there are many testing that must yet be done, surely Linmodem and/or Fisher-Modem are much more complete DSP than Asterisk-Softmodem.

So, reaching the stage where one of the two get integrate directly, make much more sense.

I built both C softmodem and saw their command line, requiring as input a "dsp" .

Now i've opened this ticket:

Test integration of Linmodem & Fisher-Modem into the VoIP Wardialer trough PJSUA and Alsa hacking https://github.com/x25today/voipwardialer/issues/16

The idea is that we may try to use those Softmodem by playing with the Alsa Loopback interface having:

- 1 Audio virtual audio device for a normal VoIP Modem (being our pjsua or other stack or even a graphical client)

- 1 Audio virtual audio device for the Softmodem command line (for easier testing)

Those crossed trough Alsa Loopback interface, but formally each having it's own audio device.

Did you considered for testing something like this? As it could be a quick and dirty hacking approach, yet to be tested

-naif

On 03/01/2020 11:08, Harald Welte wrote:

Thanks. I didn't know it, but it also seems to only implement slower speeds and not [what I find more interesting] V.34 and/or V.90. Also, the fact that it's already multi-threading seems a bit odd to me. In the end, the modem is nothing but a process that consumes samples and produces characters in the Rx side, and the inverse for the transmit side. Having a kind of library of C functions for this (like linmodem) seems most natural to me. But hey, that's a matter of personal taste.

Regards, Harald