198 lines
12 KiB
Plaintext
198 lines
12 KiB
Plaintext
================================================================================
|
|
=== Google Summer of Code 2009 ===
|
|
=== ===
|
|
=== http://www.asterisk.org/ ===
|
|
=== ===
|
|
=== <asteriskteam@digium.com> ===
|
|
================================================================================
|
|
|
|
--------------------------------------------------------------------------------
|
|
--- Personnel ------------------------------------------------------------------
|
|
--------------------------------------------------------------------------------
|
|
|
|
Administrator: Russell Bryant
|
|
|
|
Mentors: Russell Bryant
|
|
Joshua Colp
|
|
Mark Michelson
|
|
Tilghman Lesher
|
|
Luigi Rizzo
|
|
|
|
Contact:
|
|
|
|
To get in contact with mentors or the Asterisk development community in
|
|
general, the best place is the asterisk-dev mailing list, hosted on
|
|
http://lists.digium.com/. Alternatively, many developers can be found in
|
|
the #asterisk-dev IRC channel on Freenode. The most active time for this
|
|
channel on IRC is during US business hours.
|
|
|
|
Feel free to get in contact with the development community ahead of time if
|
|
you are a student interested in applying for a project with Asterisk. We
|
|
can help explain projects proposed here, or help come up with potential
|
|
alternative project proposals.
|
|
|
|
--------------------------------------------------------------------------------
|
|
--------------------------------------------------------------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
--- Project Ideas --------------------------------------------------------------
|
|
--------------------------------------------------------------------------------
|
|
|
|
1) There are a number of projects that fall into the category of improving and
|
|
creating new interfaces for developers to interface with Asterisk. To get a
|
|
bit of an idea for the higher level vision of this effort, see the following
|
|
wiki page: <http://astridevcon.pbwiki.com/Codename-Pinemango/>.
|
|
|
|
Some insight regarding the motivation for this overall effort is captured
|
|
in this mailing list post, written by Brian Degenhardt.
|
|
|
|
- http://lists.digium.com/pipermail/asterisk-dev/2008-October/034700.html
|
|
|
|
Specific project ideas in this area are listed here:
|
|
|
|
a) Create a generic "data get" layer for Asterisk components to be able to
|
|
expose data that they maintain. Currently, modules implement specific
|
|
code to implement CLI commands, manager interface actions, and so forth,
|
|
while it would be much nicer to have this data available through a common
|
|
interface. For example, SNMP support has been added to Asterisk but is
|
|
limited in what it can expose due to the lack of this interface. This
|
|
project would be to create the infrastructure for this data layer and some
|
|
uses to prove its functionality. Then, various parts of Asterisk could
|
|
be converted as time permits. Note that this may end up sharing some code
|
|
with the "data put" interface in part b.
|
|
|
|
b) Create a generic "data put" layer for Asterisk components to allow
|
|
external interfaces to update configuration items, as opposed to having
|
|
to issue a full configuration reload to account for a single change.
|
|
This project would involve writing the infrastructure and some basic usage
|
|
to prove its functionality. Various parts of Asterisk could be converted
|
|
as time permits. Note that this may end up sharing some code with the
|
|
"data get" interface in part a.
|
|
|
|
c) Improve the performance of cache handling in the event core. The event
|
|
API in Asterisk provides a generic interface for subscribing to and
|
|
publishing asynchronous events. It also provides a caching mechanism for
|
|
events that represent state changes. So, to find out a state, you can
|
|
pull it out of the event cache. For example, the state of devices as used
|
|
for presence is handled using this mechanism. The data structures
|
|
currently used for maintaining the cache are not optimal for performance
|
|
when the cache gets large. This project would be to write code to
|
|
benchmark the performance of the caching mechanism, and then implement a
|
|
new storage mechanism that is more efficient.
|
|
|
|
d) Develop a method for federating Asterisk servers using distributed events
|
|
with a transport suitable for communication beyond a LAN. The current
|
|
event infrastructure includes ways to hook in and distribute events
|
|
between servers. There is a module which implements this, res_ais, but
|
|
it is only suitable for federating servers on a high speed LAN. This
|
|
project would be to implement a new event distribution module using a
|
|
protocol such as XMPP, or something else if deemed appropriate.
|
|
|
|
e) Implement a method that makes it very easy to add synchronous hooks
|
|
throughout the code base. Hooks are arbitrary callbacks within the
|
|
internals of asterisk where external components can modify asterisk's
|
|
behavior. While the dialplan allows applications to control much of the
|
|
asterisk behavior, hooks allow for business logic to be applied to
|
|
situations that are not associated with a call (eg: a sip registration
|
|
hook could allow time-governed registration period), or for situations
|
|
that occur during the execution of a dialplan application (eg: codec
|
|
negotiation hook to apply business logic to codecs proposed in the middle
|
|
of a Dial command, or a transfer hook to execute business logic when a
|
|
SIP REINVITE is received).
|
|
|
|
f) Asterisk has a relatively new generic asynchronous event API. While it
|
|
has been implemented in several areas of the code base, one place where
|
|
it has not been utilized but would make a great fit would be to replace
|
|
the legacy code used for generating events on the Asterisk Manager
|
|
Interface (AMI). The first phase of this project would be to go through
|
|
the code base and generate new generic Asterisk events in places where
|
|
manager events are generated today. That means that those events would
|
|
be available to any part of Asterisk that would be interested in doing
|
|
something with them in a binary format as opposed to a big string.
|
|
|
|
As time permits, a second phase to this project would be to either write
|
|
a new socket based interface that exposes the generic event API, or to
|
|
modify the existing manager interface to use the ast_event API to handle
|
|
receiving events from inside of Asterisk to send to manager clients.
|
|
|
|
2) This section contains projects related to Voicemail support in Asterisk.
|
|
|
|
a) Extract the support for storage backends into an API to reduce code
|
|
complexity and its ability to be reused. The current Asterisk voicemail
|
|
application supports storing voicemail on the filesystem, in a database
|
|
via ODBC, and on an IMAP server. All of the storage code should be pulled
|
|
out into a form such that it makes the current app_voicemail easier to
|
|
maintain, but also allows the backend storage code to be used in a next
|
|
generation voicemail implementation, or potentially other things in
|
|
Asterisk that would like to use these interfaces.
|
|
|
|
b) One feature that has been widely desired for Asterisk voicemail is the
|
|
ability to customize menu layout. This project would be to improve
|
|
existing code, or develop a new voicemail application that supports
|
|
customizable menu layout. The app_minivm module currently in Asterisk
|
|
is one way of approaching this project, which is to break up current
|
|
Voicemail functionality into smaller applications to make it easier to
|
|
build a custom voicemail system in the dialplan. Luigi Rizzo had a
|
|
student work on a project to create a new voicemail system that included
|
|
these features that has some work left to be completed.
|
|
|
|
3) This section includes projects related to improving the Asterisk console and
|
|
logging interfaces.
|
|
|
|
a) Improve the way "verbose logging" works in Asterisk. Currently, the
|
|
Asterisk console and logging system only supports a single verbose level.
|
|
However, it would be extremely useful to allow a verbose setting per
|
|
console, and per log file that verbose output is being sent to.
|
|
|
|
b) Improve Asterisk logging such that advanced filtering is available at the
|
|
console so that output related to a single call is available without
|
|
having to see the output for other calls. Lack of support for debugging
|
|
individual calls has been a long standing difficulty for Asterisk
|
|
administrators on busy systems.
|
|
|
|
c) In addition to being used as an administrative interface, the Asterisk
|
|
console can also be used for making calls using the system audio and
|
|
video interfaces. In this sense, Asterisk can be used as a highly
|
|
configurable console based soft phone. Luigi Rizzo and some of his
|
|
students have put a lot of work into adding video support to the Asterisk
|
|
console when being used as a softphone. This project would be to work
|
|
with Luigi to continue this effort to improve the GUI that opens up for
|
|
handling calls. This would involve adding some buttons to handle calls
|
|
and contact lists, controlling the active audio source for a call, and
|
|
adding standard telephone buttons.
|
|
|
|
4) This section includes projects related to internationalization.
|
|
|
|
a) One of the projects that Luigi Rizzo previously worked on was replacing
|
|
the "say.c" code that implemented language support for saying dates and
|
|
times in C code, with an implementation that allows additional languages
|
|
to be added via a configuration file with special syntax. This project
|
|
would be to work with Luigi to enhance this code to better handle
|
|
languages where words change in multiple ways depending on gender and
|
|
number, and also adding more languages to the sample configuration file
|
|
that is distributed with Asterisk.
|
|
|
|
5) This section includes projects related to portability to other operating
|
|
systems.
|
|
|
|
a) Asterisk has been ported to cygwin a couple of times over the years, but
|
|
tends to bitrot due to lack of continued support by developers. This
|
|
project would be to revisit the current state of cygwin support and get
|
|
it working well in Asterisk 1.6. It should already compile, or be very
|
|
close to it. However, there is some testing to be done to ensure that
|
|
things work properly. Also, it would be most excellent to get a console
|
|
channel driver functioning in cygwin (chan_oss, chan_console, etc.).
|
|
|
|
6) There are a number of potential projects that could be done to improve
|
|
security in Asterisk. A document that lists some of the security challenges
|
|
currently faced and some ideas for improvements that could be made can be
|
|
found in the following document:
|
|
|
|
http://astridevcon.pbwiki.com/Network-Security-Framework
|
|
|
|
--------------------------------------------------------------------------------
|
|
--------------------------------------------------------------------------------
|
|
|
|
================================================================================
|
|
================================================================================
|