<div dir="auto"><br></div><div dir="auto">Maybe a dictionary of abstract commands to translate to the vendor specific like procomm used to do.</div><div dir="auto"><br></div><div dir="auto">Then only issue the abstract commands from the high level and allow it to translate.</div><div dir="auto"><br></div><div dir="auto"> </div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div>On Thu, Aug 3, 2017 at 9:24 AM Stanislav Sinyagin <<a href="mailto:ssinyagin@gmail.com">ssinyagin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Aug 3, 2017 at 3:51 PM, Tihomir Culjaga <<a href="mailto:tculjaga@gmail.com" target="_blank">tculjaga@gmail.com</a>> wrote:<br>
> how are you going to instruct mod_ttyusb_audio top open audio channel on a<br>
> specific tty ? are you planing to provide the api in ESL ?<br>
<br>
a command like "ttyusb connect /dev/ttyUSB3 <uuid>"<br>
<br>
before that, a command "ttyusb device /dev/ttyUSB3 8000 L16" would<br>
tell the module what codec to use.<br>
<br>
After the call is finished, issue "ttyusb disconnect /dev/ttyUSB3", or<br>
it would disconnect automatically when the channel is destroyed.<br>
<br>
<br>
>> Once it's done, the signaling could be done either within FreeSWITCH,<br>
>> or in an outside ESL daemon. An external daemon would allow more<br>
>> flexibility, but there's a burden of running one more process.<br>
><br>
><br>
> although it can be much more flexible and faster using an external ESL<br>
> daemon, i'd prefer to make it in FreeSWITCH as a module ... e.g. mod_hayes<br>
<br>
the commands are very different for different vendors (I compared<br>
Huawei against Simcom, and it's a lot of difference), so there should<br>
be some vendor-specific extensions. Either a rich XML file defining<br>
the whole dialogue, or a per-vendor module in FreeSWITCH. Difficult to<br>
say, I'm not that far yet.<br>
<br>
>> In regards to udev rules -- you actually don't need them. The logic of<br>
>> finding the modem and matching it against IMEI and IMSI is already in<br>
>> mod_gsmopen (was that Giovanni who implemented it?). It just needs a<br>
>> bit of improvement in making it more vendor-independent. Also I would<br>
>> do matching on IMEI OR IMSI, not the AND condition that is in the<br>
>> module currently.<br>
>><br>
> are we sure IMEI and/or IMSI will always present ?<br>
<br>
yes, as per GSM standard. But again, commands retrieving them are<br>
different between vendors. And anyway, that would only be one method<br>
of selecting a device. There should always be a way to point to a<br>
specific ttyUSB device explicitly.<br>
<br>
>> I actually do have a set of udev rules, they are in fact needed for<br>
>> data connection:<br>
>> <a href="https://github.com/ssinyagin/wwan_udev_rules" rel="noreferrer" target="_blank">https://github.com/ssinyagin/wwan_udev_rules</a><br>
>> But they fail if you have more than one modem, and here's an explanation:<br>
>><br>
>> <a href="https://txlab.wordpress.com/2017/05/19/two-lte-modems-with-pc-engines-apu3/" rel="noreferrer" target="_blank">https://txlab.wordpress.com/2017/05/19/two-lte-modems-with-pc-engines-apu3/</a><br>
><br>
><br>
> this is specific HW :=) .. im positive there is a work around this problem<br>
<br>
no, this is a generic problem, and a solution for a specific host hardware.<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬<div><br><div>☞ <a href="http://freeswitch.org/" target="_blank">http://freeswitch.org/</a>  ☞ <a href="http://cluecon.com/" target="_blank">http://cluecon.com/</a>  ☞ <a href="http://twitter.com/FreeSWITCH" target="_blank">http://twitter.com/FreeSWITCH</a></div><div><div>☞ <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch ☞ <u><a href="http://freeswitch.org/g+" target="_blank">http://freeswitch.org/g+</a></u><br><br></div><div>ClueCon Weekly Development Call <br></div><div>☎ <a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a>  ☎ +19193869900 </div><div><br></div></div></div><div><a href="https://www.youtube.com/watch?v=oAxXgyx5jUw" target="_blank">https://www.youtube.com/watch?v=oAxXgyx5jUw</a><br></div><div><a href="https://www.youtube.com/watch?v=9XXgW34t40s" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">https://www.youtube.com/watch?v=9XXgW34t40s</a></div><div><a href="https://www.youtube.com/watch?v=NLaDpGQuZDA" target="_blank">https://www.youtube.com/watch?v=NLaDpGQuZDA</a><br></div></div></div></div></div></div></div></div></div>