[Freeswitch-users] Project Announcement and Request for Direction

jesse chat2jesse at gmail.com
Sun May 22 11:13:55 MSD 2011


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


More information about the FreeSWITCH-users mailing list