[Freeswitch-users] SIM7100 LTE modem with USB audio

Enrico Mioso mrkiko.rs at gmail.com
Sat Aug 5 16:41:47 UTC 2017


Hello Stanislav,
Hello Anthony
and all of you reading this message.

First of all Stanislav, let me say I would like very very much to see a 
device like that. For me ordering this over the net is a problem for now, 
but when the device will be ready let me know, and we may arrange for a 
solution.

I think Anthony is right: ModemManager is an abstraction layer, allowing 
you to interface with the modem over DBUS calls, or listening for 
modem-related events.
Choosing this approach would have some disadvantages, this is not to be 
forgotten: like gaining some dependencies that could make life a little 
bit more complicated in an embedded environment.
Still, I think this is justifiable in the long term.
First of all, this would allow us to support a lot of already existing 
hardware out there: from Huawei dongles with Voice capabilities to ZTE 
ones (there are some with Voice Capabilities) and so on. I think this 
could be very important and help some newcomers to enjoy FreeSwitch even 
on commodity hardware.
Then, regarding alternatives: I can think of
oFono: https://github.com/rilmodem/ofono
(not sure this is the main repo or a fork)
and wader: https://github.com/andrewbird/wader
(not sure this is the main repo or a fork).

Basically, I think we need a RIL. I am not a fan of big complex software, 
but an abstraction layer is very much needed I think.

thank you all for your work,
Enrico


On Sat, 5 Aug 2017, Anthony Minessale wrote:

> Date: Sat, 5 Aug 2017 17:12:38
> From: Anthony Minessale <anthony.minessale at gmail.com>
> Reply-To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> Subject: Re: [Freeswitch-users] SIM7100 LTE modem with USB audio
> 
> 
> It sounds to me like modemmanager is an abstraction layer for the i/o and
> the signaling so an ideal componet of the first effort.
> 
> 
> 
> On Sat, Aug 5, 2017 at 9:44 AM Stanislav Sinyagin <ssinyagin at gmail.com>
> wrote:
>       well, I would say, once mod_ttyusb_audio is available and
>       stable, there may be various ways to handle the signaling, and
>       MoidemManager might be one of them.
> 
> As it's vacations time, I didn't yet approach potential sponsors, so I
> can't say how fast that will go. At the moment I'm spending 1-2 hours
> a week on it.
> 
> By the way, I'm in talks with one of Chinese ARM board makers, to
> build an appliance with mPCIE slot and metal enclosure with antenna
> mounts. It would be in the range of $50 and would run a modern Linux
> kernel (most probably the one maintained by Armbian team). So, we may
> eventually build a FreeSWITCH-based LTE voice gateway as an
> alternative to all those Asterisk-based boxes, most of which are not
> even open-source.
> 
> 
> 
> 
> On Sat, Aug 5, 2017 at 4:51 AM, Giovanni Maruzzelli
> <gmaruzz at gmail.com> wrote:
>       In a separate mail thread, Enrico Mioso (
>       mrkiko.rs at gmail.com ) just proposed an interesting
>       approach toward a new generic voicemodem endpoint, and
>       asked me to "join" the two mail threads:
> 
> 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
> ml
> 
> 
> 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
> 
> 
> 
> On 3 August 2017 at 20:48, Anthony Minessale
> <anthony.minessale at gmail.com> wrote:
> 
> Maybe a dictionary of abstract commands to translate to
> the vendor specific like procomm used to do.
> 
> Then only issue the abstract commands from the high level
> and allow it to translate.
> 
>  
> 
> 
> On Thu, Aug 3, 2017 at 9:24 AM Stanislav Sinyagin
> <ssinyagin at gmail.com> wrote:
>       On Thu, Aug 3, 2017 at 3:51 PM, Tihomir
>       Culjaga <tculjaga at gmail.com> wrote:
>       > how are you going to instruct
>       mod_ttyusb_audio top open audio channel on a
>       > specific tty ? are you planing to provide
>       the api in ESL ?
>
>       a command like "ttyusb connect /dev/ttyUSB3
>       <uuid>"
>
>       before that, a command "ttyusb device
>       /dev/ttyUSB3 8000 L16" would
>       tell the module what codec to use.
>
>       After the call is finished, issue "ttyusb
>       disconnect /dev/ttyUSB3", or
>       it would disconnect automatically when the
>       channel is destroyed.
> 
>
>       >> Once it's done, the signaling could be done
>       either within FreeSWITCH,
>       >> or in an outside ESL daemon. An external
>       daemon would allow more
>       >> flexibility, but there's a burden of
>       running one more process.
>       >
>       >
>       > although it can be much more flexible and
>       faster using an external ESL
>       > daemon, i'd prefer to make it in FreeSWITCH
>       as a module ... e.g. mod_hayes
>
>       the commands are very different for different
>       vendors (I compared
>       Huawei against Simcom, and it's a lot of
>       difference), so there should
>       be some vendor-specific extensions. Either a
>       rich XML file defining
>       the whole dialogue, or a per-vendor module in
>       FreeSWITCH. Difficult to
>       say, I'm not that far yet.
>
>       >> In regards to udev rules -- you actually
>       don't need them. The logic of
>       >> finding the modem and matching it against
>       IMEI and IMSI is already in
>       >> mod_gsmopen (was that Giovanni who
>       implemented it?). It just needs a
>       >> bit of improvement in making it more
>       vendor-independent. Also I would
>       >> do matching on IMEI OR IMSI, not the AND
>       condition that is in the
>       >> module currently.
>       >>
>       > are we sure IMEI and/or IMSI will always
>       present ?
>
>       yes, as per GSM standard. But again, commands
>       retrieving them are
>       different between vendors. And anyway, that
>       would only be one method
>       of selecting a device. There should always be
>       a way to point to a
>       specific ttyUSB device explicitly.
>
>       >> I actually do have a set of udev rules,
>       they are in fact needed for
>       >> data connection:
>       >>
>       https://github.com/ssinyagin/wwan_udev_rules
>       >> But they fail if you have more than one
>       modem, and here's an explanation:
>       >>
>       >>https://txlab.wordpress.com/2017/05/19/two-lte-modems-with-pc-engines-apu3/
>
>       >
>       >
>       > this is specific HW :=) .. im positive there
>       is a work around this problem
>
>       no, this is a generic problem, and a solution
>       for a specific host hardware.
>
>       _________________________________________________________________________
>       Professional FreeSWITCH Consulting Services:
>       consulting at freeswitch.org
>       http://www.freeswitchsolutions.com
>
>       Official FreeSWITCH Sites
>       http://www.freeswitch.org
>       http://confluence.freeswitch.org
>       http://www.cluecon.com
>
>       FreeSWITCH-users mailing list
>       FreeSWITCH-users at lists.freeswitch.org
>       http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>       UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>       http://www.freeswitch.org
> 
> --
> Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬
>http://freeswitch.org/  ☞ http://cluecon.com/  ☞
> http://twitter.com/FreeSWITCH
> ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
> 
> ClueCon Weekly Development Call 
> ☎ sip:888 at conference.freeswitch.org  ☎ +19193869900 
> 
> https://www.youtube.com/watch?v=oAxXgyx5jUw
> https://www.youtube.com/watch?v=9XXgW34t40s
> https://www.youtube.com/watch?v=NLaDpGQuZDA
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> 
> 
> 
> --
> 
> Sincerely,
> 
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> --
> Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬
>http://freeswitch.org/  ☞ http://cluecon.com/  ☞
> http://twitter.com/FreeSWITCH
> ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
> 
> ClueCon Weekly Development Call 
> ☎ sip:888 at conference.freeswitch.org  ☎ +19193869900 
> 
> https://www.youtube.com/watch?v=oAxXgyx5jUw
> https://www.youtube.com/watch?v=9XXgW34t40s
> https://www.youtube.com/watch?v=NLaDpGQuZDA
> 
>


More information about the FreeSWITCH-users mailing list