[Freeswitch-users] SIM7100 LTE modem with USB audio

Sat Aug 5 02:51:48 UTC 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170805/45baebdc/attachment-0001.html>