<p>Leveraging freeswitch event socket & customized module can accomplish all your goals.</p>
<div class="gmail_quote">On May 16, 2011 7:51 AM, "Kurtis Heimerl" <<a href="mailto:kheimerl@cs.berkeley.edu">kheimerl@cs.berkeley.edu</a>> wrote:<br type="attribution">> Hello Freeswitch Users!<br>> <br>
> My name is Kurtis Heimerl, and I'm a graduate researcher at the<br>> University of California, Berkeley in the Technology and<br>> Infrastructure for Emerging Regions (TIER) group under Eric Brewer.<br>> We're currently investigating the use of OpenBTS<br>
> (<a href="http://openbts.sourceforge.net/">http://openbts.sourceforge.net/</a>) for providing cellular coverage via<br>> low-cost base stations in low-density parts of the world. This project<br>> is called The Village Base Station. In support of that project, we're<br>
> also investigating the use of Freeswitch to support OpenBTS and<br>> provide a flexible, extensible, and simple platform for deploying<br>> voice/sms/data applications on the basestation itself. Towards this<br>
> end, I'm asking you, the freeswitch community, for advice and<br>> direction on some of our research goals.<br>> <br>> The basic story is simple. OpenBTS uses a software radio and generic<br>> PC to provide cellular service. As a byproduct of this architecture,<br>
> we also gain the ability to run freeswitch applications "locally"<br>> (concurrently with OpenBTS), and take advantage of the benefits this<br>> tight coupling provides us. These benefits are numerous; calls/SMS<br>
> between BTS users can be much cheaper, as they do not use any backhaul<br>> bandwidth. Applications can query the system for more information<br>> about users, such as location or status. As an example, unlike<br>
> traditional GSM telephony applications, we are able to query if users<br>> are currently available on the network. This could be used to create<br>> voice "chat lists", which tell participants which of their friends are<br>
> currently within cellular range.<br>> <br>> We foresee 6 features required to support these "local" freeswitch<br>> applications on our OpenBTS system. I'm very curious how the<br>> freeswitch community feels about these possible additions, as well how<br>
> they might be implemented.<br>> <br>> There are a few that are already available in freeswitch, but may be<br>> rougher than we would like. These include:<br>> <br>> 1) Identity: The ability to query for user's status, numbers, etc.<br>
> This seems simple enough in the existing system. However, we'd like to<br>> provide hooks for applications to act on these sign-ons or offs. For<br>> instance, an app may hold messages until a phone logs onto the system<br>
> and push them then. My understanding is that this should be simple,<br>> probably hooking onto "SIP presence" events?<br>> 2) Storage: Freeswitch currently seems to support only per-application<br>> storage, with limited support for cross-application storage (mostly<br>
> user directories). This is occasionally problematic: one issue we've<br>> heard is that it is difficult to place messages into voice mailboxes<br>> from other apps. We'd like a more unified storage framework. Or...<br>
> 3) "Pipes": This is the ability to pass messages between freeswitch<br>> apps. This seems pretty well supported though simple dialplan<br>> interactions, though the modules themselves may not provide enough<br>
> functionality. Is there a way to do this inside of apps? I consider<br>> this an alternative to the storage framework discussed in #2<br>> <br>> Lastly, there are three functions we don't believe are well-supported<br>
> in freeswitch. These are...<br>> 1) Privacy: We expect our BTS to be used in politically sensitive<br>> areas. Given this, freeswitch could provide an anonymity layer,<br>> providing short term phone/SMS numbers, or directing communications<br>
> through more secure layers (e.g., Tor).<br>> 2) Asynchrony: While freeswitch seems to support basic asynchrony<br>> though its event system, I couldn't find any way to delay events for<br>> indeterminate times. For instance, we may want to schedule a traffic<br>
> warning for 1PM every Wednesday to every phone currently on the<br>> system. Is there a way to do that currently?<br>> 3) SMS: Freeswitch seems to currently support SIP chat messages (using<br>> SIMPLE?). We need to either extend OpenBTS to speak SIMPLE, or extend<br>
> freeswitch to speak OpenBTS's SMS protocol. Neither seems particularly<br>> difficult. This will allow our apps to send and receive both voice and<br>> SMS messages from users.<br>> <br>> We believe these core functions will enable a wide variety of BTS<br>
> applications. I have a laundry list of those, but I'll omit them for<br>> sake of space.<br>> <br>> If any members of the community (that means you!) have any directions,<br>> ideas, projects, or thoughts, please pass them on! We're just<br>
> beginning this part of the project, and getting the lay of the land.<br>> Feedback is critical at this point.<br>> <br>> Thanks!<br>> <br>> _______________________________________________<br>> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>> <a href="http://www.freeswitch.org">http://www.freeswitch.org</a><br>
</div>