[Freeswitch-users] SIM7100 LTE modem with USB audio

Sat Aug 5 14:43:02 UTC 2017

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.html
>
>
> 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+
>> <http://freeswitch.org/g+>*
>>
>> ClueCon Weekly Development Call
>> ☎ sip:888 at conference.freeswitch.org  ☎ +19193869900
>> <%28919%29%20386-9900>
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170805/2c1ad98f/attachment-0001.html>