Moving doc/system.conf to system.conf.sample to remain consistent with the

other default/sample configuration files.


git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@4597 a0bf4364-ded3-4de4-8d8a-66a801d63aff

1 files changed, 0 insertions, 309 deletions

diff --git a/doc/system.conf b/doc/system.conf
deleted file mode 100644
index 1fd54a9..0000000
--- a/doc/system.conf
+++ /dev/null
@@ -1,309 +0,0 @@
-#
-# DAHDI Configuration File
-#
-# This file is parsed by the DAHDI Configurator, dahdi_cfg
-#
-# Span Configuration
-# ~~~~~~~~~~~~~~~~~~
-# First come the span definitions, in the format
-# 
-#   span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
-#
-# All T1/E1 spans generate a clock signal on their transmit side. The
-# <timing source> parameter determines whether the clock signal from the far
-# end of the T1/E1 is used as the master source of clock timing. If it is, our
-# own clock will synchronise to it. T1/E1's connected directly or indirectly to
-# a PSTN provider (telco) should generally be the first choice to sync to. The
-# PSTN will never be a slave to you. You must be a slave to it.
-#
-# Choose 1 to make the equipment at the far end of the E1/T1 link the preferred
-# source of the master clock. Choose 2 to make it the second choice for the master
-# clock, if the first choice port fails (the far end dies, a cable breaks, or
-# whatever). Choose 3 to make a port the third choice, and so on. If you have, say,
-# 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
-# port should be different.
-#
-# If you choose 0, the port will never be used as a source of timing. This is
-# appropriate when you know the far end should always be a slave to you. If the
-# port is connected to a channel bank, for example, you should always be its
-# master. Any number of ports can be marked as 0.
-#
-# Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
-# faxes, unreliable modem operation, and is a general all round bad thing.
-#
-# The line build-out (or LBO) is an integer, from the following table:
-#
-#  0: 0 db (CSU) / 0-133 feet (DSX-1)
-#  1: 133-266 feet (DSX-1)
-#  2: 266-399 feet (DSX-1)
-#  3: 399-533 feet (DSX-1)
-#  4: 533-655 feet (DSX-1)
-#  5: -7.5db (CSU)
-#  6: -15db (CSU)
-#  7: -22.5db (CSU)
-#
-# framing:: 
-#   one of 'd4' or 'esf' for T1 or 'cas' or 'ccs' for E1 and BRI.
-#  'd4' could be referred to as 'sf' or 'superframe'
-#
-# coding:: 
-#   one of 'ami' or 'b8zs' for T1 or 'ami' or 'hdb3' for E1 and BRI.
-#   * For E1 there is the optional keyword 'crc4' to enable CRC4 checking.
-#   * If the keyword 'yellow' follows, yellow alarm is transmitted when no
-#     channels are open.
-#
-#span=1,0,0,esf,b8zs
-#span=2,1,0,esf,b8zs
-#span=3,0,0,ccs,hdb3,crc4
-#
-# Dynamic Spans
-# ~~~~~~~~~~~~~
-# Next come the dynamic span definitions, in the form:
-# 
-#   dynamic=<driver>,<address>,<numchans>,<timing>
-#
-# Where <driver> is the name of the driver (e.g. eth), <address> is the
-# driver specific address (like a MAC for eth), <numchans> is the number
-# of channels, and <timing> is a timing priority, like for a normal span.
-# use "0" to not use this as a timing source, or prioritize them as
-# primary, secondard, etc.  Note that you MUST have a REAL DAHDI device
-# if you are not using external timing.
-#
-#   dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
-#
-# If a non-zero timing value is used, as above, only the last span should
-# have the non-zero value. 
-#
-# Channel Configuration
-# ~~~~~~~~~~~~~~~~~~~~~
-# Next come the definitions for using the channels.  The format is:
-# <device>=<channel list>
-#
-# Valid devices are:
-#
-# e&m::
-#   Channel(s) are signalled using E&M signalling (specific
-#   implementation, such as Immediate, Wink, or Feature Group D
-#   are handled by the userspace library).
-# fxsls:: 
-#   Channel(s) are signalled using FXS Loopstart protocol.
-# fxsgs:: 
-#   Channel(s) are signalled using FXS Groundstart protocol.
-# fxsks:: 
-#   Channel(s) are signalled using FXS Koolstart protocol.
-# fxols:: 
-#   Channel(s) are signalled using FXO Loopstart protocol.
-# fxogs:: 
-#   Channel(s) are signalled using FXO Groundstart protocol.
-# fxoks:: 
-#   Channel(s) are signalled using FXO Koolstart protocol.
-# sf:: 
-#   Channel(s) are signalled using in-band single freq tone. 
-#   Syntax as follows: 
-#    
-#     channel# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
-#   
-#   rxfreq is rx tone freq in Hz, rxbw is rx notch (and decode)
-#   bandwith in hz (typically 10.0), rxflag is either 'normal' or
-#   'inverted', txfreq is tx tone freq in hz, txlevel is tx tone 
-#   level in dbm, txflag is either 'normal' or 'inverted'. Set 
-#   rxfreq or txfreq to 0.0 if that tone is not desired.
-#
-# unused:: 
-#   No signalling is performed, each channel in the list remains idle
-# clear::
-#   Channel(s) are bundled into a single span.  No conversion or
-#   signalling is performed, and raw data is available on the master.
-# bchan:: 
-#   Like 'clear' except all channels are treated individually and
-#   are not bundled.  'inclear' is an alias for this.
-# rawhdlc::
-#   The DAHDI driver performs HDLC encoding and decoding on the 
-#   bundle, and the resulting data is communicated via the master
-#   device.
-# dchan::
-#   The DAHDI driver performs HDLC encoding and decoding on the
-#   bundle and also performs incoming and outgoing FCS insertion
-#   and verification.  'fcshdlc' is an alias for this.
-# hardhdlc::
-#   The hardware driver performs HDLC encoding and decoding on the
-#   bundle and also performs incoming and outgoing FCS insertion
-#   and verification.  Is subject to limitations and support of underlying
-#   hardware.
-# nethdlc::
-#   The DAHDI driver bundles the channels together into an
-#   hdlc network device, which in turn can be configured with
-#   sethdlc (available separately). In 2.6.x kernels you can also optionally
-#   pass the name for the network interface after the channel list.
-#   Syntax:
-#   
-#     nethdlc=<channel list>[:interface name]
-#   Use original names, don't use the names which have been already registered 
-#   in system e.g eth.
-#
-# dacs::
-#   The DAHDI driver cross connects the channels starting at
-#   the channel number listed at the end, after a colon
-# dacsrbs::
-#   The DAHDI driver cross connects the channels starting at
-#   the channel number listed at the end, after a colon and 
-#   also performs the DACSing of RBS bits
-#
-# The channel list is a comma-separated list of channels or ranges, for
-# example:
-#
-#   1,3,5 (channels one, three, and five)
-#   16-23, 29 (channels 16 through 23, as well as channel 29)
-#
-# So, some complete examples are:
-#
-#   e&m=1-12
-#   nethdlc=13-24
-#   fxsls=25,26,27,28
-#   fxols=29-32
-#
-#fxoks=1-24
-#bchan=25-47
-#dchan=48
-#fxols=1-12
-#fxols=13-24
-#e&m=25-29
-#nethdlc=30-33
-#clear=44
-#clear=45
-#clear=46
-#clear=47
-#fcshdlc=48
-#dacs=1-24:48
-#dacsrbs=1-24:48
-#
-# Tone Zone Data
-# ~~~~~~~~~~~~~~
-# Finally, you can preload some tone zones, to prevent them from getting
-# overwritten by other users (if you allow non-root users to open /dev/dahdi/*
-# interfaces anyway.  Also this means they won't have to be loaded at runtime.
-# The format is "loadzone=<zone>" where the zone is a two letter country code.
-# 
-# You may also specify a default zone with "defaultzone=<zone>" where zone
-# is a two letter country code.
-#
-# An up-to-date list of the zones can be found in the file zonedata.c
-#
-loadzone = us
-#loadzone = us-old
-#loadzone=gr
-#loadzone=it
-#loadzone=fr
-#loadzone=de
-#loadzone=uk
-#loadzone=fi
-#loadzone=jp
-#loadzone=sp
-#loadzone=no
-#loadzone=hu
-#loadzone=lt
-#loadzone=pl
-defaultzone=us
-#
-# PCI Radio Interface
-# ~~~~~~~~~~~~~~~~~~~
-# (see http://www.zapatatelephony.org/app_rpt.html)
-#
-# The PCI Radio Interface card interfaces up to 4 two-way radios (either
-# a base/mobile radio or repeater system) to DAHDI channels. The driver
-# may work either independent of an application, or with it, through
-# the driver;s ioctl() interface. This file gives you access to specify
-# load-time parameters for Radio channels, so that the driver may run
-# by itself, and just act like a generic DAHDI radio interface.
-#
-# Unlike the rest of this file, you specify a block of parameters, and
-# then the channel(s) to which they apply. CTCSS is specified as a frequency
-# in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS
-# for receive is specified as the code directly, for example 223. DCS for
-# transmit is specified as D and then the code, for example D223.
-#
-# The hardware supports a "community" CTCSS decoder system that has
-# arbitrary transmit CTCSS or DCS codes associated with them, unlike
-# traditional "community" systems that encode the same tone they decode.
-# 
-# this example is a single tone DCS transmit and receive
-#
-# specify the transmit tone (in DCS mode this stays constant):
-#tx=D371
-#
-# specify the receive DCS code:
-#dcsrx=223
-#
-# this example is a "community" CTCSS (if you only want a single tone, then
-# only specify 1 in the ctcss list)
-#
-# specify the default transmit tone (when not receiving):
-#tx=1000
-#
-# Specify the receive freq, the tag (use 0 if none), and the transmit code.
-# The tag may be used by applications to determine classification of tones.
-# The tones are to be specified in order of presedence, most important first.
-# Currently, 15 tones may be specified..
-#
-#ctcss=1318,1,1318
-#ctcss=1862,1,1862
-#
-# The following parameters may be omitted if their default value is acceptible
-#
-# Set the receive debounce time in milliseconds:
-#debouncetime=123
-#
-# set the transmit quiet dropoff burst time in milliseconds:
-#bursttime=234
-#
-# set the COR level threshold (specified in tenths of millivolts)
-# valid values are {3125,6250,9375,12500,15625,18750,21875,25000}
-#corthresh=12500
-#
-# Invert COR signal {y,n}
-#invertcor=y
-# Set the external tone mode; yes, no, internal {y,n,i}
-#exttone=y
-#
-# Now apply the configuration to the specified channels:
-#
-# We are all done with our channel parameters, so now we specify what
-# channels they apply to
-#channels=1-4
-#
-# Overiding PCM encoding
-# ~~~~~~~~~~~~~~~~~~~~~~
-# Usually the channel driver sets the encoding of the PCM for the
-# channel (mulaw / alaw. That is: g711u or g711a). However there are
-# some cases where you would like to override that. 'mulaw' and 'alaw'
-# set different such encoding. Use them for channels you have already
-# defined with e.g. 'bchan' or 'fxoks'.
-#mulaw=1-4
-#alaw=1-4
-#
-# 'deflaw' is similar, but resets the encoding to the channel driver's
-# default. It must be useful for something, I guess.
-#mulaw=1-10
-#deflaw=5
-#
-# Configuring modular echo cancellers
-# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-# DAHDI uses modular echocancellers that are configured per channel.  
-# The echo cancellers are compiled and configured as part of the 
-# dahdi-linux package.  You can specify in this file the default echo
-# canceller to use for a given zap channel.  The default behavior is for there
-# to be no default echo cancellers.
-#
-# Valid echo cancellers are: jpah, kb1, mg2, sec2, and sec.
-# If compiled, 'hpec' is also a valid echo canceller.
-# 
-# To configure the default echo cancellers, use the format:
-# echocanceller=<echocanceller name>,<channel(s)>
-#
-# Example:
-# Configure channels 1 through 8 to use the mg2 echocanceller
-# echocanceller=mg2,1-8 
-#
-# And change channel 2 to use the kb1 echocanceller.
-# echocanceller=kb1,2
-#