SVN-fs-dump-format-version: 2

UUID: 4ebea2bb-67d4-0310-8558-a5799e421b66

Revision-number: 0
Prop-content-length: 56
Content-length: 56

K 8
svn:date
V 27
2004-02-28T11:15:24.882843Z
PROPS-END

Revision-number: 1
Prop-content-length: 114
Content-length: 114

K 7
svn:log
V 15
initial checkin
K 10
svn:author
V 4
root
K 8
svn:date
V 27
2003-02-18T17:05:09.000000Z
PROPS-END

Node-path: trunk
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

PROPS-END


Node-path: trunk/CVSROOT
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

PROPS-END


Node-path: trunk/CVSROOT/checkoutlist
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 493
Text-content-md5: 105101f95ac33a5fa5662913fd03a3ee
Content-length: 503

PROPS-END
# The "checkoutlist" file is used to support additional version controlled
# administrative files in $CVSROOT/CVSROOT, such as template files.
#
# The first entry on a line is a filename which will be checked out from
# the corresponding RCS file in the $CVSROOT/CVSROOT directory.
# The remainder of the line is an error message to use if the file cannot
# be checked out.
#
# File format:
#
#	[<whitespace>]<filename><whitespace><error message><end-of-line>
#
# comment lines begin with '#'


Node-path: trunk/CVSROOT/commitinfo
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 760
Text-content-md5: 7f78d59a5fe160f21ee9fd4045c5fb01
Content-length: 770

PROPS-END
# The "commitinfo" file is used to control pre-commit checks.
# The filter on the right is invoked with the repository and a list 
# of files to check.  A non-zero exit of the filter program will 
# cause the commit to be aborted.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being committed to, relative
# to the $CVSROOT.  For the first match that is found, then the remainder
# of the line is the name of the filter to run.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".


Node-path: trunk/CVSROOT/config
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 527
Text-content-md5: 0c30edbbeb4491a8937c4dcf49dc13d2
Content-length: 537

PROPS-END
# Set this to "no" if pserver shouldn't check system users/passwords
#SystemAuth=no

# Put CVS lock files in this directory rather than directly in the repository.
#LockDir=/var/lock/cvs

# Set `TopLevelAdmin' to `yes' to create a CVS directory at the top
# level of the new working directory when using the `cvs checkout'
# command.
#TopLevelAdmin=no

# Set `LogHistory' to `all' or `TOFEWGCMAR' to log all transactions to the
# history file, or a subset as needed (ie `TMAR' logs all write operations)
#LogHistory=TOFEWGCMAR


Node-path: trunk/CVSROOT/cvswrappers
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 753
Text-content-md5: 7122042372bc989d1098c077df64a410
Content-length: 763

PROPS-END
# This file affects handling of files based on their names.
#
# The -t/-f options allow one to treat directories of files
# as a single file, or to transform a file in other ways on
# its way in and out of CVS.
#
# The -m option specifies whether CVS attempts to merge files.
#
# The -k option specifies keyword expansion (e.g. -kb for binary).
#
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
#
#  wildcard	[option value][option value]...
#
#  where option is one of
#  -f		from cvs filter		value: path to filter
#  -t		to cvs filter		value: path to filter
#  -m		update methodology	value: MERGE or COPY
#  -k		expansion mode		value: b, o, kkv, &c
#
#  and value is a single-quote delimited value.
# For example:
#*.gif -k 'b'


Node-path: trunk/CVSROOT/editinfo
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 1025
Text-content-md5: c0245bd6cbece787af06cb3e1969ea78
Content-length: 1035

PROPS-END
# The "editinfo" file is used to allow verification of logging
# information.  It works best when a template (as specified in the
# rcsinfo file) is provided for the logging procedure.  Given a
# template with locations for, a bug-id number, a list of people who
# reviewed the code before it can be checked in, and an external
# process to catalog the differences that were code reviewed, the
# following test can be applied to the code:
#
#   Making sure that the entered bug-id number is correct.
#   Validating that the code that was reviewed is indeed the code being
#       checked in (using the bug-id number or a seperate review
#       number to identify this particular code set.).
#
# If any of the above test failed, then the commit would be aborted.
#
# Actions such as mailing a copy of the report to each reviewer are
# better handled by an entry in the loginfo file.
#
# One thing that should be noted is the the ALL keyword is not
# supported.  There can be only one entry that matches a given
# repository.


Node-path: trunk/CVSROOT/modules
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 1151
Text-content-md5: eaadfb1d78e7d7637edd0e00b819fbda
Content-length: 1161

PROPS-END
# Three different line formats are valid:
#	key	-a    aliases...
#	key [options] directory
#	key [options] directory files...
#
# Where "options" are composed of:
#	-i prog		Run "prog" on "cvs commit" from top-level of module.
#	-o prog		Run "prog" on "cvs checkout" of module.
#	-e prog		Run "prog" on "cvs export" of module.
#	-t prog		Run "prog" on "cvs rtag" of module.
#	-u prog		Run "prog" on "cvs update" of module.
#	-d dir		Place module in directory "dir" instead of module name.
#	-l		Top-level directory only -- do not recurse.
#
# NOTE:  If you change any of the "Run" options above, you'll have to
# release and re-checkout any working directories of these modules.
#
# And "directory" is a path to a directory relative to $CVSROOT.
#
# The "-a" option specifies an alias.  An alias is interpreted as if
# everything on the right of the "-a" had been typed on the command line.
#
# You can encode a module within a module by using the special '&'
# character to interpose another module into the current module.  This
# can be useful for creating a module that consists of many directories
# spread out over the entire source repository.


Node-path: trunk/CVSROOT/notify
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 564
Text-content-md5: 3634e43fc97171e3a3121f7b5f7c2686
Content-length: 574

PROPS-END
# The "notify" file controls where notifications from watches set by
# "cvs watch add" or "cvs edit" are sent.  The first entry on a line is
# a regular expression which is tested against the directory that the
# change is being made to, relative to the $CVSROOT.  If it matches,
# then the remainder of the line is a filter program that should contain
# one occurrence of %s for the user to notify, and information on its
# standard input.
#
# "ALL" or "DEFAULT" can be used in place of the regular expression.
#
# For example:
#ALL mail %s -s "CVS notification"


Node-path: trunk/CVSROOT/rcsinfo
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 649
Text-content-md5: 4ca72032cff35f7d200d0778ba93ab65
Content-length: 659

PROPS-END
# The "rcsinfo" file is used to control templates with which the editor
# is invoked on commit and import.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being made to, relative to the
# $CVSROOT.  For the first match that is found, then the remainder of the
# line is the name of the file that contains the template.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".


Node-path: trunk/CVSROOT/taginfo
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 879
Text-content-md5: 6c6d903782cf3195ba68085654c8c5f3
Content-length: 889

PROPS-END
# The "taginfo" file is used to control pre-tag checks.
# The filter on the right is invoked with the following arguments:
#
# $1 -- tagname
# $2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag -d
# $3 -- repository
# $4->  file revision [file revision ...]
#
# A non-zero exit of the filter program will cause the tag to be aborted.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being committed to, relative
# to the $CVSROOT.  For the first match that is found, then the remainder
# of the line is the name of the filter to run.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".


Node-path: trunk/CVSROOT/verifymsg
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 1026
Text-content-md5: 0ad9fcdfc8f7bc24ba445a785fdd1bfc
Content-length: 1036

PROPS-END
# The "verifymsg" file is used to allow verification of logging
# information.  It works best when a template (as specified in the
# rcsinfo file) is provided for the logging procedure.  Given a
# template with locations for, a bug-id number, a list of people who
# reviewed the code before it can be checked in, and an external
# process to catalog the differences that were code reviewed, the
# following test can be applied to the code:
#
#   Making sure that the entered bug-id number is correct.
#   Validating that the code that was reviewed is indeed the code being
#       checked in (using the bug-id number or a seperate review
#       number to identify this particular code set.).
#
# If any of the above test failed, then the commit would be aborted.
#
# Actions such as mailing a copy of the report to each reviewer are
# better handled by an entry in the loginfo file.
#
# One thing that should be noted is the the ALL keyword is not
# supported.  There can be only one entry that matches a given
# repository.


Revision-number: 2
Prop-content-length: 115
Content-length: 115

K 7
svn:log
V 16
initial checkin

K 10
svn:author
V 4
root
K 8
svn:date
V 27
2003-02-18T17:05:09.000000Z
PROPS-END

Node-path: trunk/CVSROOT/loginfo
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 1141
Text-content-md5: d2a958f146de3e13b1d0935c0d319a88
Content-length: 1151

PROPS-END
# The "loginfo" file controls where "cvs commit" log information
# is sent.  The first entry on a line is a regular expression which must match
# the directory that the change is being made to, relative to the
# $CVSROOT.  If a match is found, then the remainder of the line is a filter
# program that should expect log information on its standard input.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name ALL appears as a regular expression it is always used
# in addition to the first matching regex or DEFAULT.
#
# You may specify a format string as part of the
# filter.  The string is composed of a `%' followed
# by a single format character, or followed by a set of format
# characters surrounded by `{' and `}' as separators.  The format
# characters are:
#
#   s = file name
#   V = old version number (pre-checkin)
#   v = new version number (post-checkin)
#
# For example:
#DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
# or
#DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog


Revision-number: 3
Prop-content-length: 118
Content-length: 118

K 7
svn:log
V 17
Initial revision

K 10
svn:author
V 6
gernot
K 8
svn:date
V 27
2003-02-19T08:19:51.000000Z
PROPS-END

Node-path: trunk/capisuite
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

PROPS-END


Node-path: trunk/capisuite/.cvsignore
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 131
Text-content-md5: 0b7fb345a5c8928d6ed97b1cffd589cb
Content-length: 141

PROPS-END
Makefile
Makefile.in
aclocal.m4
autom4te.cache
stamp-h1
config.*
configure
configure.scan
autoscan.log
capisuite.cron
rc.capisuite


Node-path: trunk/capisuite/AUTHORS
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 35
Text-content-md5: 1229b475773c688e1c0d176161741a6b
Content-length: 45

PROPS-END
Gernot Hillier <gernot@hillier.de>


Node-path: trunk/capisuite/ChangeLog
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Content-length: 10

PROPS-END


Node-path: trunk/capisuite/Makefile.am
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 611
Text-content-md5: 8fd1875b3f5a930c9109a41a65eb08a7
Content-length: 621

PROPS-END
spooldir = @localstatedir@/spool/capisuite
pkgsysconfdir = @sysconfdir@/capisuite
docdir = @docdir@
doc_DATA = COPYING NEWS README
EXTRA_DIST = rc.capisuite.in capisuite.spec capisuite.cronin

SUBDIRS = src scripts docs

all: capisuite.cron rc.capisuite

capisuite.cron: capisuite.cronin
	rm -f $@
	sed -e 's,@pkgsysconfdir\@,$(pkgsysconfdir),g' \
            -e 's,@spooldir\@,$(spooldir),g' $< >$@
	chmod a+x $@

rc.capisuite: rc.capisuite.in
	rm -f $@
	sed -e 's,@pkgsysconfdir\@,$(pkgsysconfdir),g' \
	    -e 's,@bindir\@,$(bindir),g' $< >$@
	chmod a+x $@

clean-local:
	rm -f rc.capisuite capisuite.cron 



Node-path: trunk/capisuite/NEWS
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 4773
Text-content-md5: 3da50d34adf04ebb0c79008bb0a85c2a
Content-length: 4783

PROPS-END
0.01 (tag CAPISUITE_001):
=========================

	* changed name from CapiCom to CapiSuite (name conflict with MS crypto API)
	* added doxygen-created documentation for classes and python exported functions
	* get_DTMF() was renamed to read_DTMF() and can wait for DTMF now
	* connect_telephony() renamed to connect_voice()

0.02 (tag CAPISUITE_002):
=========================

	* many bug fixes as usual (SEGV, ...)
	* service constants SERVICE_VOICE, SERVICE_FAXG3 and SERVICE_OTHER 
	  available in python now, no need to use CIP values any more
	* audio_send and audio_receive return length in seconds now
	* added support for idle script which can initiate outgoing calls

0.03 (tag CAPISUITE_003):
=========================

	* improvement in idle script handling, own class for it (IdleScript)
	* new classes for Python script handling (PythonScript) and derived classes 
	  (IncomingScript & IdleScript)
	* new python functions call_voice and call_faxG3 to initiate outgoing calls
	* changed python exception handling to allow multiple calls in one script to be 
 	  handled correctly
	* python functions disconnect() and reject() wait for complete disconnection and  
	  return the disconnect cause now
	* assure nice disconnection in any error case (hopefully)
	* when error occured in script, physical connection is finished immediately leading 
	  to an error visible at the sending side (e.g. when using the fax protocol)
	* cleaned up python reference counting and threads, no known memory leaks any more 
	* many changes to support outgoing calls (new module, many small changes) 
	* Connection objects will be destroyed by application level now so dangling pointers
	  are avoided
	* exception handling generally improved

0.1 (tag CAPISUITE_01):
=======================
	* "make install" and "make dist" work now, use config.h
	* added main docu page for doxygen
	* added capisuitefax-script (command line tool for sending faxes)
	* added support for sending faxes in idle.py
	* added support for "capisuite.conf" (global configuration file)
	* capisuite can write its output to logfiles now
	* faxsend module added, new python function fax_send()
	* idle script will be disabled after 10 subsequent errors
	* B3 disconnect cause now returned by disconnect() python function

0.2 (tag CAPISUITE_02):
=======================
	* log improvements: log-level configurable (see capisuite.conf), appending log-file instead of re-creating
	* configure allows to set docdir with --with-docdir 
	* CapiSuite can be finished using Ctrl-C and SIGTERM nicely 
	* very limited support for reload (kill -1) - only re-activates de-actived idle script yet,
	  no reload of configuration
	* all configuration for the scripts put in own config file 
	* support for various new configuration options, multi-user-ready scripts (different user dirs in spool_dir/users)
	* audio_receive does truncate recorded silence away 
	* remote inquiry supports recording of own announcement
	* commandline option "-d" runs CapiSuite as daemon
	* new python commands: capisuite.log and capisuite.error let scripts write messages to the CapiSuite log
	  and error log
	 
0.2.1 (tag CAPISUITE_021):
==========================
	* many document improvements (new DocBook manual)

0.3 (tag CAPISUITE_03):
=======================
	* split up script configuration in two files (anwering machine, fax),
	  some new features configurable now (e.g. actions)

0.3.1 (tag CAPISUITE_031):
==========================
	* dist: included spec and init file in CVS and dist
	* scripts: use different sendqueues for each user 
	* core: fixed some bugs: 
		- capisuite.error() didn't work, 
		- logging in outgoing connections didn't work 
		- callingParty wasn't set correctly
	* scripts: answering machine switches to fax when incoming service indicator says fax
	* scripts: sayNumber can now handle all number from 0 to 99, so all dates and times are 
	  now said nearly correctly for the remote inquiry
	* scripts: fixed a typo in incoming.py
	* docs: added ISDN/CAPI error codes to manual 

0.3.2 (tag CAPISUITE_032):
==========================
	* core: finally got rid of the CommonC++ library:
		- threading implemented using native pthread_* calls
		- rewritten CapiSuite::parseConfigFile() to use STL string routines
		- changed Connection class to use pthread_mutex_*
	* scripts: fixed bug which lead to hanging processes of externally started 
	           progs like sendmail
	* scripts: minor fixes 
		
0.4 (tag CAPISUITE_04):
=======================
	* added cron script for cleaning up spool dirs
	* fixed bug in rc.capisuite (was also started when not configured)
	* scripts: remote inquiry supports new and old messages now
	* scripts: capisuitefax can show sendqueue and delete jobs now	


Node-path: trunk/capisuite/README
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 186
Text-content-md5: 771174fee3f300515e938bc0a070ee65
Content-length: 196

PROPS-END
CapiSuite
=========

For the documentation see the created HTML documents
situated in docs/manual/index.html or in the installed version see
PREFIX/share/doc/capisuite/manual/index.html


Node-path: trunk/capisuite/TODO
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 884
Text-content-md5: 1c646914ed340a543d1387af747e87a9
Content-length: 894

PROPS-END
CRITICAL:
- finish manual.docbook, provide simple examples
- somewhere there's a bad thing (tm) which holds the python global lock
  despite it mustn't (try incoming + outgoing call at the same time,
  idlescript will stop working sometime...)

IMPORTANT:
- fax headline

NICE:
- ?valgrind-clean the used libs and Python?
- support more than one send_controller
- don't use 34xx codes, define constants instead and print meaningful messages
- include email account check in idly.py 
- add docbook -> html to Makefile.am
- any solution for sending fax when having no fax config?

FUTURE PLANS:
- setuid away from root (problem: chown of recorded file to user)
- log syntax errors in scripts, too
	- PyRun_SimpleFile must be replaced by PyRun_File for this IMHO
- test-implement the whole application part in Python
- rewrite capisuitefax and idle.py to use named socket communication



Node-path: trunk/capisuite/acinclude.m4
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 3797
Text-content-md5: 2e68afb0ee8fff4c28b58a504bee0d85
Content-length: 3807

PROPS-END
#
# Autoconf macros for configuring the build of Python extension modules
#
# $Header: /root/cvs2svn/capisuite/capisuite/acinclude.m4,v 1.1 2003/02/19 08:19:52 gernot Exp $
#
# taken out of Postgres CVS by Gernot Hillier 
#

# CS_SET_DOCDIR
# -------------
# Set the name of the docdir to the given value. This is not nice, but I 
# found no other name to do it than with AC_ARG_WITH. Please tell me if 
# you have better ideas...
AC_DEFUN(CS_SET_DOCDIR,
[AC_ARG_WITH(docdir,
	     AC_HELP_STRING([--with-docdir=DOCDIR],
			    [use DOCDIR to install documentation to (default is PREFIX/share/doc/capisuite)]),
	docdir=$withval, docdir=$datadir/doc/capisuite)
AC_SUBST(docdir)
])

# PGAC_CHECK_PYTHON_DIRS
# -----------------------
# Determine the name of various directory of a given Python installation.
AC_DEFUN([PGAC_CHECK_PYTHON_DIRS],
[AC_REQUIRE([AM_PATH_PYTHON])
AC_MSG_CHECKING([Python installation directories])
python_version=`${PYTHON} -c "import sys; print sys.version[[:3]]"`
python_prefix=`${PYTHON} -c "import sys; print sys.prefix"`
python_execprefix=`${PYTHON} -c "import sys; print sys.exec_prefix"`
python_libdir=`${PYTHON} -c "from distutils import sysconfig; print sysconfig.get_python_lib(1,1)"`
python_configdir="${python_libdir}/config"
python_moduledir="${python_libdir}/site-packages"
python_moduleexecdir="${python_libdir}/site-packages"
python_includespec="-I${python_prefix}/include/python${python_version}"
python_linkforshared=`${PYTHON} -c "import distutils.sysconfig; print distutils.sysconfig.get_config_var('LINKFORSHARED')"`
if test "$python_prefix" != "$python_execprefix"; then
  python_includespec="-I${python_execprefix}/include/python${python_version} $python_includespec"
fi

AC_SUBST(python_version)[]dnl
AC_SUBST(python_prefix)[]dnl
AC_SUBST(python_execprefix)[]dnl
AC_SUBST(python_configdir)[]dnl
AC_SUBST(python_moduledir)[]dnl
AC_SUBST(python_moduleexecdir)[]dnl
AC_SUBST(python_includespec)[]dnl
AC_SUBST(python_linkforshared)[]dnl
# This should be enough of a message.
if test "$python_prefix" != "$python_execprefix"; then
  AC_MSG_RESULT([$python_libdir and $python_execprefix])
else
  AC_MSG_RESULT([$python_libdir])
fi
])# _PGAC_CHECK_PYTHON_DIRS


# PGAC_CHECK_PYTHON_MODULE_SETUP
# ------------------------------
# Finds things required to build a Python extension module.
# This used to do more, that's why it's separate.
#
# It would be nice if we could check whether the current setup allows
# the build of the shared module. Future project.
AC_DEFUN([PGAC_CHECK_PYTHON_MODULE_SETUP],
[
  AC_REQUIRE([PGAC_CHECK_PYTHON_DIRS])
])# PGAC_CHECK_PYTHON_MODULE_SETUP


# PGAC_CHECK_PYTHON_EMBED_SETUP
# -----------------------------
# Courtesy of the INN 2.3.1 package...
AC_DEFUN([PGAC_CHECK_PYTHON_EMBED_SETUP],
[AC_REQUIRE([PGAC_CHECK_PYTHON_DIRS])
AC_MSG_CHECKING([how to link an embedded Python application])

if test ! -f "$python_configdir/Makefile"; then
  AC_MSG_RESULT(no)
  AC_MSG_ERROR([Python Makefile not found])
fi

_python_libs=`grep '^LIBS=' $python_configdir/Makefile | sed 's/^.*=//'`
_python_libc=`grep '^LIBC=' $python_configdir/Makefile | sed 's/^.*=//'`
_python_libm=`grep '^LIBM=' $python_configdir/Makefile | sed 's/^.*=//'`
_python_liblocalmod=`grep '^LOCALMODLIBS=' $python_configdir/Makefile | sed 's/^.*=//'`
_python_libbasemod=`grep '^BASEMODLIBS=' $python_configdir/Makefile | sed 's/^.*=//'`

pgac_tab="	" # tab character
python_libspec=`echo X"$_python_libs $_python_libc $_python_libm -lpython$python_version $_python_liblocalmod $_python_libbasemod" | sed -e 's/^X//' -e "s/[[ $pgac_tab]][[ $pgac_tab]]*/ /g"`
LIBS="$LIBS $python_libspec"
LDFLAGS="$LDFLAGS -L$python_configdir $python_linkforshared"
AC_MSG_RESULT([${python_libspec}])

AC_SUBST(LIBS)[]dnl
AC_SUBST(LDFLAGS)
])# PGAC_CHECK_PYTHON_EMBED_SETUP



Node-path: trunk/capisuite/capisuite.cronin
Node-kind: file
Node-action: add
Prop-content-length: 36
Text-content-length: 1104
Text-content-md5: 8df12639fa0ca719067e935c7a5e446f
Content-length: 1140

K 14
svn:executable
V 1
*
PROPS-END
#!/bin/sh
#
# capisuite. CapiSuite cleanup script, should be run regularly 
# by cron. It's only useful for the default scripts provided 
# with CapiSuite. 
#
# It will read a central configuration file placed in 
# /etc/capisuite/cronjob.conf where you must define a variable
# called MAX_DAYS which defines how many days a received or sent
# file may stay in the spool dirs. 
#
# Author: Gernot Hillier <gernot@hillier.de>
#

#
# paranoia settings
#
umask 022

PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH

# do nothing if there is no global config
test -r @pkgsysconfdir@/cronjob.conf || exit

for i in @spooldir@/users/*/received @spooldir@/done @spooldir@/failed; do
   # reset defaults
   test -r @pkgsysconfdir@/cronjob.conf && . @pkgsysconfdir@/cronjob.conf
   # user can overwrite default values
   test -r $i/cronjob.conf && . $i/cronjob.conf
   
   test "$MAX_DAYS" -gt 0 2> /dev/null || continue
   find $i/. -name "*fax-[0-9]*.*" ! -type d ! -type s -atime +$MAX_DAYS -exec rm {} \;
   find $i/. -name "*voice-[0-9]*.*" ! -type d ! -type s -atime +$MAX_DAYS -exec rm {} \; 
done;

exit 0



Node-path: trunk/capisuite/capisuite.spec
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 2126
Text-content-md5: f9299a25a2f3d2687096b2dfcd70d3a9
Content-length: 2136

PROPS-END
#
# spec file for package capisuite 
#
# Author: Gernot Hillier <gernot@hillier.de>
#
# This spec file was developed for the use with SuSE Linux.  But it
# should also work for any other distribution with slight changes.
# If you created your own RPM, please tell me and I'll happily include
# the spec or a link to your RPM on the homepage.

# neededforbuild  capi4linux gcc-c++ libstdc++-devel libxml2-devel python python-devel

Name:         capisuite
License:      GPL
Group:        Applications/Communications
Autoreqprov:  on
Version:      0.3  
Release:      0
Requires:     sfftobmp sox
Summary:      capisuite
Source0:      capisuite-%{version}.tar.gz
Source1:      rc.capisuite
Url:          http://www.capisuite.de 
BuildRoot:    %{_tmppath}/%{name}-%{version}-build
PreReq:       %insserv_prereq

%description
CapiSuite is a ISDN telecommunication suite providing easy to use
telecommunication functions which can be controlled from Python scripts.

It uses a CAPI-compatible driver for accessing the ISDN-hardware, so you'll
need a Eicon or AVM card with the according driver.

CapiSuite is distributed with two example scripts for call incoming handling
and fax sending. See /usr/share/capisuite/scripts and
/usr/share/doc/packages/capisuite for further information.

Authors:
--------
        Gernot Hillier

%prep
%setup  
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-docdir=/usr/share/doc/packages/capisuite 

%build
make 

%install
make DESTDIR=$RPM_BUILD_ROOT install
mkdir -p $RPM_BUILD_ROOT/etc/init.d
mkdir -p $RPM_BUILD_ROOT/usr/sbin
install -g root -m 755 -o root %{SOURCE1} $RPM_BUILD_ROOT/etc/init.d/capisuite
ln -sf ../../etc/init.d/capisuite $RPM_BUILD_ROOT/usr/sbin/rccapisuite

%clean
rm -rf $RPM_BUILD_ROOT

%files
%config /etc/capisuite/capisuite.conf
%config /etc/capisuite/fax.conf
%config /etc/capisuite/answering_machine.conf
/usr/bin/capisuite
/usr/bin/capisuitefax
%doc /usr/share/doc/packages/capisuite
/usr/share/capisuite
/usr/lib/capisuite
/var/spool/capisuite
/usr/%{_lib}/python2.2/site-packages/cs_helpers.py
/etc/init.d/capisuite
/usr/sbin/rccapisuite



Node-path: trunk/capisuite/configure.in
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 846
Text-content-md5: 11d62b174200f50e81f85a7117e99e02
Content-length: 856

PROPS-END
AC_INIT(src/main.cpp)
AM_INIT_AUTOMAKE(capisuite,0.4)
AM_CONFIG_HEADER(config.h)

AC_LANG_CPLUSPLUS
AC_PROG_CC
AC_PROG_CXX
AC_PROG_INSTALL
AC_PROG_RANLIB
AC_PROG_MAKE_SET
AC_PATH_PROG(doxygen,doxygen)
dnl suggested by autoscan:

AC_CHECK_FUNCS([gettimeofday])
AC_CHECK_HEADERS([sys/time.h])
AC_HEADER_TIME

CS_SET_DOCDIR

AC_CHECK_LIB(capi20,capi20_register,,AC_MSG_ERROR(libcapi20 not found))
AC_CHECK_LIB(pthread,pthread_create,,AC_MSG_ERROR(libpthread not found))
AM_PATH_PYTHON(2.2)
PGAC_CHECK_PYTHON_EMBED_SETUP
CPPFLAGS='-DLOCALSTATEDIR=\"$(localstatedir)\" -DPKGDATADIR=\"$(pkgdatadir)\" -DPKGSYSCONFDIR=\"$(sysconfdir)/capisuite\" -DPKGLIBDIR=\"$(pkglibdir)\" $(python_includespec)'

AC_OUTPUT(Makefile src/Makefile src/backend/Makefile src/modules/Makefile src/application/Makefile scripts/Makefile scripts/waves/Makefile docs/Makefile)


Node-path: trunk/capisuite/docs
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

PROPS-END


Node-path: trunk/capisuite/docs/.cvsignore
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 88
Text-content-md5: c29578883e660be16a5dfbdb7d68036c
Content-length: 98

PROPS-END
reference
reference/*
manual
manual/*
susebuch
susebuch/*
Doxyfile
Makefile
Makefile.in


Node-path: trunk/capisuite/docs/Doxyfile.in
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 38633
Text-content-md5: 50a8f68282599f2af2f625e44c4aa4fe
Content-length: 38643

PROPS-END
# Doxyfile 1.2.17

# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project
#
# All text after a hash (#) is considered a comment and will be ignored
# The format is:
#       TAG = value [value, ...]
# For lists items can also be appended using:
#       TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ")

#---------------------------------------------------------------------------
# General configuration options
#---------------------------------------------------------------------------

# The PROJECT_NAME tag is a single word (or a sequence of words surrounded 
# by quotes) that should identify the project.

PROJECT_NAME           = CapiSuite 

# The PROJECT_NUMBER tag can be used to enter a project or revision number. 
# This could be handy for archiving the generated documentation or 
# if some version control system is used.

PROJECT_NUMBER         = @version@ 

# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) 
# base path where the generated documentation will be put. 
# If a relative path is entered, it will be relative to the location 
# where doxygen was started. If left blank the current directory will be used.

OUTPUT_DIRECTORY       = . 

# The OUTPUT_LANGUAGE tag is used to specify the language in which all 
# documentation generated by doxygen is written. Doxygen will use this 
# information to generate all constant output in the proper language. 
# The default language is English, other supported languages are: 
# Brazilian, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, 
# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en 
# (Japanese with english messages), Korean, Norwegian, Polish, Portuguese, 
# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish and Ukrainian.

OUTPUT_LANGUAGE        = English

# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in 
# documentation are documented, even if no documentation was available. 
# Private class members and static file members will be hidden unless 
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES

EXTRACT_ALL            = NO

# If the EXTRACT_PRIVATE tag is set to YES all private members of a class 
# will be included in the documentation.

EXTRACT_PRIVATE        = YES 

# If the EXTRACT_STATIC tag is set to YES all static members of a file 
# will be included in the documentation.

EXTRACT_STATIC         = YES 

# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) 
# defined locally in source files will be included in the documentation. 
# If set to NO only classes defined in header files are included.

EXTRACT_LOCAL_CLASSES  = NO

# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all 
# undocumented members of documented classes, files or namespaces. 
# If set to NO (the default) these members will be included in the 
# various overviews, but no documentation section is generated. 
# This option has no effect if EXTRACT_ALL is enabled.

HIDE_UNDOC_MEMBERS     = NO

# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all 
# undocumented classes that are normally visible in the class hierarchy. 
# If set to NO (the default) these class will be included in the various 
# overviews. This option has no effect if EXTRACT_ALL is enabled.

HIDE_UNDOC_CLASSES     = NO

# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will 
# include brief member descriptions after the members that are listed in 
# the file and class documentation (similar to JavaDoc). 
# Set to NO to disable this.

BRIEF_MEMBER_DESC      = YES

# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 
# the brief description of a member or function before the detailed description. 
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 
# brief descriptions will be completely suppressed.

REPEAT_BRIEF           = YES

# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then 
# Doxygen will generate a detailed section even if there is only a brief 
# description.

ALWAYS_DETAILED_SEC    = YES 

# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited 
# members of a class in the documentation of that class as if those members were 
# ordinary class members. Constructors, destructors and assignment operators of 
# the base classes will not be shown.

INLINE_INHERITED_MEMB  = NO 

# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full 
# path before files name in the file list and in the header files. If set 
# to NO the shortest path that makes the file name unique will be used.

FULL_PATH_NAMES        = NO

# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag 
# can be used to strip a user defined part of the path. Stripping is 
# only done if one of the specified strings matches the left-hand part of 
# the path. It is allowed to use relative paths in the argument list.

STRIP_FROM_PATH        = 

# The INTERNAL_DOCS tag determines if documentation 
# that is typed after a \internal command is included. If the tag is set 
# to NO (the default) then the documentation will be excluded. 
# Set it to YES to include the internal documentation.

INTERNAL_DOCS          = NO

# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 
# doxygen to hide any special comment blocks from generated source code 
# fragments. Normal C and C++ comments will always remain visible.

STRIP_CODE_COMMENTS    = YES

# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate 
# file names in lower case letters. If set to YES upper case letters are also 
# allowed. This is useful if you have classes or files whose names only differ 
# in case and if your file system supports case sensitive file names. Windows 
# users are adviced to set this option to NO.

CASE_SENSE_NAMES       = YES

# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter 
# (but less readable) file names. This can be useful is your file systems 
# doesn't support long names like on DOS, Mac, or CD-ROM.

SHORT_NAMES            = NO

# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen 
# will show members with their full class and namespace scopes in the 
# documentation. If set to YES the scope will be hidden.

HIDE_SCOPE_NAMES       = NO

# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen 
# will generate a verbatim copy of the header file for each class for 
# which an include is specified. Set to NO to disable this.

VERBATIM_HEADERS       = YES

# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen 
# will put list of the files that are included by a file in the documentation 
# of that file.

SHOW_INCLUDE_FILES     = YES

# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen 
# will interpret the first line (until the first dot) of a JavaDoc-style 
# comment as the brief description. If set to NO, the JavaDoc 
# comments  will behave just like the Qt-style comments (thus requiring an 
# explict @brief command for a brief description.

JAVADOC_AUTOBRIEF      = NO

# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen 
# treat a multi-line C++ special comment block (i.e. a block of //! or /// 
# comments) as a brief description. This used to be the default behaviour. 
# The new default is to treat a multi-line C++ comment block as a detailed 
# description. Set this tag to YES if you prefer the old behaviour instead.

MULTILINE_CPP_IS_BRIEF = NO

# If the DETAILS_AT_TOP tag is set to YES then Doxygen 
# will output the detailed description near the top, like JavaDoc.
# If set to NO, the detailed description appears after the member 
# documentation.

DETAILS_AT_TOP         = NO 

# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented 
# member inherits the documentation from any documented member that it 
# reimplements.

INHERIT_DOCS           = YES

# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] 
# is inserted in the documentation for inline members.

INLINE_INFO            = YES

# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen 
# will sort the (detailed) documentation of file and class members 
# alphabetically by member name. If set to NO the members will appear in 
# declaration order.

SORT_MEMBER_DOCS       = YES

# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC 
# tag is set to YES, then doxygen will reuse the documentation of the first 
# member in the group (if any) for the other members of the group. By default 
# all members of a group must be documented explicitly.

DISTRIBUTE_GROUP_DOC   = NO

# The TAB_SIZE tag can be used to set the number of spaces in a tab. 
# Doxygen uses this value to replace tabs by spaces in code fragments.

TAB_SIZE               = 8

# The GENERATE_TODOLIST tag can be used to enable (YES) or 
# disable (NO) the todo list. This list is created by putting \todo 
# commands in the documentation.

GENERATE_TODOLIST      = YES

# The GENERATE_TESTLIST tag can be used to enable (YES) or 
# disable (NO) the test list. This list is created by putting \test 
# commands in the documentation.

GENERATE_TESTLIST      = YES

# The GENERATE_BUGLIST tag can be used to enable (YES) or 
# disable (NO) the bug list. This list is created by putting \bug 
# commands in the documentation.

GENERATE_BUGLIST       = YES

# This tag can be used to specify a number of aliases that acts 
# as commands in the documentation. An alias has the form "name=value". 
# For example adding "sideeffect=\par Side Effects:\n" will allow you to 
# put the command \sideeffect (or @sideeffect) in the documentation, which 
# will result in a user defined paragraph with heading "Side Effects:". 
# You can put \n's in the value part of an alias to insert newlines.

ALIASES                = 

# The ENABLED_SECTIONS tag can be used to enable conditional 
# documentation sections, marked by \if sectionname ... \endif.

ENABLED_SECTIONS       = 

# The MAX_INITIALIZER_LINES tag determines the maximum number of lines 
# the initial value of a variable or define consist of for it to appear in 
# the documentation. If the initializer consists of more lines than specified 
# here it will be hidden. Use a value of 0 to hide initializers completely. 
# The appearance of the initializer of individual variables and defines in the 
# documentation can be controlled using \showinitializer or \hideinitializer 
# command in the documentation regardless of this setting.

MAX_INITIALIZER_LINES  = 30

# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources 
# only. Doxygen will then generate output that is more tailored for C. 
# For instance some of the names that are used will be different. The list 
# of all members will be omitted, etc.

OPTIMIZE_OUTPUT_FOR_C  = NO

# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources 
# only. Doxygen will then generate output that is more tailored for Java. 
# For instance namespaces will be presented as packages, qualified scopes 
# will look different, etc.

OPTIMIZE_OUTPUT_JAVA   = NO

# Set the SHOW_USED_FILES tag to NO to disable the list of files generated 
# at the bottom of the documentation of classes and structs. If set to YES the 
# list will mention the files that were used to generate the documentation.

SHOW_USED_FILES        = YES

#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------

# The QUIET tag can be used to turn on/off the messages that are generated 
# by doxygen. Possible values are YES and NO. If left blank NO is used.

QUIET                  = NO

# The WARNINGS tag can be used to turn on/off the warning messages that are 
# generated by doxygen. Possible values are YES and NO. If left blank 
# NO is used.

WARNINGS               = YES

# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings 
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will 
# automatically be disabled.

WARN_IF_UNDOCUMENTED   = YES

# The WARN_FORMAT tag determines the format of the warning messages that 
# doxygen can produce. The string should contain the $file, $line, and $text 
# tags, which will be replaced by the file and line number from which the 
# warning originated and the warning text.

WARN_FORMAT            = "$file:$line: $text"

# The WARN_LOGFILE tag can be used to specify a file to which warning 
# and error messages should be written. If left blank the output is written 
# to stderr.

WARN_LOGFILE           = 

#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------

# The INPUT tag can be used to specify the files and/or directories that contain 
# documented source files. You may enter file names like "myfile.cpp" or 
# directories like "/usr/src/myproject". Separate the files or directories 
# with spaces.

INPUT                  = @capisuite_sources@ @srcdir@ 

# If the value of the INPUT tag contains directories, you can use the 
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
# and *.h) to filter out the source-files in the directories. If left 
# blank the following patterns are tested: 
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp 
# *.h++ *.idl *.odl

FILE_PATTERNS          = *.cpp *.h *.doxy

# The RECURSIVE tag can be used to turn specify whether or not subdirectories 
# should be searched for input files as well. Possible values are YES and NO. 
# If left blank NO is used.

RECURSIVE              = YES

# The EXCLUDE tag can be used to specify files and/or directories that should 
# excluded from the INPUT source files. This way you can easily exclude a 
# subdirectory from a directory tree whose root is specified with the INPUT tag.

EXCLUDE                = 

# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories 
# that are symbolic links (a Unix filesystem feature) are excluded from the input.

EXCLUDE_SYMLINKS       = NO

# If the value of the INPUT tag contains directories, you can use the 
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 
# certain files from those directories.

EXCLUDE_PATTERNS       = 

# The EXAMPLE_PATH tag can be used to specify one or more files or 
# directories that contain example code fragments that are included (see 
# the \include command).

EXAMPLE_PATH           = 

# If the value of the EXAMPLE_PATH tag contains directories, you can use the 
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
# and *.h) to filter out the source-files in the directories. If left 
# blank all files are included.

EXAMPLE_PATTERNS       = 

# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be 
# searched for input files to be used with the \include or \dontinclude 
# commands irrespective of the value of the RECURSIVE tag. 
# Possible values are YES and NO. If left blank NO is used.

EXAMPLE_RECURSIVE      = NO

# The IMAGE_PATH tag can be used to specify one or more files or 
# directories that contain image that are included in the documentation (see 
# the \image command).

IMAGE_PATH             = 

# The INPUT_FILTER tag can be used to specify a program that doxygen should 
# invoke to filter for each input file. Doxygen will invoke the filter program 
# by executing (via popen()) the command <filter> <input-file>, where <filter> 
# is the value of the INPUT_FILTER tag, and <input-file> is the name of an 
# input file. Doxygen will then use the output that the filter program writes 
# to standard output.

INPUT_FILTER           = 

# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using 
# INPUT_FILTER) will be used to filter the input files when producing source 
# files to browse.

FILTER_SOURCE_FILES    = NO

#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------

# If the SOURCE_BROWSER tag is set to YES then a list of source files will 
# be generated. Documented entities will be cross-referenced with these sources.

SOURCE_BROWSER         = NO

# Setting the INLINE_SOURCES tag to YES will include the body 
# of functions and classes directly in the documentation.

INLINE_SOURCES         = NO

# If the REFERENCED_BY_RELATION tag is set to YES (the default) 
# then for each documented function all documented 
# functions referencing it will be listed.

REFERENCED_BY_RELATION = YES

# If the REFERENCES_RELATION tag is set to YES (the default) 
# then for each documented function all documented entities 
# called/used by that function will be listed.

REFERENCES_RELATION    = YES

#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------

# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index 
# of all compounds will be generated. Enable this if the project 
# contains a lot of classes, structs, unions or interfaces.

ALPHABETICAL_INDEX     = YES

# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then 
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns 
# in which this list will be split (can be a number in the range [1..20])

COLS_IN_ALPHA_INDEX    = 5

# In case all classes in a project start with a common prefix, all 
# classes will be put under the same header in the alphabetical index. 
# The IGNORE_PREFIX tag can be used to specify one or more prefixes that 
# should be ignored while generating the index headers.

IGNORE_PREFIX          = 

#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------

# If the GENERATE_HTML tag is set to YES (the default) Doxygen will 
# generate HTML output.

GENERATE_HTML          = YES

# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. 
# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
# put in front of it. If left blank `html' will be used as the default path.

HTML_OUTPUT            = reference 

# The HTML_FILE_EXTENSION tag can be used to specify the file extension for 
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank 
# doxygen will generate files with .html extension.

HTML_FILE_EXTENSION    = .html

# The HTML_HEADER tag can be used to specify a personal HTML header for 
# each generated HTML page. If it is left blank doxygen will generate a 
# standard header.

HTML_HEADER            = 

# The HTML_FOOTER tag can be used to specify a personal HTML footer for 
# each generated HTML page. If it is left blank doxygen will generate a 
# standard footer.

HTML_FOOTER            = 

# The HTML_STYLESHEET tag can be used to specify a user defined cascading 
# style sheet that is used by each HTML page. It can be used to 
# fine-tune the look of the HTML output. If the tag is left blank doxygen 
# will generate a default style sheet

HTML_STYLESHEET        = 

# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 
# files or namespaces will be aligned in HTML using tables. If set to 
# NO a bullet list will be used.

HTML_ALIGN_MEMBERS     = YES

# If the GENERATE_HTMLHELP tag is set to YES, additional index files 
# will be generated that can be used as input for tools like the 
# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) 
# of the generated HTML documentation.

GENERATE_HTMLHELP      = NO

# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can 
# be used to specify the file name of the resulting .chm file. You 
# can add a path in front of the file if the result should not be 
# written to the html output dir.

CHM_FILE               = 

# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can 
# be used to specify the location (absolute path including file name) of 
# the HTML help compiler (hhc.exe). If non empty doxygen will try to run 
# the html help compiler on the generated index.hhp.

HHC_LOCATION           = 

# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag 
# controls if a separate .chi index file is generated (YES) or that 
# it should be included in the master .chm file (NO).

GENERATE_CHI           = NO

# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag 
# controls whether a binary table of contents is generated (YES) or a 
# normal table of contents (NO) in the .chm file.

BINARY_TOC             = NO

# The TOC_EXPAND flag can be set to YES to add extra items for group members 
# to the contents of the Html help documentation and to the tree view.

TOC_EXPAND             = NO

# The DISABLE_INDEX tag can be used to turn on/off the condensed index at 
# top of each HTML page. The value NO (the default) enables the index and 
# the value YES disables it.

DISABLE_INDEX          = NO

# This tag can be used to set the number of enum values (range [1..20]) 
# that doxygen will group on one line in the generated HTML documentation.

ENUM_VALUES_PER_LINE   = 4

# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
# generated containing a tree-like index structure (just like the one that 
# is generated for HTML Help). For this to work a browser that supports 
# JavaScript and frames is required (for instance Mozilla, Netscape 4.0+, 
# or Internet explorer 4.0+). Note that for large projects the tree generation 
# can take a very long time. In such cases it is better to disable this feature. 
# Windows users are probably better off using the HTML help feature.

GENERATE_TREEVIEW      = NO

# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be 
# used to set the initial width (in pixels) of the frame in which the tree 
# is shown.

TREEVIEW_WIDTH         = 250

#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------

# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 
# generate Latex output.

GENERATE_LATEX         = NO 

# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 
# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
# put in front of it. If left blank `latex' will be used as the default path.

LATEX_OUTPUT           = latex

# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be invoked. If left blank `latex' will be used as the default command name.

LATEX_CMD_NAME         = latex

# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to 
# generate index for LaTeX. If left blank `makeindex' will be used as the 
# default command name.

MAKEINDEX_CMD_NAME     = makeindex

# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact 
# LaTeX documents. This may be useful for small projects and may help to 
# save some trees in general.

COMPACT_LATEX          = NO

# The PAPER_TYPE tag can be used to set the paper type that is used 
# by the printer. Possible values are: a4, a4wide, letter, legal and 
# executive. If left blank a4wide will be used.

PAPER_TYPE             = a4wide

# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
# packages that should be included in the LaTeX output.

EXTRA_PACKAGES         = 

# The LATEX_HEADER tag can be used to specify a personal LaTeX header for 
# the generated latex document. The header should contain everything until 
# the first chapter. If it is left blank doxygen will generate a 
# standard header. Notice: only use this tag if you know what you are doing!

LATEX_HEADER           = 

# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated 
# is prepared for conversion to pdf (using ps2pdf). The pdf file will 
# contain links (just like the HTML output) instead of page references 
# This makes the output suitable for online browsing using a pdf viewer.

PDF_HYPERLINKS         = YES

# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of 
# plain latex in the generated Makefile. Set this option to YES to get a 
# higher quality PDF documentation.

USE_PDFLATEX           = YES

# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. 
# command to the generated LaTeX files. This will instruct LaTeX to keep 
# running if errors occur, instead of asking the user for help. 
# This option is also used when generating formulas in HTML.

LATEX_BATCHMODE        = NO

#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------

# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output 
# The RTF output is optimised for Word 97 and may not look very pretty with 
# other RTF readers or editors.

GENERATE_RTF           = NO

# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. 
# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
# put in front of it. If left blank `rtf' will be used as the default path.

RTF_OUTPUT             = rtf

# If the COMPACT_RTF tag is set to YES Doxygen generates more compact 
# RTF documents. This may be useful for small projects and may help to 
# save some trees in general.

COMPACT_RTF            = NO

# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated 
# will contain hyperlink fields. The RTF file will 
# contain links (just like the HTML output) instead of page references. 
# This makes the output suitable for online browsing using WORD or other 
# programs which support those fields. 
# Note: wordpad (write) and others do not support links.

RTF_HYPERLINKS         = NO

# Load stylesheet definitions from file. Syntax is similar to doxygen's 
# config file, i.e. a series of assigments. You only have to provide 
# replacements, missing definitions are set to their default value.

RTF_STYLESHEET_FILE    = 

# Set optional variables used in the generation of an rtf document. 
# Syntax is similar to doxygen's config file.

RTF_EXTENSIONS_FILE    = 

#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------

# If the GENERATE_MAN tag is set to YES (the default) Doxygen will 
# generate man pages

GENERATE_MAN           = NO

# The MAN_OUTPUT tag is used to specify where the man pages will be put. 
# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
# put in front of it. If left blank `man' will be used as the default path.

MAN_OUTPUT             = man

# The MAN_EXTENSION tag determines the extension that is added to 
# the generated man pages (default is the subroutine's section .3)

MAN_EXTENSION          = .3

# If the MAN_LINKS tag is set to YES and Doxygen generates man output, 
# then it will generate one additional man file for each entity 
# documented in the real man page(s). These additional files 
# only source the real man page, but without them the man command 
# would be unable to find the correct page. The default is NO.

MAN_LINKS              = NO

#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------

# If the GENERATE_XML tag is set to YES Doxygen will 
# generate an XML file that captures the structure of 
# the code including all documentation. Note that this 
# feature is still experimental and incomplete at the 
# moment.

GENERATE_XML           = NO

#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------

# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will 
# generate an AutoGen Definitions (see autogen.sf.net) file 
# that captures the structure of the code including all 
# documentation. Note that this feature is still experimental 
# and incomplete at the moment.

GENERATE_AUTOGEN_DEF   = NO

#---------------------------------------------------------------------------
# Configuration options related to the preprocessor   
#---------------------------------------------------------------------------

# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will 
# evaluate all C-preprocessor directives found in the sources and include 
# files.

ENABLE_PREPROCESSING   = YES

# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro 
# names in the source code. If set to NO (the default) only conditional 
# compilation will be performed. Macro expansion can be done in a controlled 
# way by setting EXPAND_ONLY_PREDEF to YES.

MACRO_EXPANSION        = NO

# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES 
# then the macro expansion is limited to the macros specified with the 
# PREDEFINED and EXPAND_AS_PREDEFINED tags.

EXPAND_ONLY_PREDEF     = NO

# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files 
# in the INCLUDE_PATH (see below) will be search if a #include is found.

SEARCH_INCLUDES        = YES

# The INCLUDE_PATH tag can be used to specify one or more directories that 
# contain include files that are not input files but should be processed by 
# the preprocessor.

INCLUDE_PATH           = 

# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard 
# patterns (like *.h and *.hpp) to filter out the header-files in the 
# directories. If left blank, the patterns specified with FILE_PATTERNS will 
# be used.

INCLUDE_FILE_PATTERNS  = 

# The PREDEFINED tag can be used to specify one or more macro names that 
# are defined before the preprocessor is started (similar to the -D option of 
# gcc). The argument of the tag is a list of macros of the form: name 
# or name=definition (no spaces). If the definition and the = are 
# omitted =1 is assumed.

PREDEFINED             = 

# If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then 
# this tag can be used to specify a list of macro names that should be expanded. 
# The macro definition that is found in the sources will be used. 
# Use the PREDEFINED tag if you want to use a different macro definition.

EXPAND_AS_DEFINED      = 

# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then 
# doxygen's preprocessor will remove all function-like macros that are alone 
# on a line, have an all uppercase name, and do not end with a semicolon. Such 
# function macros are typically used for boiler-plate code, and will confuse the 
# parser if not removed.

SKIP_FUNCTION_MACROS   = YES

#---------------------------------------------------------------------------
# Configuration::addtions related to external references   
#---------------------------------------------------------------------------

# The TAGFILES tag can be used to specify one or more tagfiles.

TAGFILES               = 

# When a file name is specified after GENERATE_TAGFILE, doxygen will create 
# a tag file that is based on the input files it reads.

GENERATE_TAGFILE       = 

# If the ALLEXTERNALS tag is set to YES all external classes will be listed 
# in the class index. If set to NO only the inherited external classes 
# will be listed.

ALLEXTERNALS           = NO

# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed 
# in the modules index. If set to NO, only the current project's groups will 
# be listed.

EXTERNAL_GROUPS        = YES

# The PERL_PATH should be the absolute path and name of the perl script 
# interpreter (i.e. the result of `which perl').

PERL_PATH              = /usr/bin/perl

#---------------------------------------------------------------------------
# Configuration options related to the dot tool   
#---------------------------------------------------------------------------

# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will 
# generate a inheritance diagram (in Html, RTF and LaTeX) for classes with base or 
# super classes. Setting the tag to NO turns the diagrams off. Note that this 
# option is superceded by the HAVE_DOT option below. This is only a fallback. It is 
# recommended to install and use dot, since it yield more powerful graphs.

CLASS_DIAGRAMS         = YES

# If set to YES, the inheritance and collaboration graphs will hide 
# inheritance and usage relations if the target is undocumented 
# or is not a class.

HIDE_UNDOC_RELATIONS   = YES

# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is 
# available from the path. This tool is part of Graphviz, a graph visualization 
# toolkit from AT&T and Lucent Bell Labs. The other options in this section 
# have no effect if this option is set to NO (the default)

HAVE_DOT               = NO

# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen 
# will generate a graph for each documented class showing the direct and 
# indirect inheritance relations. Setting this tag to YES will force the 
# the CLASS_DIAGRAMS tag to NO.

CLASS_GRAPH            = YES

# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen 
# will generate a graph for each documented class showing the direct and 
# indirect implementation dependencies (inheritance, containment, and 
# class references variables) of the class with other documented classes.

COLLABORATION_GRAPH    = YES

# If set to YES, the inheritance and collaboration graphs will show the 
# relations between templates and their instances.

TEMPLATE_RELATIONS     = YES

# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT 
# tags are set to YES then doxygen will generate a graph for each documented 
# file showing the direct and indirect include dependencies of the file with 
# other documented files.

INCLUDE_GRAPH          = YES

# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and 
# HAVE_DOT tags are set to YES then doxygen will generate a graph for each 
# documented header file showing the documented files that directly or 
# indirectly include this file.

INCLUDED_BY_GRAPH      = YES

# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen 
# will graphical hierarchy of all classes instead of a textual one.

GRAPHICAL_HIERARCHY    = YES

# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images 
# generated by dot. Possible values are png, jpg, or gif
# If left blank png will be used.

DOT_IMAGE_FORMAT       = png

# The tag DOT_PATH can be used to specify the path where the dot tool can be 
# found. If left blank, it is assumed the dot tool can be found on the path.

DOT_PATH               = 

# The DOTFILE_DIRS tag can be used to specify one or more directories that 
# contain dot files that are included in the documentation (see the 
# \dotfile command).

DOTFILE_DIRS           = 

# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width 
# (in pixels) of the graphs generated by dot. If a graph becomes larger than 
# this value, doxygen will try to truncate the graph, so that it fits within 
# the specified constraint. Beware that most browsers cannot cope with very 
# large images.

MAX_DOT_GRAPH_WIDTH    = 1024

# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height 
# (in pixels) of the graphs generated by dot. If a graph becomes larger than 
# this value, doxygen will try to truncate the graph, so that it fits within 
# the specified constraint. Beware that most browsers cannot cope with very 
# large images.

MAX_DOT_GRAPH_HEIGHT   = 1024

# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will 
# generate a legend page explaining the meaning of the various boxes and 
# arrows in the dot generated graphs.

GENERATE_LEGEND        = YES

# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will 
# remove the intermedate dot files that are used to generate 
# the various graphs.

DOT_CLEANUP            = YES

#---------------------------------------------------------------------------
# Configuration::addtions related to the search engine   
#---------------------------------------------------------------------------

# The SEARCHENGINE tag specifies whether or not a search engine should be 
# used. If set to NO the values of all tags below this one will be ignored.

SEARCHENGINE           = NO

# The CGI_NAME tag should be the name of the CGI script that 
# starts the search engine (doxysearch) with the correct parameters. 
# A script with this name will be generated by doxygen.

CGI_NAME               = search.cgi

# The CGI_URL tag should be the absolute URL to the directory where the 
# cgi binaries are located. See the documentation of your http daemon for 
# details.

CGI_URL                = 

# The DOC_URL tag should be the absolute URL to the directory where the 
# documentation is located. If left blank the absolute path to the 
# documentation, with file:// prepended to it, will be used.

DOC_URL                = 

# The DOC_ABSPATH tag should be the absolute path to the directory where the 
# documentation is located. If left blank the directory on the local machine 
# will be used.

DOC_ABSPATH            = 

# The BIN_ABSPATH tag must point to the directory where the doxysearch binary 
# is installed.

BIN_ABSPATH            = /usr/local/bin/

# The EXT_DOC_PATHS tag can be used to specify one or more paths to 
# documentation generated for other projects. This allows doxysearch to search 
# the documentation for these projects as well.

EXT_DOC_PATHS          = 


Node-path: trunk/capisuite/docs/Makefile.am
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 1002
Text-content-md5: 84dd6cf7d307380f4cfaaabea9edf63d
Content-length: 1012

PROPS-END
docdir = @docdir@
EXTRA_DIST = Doxyfile.in mainpage.doxy manual.docbook manual.README 

all: docs

docs: Doxyfile
	if test "x$(doxygen)" != "x"; then \
		$(doxygen) Doxyfile ;\
	fi

dist-hook: Doxyfile 
	$(doxygen) Doxyfile
	mkdir $(distdir)/reference
	cp $(srcdir)/reference/* $(distdir)/reference/ 
	mkdir $(distdir)/manual
	cp $(srcdir)/manual/* $(distdir)/manual/

Doxyfile: Doxyfile.in
	sed -e 's,@version\@,$(VERSION),g' \
	    -e 's,@capisuite_sources\@,$(top_srcdir)/src,g' \
	    -e 's,@srcdir\@,$(srcdir),g' $< >$@

install-data-local:
	$(mkinstalldirs) $(DESTDIR)$(docdir)/reference ; \
	(cd reference; for i in *; do \
		$(INSTALL_DATA) $$i $(DESTDIR)$(docdir)/reference/$$i  ;\
        done;) 
	$(mkinstalldirs) $(DESTDIR)$(docdir)/manual ; \
	(cd manual; for i in *; do \
                $(INSTALL_DATA) $$i $(DESTDIR)$(docdir)/manual/$$i  ;\
        done;)

uninstall-local:
	rm -rf $(DESTDIR)$(docdir) 

clean-local:
	rm -f Doxyfile

maintainer-clean-local:
	rm -rf reference manual;
 


Node-path: trunk/capisuite/docs/mainpage.doxy
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 353
Text-content-md5: 1bd6fab7469f5d47bdf568764c56b9ee
Content-length: 363

PROPS-END
/** @mainpage %CapiSuite Documentation

This is the reference manual describing the internal structures of %CapiSuite. If you're interested in developing,
you're right here. 
@htmlonly
If you "just" want to use it, please refer to <a href="../manual/index.html">../manual/index.html</a>.
@endhtmlonly
Thx!

@author Gernot Hillier <gernot@hillier.de>
*/


Node-path: trunk/capisuite/docs/manual.README
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 765
Text-content-md5: 161d318522fe09f1f57b76d390538d92
Content-length: 775

PROPS-END
The CapiSuite manual is written in the DocBook format. Only
read on if you want to change it. You'll need some knowledge
of DocBook and the appropriate tools for that.

Otherwise just use the prepared HTML documentation which
will be installed in your doc_dir when you do "make install".
Have a look into /usr/local/share/doc/capisuite/manual/
after the installation and please READ it. :-)

------ Only experts read on here, please ------

You can create HTML pages by using tools like xsltproc and
the DocBook stylesheets of Norman Walsh. 

An example of how to call xsltproc:

xsltproc -o manual/ /usr/share/sgml/docbook/docbook-xsl-stylesheets/xhtml/chunk.xsl manual.docbook

To validate the document, use e.g. xmllint:

xmllint --noout --valid manual.docbook



Node-path: trunk/capisuite/docs/manual.docbook
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 77511
Text-content-md5: e56d19afdb6b9b4177d3f426e75d04b1
Content-length: 77521

PROPS-END
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[
<!ENTITY cs "<application>CapiSuite</application>">
]>
<book lang="en">
<title>CapiSuite 0.4</title>
<subtitle><ulink url="http://www.capisuite.de"/></subtitle>


<bookinfo>
	<author>
		<firstname>Gernot</firstname><surname>Hillier</surname>
		<affiliation><address><email>gernot@hillier.de</email></address></affiliation>
	</author>
</bookinfo>


<preface id="intro"><title>Introduction</title>

	<sect1 id="welcome"><title>Welcome to &cs;</title>
		<para>Welcome to &cs;, a python-scriptable ISDN telecommunication suite. It uses the new CAPI interface for accessing
		your ISDN-hardware - so you'll need a card for which a CAPI compatible
		driver is available. Currently these are all cards manufactured by AVM
		and some Eicon cards.
		</para>

		<para>
		This manual should help you to be able to use &cs; as quick as possible.
		As I hate reading long documentation just as much as you do, let's jump
		right in.
		</para>
	</sect1>
	<sect1 id="whatis"><title>What the heck is "&cs;"?!</title>
		<para>&cs; tries to give the user the ability to code his own ISDN applications
		without having to fiddle around with all the dirty programming details like callback
		functions, data buffers, protocol settings and so on.</para>

		<para>I took a scripting language which is (in my opinion) very easy to understand,
		to use and to learn - especially for beginners: Python. I extended it with some
		functions providing the basic ISDN "building blocks" for the users application.
		Behind these functions the heart of &cs; implements all the dirty details
		a user isn't interested in. My goal was to make script-coding as
		simple as possible but to also give you the flexibility to realize what you
		want.</para>

		<para>To give you an impression, coding a simple answering machine is as easy as:

		<informalexample>
		<programlisting>def callIncoming (call, service, call_from, call_to):   # defines a function executed at incoming calls
        connect_voice (call, 10)                        # answer the call after 10 seconds
        audio_send (call, "my-announcement.la")         # wave file containing the announcement
        audio_send (call, "beep.la")                    # wave file containing BEEP
        audio_receive (call, "call.la", 10)             # record max. 10 seconds into call.la</programlisting>
		</informalexample>
		</para>

		<para>Of course some details are missing like creating a unique filename or storing
		the additional information (called and calling party numbers, time, ...) - but I assume
		you got my idea.</para>

		<para>And - don't be afraid - if you just want to have a normal answering machine or send and
		receive some fax documents, you can use the default scripts distributed with &cs;.
		They give you already some nice features - e.g. the answering machine is multi-user
		ready, supports automatic fax detection and remote inquiry functions. You'll only
		need to tell &cs; some details like your own number, record an own announcement
		and that's it.</para>

		<para>So &cs; is already equipped for your daily telecommunication needs - but if you don't
		like to do the things the way I do - just change it or completely do it on your
		own (and if you write nice scripts or have changes to my default scripts, I would
		love to get and perhaps make them available for all users if you don't mind).</para>

	</sect1>
	<sect1 id="manual"><title>Structure of the manual</title>
		<para>This manual is split into three big parts.</para>

		<para>The first part (<xref linkend="gettingstarted"/>) explains how you install &cs;, what
		you can do with the default scripts you have after installing it and how
		to configure them. No line of code will be presented here. If you just want
		to use the default scripts that should be all the reading you need.</para>

		<para>The second part (<xref linkend="userguide"/>) will tell you how to write your own scripts. It will
		give you a very, very small introduction into Python and a complete reference
		of the commands &cs; adds to it. Last, an overview over the default
		scripts is given which will tell you how they work so you can easily take them
		as starting points and/or examples for your own application.</para>

		<para>The last part (<xref linkend="develguide"/>) is intended for programmers who want to
		help in developing the &cs; core. It provides a rough overview of the internal
		structure of the program. All the rest is documented in doxygen pages, which give you
		a thorough description for each single class, method and attribute...</para>

		<para>There are also some additional parts containing "what I also wanted to mention":</para>

		<para>Look at @ref knownbugs to find a list of known problems and what you should do
		if you think you found a bug.</para>

		<para>As &cs; started as a diploma thesis, I want to thank all who helped me so far in this section
		 @ref blubber.</para>

		<para>When you want to code your own scripts or want to help in developing the &cs; core,
		you'll soon stumble upon some special ISDN and CAPI error codes, which are explained in
		<xref linkend="capicodes"/>.
		</para>

		<para>Hope I managed to whet your appetite - so let's now really start over to get you ready to
		use it.</para>
	</sect1>
</preface>

<chapter id="gettingstarted"><title>Getting Started</title>
	<sect1 id="install"><title>Requirements and installation of &cs;</title>

		<sect2 id="requirements"><title>Requirements</title>
			<sect3 id="require_hard"><title>Hardware and drivers</title>
				<para>As &cs; uses the CAPI (Common ISDN Application Programming Interface)
				for accessing your ISDN-hardware, you'll need a card for which a CAPI compatible 
				driver is available.</para>

				<para>Currently these are all cards manufactured by AVM and some Eicon cards.
				If you have one of the passive cards of AVM, you'll
				have to download and install their CAPI drivers - you can't use the
				drivers of the ISDN4Linux project included in the default Linux kernel yet.
				There are also some distributions (e.g. current versions of SuSE) which
				include the Capi4Linux drivers from AVM already - you'll only have to
				activate them (use YaST2 in SuSE Linux). If you own an active card of AVM
				(e.g. the B1, C2 or C4), then you'll have everything you need already installed.</para>

				<para>No, there's currently no way to get it working with the old ISDN4Linux interface.
				Perhaps there never will be one as the ISDN4Linux project will provide a CAPI
				compatible interface some near day in the future - so all supported ISDN cards
				will work with &cs; then. If you nevertheless want to write a backend for
				ISDN4Linux, just contact me - I'll be more than happy to help you with that.</para>

				<para>&cs; has mainly been tested on AVM ISDN cards, esp. the Fritz!PCI, the Fritz!USB and
				the B1 on the i386 platform but there should be no problem with other
				CAPI-compatible drivers for other cards or on other platforms. Nevertheless,
				some features aren't mandatory for all CAPI-compatible cards, so perhaps
				you may not be able to fax or to switch from voice to fax mode with all
				cards.</para>
			</sect3>
			<sect3 id="require_soft"><title>Software</title>
				<para>&cs; depends on some packages which must be installed before &cs; can be used.</para>

				<para>I will list them here with a short information why this packages are needed and where to
				find further information on how to install them. It may be always a good idea to check the
				installation tool of your favourite distribution first and see if they're included with it before
				trying to download and install them from the net. Don't be afraid, because there are so many -
				most of them will be included in nearly every distribution and perhaps are already installed on your system.</para>

				<variablelist>
					<varlistentry>
						<term>Python</term>
						<listitem><para>&cs; uses an embedded Python interpreter to interpret the given scripts -
							so you'll need an installed and working version of Python. This should be included
							in mostly every up-to-date Linux distribution. For further infos on Python, a nice
							tutorial and much more, please go to <ulink url="http://www.python.org"/></para>
						</listitem>
					</varlistentry>
					<varlistentry>
						<term>sox</term>
						<listitem><para>This is the swiss-knife for converting audio formats. It's not required
							by the &cs; core, but will be very helpful if you want to hear or record the
							voice files used for calls on your machine. It's also required if you want to
							use the default scripts of &cs;. I'll bet this is included in your distribution
							and most likely already installed on your system. Just try to start <command>sox</command>
							to get sure. You'll find more details on <ulink url="http://sox.sourceforge.net"/>
						</para></listitem>
					</varlistentry>
					<varlistentry>
						<term>sfftobmp</term>
						<listitem><para>&cs; will save fax files in the CAPI specific format Structured Fax File (SFF).
							sfftobmp is a small but useful converter to convert this files to more
							common formats like JPEG, TIFF or BMP. Get it on <ulink url="http://sfftools.sourceforge.net/sfftobmp.html"/>.
							It's again not needed by the &cs; core, but for the default scripts.</para>
						</listitem>
					</varlistentry>
					<varlistentry>
						<term>sffview</term>
						<listitem><para>This tool is a simple but useful SFF viewer. It's not needed by any
						&cs; component, but very useful if you just want to see a fax file without
						the need to convert it first. You can get it from <ulink url="http://sfftools.sourceforge.net/sffview.html"/>.</para>
						</listitem>
					</varlistentry>
					<varlistentry>
						<term>tiff2ps</term>
						<listitem><para>A small utility to convert TIFF files to the Postscript format. It's needed by
							the default script to convert faxes to PDF files (SFF->TIFF->PS->PDF :-} ).
							Surely already on your system. Details on <ulink url="http://www.libtiff.org"/>
						</para></listitem>
					</varlistentry>
					<varlistentry>
						<term>ps2pdf</term>
						<listitem><para>Again a small utility for the SFF->PDF chain - this time for the
							conversion of Adobe PostScript to Adobe PDF. It's part of Ghostscript, so
							you have it definitely already. (<ulink url="http://www.gnu.org/software/ghostscript/ghostscript.html"/>)
						</para></listitem>
					</varlistentry>
					<varlistentry>
						<term>current Ghostscript with cfax patch</term>
						<listitem><para>Current Ghostscript versions will include a device to create the above mentioned
							SFF files. If you have an older version, you'll need the patch from
							<ulink url="http://sfftools.sourceforge.net/ghostscript.html"/>. To see if your GhostScript
							version already has this patch, please call <command>gs --help</command> and see if you can
							find the device <literal>cfax</literal> in the long list of supported devices.</para>
						</listitem>
					</varlistentry>
				</variablelist>
			</sect3>
		</sect2>
		<sect2 id="install_install"><title>Installation</title>
			<para>First of all, I would suggest to check if your CAPI-driver is setup correctly.
			To do this, simply run <command>capiinfo</command> on a root shell.</para>

			<para>If you get many lines of output, your CAPI driver works. If you just get
			an error message, you'll have to install CAPI-compatible drivers. Refer
			to the documentation of your ISDN card vendor, your Linux distribution
			and/or some ISDN mailing lists for this, please. If you really can't find
			anyone to support you in doing this, you may ask on the &cs; mailing
			lists for support <emphasis>as last resort</emphasis>.</para>

			<para>The rest of the installation depends on wether you use binary or source
			packages for installing &cs;. If you don't want to change the
			&cs; sources, I would recommend you to use the binary packages
			when available for your distribution and platform.</para>

			<para>You can download both binary packages and sources from the download section on
			<ulink url="http://www.capisuite.de/download"/>. If you built up your own RPM packages
			for other distributions, please send me them and I'll copy them there...</para>

			<sect3 id="install_bin"><title>Installation from binary packages</title>

				<para>If you can get binary packages for your distribution and platform,
				I would advise to use them. Currently, there are only RPM packages
				for SuSE Linux available as this is the distribution I use (and BTW
				the company which paid and supported me to write &cs; as diploma
				thesis ;-) ).</para>

				<para>To install the &cs; RPM packages you can either use your favorite setup tool -
				either given by your distributor or the community - or you can do manually
				(as root):</para>

				<screen>rpm -Uvh capisuite-version.rpm</screen>

				<para>To install binary packages not in the RPM format, please refer to the
				documentation of you package manager.</para>

				<para>If you managed to install &cs; on a system not mentioned above,
				please tell me and I'll include the instructions here certainly.</para>

				<para>Now everything should be setup ready to run. So please read on in
				<xref linkend="csglobal"/>.</para>
			</sect3>

			<sect3 id="install_source"><title>Installation from the source packages</title>
				<para>If there are no binary packages you can use or if you like to do
				everything on your own, you can get the sources from the download section.</para>

				<para>Download the newest source tarball (capisuite-X.Y.tar.gz) from the
				&cs; homepage and copy it to some location. Go there and issue the following commands:</para>

				<screen
>./configure
make
su # get root now
make install</screen>

				<para>This will install &cs; completely in the <filename>/usr/local</filename>-tree. If you
				want it to stay in other directories, please see the commandline-help
				printed by

				<screen
>./configure --help</screen>

				for options to customize the installation directories.</para>
			</sect3>
			<sect3 id="install_CVS"><title>Installation from CVS</title>
				<para>If you want to live on the bleeding edge and always test the newest features,
				you may also checkout the current sources of &cs; from the CVS
				repository.</para>

				<para><emphasis>This is not recommended unless you want to test the newest features or
				want to help in developing &cs;! The sources in CVS may do anything,
				may not work or not even compile. Do this on your own risk!</emphasis></para>

				<para>You'll need installed and working versions of the usual development tools like
				autoconf, autoheader, automake, GNU make, gcc/g++ and also the components described
				above (esp. development packages of Python).</para>

				<para>If you want to build the documentation out of the sources, you'll also need
				Doxygen.</para>

				<para>For instructions on where to find the CVS repository and how to checkout
				the sources, please refer to the download section on the &cs; homepage
				on <ulink url="http://www.capisuite.de"/>.</para>

				<para>After you checked out the sources to some directory, please do

				<screen
>automake -a
autoreconf</screen>
				</para>

				<para>After that you can continue with the normal installation process as described in
				<xref linkend="install_source"/>.</para>


			</sect3>
		</sect2>
	</sect1>
	<sect1 id="csglobal"><title>How &cs; works, how it is configured and started</title>
		<para>First, let's start with a short introduction what &cs; actually
		is and how it works. After that, the configuration and startup of &cs;
		will be explained in short.</para>

		<sect2 id="howwork"><title>How does &cs; work?</title>
			<para>&cs; is a daemon (program which runs in the background) whos
			main task is to sit around and wait until a call is incoming.
			If this happens it will start a special Python script - the
			<emphasis>incoming script</emphasis> - and do what this script tells it, for example
			record a voice call to implement an answering machine.</para>

			<para>To also be able to issue outgoing calls, another script is called
			at regular intervals - the <emphasis>idle script</emphasis>. It can check any resource
			to get instructions for placing a call - one can for example imagine
			to check a special mail account or watch a special directory where
			tasks are placed by the user.</para>

			<para>So all user-visible actions and the behaviour of &cs; are defined
			in these two scripts.</para>

			<para>You'll need to do two things now:</para>

			<itemizedlist>
				<listitem><para>provide scripts by either</para>
					<itemizedlist>
						<listitem><para>using and configuring the default scripts distributed with &cs; or</para></listitem>
						<listitem><para>writing your own scripts (perhaps by using the default ones as templates)</para></listitem>
					</itemizedlist>
				</listitem>
				<listitem><para>configure &cs; itself and tell it where to find the two scripts</para></listitem>
			</itemizedlist>

			<para>This page concentrates on the general configuration of &cs; - that consists mainly of
			options telling it which scripts to use and where and how to log its activities. After
			that, some details about starting &cs; are described.</para>

			<para>The next pages will then introduce the standard scripts you already installed along with
			&cs; and tell you how to use the answering maching and fax functions provided
			by them.</para>

			<para>The details on how to write your own scripts are covered in another part of the
			documentation (<xref linkend="userguide"/>).</para>
		</sect2>
		<sect2 id="configcs"><title>Configuration of &cs;</title>
			<para>&cs; uses a general configuration file for the core functions. This file should
			be located in <filename>/etc/capisuite/capisuite.conf</filename> or <filename>/usr/local/etc/capisuite/capisuite.conf</filename>
			depending on how you installed &cs;.</para>

			<para>Most options are set to reasonable defaults already for using the standard scripts
			- so if you want you can also skip this section and read on in <xref linkend="startcs"/></para>

			<para>The options will be presented in brief here - for further details please
			refer to the comments in the configuration file itself.</para>

			<variablelist><title>Options available in capisuite.conf</title>
				<varlistentry>
					<term><option>incoming_script="/path/to/incoming.py"</option></term>
					<listitem><para>This option tells &cs; which script should be executed at incoming
						calls. Only change this if you want to use your own script.</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>idle_script="/path/to/idle.py"</option></term>
					<listitem><para>This option reflects the path and name of the idle script.
						This script is called in regular intervalls to check if any outgoing
						call should be done. As above, the default should be ok if you don't
						use your own script.</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>idle_script_interval="60"</option></term>
					<listitem><para>Here you can define how often the idle script should be executed. The
						number given is the interval between subsequent invocations in seconds.
						Lesser numbers give you quicker response to queued jobs but also a higher
						system load. The default should be ok in most cases.</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>log_file="/path/to/capisuite.log"</option></term>
					<listitem><para>This file will be used for all "normal" messages printed by
						&cs; telling you what it does. Error messages are written to a
						special log (see below).</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>log_level="1"</option></term>
					<listitem><para>You can define how detailled the log output of &cs; will be.
						The default will give you some informational messages for each
						incoming and outgoing call and should be enough for normal use. I would
						recommend to only increase it if you encounter some problems.
						Logs of higher level are mainly intended for developers, so just use
						them if you want to report a problem or have some know-how of the CAPI
						interface and the internals of &cs;.</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>log_error="/path/to/capisuite.error"</option></term>
					<listitem><para>All errors which &cs; detects internally and in your scripts
						will end up here. These were put to an extra file so that they don't
						get lost in the normal log. Please check this log regularly for any
						messages - especially when you encounter problems. Please report all
						messages you don't understand and which aren't caused by your
						own script-modifications to the &cs; team.</para></listitem>
				</varlistentry>
			</variablelist>
		</sect2>
		<sect2 id="startcs"><title>Startup of CapiSuite</title>
			<para>As &cs; is a daemon, it is normally activated during the system
			startup process. Just add a call to

			<screen><command>/path/to/capisuite -d</command></screen>

			in your startup scripts. In LSB conforming Linux distributions, you'll
			find the startup scripts in <filename>/etc/init.d</filename>. For detailled documentation
			how to add a service there please refer to the documentation of your
			distribution. There's an example startup script written for SuSE Linux included
			in the source distribution (see <filename>rc.capisuite</filename>) which should (hopefully)
			work with other LSB compliant distributions, too. If you need to modify it, I'll
			welcome your feedback and happily add instructions for other distributions here.</para>

			<para>If you use the right RPM packages of &cs;, the necessary scripts
			should already be included. For activating them, please use your
			distributors config tool. If you use the RPM distributed with SuSE Linux
			and want to stay with the default scripts, everything should work "out of the box".
			As soon as you have configured the default scripts, simply run
			<command>rccapisuite restart</command>.</para>

			<para>For debug puposes, you can also start capisuite manually at any time
			by just calling

			<screen><command>/path/to/capisuite</command></screen></para>

			<para>There are also some other commandline options available:</para>

			<variablelist>
				<title>commandline options of &cs;</title>
				<varlistentry>
					<term><option>--help, -h</option></term>
					<listitem><para>show a short summary of commandline options</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>--config=file, -c file</option></term>
					<listitem><para>use a custom configuration file instead
						of <filename>/etc/capisuite/capisuite.conf</filename> or
						<filename>/usr/local/etc/capisuite/capisuite.conf</filename>.</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>--daemon, -d</option></term>
					<listitem><para>run as daemon (used in your startup script, see above)</para></listitem>
				</varlistentry>
			</variablelist>
		</sect2>
	</sect1>
	<sect1 id="scripts"><title>Features and configuration of the default scripts</title>
		<para>As already written above, &cs; comes with default scripts
		giving you the most used communication functions of an answering machine
		and a fax device.</para>

		<para>This section should help you to use them for your daily needs.</para>

		<sect2 id="script_features"><title>Script features</title>
			<para>The scripts distributed with &cs; give you the following main
			functions:</para>

			<itemizedlist>
				<listitem>
					<para>multi-user answering machine</para>
					<itemizedlist>
						<listitem><para>different users using different numbers and different announcements are supported</para></listitem>
						<listitem><para>incoming calls are saved and sent to the user by email</para></listitem>
						<listitem><para>the delay until a call is accepted and the maximum record length are freely adjustable</para></listitem>
						<listitem><para>silence is detected and the call terminated after an adjustable silence time</para></listitem>
						<listitem><para>incoming fax calls are automatically detected by the CNG/CED signals and received</para></listitem>
						<listitem><para>comfortable, menu-controlled remote inquiry functions are supported telling you
							the date/time when the call was received and the called and calling numbers (currently only german).</para></listitem>
						<listitem><para>record your own announcement via the remote inquiry menu</para></listitem>
						<listitem><para>nearly each setting is configurable globally but can be overwritten for each user also</para></listitem>
					</itemizedlist>
				</listitem>
				<listitem>
					<para>fax machine</para>
					<itemizedlist>
						<listitem><para>different users using different numbers are supported for incoming faxes</para></listitem>
						<listitem><para>incoming faxes are stored and sent to the user by email</para></listitem>
						<listitem><para>command line tool for sending PostScript documents as fax included</para></listitem>
						<listitem><para>number of tries and delays for sending faxes freely configurable</para></listitem>
						<listitem><para>currently supports only one ISDN controller for outgoing faxes</para></listitem>
					</itemizedlist>
				</listitem>
			</itemizedlist>
		</sect2>

		<sect2 id="howscriptswork"><title>How the scripts work</title>
			<para>Here follows a rough overview of how the scripts work generally. I will only explain
			the behaviour which is important for the user here. If you want to understand the internals,
			please refer to @ref userguidescriptchapter</para>

			<para>When an incoming call is received, several lists for the different users are
			searched for the called number. The different users can define their own numbers in
			the configuration (see below). So the scripts decide by looking on the called number
			to which user the call destinates. If they find the number in the voice- or fax-number
			list of any user, they'll answer the call with this service and give the caller the possibility to
			leave his message or send his fax.</para>

			<para>The received document is then saved to a local directory in some native format
			and also converted to a well-known format and mailed to the user along with some
			details of the call. Voice calls are sent as a WAV attachment, while fax calls
			are sent as PDF documents attached to the mail.</para>

			<para>So you'll normally get your incoming calls as a mail to a specified address -
			but they're also saved in the local filesystem to be on the safe side.
			It's your task to delete old files you don't need any more - perhaps via
			some script called by a cronjob.</para>

			<para>There's also the possibility to do a remote inquiry on the answering machine
			via a normal phone. The caller is presented a menu where he can choose to record
			his announcement or to hear the saved voice calls. He will be told how many calls
			are available, from whom and when they were received and so on. He'll also be
			able to delete recorded calls he doesn't need any more.</para>

			<para>Another script will check a special queue directory for fax send jobs
			regularly. To put jobs in this directory, a special commandline tool is also
			provided. See <xref linkend="usingscripts"/> for further details on this.</para>
		</sect2>

		<sect2 id="script_config"><title>Script configuration</title>
			<para>There are some important options which the scripts need to know before you can use them -
			things like numbers and some details of how to handle the calls.</para>

			<para>These options are read from two configuration files. Each configuration file is divided into
			one or more sections. A section begins with the section name in square brackets like <literal>[section]</literal> 
			while the options are <literal>key="value"</literal> lines.</para>

			<para>Each file must have a special section called <literal>[GLOBAL]</literal> and one section
			for each user called <literal>[&lt;username&gt;]</literal> (with <literal>&lt;username&gt;</literal> being a
			valid system user).</para>

			<para>The <literal>[GLOBAL]</literal>-section defines some global options like
			pathnames and default settings for options users can change on their own. The user-sections
			hold all the options which belong to the particular user.</para>

			<para>All options for the two files are described in short below. For all details, please see the comments
			in the sample configuration files installed with &cs;.</para>

			<sect3 id="script_config_fax"><title>Configuration for fax service</title>
				<para>This file holds all available config options for the fax services (fax receive and send).</para>

				<para>It's read from <filename>/etc/capisuite/fax.conf</filename> or
				  <filename>/usr/local/etc/capisuite/fax.conf</filename> (depending on the installation).</para>

				<variablelist><title>available options for [GLOBAL] section in fax config</title>
					<varlistentry id="fax_spool_dir">
						<term><option>spool_dir="/path/to/spooldir/"</option></term>
						<listitem><para>This directory is used to archive sent (or failed) jobs. It must exist and
							the user &cs; runs as must have write permission to its subdirectories.
							Two subdirectories are used:</para>
							<variablelist>
								<varlistentry>
									<term><filename>spooldir/done/</filename></term>
									<listitem><para>Successfully finished jobs are moved to this directory.</para></listitem>
								</varlistentry>
								<varlistentry>
									<term><filename>spooldir/failed/</filename></term>
									<listitem><para>A job which has failed finally ends up here.</para></listitem>
								</varlistentry>
							</variablelist>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_user_dir">
						<term><option>fax_user_dir="/path/to/userdir/"</option></term>
						<listitem><para>This directory is used to save faxes to. It must exist and
							the user &cs; runs as must have write permission to it. It will contain
							one subdirectory for each configured user (named like his userid). The
							following subdirectories are used below the user-specific dir:</para>
							<variablelist>
								<varlistentry>
									<term><filename>user_dir/username/received/</filename></term>
									<listitem><para>Received faxes are saved here.</para></listitem>
								</varlistentry>
								<varlistentry>
									<term><filename>user_dir/username/sendq/</filename></term>
									<listitem><para>Fax files to be sent are queued here by <command>capisuitefax</command>.</para></listitem>
								</varlistentry>
							</variablelist>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_send_tries">
						<term><option>send_tries="10"</option></term>
						<listitem><para>When a fax can't be sent to the destination for any reason, it's tried for several times.
						This setting limits the number of tries. If all tries failed, the job will be considered
						failed, moved to the failed dir (see <xref linkend="fax_spool_dir"/>) and the user will get a mail.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_send_delays">
						<term><option>send_delays="60,60,60,300,300,3600,3600,18000,36000"</option></term>
						<listitem><para>When a fax can't be sent to the destination for any reason, it's tried again.
							This setting specifies the delays in seconds between subsequent tries. The different values are
							separated with commas and <emphasis>no blanks</emphasis>. The list should have send_tries-1
							(see <xref linkend="fax_send_tries"/>) values - if not, surplus entries are ignored and missing
							entries are filled up with the last value. The default should just be ok giving you increasing
							delays for up to 10 tries.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_send_controller">
						<term><option>send_controller="1"</option></term>
						<listitem><para>If you have more than one ISDN controller installed (some active cards for more than
							one basic rate interface like the AVM C2 or C4 are also represented as multiple controllers for
							CAPI applications like &cs;), you can decide which controller (and therefore which basic rate
							interface) should be used for sending your faxes. All controllers are numbered starting with 1.
							If you're not sure which controller has which number, increase the log level to at least 2
							in &cs; (see <xref linkend="configcs"/>), restart it and have a look in the log file where all
							controllers will be listed then. Unfortunately, &cs; isn't able to use more than one controller
							for sending faxes at the moment, so no list is allowed here. If you have only one controller,
							just leave it at <literal>1</literal></para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_outgoing_MSN">
						<term><option>outgoing_MSN="&lt;your MSN&gt;"</option></term>
						<listitem><para>This number is used as our own number for outgoing calls. If it's not given,
							the first number of fax_numbers is used (see <xref linkend="fax_numbers"/>). Please
							replace with one valid MSN of your ISDN interface or leave empty. This value can be
							overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_outgoing_timeout">
						<term><option>outgoing_timeout="60"</option></term>
						<listitem><para>Default setting which defines how many seconds we will wait for a successful connection after
							dialing the number. This value can be overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_stationID">
						<term><option>fax_stationID="&lt;your faxID&gt;"</option></term>
						<listitem><para>Default fax station ID to use when sending a fax document. The station ID is
							usually the number of your fax station in international format, so an example would be
							"+49 89 123456" for a number in Munich, Germany. Station IDs may only consist of the "+"-sign,
							spaces and the digits 0-9. The maximal length is 20. This value can be overwritten in the user
							sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_headline">
						<term><option>fax_headline="&lt;your faxheadline&gt;"</option></term>
						<listitem><para>Default fax headline to use when sending a fax document. Where and if this
							headline will be presented depends on the implementation of your CAPI driver. The headline
							should have a reasonable length to fit on the top of a page, but there's no definite limit
							given.</para>
						</listitem>
					</varlistentry>
				</variablelist>
				<variablelist><title>available options for user sections in fax config</title>
					<varlistentry>
						<term><option>outgoing_MSN</option></term>
						<listitem><para>User specific value for the global option <xref linkend="fax_outgoing_MSN"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>outgoing_timeout</option></term>
						<listitem><para>User specific value for the global option <xref linkend="fax_outgoing_timeout"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>fax_stationID</option></term>
						<listitem><para>User specific value for the global option <xref linkend="fax_stationID"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>fax_headline</option></term>
						<listitem><para>User specific value for the global option <xref linkend="fax_headline"/> above</para></listitem>
					</varlistentry>
					<varlistentry id="fax_numbers">
						<term><option>fax_numbers="&lt;number1&gt;,&lt;number2&gt;,..."</option></term>
						<listitem><para>A list containing the numbers on which this user wants to receive incoming fax calls.
							These numbers are used to differ between users - so the same number must not appear in more
							than one user section! The numbers are separated with commas and <emphasis>no blanks</emphasis>
							are allowed. The first number of the list also serves as our own number when
							sending a fax if outgoing_MSN is not set (see <xref linkend="fax_outgoing_MSN"/>)</para>
							<para>If you want to use the same number for receiving fax and voice calls, please
							<emphasis>do not</emphasis> enter it here. Use the voice_numbers option instead
							(see <xref linkend="voice_numbers"/>) - the answering machine has a built in fax detection
							and can also receive faxes.</para>
							<para>When this list is set to <literal>*</literal>,
							<emphasis>all</emphasis> incoming calls will be accepted for this user (use with care!).
							This is only useful for a setup with only one user which wants to receive any call as fax.
							</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_email">
						<term><option>fax_email=""</option></term>
						<listitem><para>If given, this string indicates an email-address where the received faxes and
							voice calls will be sent to. If it is empty, they will be sent to the user account on the
							system &cs; is running on. The address is also used to send status reports
							for sent fax jobs to. If you don't want emails to be sent at all, use the
							action option (see <xref linkend="fax_action"/>).</para>
						</listitem>
					</varlistentry>
					<varlistentry id="fax_action">
						<term><option>fax_action="MailAndSave"</option></term>
						<listitem><para>Here you can define what action will be taken when a call is received.
								Currently, three possible actions are supported:
								<variablelist>
									<varlistentry>
										<term><option>MailAndSave</option></term>
										<listitem><para>the received call will be mailed to the given address (see
											<xref linkend="fax_email"/> above) and saved to the user_dir (see <xref linkend="fax_user_dir"/>)
											</para>
										</listitem>
									</varlistentry>
									<varlistentry>
										<term><option>SaveOnly</option></term>
										<listitem><para>the call will be only saved to the user_dir (see <xref linkend="fax_user_dir"/>)</para>
										</listitem>
									</varlistentry>
								</variablelist>
							</para>
						</listitem>
					</varlistentry>
				</variablelist>
			</sect3>
			<sect3 id="script_config_voice"><title>Configuration for the answering machine</title>
				<para>This file holds all available config options for the answering machine.</para>

				<para>It's read from <filename>/etc/capisuite/answering_machine.conf</filename> or
				  <filename>/usr/local/etc/capisuite/answering_machine.conf</filename> (depending on the installation).</para>

				<variablelist><title>available options for [GLOBAL] section in answering machine config</title>
					<varlistentry id="voice_audio_dir">
						<term><option>audio_dir="/path/to/audiodir/"</option></term>
						<listitem><para>The answering machine script uses several wave files, for example
							a global announcement if the user hasn't set his own and some spoken word fragments
							for the remote inquiry and the menu presented there. These audio files are searched
							in this directory. If user_audio_files is enabled (see <xref linkend="voice_user_audio_files"/>), each user can also
							provide his own audio snippets in his user_dir (see <xref linkend="voice_user_dir"/>).</para></listitem>
					</varlistentry>
					<varlistentry id="voice_user_dir">
						<term><option>voice_user_dir="/path/to/userdir/"</option></term>
						<listitem><para>This directory is used to save user specific data to. It must exist and
							the user &cs; runs as must have write permission to it. It will contain
							one subdirectory for each configured user (named like his userid). The
							following subdirectories are used below the user-specific dir:</para>
							<variablelist>
								<varlistentry>
									<term><filename>user_dir/username/</filename></term>
									<listitem><para>Here the user may provide his own audio_files
									(see also option <xref linkend="voice_user_audio_files"/> above).
									The user defined announcement is also saved here.</para></listitem>
								</varlistentry>
								<varlistentry>
									<term><filename>user_dir/username/received/</filename></term>
									<listitem><para>Received voice calls are saved here.</para></listitem>
								</varlistentry>
							</variablelist>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_user_audio_files">
						<term><option>user_audio_files="1"</option></term>
						<listitem><para>If set to <literal>1</literal>, each user may provide his own audio files
						in his user directory (see <xref linkend="voice_user_dir"/>). If set to <literal>0</literal>,
						only the audio_dir (see <xref linkend="voice_audio_dir"/>) will be searched.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_delay">
						<term><option>voice_delay="15"</option></term>
						<listitem><para>Sets the default value for the delay for accepting an incoming
							call in (in seconds). A value of <literal>10</literal> means that the answering
							machine accepts incoming calls 10 seconds after the incoming connection request.
							This value can be overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_announcement">
						<term><option>announcement="announcement.la"</option></term>
						<listitem><para>Sets the default name for the announcement files for the users.
							The announcement is searched in user_dir/username/announcement then. If not found,
							a global announcement containing the called MSN will be played. This value can
							be overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_record_length">
						<term><option>record_length="60"</option></term>
						<listitem><para>Default setting for the maximum record length in seconds. This value can
							be overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_record_silence_timeout">
						<term><option>record_silence_timeout="5"</option></term>
						<listitem><para>Default setting for the record silence timeout in seconds. When set to a value
							greater than 0, the recording will be aborted if silence is detected for the given
							amount of seconds. Set this to 0 to disable it. This value can
							be overwritten in the user sections individually.</para>
						</listitem>
					</varlistentry>
				</variablelist>
				<variablelist><title>available options for user sections in answering machine config</title>
					<varlistentry>
						<term><option>voice_delay</option></term>
						<listitem><para>User specific value for the global option <xref linkend="voice_delay"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>announcement</option></term>
						<listitem><para>User specific value for the global option <xref linkend="voice_announcement"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>record_length</option></term>
						<listitem><para>User specific value for the global option <xref linkend="voice_record_length"/> above</para></listitem>
					</varlistentry>
					<varlistentry>
						<term><option>record_silence_timeout</option></term>
						<listitem><para>User specific value for the global option <xref linkend="voice_record_silence_timeout"/> above</para></listitem>
					</varlistentry>
					<varlistentry id="voice_numbers">
						<term><option>voice_numbers="&lt;number1&gt;,&lt;number2&gt;,..."</option></term>
						<listitem><para>A list containing the numbers on which this user wants to receive incoming voice calls.
							These numbers are used to differ between users - so the same number must not appear in more
							than one user section! The numbers are separated with commas and <emphasis>no blanks</emphasis>
							are allowed. The answering machine script does also automatic fax detection, so a fax can
							also be sent to this number. When this list is set to <literal>*</literal>,
							<emphasis>all</emphasis> incoming calls will be accepted for this user (use with care!).
							This is only useful for a setup with only one user which wants to receive any call.</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_email">
						<term><option>voice_email=""</option></term>
						<listitem><para>If given, this string indicates an email-address where the received faxes and
							voice calls will be sent to. If it is empty, they will be sent to the user account on the
							system &cs; is running on. The address is also used to send status reports
							for sent fax jobs to. If you don't want emails to be sent at all, use the
							action option (see <xref linkend="voice_action"/>).</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_pin">
						<term><option>pin="&lt;your PIN&gt;"</option></term>
						<listitem><para>The answering machine also supports a remote inquiry function.
							This function is used by entering a PIN (Personal Identification Number)
							while the announcement is played. This PIN can be setup here.
							If you don't want to use the remote inquiry function, just use an empty
							PIN setting. The PIN doesn't have a maximal length - but perhaps you should
							not use 200 digits or you perhaps won't be able to remember them (I won't at least). ;-)</para>
						</listitem>
					</varlistentry>
					<varlistentry id="voice_action">
						<term><option>voice_action="MailAndSave"</option></term>
						<listitem><para>Here you can define what action will be taken when a call is received.
								Currently, three possible actions are supported:
								<variablelist>
									<varlistentry>
										<term><option>MailAndSave</option></term>
										<listitem><para>the received call will be mailed to the given address (see
											<xref linkend="voice_email"/> above) and saved to the user_dir (see <xref linkend="voice_user_dir"/>)
											</para>
										</listitem>
									</varlistentry>
									<varlistentry>
										<term><option>SaveOnly</option></term>
										<listitem><para>the call will be only saved to the user_dir (see <xref linkend="voice_user_dir"/>)</para>
										</listitem>
									</varlistentry>
									<varlistentry>
										<term><option>None</option></term>
										<listitem><para>only the announcement will be played - no voice file will
											be recorded</para>
										</listitem>
									</varlistentry>
								</variablelist>
							</para>
						</listitem>
					</varlistentry>
				</variablelist>
			</sect3>
		</sect2>
		<sect2 id="deleteoldfiles"><title>Deleting old files</title>

			<para>As written above, all incoming and outgoing calls will be saved on
			the local file system to assure nothing gets lost. There's no cleaning
			up done by &cs;, so these files will stay forever on your system
			if you don't clean them up from time to time.</para>

			<para>As it's not very convenient to do this manually, I would advise to
			automate this process. <application>cron</application> is predestinated for
			such a task. On most modern GNU/Linux distributions, you can simply place
			scripts in <filename>/etc/cron.daily</filename> and they will be called
			automatically once a day.</para>

			<para>An example for a bash script you can use is also in the &cs; distribution.
			Just copy <filename>capisuite.cron</filename> to <filename>/etc/cron.daily/capisuite</filename>
			and assure it has correct permissions (owner root, executable bit set).</para>

			<para>Now create a file <filename>cronjob.conf</filename> holding a line like

			<screen>MAX_DAYS=30</screen>

			in your &cs; configuration directory (usually <filename>/etc/capisuite</filename>
			or <filename>/usr/local/etc/capisuite</filename>). This tells the cron job how
			long the files should be stored. Each file which wasn't accessed in the
			last <literal>MAX_DAYS</literal> days will be deleted when 
			<filename>/etc/cron.daily/capisuite</filename> is started. If 
			<literal>MAX_DAYS</literal> is set to 0, no cleaning up is done. You can
			also place a <filename>cronjob.conf</filename> file with an own value for
			<literal>MAX_DAYS</literal> in each directory which is cleaned up.</para>
		</sect2>
	</sect1>
	<sect1 id="usingscripts"><title>Using &cs; together with the default scripts</title>
		<sect2 id="usingscripts_receive"><title>Receiving calls</title>
			<para>Now this is a nice, short section. Once you have configured
			&cs;, the scripts and started &cs; successfully, there's nothing
			more you have to do. You'll get your mails as described in
			<xref linkend="howscriptswork"/> and that's it. You only have
			to setup your mail program to receive local mails. Enjoy! :-)</para>
		</sect2>
		<sect2 id="usingscripts_remoteinquiry"><title>Doing a remote inquiry</title>
			<para>To do a remote inquiry, please enter your PIN (see <xref linkend="voice_pin"/>)
			while the announcement of the answering machine is played. After some seconds
			you will get a "voice menu" telling you how to record your own announcement
			for your answering machine or how to playback the received calls.</para>
		</sect2>
		<sect2 id="usingscripts_send"><title>Sending fax jobs</title>
			<para>The default scripts for &cs; also include a commandline
			tool for sending faxes called <command>capisuitefax</command>.</para>

			<para><command>capisuitefax</command> will be called with some parameters
			telling it which file to send (it currently only supports PostScript files)
			and to which number. It will then enqueue the job converted to the
			right format into the send queue
			from which it's collected by another &cs; script and sent to the
			destination. If the sending was completed successfully or failed finally
			after trying for some times, the according user will get an email
			telling him what has happened.</para>

			<para>The following options are recognized by <command>capisuitefax</command>:</para>

			<screen>capisuitefax -d dialstring [-h] [-q] file1 [file2...]</screen>
			<variablelist>
				<varlistentry>
					<term><option>-d dialstring</option></term>
					<listitem><para>the number which should be called (destination of the fax)</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>-h</option></term>
					<listitem><para>show a short commandline help</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>-q</option></term>
					<listitem><para>be quiet, don't output informational messages</para></listitem>
				</varlistentry>
				<varlistentry>
					<term><option>file1 [file2...]</option></term>
					<listitem><para>one or more PostScript files to send to this destination (more than
					one PostScript file will produce several separate fax jobs)</para></listitem>
				</varlistentry>
			</variablelist>
		</sect2>
	</sect1>
</chapter>


<chapter id="userguide"><title>Users Guide</title>

		<para>In the last chapter you've seen how to use the default scripts distributed with &cs;.
		But the main goal in developing &cs; was not to provide a perfect ready-to-use
		application. I intended to develop a tool where you can write your <emphasis>own</emphasis>
		applications very easy. I'll show you how to do this in the next sections.</para>


	<sect1 id="ug_python"><title>Introduction to Python</title>

 		<para>As I tought about the scripting language I wanted to integrate into &cs;,
		my first idea was to develop an own, simple one. But as more as I looked into it, as
		more I found that a general purpose language having common features already will be much
		more helpful than re-inventing every wheel that I would need. So I looked for some
		easy to integrate (and to learn) language. The one I liked most was Python - and it
		also had a nice documentation about embedding, so I chose it and I'm still happy about
		that decision. :-)</para>

		<para>So the first thing you'll have to do is to learn a little bit of Python. Don't be afraid -
		it was developed as a beginners language and Guido (Guido van Rossum, the inventor of Python)
		has done very well in my opinion.</para>

		<para>In the next few sections, I'll give you a short introduction to the features of Python
		you most probably will need for &cs;. As this shouldn't be a manual about Python or a tutorial
		in computer programming, I assume you're already familiar with the basic concepts of todays
		wide-spread procedural and object-oriented languages.</para>

		<para>If not, I would advise you to get and read a book for learning Python - there are many
		available in different languages - or to have a look on the Python home page on
		<ulink url="http://www.python.org"/> where nice and comprehensive manuals and tutorials are
		available for free.</para>
		
		<sect2 id="python_basics"><title>Python Basics</title>
		
		<para>Python supports most features you know from other common languages. So here's the
		syntax of the basic operations shown in a Python session. A python session is another
		fine feature of its interpreter: just start it by typing <command>python</command>
		in a shell and you'll get the prompt of Python:</para>
		
		<screen></screen>

		</sect2>
	</sect1>
	<sect1 id="fileformats"><title>Used file formats</title>
		<para>&cs; always reads and saves files in the native format as they will be expected and given
		by the CAPI ISDN drivers. This preserves it from having to convert everything from and to other
		formats thus reducing unnecessary overhead.</para>

		<para>As these formats aren't that well-known and you will need special tools to convert or
		view/play them, I'll give you a short overview of how you can do this.</para>

		<para>All tools which I refer to here are described in <xref linkend="require_soft"/>. See
		there for informations how to get them.</para>

		<sect2 id="voice_fileformat"><title>Format for voice files (inversed A-Law, 8kHz, mono)</title>
			<para>ISDN transmits voice data as waves with a sample-rate of 8kHz in mono. To
			save bandwith, a compression called A-Law is used (at least in Europe, other countries
			like the USA use u-Law which is quite similar to A-Law). For any reason
			beyond my understanding, they use a bit-reversed form of A-Law called
			inversed A-Law.</para>

			<sect3 id="creating_alaw"><title>Creating A-Law files</title>

				<para>There are two possible ways to create A-Law files.</para>

				<para>The first one is to call your computer with your phone (either use the default answering
				machine script and configure it as described in <xref linkend="script_config_voice"/>
				or write a simple script yourself), record whatever you want and take the created
				output file (when you use the default scripts please take the file from the
				user_dir, not the attachment of the mail as this is already converted) and use it.</para>

				<para>You eventually want to trim the recorded file and remove unwanted
				noise and silence at the beginning and the end. This can easily be done
				by <command>sox</command> and <command>play</command> (which comes together
				with <command>sox</command>).</para>

				<para><command>sox</command> is used to convert a file while <command>play</command>
				is used to just play it. Both support the same effects including the trim option.
				Both also detect what type of file you are using by looking at the suffix of
				your file name. So all your inversed A-Law files should be named <filename>something.la</filename>
				(<filename>.la</filename> is the inversed form of <filename>.al</filename> which stands for A-Law).</para>

				<para>So let's first try to find the optimal values for the trim effect by calling
				<command>play:</command></para>

				<screen><command>play myfile.la trim &lt;start-offset&gt; &lt;duration&gt;</command></screen>

				<para>Now play around with start-offset and duration (both given in seconds) until
				you find the right values. If you found them, you can use <command>sox</command>
				to actually produce the needed file:</para>

				<screen><command>sox myfile.la outfile.la trim &lt;start-offset&gt; &lt;duration&gt;</command></screen>

				<para>You'll now get a file named <filename>outfile.la</filename> which should
				contain what you want.</para>

				<para>The second way to create an inversed A-Law file is to record a normal WAV-file
				with your favourite sound-tools and convert it to the destination format using
				<command>sox</command>. You'll get the best results when your WAV file already
				is in 8kHz, mono, 8 bit format. <command>sox</command> is able to convert
				other waves if necessary but this usually will result in bad quality.</para>

				<para>Now you can convert the WAV to inversed A-Law by calling:</para>

				<screen><command>sox myfile.wav -r 8000 -c 1 -b outfile.la</command></screen>

			</sect3>
			<sect3 id="playing_alaw"><title>Playing A-Law files</title>
				<para>Again, there are two possibilities. The <command>play</command> command
				of <command>sox</command> is able to just play the inversed A-Law format without
				any conversion. Just call <command>play</command> with the filename as parameter:</para>

				<screen><command>play myfile.la</command></screen>

				<para>But you can also use sox to convert the A-Law files to the more common
				WAV format by just invoking:</para>

				<screen><command>sox myfile.la outfile.wav</command></screen>

				<para>The created <filename>outfile.wav</filename> can be played
				by nearly any audio player without problems.</para>
			</sect3>
		</sect2>
		<sect2 id="fax_fileformat"><title>Format of fax files (Structured Fax Files)</title>
			<para>CAPI-compliant drivers will expect and provide fax files in a so called
			Structured Fax File (SFF). As this seems to be a CAPI-specific format, there
			are not much tools out there for GNU/Linux which are capable of handling it.
			Finally I found some small tools written by Peter Sch&auml;fer, so
			we can use them thankfully :-).</para>

			<sect3 id="create_sff"><title>Creating a SFF</title>
				<para>In current Ghostscript releases, a patch from Peter has been
				included to produce SF files. To see if your Ghostscript already
				supports it, enter <command>gs --help</command> and look for
				the so-called <command>cfax</command>-device in the long device list
				presented to you. If it's not listed, you have to take a newer Ghostscript
				or recompile it, sorry. I don't know any other w