Hello guys. First of all - hello to you all nice community. I am sorry i started a new thread here, instead of joining the original one at http://lists.freeswitch.org/pipermail/freeswitch-users/2017-August/127153.ht... I coincidentally started thinking about this thing some days ago. i enjoyed a lot using FreeSwitch with some Huawei Dongles, and i can say it worked with Huawei E173, Huawei E3531 and maybe others. There where some problems, like DTMF not working properly with all dongles, but voice could be heard. But the most important problem, to me at least, was instability. After some time of operation, the modem did ring but FS didn't notice, or outgoing call did get stuck in some strange way. I decided to let things go at that time, but now something new happened: ModemManager project: https://www.freedesktop.org/wiki/Software/ModemManager/ operated by very nice and cool people, implemented support for voice in modems supporting it. I didn't look deep enough, but I think it's handling only initializzation and preparation tasks in general. I tought it would be cool to let FreeSwitch use ModemManager, for various reasons. 1 - They did all the work of preparing udev rules for different hardware, and they ship them in an elegantly packaged and proper way. 2 - They support a lot of different modems, with related firmware kludges and workarounds. 3 - Most importantly, they offer unified APIs to control the modem they support, over a DBUS interface. I think this would bring FS support for voicemodems to the next level, for various reasons. The first and most important one being robustness: since ModemManager handles tricky devices from long time now, and has undergone a good development and bugfixing time by now. The second thing to consider is the fact that it will allow us to use our modems in a more advanced way. Some modems offer native-level functionalities like SMS handling and other things via protocols like QMI: and using those functionalities this way could be very interesting, especially considering the buggyness some firmwares can exhibit when the modem is interfaced with situations that Windows drivers / Vendor software did not think about. I a very new to FS, both from a user perspective, and even more from a developer one: so i started a cursory look at what's happening in the FS eventing system. I didn't read further. Still, I was thinking about the following steps: 1 - Implementing a DBUS->FS gateway module, allowing for modules inside FS to listen and react fo dbus events. this would be necessary to allow us to talk to ModemManager, which talks via dbus. I don't know if this already exist: but I think it could be useful even for other situations. 2 - Isolating audio processing in one module. i noticed this is already in progress, good job guys! And thanks. 3 - Reimplementing something like mod_gsmopen, that talks via DBUS with ModemManager and interfaces with FS, allowing for call setup/teardown, SMS handling and so on. I know I know: ModemManager is an external process and is a piece of complex software. But following a little bit the development via the repository and playing with different modems, I can tell you there are good reasons for this. And companies building those hardware are not known for standardizzing things so much: and the amount of work to be done isn't small by no mean. I think we should try to do it only once if possible, with incremental develpment / fixes. FS is known for it's reliability and robustness: and building something reliable and robust is fundamental I think. I couldn't convince myself about 3G/4G modems firmwares being robust pieces of software, also due to their complexity. I think we should join our effort. Enrico