[Freeswitch-dev] Project Announcement and Request for Direction

[Kurtis Heimerl]

Hello Freeswitch-dev! I originally sent this email to
freeswitch-users, and didn't get a lot of responses. I thought this
might be a better list for this discussion.

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!