[Freeswitch-users] SIM7100 LTE modem with USB audio

Anthony Minessale anthony.minessale at gmail.com
Sat Aug 5 15:12:38 UTC 2017


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.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
>>
>
> _________________________________________________________________________
> 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

https://www.youtube.com/watch?v=oAxXgyx5jUw
https://www.youtube.com/watch?v=9XXgW34t40s
https://www.youtube.com/watch?v=NLaDpGQuZDA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170805/41037372/attachment-0001.html>


More information about the FreeSWITCH-users mailing list