[Freeswitch-dev] Project Announcement and Request for Direction
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!
I would be willing to contribute Sent from my iPhone On May 18, 2011, at 8:59 PM, Kurtis Heimerl <kheimerl@cs.berkeley.edu> wrote:
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!
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (2)
-
Kurtis Heimerl
-
Robert-iPhone