From 6b593940a32b71311e93d10e392590b835a257a1 Mon Sep 17 00:00:00 2001 From: Shaun Ruffell Date: Thu, 10 Jul 2008 16:45:14 +0000 Subject: 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 --- doc/system.conf | 309 -------------------------------------------------------- 1 file changed, 309 deletions(-) delete mode 100644 doc/system.conf (limited to 'doc') 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=,,,,[,yellow] -# -# All T1/E1 spans generate a clock signal on their transmit side. The -# 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=,
,, -# -# Where is the name of the driver (e.g. eth),
is the -# driver specific address (like a MAC for eth), is the number -# of channels, and 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: -# = -# -# 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 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=[: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=" where the zone is a two letter country code. -# -# You may also specify a default zone with "defaultzone=" 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=, -# -# 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 -# -- cgit v1.2.3