xpp: support loading Octasic EC firmware
[dahdi/tools.git] / system.conf.sample
1 #
2 # DAHDI Configuration File
3 #
4 # This file is parsed by the DAHDI Configurator, dahdi_cfg
5 #
6 # Span Configuration
7 # ^^^^^^^^^^^^^^^^^^
8 # First come the span definitions, in the format
9
10 #   span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
11 #
12 # All T1/E1/BRI spans generate a clock signal on their transmit side. The
13 # <timing source> parameter determines whether the clock signal from the far
14 # end of the T1/E1/BRI is used as the master source of clock timing. If it is, our
15 # own clock will synchronise to it. T1/E1/BRI connected directly or indirectly to
16 # a PSTN provider (telco) should generally be the first choice to sync to. The
17 # PSTN will never be a slave to you. You must be a slave to it.
18 #
19 # Choose 1 to make the equipment at the far end of the E1/T1/BRI link the preferred
20 # source of the master clock. Choose 2 to make it the second choice for the master
21 # clock, if the first choice port fails (the far end dies, a cable breaks, or
22 # whatever). Choose 3 to make a port the third choice, and so on. If you have, say,
23 # 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
24 # port should be different.
25 #
26 # If you choose 0, the port will never be used as a source of timing. This is
27 # appropriate when you know the far end should always be a slave to you. If
28 # the port is connected to a channel bank, for example, you should always be
29 # its master. Likewise, BRI TE ports should always be configured as a slave.
30 # Any number of ports can be marked as 0.
31 #
32 # Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
33 # faxes, unreliable modem operation, and is a general all round bad thing.
34 #
35 # NOTE: The B410P card cannot reliably connect one of its four ports
36 # configured in TE mode to another one configured in NT mode. It will not
37 # reliably sync clock from itself. Please use another physical card and
38 # configure one to provide clock and one to recover clock in any B410P test
39 # environments.
40 #
41 # The line build-out (or LBO) is an integer, from the following table:
42 #
43 #  0: 0 db (CSU) / 0-133 feet (DSX-1)
44 #  1: 133-266 feet (DSX-1)
45 #  2: 266-399 feet (DSX-1)
46 #  3: 399-533 feet (DSX-1)
47 #  4: 533-655 feet (DSX-1)
48 #  5: -7.5db (CSU)
49 #  6: -15db (CSU)
50 #  7: -22.5db (CSU)
51 #
52 # If the span is a BRI port the line build-out is not used and should be set
53 # to 0.
54 #
55 # framing:: 
56 #   one of 'd4' or 'esf' for T1 or 'cas' or 'ccs' for E1. Use 'ccs' for BRI.
57 #  'd4' could be referred to as 'sf' or 'superframe'
58 #
59 # coding:: 
60 #   one of 'ami' or 'b8zs' for T1 or 'ami' or 'hdb3' for E1. Use 'ami' for
61 #   BRI.
62 #
63 #   * For E1 there is the optional keyword 'crc4' to enable CRC4 checking.
64 #   * If the keyword 'yellow' follows, yellow alarm is transmitted when no
65 #     channels are open.
66 #
67 #span=1,0,0,esf,b8zs
68 #span=2,1,0,esf,b8zs
69 #span=3,0,0,ccs,hdb3,crc4
70 #
71 # Dynamic Spans
72 # ^^^^^^^^^^^^^
73 # Next come the dynamic span definitions, in the form:
74
75 #   dynamic=<driver>,<address>,<numchans>,<timing>
76 #
77 # Where <driver> is the name of the driver (e.g. eth), <address> is the
78 # driver specific address (like a MAC for eth), <numchans> is the number
79 # of channels, and <timing> is a timing priority, like for a normal span.
80 # use "0" to not use this as a timing source, or prioritize them as
81 # primary, secondard, etc.  Note that you MUST have a REAL DAHDI device
82 # if you are not using external timing.
83 #
84 #   dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
85 #
86 # If a non-zero timing value is used, as above, only the last span should
87 # have the non-zero value. 
88 #
89 # Channel Configuration
90 # ^^^^^^^^^^^^^^^^^^^^^
91 # Next come the definitions for using the channels.  The format is:
92 # <device>=<channel list>
93 #
94 # Valid devices are:
95 #
96 # e&m::
97 #   Channel(s) are signalled using E&M signalling on a T1 line.
98 #   Specific implementation, such as Immediate, Wink, or Feature
99 #   Group D are handled by the userspace library.
100 # e&me1::
101 #   Channel(s) are signalled using E&M signalling on an E1 line.
102 # fxsls:: 
103 #   Channel(s) are signalled using FXS Loopstart protocol.
104 # fxsgs:: 
105 #   Channel(s) are signalled using FXS Groundstart protocol.
106 # fxsks:: 
107 #   Channel(s) are signalled using FXS Koolstart protocol.
108 # fxols:: 
109 #   Channel(s) are signalled using FXO Loopstart protocol.
110 # fxogs:: 
111 #   Channel(s) are signalled using FXO Groundstart protocol.
112 # fxoks:: 
113 #   Channel(s) are signalled using FXO Koolstart protocol.
114 # sf:: 
115 #   Channel(s) are signalled using in-band single freq tone. 
116 #   Syntax as follows: 
117 #    
118 #     channel# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
119 #   
120 #   rxfreq is rx tone freq in Hz, rxbw is rx notch (and decode)
121 #   bandwith in hz (typically 10.0), rxflag is either 'normal' or
122 #   'inverted', txfreq is tx tone freq in hz, txlevel is tx tone 
123 #   level in dbm, txflag is either 'normal' or 'inverted'. Set 
124 #   rxfreq or txfreq to 0.0 if that tone is not desired.
125 #
126 # unused:: 
127 #   No signalling is performed, each channel in the list remains idle
128 # clear::
129 #   Channel(s) are bundled into a single span.  No conversion or
130 #   signalling is performed, and raw data is available on the master.
131 # bchan:: 
132 #   Like 'clear' except all channels are treated individually and
133 #   are not bundled.  'inclear' is an alias for this.
134 # rawhdlc::
135 #   The DAHDI driver performs HDLC encoding and decoding on the 
136 #   bundle, and the resulting data is communicated via the master
137 #   device.
138 # dchan::
139 #   The DAHDI driver performs HDLC encoding and decoding on the
140 #   bundle and also performs incoming and outgoing FCS insertion
141 #   and verification.  'fcshdlc' is an alias for this. 
142 # hardhdlc::
143 #   The hardware driver performs HDLC encoding and decoding on the
144 #   bundle and also performs incoming and outgoing FCS insertion
145 #   and verification.  Is subject to limitations and support of underlying
146 #   hardware. BRI spans serviced by the wcb4xxp driver must use hardhdlc
147 #   channels for the signalling channels. 
148 # nethdlc::
149 #   The DAHDI driver bundles the channels together into an
150 #   hdlc network device, which in turn can be configured with
151 #   sethdlc (available separately). In 2.6.x kernels you can also optionally
152 #   pass the name for the network interface after the channel list.
153 #   Syntax:
154 #   
155 #     nethdlc=<channel list>[:interface name]
156 #   Use original names, don't use the names which have been already registered 
157 #   in system e.g eth.
158 #
159 # dacs::
160 #   The DAHDI driver cross connects the channels starting at
161 #   the channel number listed at the end, after a colon
162 # dacsrbs::
163 #   The DAHDI driver cross connects the channels starting at
164 #   the channel number listed at the end, after a colon and 
165 #   also performs the DACSing of RBS bits
166 #
167 # The channel list is a comma-separated list of channels or ranges, for
168 # example:
169 #
170 #   1,3,5 (channels one, three, and five)
171 #   16-23, 29 (channels 16 through 23, as well as channel 29)
172 #
173 # So, some complete examples are:
174 #
175 #   e&m=1-12
176 #   nethdlc=13-24
177 #   fxsls=25,26,27,28
178 #   fxols=29-32
179 #
180 # An example of BRI port:
181
182 #   span=1,1,0,ccs,ami
183 #   bchan=1,2
184 #   hardhdlc=3
185 #
186 # NOTE: When using BRI channels in asterisk, use the bri_cpe, bri_net, or
187 # bri_cpe_ptmp (for point to multipoint mode). libpri does not currently
188 # support point to multipoint when in NT mode. Otherwise, the bearer channel
189 # are configured identically to other DAHDI channels.
190 #
191 #fxoks=1-24
192 #bchan=25-47
193 #dchan=48
194 #fxols=1-12
195 #fxols=13-24
196 #e&m=25-29
197 #nethdlc=30-33
198 #clear=44
199 #clear=45
200 #clear=46
201 #clear=47
202 #fcshdlc=48
203 #dacs=1-24:48
204 #dacsrbs=1-24:48
205 #
206 # Tone Zone Data
207 # ^^^^^^^^^^^^^^
208 # Finally, you can preload some tone zones, to prevent them from getting
209 # overwritten by other users (if you allow non-root users to open /dev/dahdi/*
210 # interfaces anyway.  Also this means they won't have to be loaded at runtime.
211 # The format is "loadzone=<zone>" where the zone is a two letter country code.
212
213 # You may also specify a default zone with "defaultzone=<zone>" where zone
214 # is a two letter country code.
215 #
216 # An up-to-date list of the zones can be found in the file zonedata.c
217 #
218 loadzone = us
219 #loadzone = us-old
220 #loadzone=gr
221 #loadzone=it
222 #loadzone=fr
223 #loadzone=de
224 #loadzone=uk
225 #loadzone=fi
226 #loadzone=jp
227 #loadzone=sp
228 #loadzone=no
229 #loadzone=hu
230 #loadzone=lt
231 #loadzone=pl
232 defaultzone=us
233 #
234 # PCI Radio Interface
235 # ^^^^^^^^^^^^^^^^^^^
236 # (see http://www.zapatatelephony.org/app_rpt.html)
237 #
238 # The PCI Radio Interface card interfaces up to 4 two-way radios (either
239 # a base/mobile radio or repeater system) to DAHDI channels. The driver
240 # may work either independent of an application, or with it, through
241 # the driver;s ioctl() interface. This file gives you access to specify
242 # load-time parameters for Radio channels, so that the driver may run
243 # by itself, and just act like a generic DAHDI radio interface.
244 #
245 # Unlike the rest of this file, you specify a block of parameters, and
246 # then the channel(s) to which they apply. CTCSS is specified as a frequency
247 # in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS
248 # for receive is specified as the code directly, for example 223. DCS for
249 # transmit is specified as D and then the code, for example D223.
250 #
251 # The hardware supports a "community" CTCSS decoder system that has
252 # arbitrary transmit CTCSS or DCS codes associated with them, unlike
253 # traditional "community" systems that encode the same tone they decode.
254
255 # this example is a single tone DCS transmit and receive
256 #
257 # specify the transmit tone (in DCS mode this stays constant):
258 #tx=D371
259 #
260 # specify the receive DCS code:
261 #dcsrx=223
262 #
263 # this example is a "community" CTCSS (if you only want a single tone, then
264 # only specify 1 in the ctcss list)
265 #
266 # specify the default transmit tone (when not receiving):
267 #tx=1000
268 #
269 # Specify the receive freq, the tag (use 0 if none), and the transmit code.
270 # The tag may be used by applications to determine classification of tones.
271 # The tones are to be specified in order of presedence, most important first.
272 # Currently, 15 tones may be specified..
273 #
274 #ctcss=1318,1,1318
275 #ctcss=1862,1,1862
276 #
277 # The following parameters may be omitted if their default value is acceptible
278 #
279 # Set the receive debounce time in milliseconds:
280 #debouncetime=123
281 #
282 # set the transmit quiet dropoff burst time in milliseconds:
283 #bursttime=234
284 #
285 # set the COR level threshold (specified in tenths of millivolts)
286 # valid values are {3125,6250,9375,12500,15625,18750,21875,25000}
287 #corthresh=12500
288 #
289 # Invert COR signal {y,n}
290 #invertcor=y
291 # Set the external tone mode; yes, no, internal {y,n,i}
292 #exttone=y
293 #
294 # Now apply the configuration to the specified channels:
295 #
296 # We are all done with our channel parameters, so now we specify what
297 # channels they apply to
298 #channels=1-4
299 #
300 # Overiding PCM encoding
301 # ^^^^^^^^^^^^^^^^^^^^^^
302 # Usually the channel driver sets the encoding of the PCM for the
303 # channel (mulaw / alaw. That is: g711u or g711a). However there are
304 # some cases where you would like to override that. 'mulaw' and 'alaw'
305 # set different such encoding. Use them for channels you have already
306 # defined with e.g. 'bchan' or 'fxoks'.
307 #mulaw=1-4
308 #alaw=1-4
309 #
310 # 'deflaw' is similar, but resets the encoding to the channel driver's
311 # default. It must be useful for something, I guess.
312 #mulaw=1-10
313 #deflaw=5
314 #
315 # Echo Cancellers
316 # ^^^^^^^^^^^^^^^
317 # DAHDI uses modular echo cancellers that are configured per channel. The echo
318 # cancellers are compiled and installed as part of the dahdi-linux package.
319 # You can specify in this file the echo canceller to be used for each
320 # channel. The default behavior is for there to be NO echo canceller on any
321 # channel, so it is very important that you specify one here.
322 #
323 # Valid echo cancellers are: hwec, mg2, kb1, sec2, and sec.
324 # 'hwec' is a special echo canceller that should be used if hardware echo
325 # cancellation is desired on and available on the specified channels.
326 # If compiled, 'hpec' is also a valid echo canceller.
327
328 # To configure the default echo cancellers, use the format:
329 # echocanceller=<echocanceller name>,<channel(s)>
330 #
331 # Example:
332 # Configure channels 1 through 8 to use the mg2 echo canceller
333 #echocanceller=mg2,1-8 
334 #
335 # And change channel 2 to use the kb1 echo canceller.
336 #echocanceller=kb1,2
337 #