SIM7100 LTE modem with USB audio
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration. It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation. So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting). I ordered a sample, will check it out soon. cheers, stanislav
Hello Stanislav, have you had time to tinker with it? How it goes? Also, why you would prefer this one instead of the already supported ones? -giovanni On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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
Hi Giovanni, I only had time to configure it for Internet access: https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/ The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :) I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update. On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so. Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver. Happy hacking! -giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@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
I assembled the lab, and will start digging the code tomorrow. The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings. On 25 Jul 2017 15:10, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so.
Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver.
Happy hacking!
-giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/free switch-users http://www.freeswitch.org
--
Sincerely,
Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 26 July 2017 at 01:54, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I assembled the lab, and will start digging the code tomorrow.
The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings.
Nice!!! -giovanni
I looked inside gsmopen_protocol.cpp and my eyes hurt. It has so many hardcoded vendor-specific commands, and it does not know the actual vendor that it speaks to. I really don't like adding more bad code here. I'm inclining to have a Perl daemon working the AT commands via the control UART ports, and telling FreeSWITCH take the audio channel from the audio UART port when it's ready. I think mod_portaudio should do the job after minor modifications. Then the AT command handler can be written in a modern and modular fashion, with independent modules for different hardware. Also this way we would open the door for new hardware solutions which are able to send/receive PCM via ttyUSB ports. Then, for example, one may build a hardware phone with it :) On Wed, Jul 26, 2017 at 1:54 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I assembled the lab, and will start digging the code tomorrow.
The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings.
On 25 Jul 2017 15:10, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so.
Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver.
Happy hacking!
-giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Stanislav, I like the idea! i'd prefer to have a separate module (not some perl daemon) tho. you can instruct udev to run an external program to name devices ( a simple rpc to stdout would to great ) . This way you can specify dongles (vendorID, productID, interfaceNumber, dongleSerial...) in your module config and let your module name the ttys accordingly. The module should have AT command mappings for preInit, Init, postInit, dongle_events ( incoming call, ring,...), basic commands ( answer, hangup...) exposed all in config... This is where it gets ugly (and a bit less secure), but to keep the module code sane, its better to expose AT mappings in config. Once the "signaling" is done, the module should notify mod_portaudio ( a fork of ) what audio tty it should sit on for the given call well in theory :=) i see a lot of work ahead.. On 27 July 2017 at 00:41, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I looked inside gsmopen_protocol.cpp and my eyes hurt. It has so many hardcoded vendor-specific commands, and it does not know the actual vendor that it speaks to. I really don't like adding more bad code here.
I'm inclining to have a Perl daemon working the AT commands via the control UART ports, and telling FreeSWITCH take the audio channel from the audio UART port when it's ready. I think mod_portaudio should do the job after minor modifications.
Then the AT command handler can be written in a modern and modular fashion, with independent modules for different hardware.
Also this way we would open the door for new hardware solutions which are able to send/receive PCM via ttyUSB ports. Then, for example, one may build a hardware phone with it :)
On Wed, Jul 26, 2017 at 1:54 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I assembled the lab, and will start digging the code tomorrow.
The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings.
On 25 Jul 2017 15:10, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com>
wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and
enclosure.
No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so.
Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver.
Happy hacking!
-giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com>
wrote:
Simcom has recently released a new 4G/LTE modem, and it has USB audio support. You can find sim7100_usb_audio_application_note_v0.01.pdf with details at the vendor site, or at techship.com after registration.
It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation.
So, in theory, gsmopen module may be adapted to it (or maybe a new module is worth starting).
I ordered a sample, will check it out soon.
cheers, stanislav
____________________________________________________________
Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Greetings, I started slowly outlining a new module, mod_ttyusb_audio. It will do a simple task by bridging a channel with a specified /dev/ttyUSBx PCM flow using a specified codec (All modems that I know use the same L16 at 8kHZ, but who knows what other codecs there might be). As I didn't yet find a sponsor for this development, it goes quite slowly. 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. 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. 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/ cheers, stanislav On Sun, Jul 30, 2017 at 6:08 PM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Hi Stanislav, I like the idea!
i'd prefer to have a separate module (not some perl daemon) tho.
you can instruct udev to run an external program to name devices ( a simple rpc to stdout would to great ) . This way you can specify dongles (vendorID, productID, interfaceNumber, dongleSerial...) in your module config and let your module name the ttys accordingly.
The module should have AT command mappings for preInit, Init, postInit, dongle_events ( incoming call, ring,...), basic commands ( answer, hangup...) exposed all in config...
This is where it gets ugly (and a bit less secure), but to keep the module code sane, its better to expose AT mappings in config.
Once the "signaling" is done, the module should notify mod_portaudio ( a fork of ) what audio tty it should sit on for the given call
well in theory :=) i see a lot of work ahead..
On 27 July 2017 at 00:41, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I looked inside gsmopen_protocol.cpp and my eyes hurt. It has so many hardcoded vendor-specific commands, and it does not know the actual vendor that it speaks to. I really don't like adding more bad code here.
I'm inclining to have a Perl daemon working the AT commands via the control UART ports, and telling FreeSWITCH take the audio channel from the audio UART port when it's ready. I think mod_portaudio should do the job after minor modifications.
Then the AT command handler can be written in a modern and modular fashion, with independent modules for different hardware.
Also this way we would open the door for new hardware solutions which are able to send/receive PCM via ttyUSB ports. Then, for example, one may build a hardware phone with it :)
On Wed, Jul 26, 2017 at 1:54 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I assembled the lab, and will start digging the code tomorrow.
The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings.
On 25 Jul 2017 15:10, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so.
Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver.
Happy hacking!
-giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
Hello Stanislav,
have you had time to tinker with it?
How it goes?
Also, why you would prefer this one instead of the already supported ones?
-giovanni
On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> wrote: > > Simcom has recently released a new 4G/LTE modem, and it has USB > audio > support. > You can find sim7100_usb_audio_application_note_v0.01.pdf with > details at the vendor site, or at techship.com after registration. > > It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation. > > So, in theory, gsmopen module may be adapted to it (or maybe a new > module is worth starting). > > I ordered a sample, will check it out soon. > > cheers, > stanislav > > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 31 July 2017 at 02:43, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Greetings,
I started slowly outlining a new module, mod_ttyusb_audio. It will do a simple task by bridging a channel with a specified /dev/ttyUSBx PCM flow using a specified codec (All modems that I know use the same L16 at 8kHZ, but who knows what other codecs there might be). As I didn't yet find a sponsor for this development, it goes quite slowly.
as far as i know they all use L16 so no biggie there.
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 ?
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
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 ?
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 :=)
cheers, stanislav
On Sun, Jul 30, 2017 at 6:08 PM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Hi Stanislav, I like the idea!
i'd prefer to have a separate module (not some perl daemon) tho.
you can instruct udev to run an external program to name devices ( a simple rpc to stdout would to great ) . This way you can specify dongles (vendorID, productID, interfaceNumber, dongleSerial...) in your module config and let your module name the ttys accordingly.
The module should have AT command mappings for preInit, Init, postInit, dongle_events ( incoming call, ring,...), basic commands ( answer, hangup...) exposed all in config...
This is where it gets ugly (and a bit less secure), but to keep the module code sane, its better to expose AT mappings in config.
Once the "signaling" is done, the module should notify mod_portaudio ( a fork of ) what audio tty it should sit on for the given call
well in theory :=) i see a lot of work ahead..
On 27 July 2017 at 00:41, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I looked inside gsmopen_protocol.cpp and my eyes hurt. It has so many hardcoded vendor-specific commands, and it does not know the actual vendor that it speaks to. I really don't like adding more bad code here.
I'm inclining to have a Perl daemon working the AT commands via the control UART ports, and telling FreeSWITCH take the audio channel from the audio UART port when it's ready. I think mod_portaudio should do the job after minor modifications.
Then the AT command handler can be written in a modern and modular fashion, with independent modules for different hardware.
Also this way we would open the door for new hardware solutions which are able to send/receive PCM via ttyUSB ports. Then, for example, one may build a hardware phone with it :)
On Wed, Jul 26, 2017 at 1:54 AM, Stanislav Sinyagin <
ssinyagin@gmail.com>
wrote:
I assembled the lab, and will start digging the code tomorrow.
The modem sends PCM audio via an UART USB device, just like Huawei dongles do. So, it looks like only a matter of accommodating to vendor and product codes and initialization strings.
On 25 Jul 2017 15:10, "Giovanni Maruzzelli" <gmaruzz@gmail.com> wrote:
On 23 July 2017 at 10:17, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Hi Giovanni, I only had time to configure it for Internet access:
https://txlab.wordpress.com/2017/07/23/simcom-sim7100e-lte-modem/
The benefit is mPCIe interface, so it can be placed inside and enclosure. No silly dongles any more :)
I'll tinker with voice some time later. I can also provide you SSH access if you wish to work on gsmopen update.
Please, let me know if any progress or so.
Will not be so easy to interface audio to it via USB, will need to create a kernel driver, or use a userspace USB lib and create a user space driver.
Happy hacking!
-giovanni
On 21 Jul 2017 18:36, "Giovanni Maruzzelli" <gmaruzz@gmail.com>
wrote:
> > Hello Stanislav, > > have you had time to tinker with it? > > How it goes? > > Also, why you would prefer this one instead of the already supported > ones? > > -giovanni > > > On 8 July 2017 at 21:28, Stanislav Sinyagin <ssinyagin@gmail.com> > wrote: >> >> Simcom has recently released a new 4G/LTE modem, and it has USB >> audio >> support. >> You can find sim7100_usb_audio_application_note_v0.01.pdf with >> details at the vendor site, or at techship.com after registration. >> >> It transmits 8kHZ, 16-bit PCM audio via a USB UART simulation. >> >> So, in theory, gsmopen module may be adapted to it (or maybe a new >> module is worth starting). >> >> I ordered a sample, will check it out soon. >> >> cheers, >> stanislav >> >> >> >> ____________________________________________________________
>> Professional FreeSWITCH Consulting Services: >> consulting@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@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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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.
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@gmail.com> wrote:
On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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@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@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@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
In a separate mail thread, Enrico Mioso ( mrkiko.rs@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... 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@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@gmail.com> wrote:
On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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@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@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@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@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@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
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@gmail.com> wrote:
In a separate mail thread, Enrico Mioso ( mrkiko.rs@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...
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@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@gmail.com> wrote:
On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@gmail.com> wrote:
In a separate mail thread, Enrico Mioso ( mrkiko.rs@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...
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@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@gmail.com> wrote:
On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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@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@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@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@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@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@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@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@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@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@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
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@gmail.com> Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> To: FreeSWITCH Users Help <freeswitch-users@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@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@gmail.com> wrote: In a separate mail thread, Enrico Mioso ( mrkiko.rs@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@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@gmail.com> wrote: On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <tculjaga@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@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@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@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@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@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@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@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@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@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@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
participants (5)
-
Anthony Minessale
-
Enrico Mioso
-
Giovanni Maruzzelli
-
Stanislav Sinyagin
-
Tihomir Culjaga