[Freeswitch-users] Project Announcement and Request for Direction

[Roger Castaldo]

In my humble opinion and experience with writing an application to interface
into freeswitch, it sounds as if a centralized deployment server sending out
xml responses to the module that allows for freeswitch to be configured
remotely ( I believe its called mod_curl or xml_rpc something like that I
cannot remember) would solve a couple of items on the list.  As for the
other items, one suggestion I would like to make is to run something
independent of freeswitch that links into the event socket, this would allow
you to implement something to handle most if not all of the features without
a need to add some things to freeswitch.  The event socket from my
experience has been quite the effective API, as well as it is quite
effective for gathering messages from the system itself.  Something along
those lines would allow you to "pipe" items between multiple servers.

On Sat, May 14, 2011 at 6:47 PM, 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/20110516/232e0592/attachment.html