understand, and do not affect how it is actually parsed.
Entries of the form 'variable=value' set the value of some parameter in
-asterisk. For example, in zapata.conf, one might specify:
+asterisk. For example, in chan_dahdi.conf, one might specify:
switchtype=national
#endif
;
-static const char config[] = "chan_dahdi.conf";
-
#define SIG_EM DAHDI_SIG_EM
#define SIG_EMWINK (0x0100000 | DAHDI_SIG_EM)
#define SIG_FEATD (0x0200000 | DAHDI_SIG_EM)
#endif
#ifdef HAVE_ZAPTEL
- cfg = ast_config_load("zapata.conf");
+ if (!(cfg = ast_config_load("zapata.conf"))) {
+ ast_log(LOG_ERROR, "Unable to load zapata.conf\n");
+ return 0;
+ }
#else
- cfg = ast_config_load(config);
-#endif
- /* Error if we have no config file... */
- if (!cfg) {
- ast_log(LOG_ERROR, "Unable to load either config %s or zapata.conf\n", config);
- return 0;
+ if (!(cfg = ast_config_load("chan_dahdi.conf"))) {
+ ast_log(LOG_ERROR, "Unable to load chan_dahdi.conf\n");
+ return 0;
}
-
+#endif
/* It's a little silly to lock it, but we mind as well just to be sure */
ast_mutex_lock(&iflock);
#ifdef HAVE_PRI
;
-; Zapata telephony interface
+; DAHDI telephony interface
;
; Configuration file
;
-; You need to restart Asterisk to re-configure the Zap channel
-; CLI> reload chan_zap.so
+; You need to restart Asterisk to re-configure the DAHDI channels
+; CLI> reload chan_dahdi.so
; will reload the configuration file,
; but not all configuration options are
; re-configured during a reload.
; trunkgroup => <trunkgroup>,<dchannel>[,<backup1>...]
;
; trunkgroup is the numerical trunk group to create
-; dchannel is the zap channel which will have the
+; dchannel is the DAHDI channel which will have the
; d-channel for the trunk.
; backup1 is an optional list of backup d-channels.
;
;trunkgroup => 1,24
;
; Spanmap: Associates a span with a trunk group
-; spanmap => <zapspan>,<trunkgroup>[,<logicalspan>]
+; spanmap => <dahdispan>,<trunkgroup>[,<logicalspan>]
;
-; zapspan is the zap span number to associate
+; dahdispan is the DAHDI span number to associate
; trunkgroup is the trunkgroup (specified above) for the mapping
; logicalspan is the logical span number within the trunk group to use.
; if unspecified, no logical span number is used.
; Note that when setting the number of taps, the number 256 does not translate
; to 256 ms of echo cancellation. echocancel=256 means 256 / 8 = 32 ms.
;
-; Note that if any of your Zaptel cards have hardware echo cancellers,
+; Note that if any of your DAHDI cards have hardware echo cancellers,
; then this setting only turns them on and off; numeric settings will
; be treated as "yes". There are no special settings required for
; hardware echo cancellers; when present and enabled in their kernel
; modules, they take precedence over the software echo canceller compiled
-; into Zaptel automatically.
+; into DAHDI automatically.
;
echocancel=yes
;
;
; FXO (FXS signalled) devices must have a timeout to determine if there was a
; hangup before the line was answered. This value can be tweaked to shorten
-; how long it takes before Zap considers a non-ringing line to have hungup.
+; how long it takes before DAHDI considers a non-ringing line to have hungup.
;
;ringtimeout=8000
;
;mohsuggest=default
;
; PRI channels can have an idle extension and a minunused number. So long as
-; at least "minunused" channels are idle, chan_zap will try to call "idledial"
+; at least "minunused" channels are idle, chan_dahdi will try to call "idledial"
; on them, and then dump them into the PBX in the "idleext" extension (which
; is of the form exten@context). When channels are needed the "idle" calls
; are disconnected (so long as there are at least "minidle" calls still
;minunused=2
;minidle=1
;
-; Configure jitter buffers in zapata (each one is 20ms, default is 4)
+; Configure jitter buffers in DAHDI (each one is 20ms, default is 4)
;
;jitterbuffers=4
;
;------------------------------ JITTER BUFFER CONFIGURATION --------------------------
; jbenable = yes ; Enables the use of a jitterbuffer on the receiving side of a
- ; ZAP channel. Defaults to "no". An enabled jitterbuffer will
+ ; DAHDI channel. Defaults to "no". An enabled jitterbuffer will
; be used only if the sending side can create and the receiving
- ; side can not accept jitter. The ZAP channel can't accept jitter,
- ; thus an enabled jitterbuffer on the receive ZAP side will always
+ ; side can not accept jitter. The DAHDI channel can't accept jitter,
+ ; thus an enabled jitterbuffer on the receive DAHDI side will always
; be used if the sending side can create jitter.
; jbmaxsize = 200 ; Max length of the jitterbuffer in milliseconds.
; big jumps in/broken timestamps, usually sent from exotic devices
; and programs. Defaults to 1000.
-; jbimpl = fixed ; Jitterbuffer implementation, used on the receiving side of a ZAP
+; jbimpl = fixed ; Jitterbuffer implementation, used on the receiving side of a DAHDI
; channel. Two implementations are currently available - "fixed"
; (with size always equals to jbmax-size) and "adaptive" (with
; variable size, actually the new jb of IAX2). Defaults to fixed.
TRUNK="Zap/g2"; // Trunk interface
//
// Note the 'g2' in the TRUNK variable above. It specifies which group (defined
- // in zapata.conf) to dial, i.e. group 2, and how to choose a channel to use in
+ // in chan_dahdi.conf) to dial, i.e. group 2, and how to choose a channel to use in
// the specified group. The four possible options are:
//
// g: select the lowest-numbered non-busy Zap channel
TRUNK=Zap/G2 ; Trunk interface
;
; Note the 'G2' in the TRUNK variable above. It specifies which group (defined
-; in zapata.conf) to dial, i.e. group 2, and how to choose a channel to use in
+; in chan_dahdi.conf) to dial, i.e. group 2, and how to choose a channel to use in
; the specified group. The four possible options are:
;
; g: select the lowest-numbered non-busy Zap channel
;autocontext=line1 ; This supports automatic generation of the dialplan entries
; if the autocontext option is used. Each trunk should have
- ; a unique context name. Then, in zapata.conf, this device
+ ; a unique context name. Then, in chan_dahdi.conf, this device
; should be configured to have incoming calls go to this context.
;ringtimeout=30 ; Set how long to allow this trunk to ring on an inbound call before hanging
[interfaces]
; Specify serial ports to listen for SMDI messages on below. These will be
-; referenced later in zapata.conf. If you do not specify any interfaces then
+; referenced later in chan_dahdi.conf. If you do not specify any interfaces then
; SMDI will be disabled. Interfaces can have several different attributes
; associated with them.
echo >> $OUTPUT;
echo >> $OUTPUT;
+ echo "------------------" >> $OUTPUT;
+ echo "DAHDI CONFIG" >> $OUTPUT;
+ echo "------------------" >> $OUTPUT;
+ grep -v '^;' /etc/asterisk/chan_dahdi.conf >> $OUTPUT;
+ echo >> $OUTPUT;
+ echo >> $OUTPUT;
+
echo "------------------" >> $OUTPUT;
echo "EXTENSIONS CONFIG" >> $OUTPUT;
echo "------------------" >> $OUTPUT;
Asterisk acts as a server. Devices involved in telephony, like Zapata
cards, or Voip phones, all indicate some context that should be
activated in their behalf. See the config file formats for IAX, SIP,
-zapata.conf, etc. They all help describe a device, and they all
+chan_dahdi.conf, etc. They all help describe a device, and they all
specify a context to activate when somebody picks up a phone, or a
call comes in from the phone company, or a voip phone, etc.
label = value
label2 = value
-In some files, (e.g. mgcp.conf, zapata.conf and agents.conf), the syntax
+In some files, (e.g. mgcp.conf, chan_dahdi.conf and agents.conf), the syntax
is a bit different. In these files the syntax is as follows:
[section]
An SLA system is built up of virtual trunks and stations mapped to real
Asterisk devices. The configuration for all of this is done in three
different files: extensions.conf, sla.conf, and the channel specific
-configuration file such as sip.conf or zapata.conf.
+configuration file such as sip.conf or chan_dahdi.conf.
\subsection{Dialplan}
An SLA trunk is a mapping between a virtual trunk and a real Asterisk device.
This device may be an analog FXO line, or something like a SIP trunk. A trunk
must be configured in two places. First, configure the device itself in the
-channel specific configuration file such as zapata.conf or sip.conf. Once the
+channel specific configuration file such as chan_dahdi.conf or sip.conf. Once the
trunk is configured, then map it to an SLA trunk in sla.conf.
\begin{verbatim}
Be sure to configure the trunk's context to be the same one that is set for the
"autocontext" option in sla.conf if automatic dialplan configuration is used.
-This would be done in the regular device entry in zapata.conf, sip.conf, etc.
+This would be done in the regular device entry in chan_dahdi.conf, sip.conf, etc.
Note that the automatic dialplan generation creates the SLATrunk() extension
at extension 's'. This is perfect for Zap channels that are FXO trunks, for
example. However, it may not be good enough for an IP trunk, since the call
With this configuration, the dialplan is generated automatically. The first
zap channel should have its context set to "line1" and the second should be
-set to "line2" in zapata.conf. In sip.conf, station1, station2, and station3
+set to "line2" in chan_dahdi.conf. In sip.conf, station1, station2, and station3
should all have their context set to "sla\_stations".
For reference, here is the automatically generated dialplan for this situation:
are Zap/1 and Zap/2. The stations are SIP/station1, SIP/station2, and
SIP/station3.
-In zapata.conf, channel 1 has context=line1 and channel 2 has context=line2.
+In chan_dahdi.conf, channel 1 has context=line1 and channel 2 has context=line2.
In sip.conf, all three stations are configured with context=sla\_stations.
*/
/*! \page Config_zap Zaptel configuration
- * \section zapconf zapata.conf
+ * \section zapconf chan_dahdi.conf
* \arg Implemented in \ref chan_zap.c
- * \verbinclude zapata.conf.sample
+ * \verbinclude chan_dahdi.conf.sample
*/
/*! \page Config_h323 H.323 channel driver information
projects / thirdparty / asterisk.git / commitdiff
