<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><FONT size=3>FYI here is the newly updated README
from the experimental directory. The first section explains the purpose of the
directory.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT size=3>g-)</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT size=3></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>The Purpose of The Experimental
Directory<BR>=========================================<BR>The experimental
directory has been created to lower the threshold for adding <BR>new code to
SER, while keeping the main code tree robust. Experimental exists <BR>both
in CVS head (the main development branch), as well as in release branches
<BR>(ex. rel_0_9_0). </FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>In the CVS head, experimental can be
used for patches to the main code tree, <BR>as well as for modules that extend
SER's functionality. Any code will be <BR>excepted, provided that the code
give some generic value and one or more <BR>developers are willing to maintain
the code. Code that proves itself popular <BR>and stable will be moved to the
main code tree.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>In a release branch, experimental can
be used to add new functionality to an<BR>already released version. Code will
never be allowed into the main code tree<BR>(because the code has been freezed),
but people can add experimental features<BR>to the stable release. This way
limited functionality can be added without <BR>having to use the CVS head, which
will have lots of (possibly untested)<BR>functionality added. Often
modules that have been developed for CVS head will <BR>be "backported", i.e.
made to work with a previous, stable version. Also, some<BR>developers may use a
stable release and have developed a module for that version.<BR>This module can
be submitted to experimental of a released version to facilitate<BR>the
introduction of the new code into SER. (NOTE that ALL code submitted to a
<BR>stable version MUST be ported to also work with CVS head. Allowing a module
only<BR>into the experimental directory of a stable release is just time-limited
until <BR>porting has been done.)</FONT></FONT></DIV>
<DIV> </DIV><FONT face=Arial size=2><FONT size=3>
<DIV><BR>What You Will Find in
Experimental<BR>==================================<BR>The experimental directory
may contain three types of code:<BR>1. *Simple modules* that can be dropped into
main code tree<BR>2. *Complex modules* that require patching of the main
tree<BR>3. *Code patches* (no module) that modify the core to accomplish new
functionality</DIV>
<DIV> </DIV>
<DIV>Submitting Bug Reports<BR>======================<BR>For experimental code
to enter the main code tree, it needs to be used, tested,<BR>and bugs/feature
requests most be reported. If you use code from the
experimental<BR>directory,remember that the code maintainer will love to hear
about your <BR>experiences! Contact the code maintainer directly (see
information below).</DIV>
<DIV> </DIV>
<DIV>If you have found a bug or have a feature request, please use:<BR><A
href="http://bugs.sip-router.org/">http://bugs.sip-router.org/</A> </DIV>
<DIV> </DIV>
<DIV>=============================<BR>Description of
Modules:<BR>=============================</DIV>
<DIV> </DIV>
<DIV>path module, simple module<BR>-----------<BR>COMMENT:The path module has
been ported into the main code tree by Andreas Granig.<BR>This module will thus
be removed as this effort has been finished.</DIV>
<DIV> </DIV>
<DIV>Maintainer: Fermin Galan Marquez <<A
href="mailto:fermin.galan@agora-2000.com">fermin.galan@agora-2000.com</A>></DIV>
<DIV> </DIV>
<DIV>This module implements the Session Initiation Protocol (SIP)
Extension<BR>Header Field for Registering Non-Adjacent Contacts, as described in
RFC<BR>3327</DIV>
<DIV> </DIV>
<DIV>tls, code patches<BR>----------<BR>Maintainer: Cesc Santasusana <<A
href="mailto:cesc.santa@gmail.com">cesc.santa@gmail.com</A>><BR>TLS is an
optional part of the core, not a module. TLS, as defined in SIP RFC, <BR>is a
mandatory feature for proxies and can be used to secure the SIP signalling<BR>on
a hop-by-hop basis (not end-to-end). TLS works on top of TCP (DTLS, or TLS
<BR>over UDP is already defined by IETF and may become available in the
future).</DIV>
<DIV> </DIV>
<DIV>usrloc-cl module<BR>-----------<BR>COMMENT: This module is currently only
found in rel_0_9_0 branch. Work is in <BR>progress to port the module to CVS
head.<BR>Maintainer: Andreas Granig <<A
href="mailto:agranig@linguin.org">agranig@linguin.org</A>></DIV>
<DIV> </DIV>
<DIV>This is a cacheless implementation of the usrloc API and replaces the
original<BR>usrloc module. It provides access to domain tables (like location
and aliases)<BR>to other modules. The module exports no functions that could be
used directly<BR>from scripts.</DIV>
<DIV> </DIV>
<DIV>The typical use case for this module over the original usrloc module is
that<BR>one wants to replicate the tables on the database layer without the need
of SIP<BR>replication. This allows better scalability at the cost of
performance.</DIV>
<DIV> </DIV>
<DIV>osp module<BR>----------<BR>COMMENT: The maintainer is currently working on
packaging the code for <BR>submission to the cvs.<BR>Maintainer: Dmitry
Isakbayev <<A href="mailto:isakdim@gmail.com">isakdim@gmail.com</A>>
</DIV>
<DIV> </DIV>
<DIV>This module adds support for the Open Settlement Protocol to SER. The
Open<BR>Settlement Protocol (OSP) standard is an operations and billing
support<BR>system protocol for IP network applications such as VoIP, video,
short<BR>message services (SMS) and content brokering. OSP is an open
standard<BR>defined by ETSI - the European Telecommunications Standards
Institute. OSP<BR>has been widely deployed by VoIP carriers to enforce
secure access control<BR>for peer to peer inter-domain VoIP routing and Call
Detail Record (CDR)<BR>collection. For more information see <A
href="http://www.etsi.org">www.etsi.org</A> and search for ETSI TS<BR>101
321.</DIV>
<DIV> </DIV>
<DIV>lcr module<BR>----------<BR>COMMENT: The LCR module of head has a slightly
different feature set that<BR>have been difficult to backport to
0.9.x.<BR>Maintainer: Juha Heinanen <<A
href="mailto:jh@tutpro.com">jh@tutpro.com</A>></DIV>
<DIV> </DIV>
<DIV>Backported Least Cost Routing module from HEAD.
</FONT></DIV></FONT></BODY></HTML>