./install_prereq test
Name | Last modified | Size | Description | |
---|---|---|---|---|
zaptel.conf.sample | 2008-07-09 11:56 | 9.9K | ||
man/ | 2009-07-29 09:19 | - | ||
extra/ | 2010-11-22 14:49 | - | ||
dahdi-tools/ | 2008-11-27 11:05 | - | ||
dahdi-linux/ | 2009-10-11 20:24 | - | ||
README.html | 2008-10-27 20:46 | 64K | ||
README.Astribank.html | 2009-06-23 19:21 | 89K | ||
Zaptel is a short for ZAPata TELephony.
wct4xxp:
Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1
Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1
Digium TE220: PCI-Express dual-port T1/E1/J1
Digium TE420: PCI-Express quad-port T1/E1/J1
wcte12xp:
Digium TE120P: PCI single-port T1/E1/J1
Digium TE121: PCI-Express single-port T1/E1/J1
Digium TE122: PCI single-port T1/E1/J1
wcte11xp:
Digium TE110P: PCI single-port T1/E1/J1
wct1xxp:
Digium T100P: PCI single-port T1
Digium E100P: PCI single-port E1
tor2: Tormenta quad-span T1/E1 card from the Zapata Telephony project
torisa: The old dual-span ISA T1 card from Zapata Telephony
wctdm24xxp:
Digium TDM2400P/AEX2400: up to 24 analog ports
Digium TDM800P/AEX800: up to 8 analog ports
Digium TDM410: up to 4 analog ports
wctdm:
Digium TDM400P: up to 4 analog ports
xpp: Xorcom Astribank: a USB connected unit of up to 32 ports (includeing the digital BRI and E1/T1 modules)
wcfxo: X100P, similar and clones. A simple single-port FXO card
wcusb: Digium S100U: A simple single-port USB FXS unit
pciradio: Zapata Telephony PCI Quad Radio Interface
wctc4xxp: Digium hardware transcoder cards (also need zttranscode). Note that this driver requires Asterisk 1.4.22 or above because the interface used by codec_zap was changed in zaptel-1.4.12.
ztd-eth: TDM over Ethernet (TDMoE) driver. Requires ztdynamic
ztd-loc: Mirror a local span. Requires ztdynamic
ztdummy: A dummy driver that only provides a zaptel timing source.
You will need a matching kernel source tree and a working Linux build system. Some of the programs require some additional libraries.
The script install_prereq should help you install the required packages. To see what it suggests, run:
./install_prereq test
You can either copy/paste that code to a terminal to run it, or just run:
./install_prereq install
Building Zaptel requires a kernel build tree.
This should basically be at least a partial kernel source tree and most importantly, the exact kernel .config file used for the build as well as several files generated at kernel build time.
KERNEL_VERSION is the output of the command uname -r
If you build your own kernel, you need to point to the exact kernel build tree. Luckily for you, this will typically be pointed by the symbolic link /lib/modules/KERNEL_VERSION/build which is the location zaptel checks by default.
If you use a kernel from your distribution you will typically have a package with all the files required to build a kernel modules for your kernel image.
On Debian Etch and above and any Ubuntu this is linux-headers-`uname -r`
On Fedora, RHEL and compatibles (e.g. CentOS) this is the kernel-devel package. Or if you run kernel-smp or kernel-xen, you need kernel-smp-devel or kernel-xen-devel, respectively.
On SUSE you seem to need the package kernel-source .
In some distributions (e.g.: in RHEL/CentOS, Fedora, Ubuntu) the installation of the kernel-devel / kernel-headers package will be of a version that is newer than the one you currently run. In such a case you may need to upgrade the kernel package itself as well and reboot.
To point explicitly to a different build tree: set KSRC to the kernel source tree and KVERS to the exact kernel version:
make KVERS=2.6.18.Custom KSRC=/home/tzafrir/kernels/2.6.18
If you build a custom kernel, note the following configuration items:
CONFIG_CRC_CCITT must be enabled (y or m). On 2.6 kernels this can be selected These can be selected from the "Library Routines" submenu during kernel configuration via "make menuconfig".
If you don't have any Zaptel hardware, you need ztdummy. ztdummy takes its timing from the kernel. It can use either of the following:
ztdummy on i386/x86_64 with kernels >= 2.6.22 can (and should) use high resolution timers (CONFIG_HIGH_RES_TIMERS), and (if available), the system HPET. This shows as "source: HRTimer". This is recommended.
ztdummy on i386/x86_64 with kernels >= 2.6.15 can use the system's RTC (Real Time Clock). This shows as "source: RTC".
Failing that, on Linux 2.6 kernels with HZ=1000 (was the default before 2.6.13). This shows as "source: Linux26".
Alternatives to that for ztdummy are a UHCI USB controller (USB controllers made by Intel or VIA) or a kernel that has HZ=1000 (default on kernels 2.6.0-2.6.12, optional on newer kernels. Not possible on 2.4). This shows as: "source: UHCI".
gcc and friends. Generally you will need to install the package gcc. There may be cases where you will need a specific version of gcc to build kernel modules.
Some libraries are needed for extra utilities that are provided with Zaptel
libusb is needed for building fpga_load, needed for firmware loading of the Xorcom Astribank.
libnewt is needed to build the optional but useful utility zttool.
apt-get install linux-headers-`uname -r` build-essential libnewt-dev libusb-dev
apt-get install kernel-headers-`uname -r` build-essential libnewt-dev libusb-dev
You need the following non-kernel-related packages:
yum install gcc newt-devel libusb-devel
If the following command produces an error, you need to install the kernel devel package:
ls /lib/modules/`uname -r`/build/.config
The right one depends on your kernel version. If the following command produces output you have an SMP kernel:
uname -r | grep smp
and thus need to run:
yum install kernel-smp kernel-smp-devel
If that command produced no output, you have a non-SMP kernel:
yum install kernel kernel-devel
At this point you should probably reboot to get the new kernel in effect.
Note: If using sudo to build/install, you may need to add /sbin to your PATH.
./configure # optional step: select custom configuration: #make menuconfig make make install # To install init scripts and config files: #make config
You can select the modules and utilities you wish to build and firmwares you wish to download by running make menuselect . The selection of modules that you build (or rather: not build) is saved in the file menuselect.makeopts.
To build extra modules / modules directory not included in the Zaptel distribution, use the optional variables MODULES_EXTRA and SUBDIRS_EXTRA:
make MODULES_EXTRA="mod1 mod2" make MODULES_EXTRA="mod1 mod2" SUBDIRS_EXTRA="subdir1/ subdir1/"
Note that those names are not guaranteed to continue to work on newer versions. Hopefully there will be no need for such extra configuration.
There are some make targets that are provided to build or install just parts of Zaptel:
Build targets:
make modules: build just the kernel modules.
make programs: Build just the Zaptel userspace programs. partial targets of it:
make utilname: builds utilname alone (e.g: make ztdiag)
make utils: Build libtonezone.
make libs: Build libtonezone.
Install targets:
make install-modules: install just kernel modules.
make firmware: download and install firmwares for Digium cards
make install-programs: Userspace: Partial targets of it are:
make install-utils: install Zaptel userspace programs and and basic support files.
make install-libs: install libtonezone
make install-include: install zaptel.h
make config: should be run once to configure
The following may be useful when testing the package or when preparing a package for a binary distribution (such as an rpm package) installing onto a subtree rather than on th real system.
make install DESTDIR=targetdir
This can be useful for any partial install target of the above (e.g: install-modules or install-programs).
the targetdir must be an absolute path, at least if you install the modules. To install to a relative path you can use something like:
make install-modules DESTDIR=$PWD/target
The install target might fail if run as a user to a DESTDIR when attempting to generate device files. In that case, try:
make install DESTDIR=$PWD/target DYNFS=
If you need to test a version of Zaptel without touching the version installed on your system, you can use the script live_zap . Note, however, that it may take some extra configuration to be used right.
Basic usage:
./configure make ./live_zap install # instead of 'make install' ./live_zap config # instead of 'make config' ./live_zap unload # instead of '/etc/init.d/zaptel stop' ./live_zap load # instead of '/etc/init.d/zaptel start'
Everything is installed under the subdirectory live/ . You will probably need to adjust MODULES . Generally you should not edit the script itself, but , rather, edit live/live.conf . Please let me know if you needed to change anything in the script beyond changing live.conf so I can include useful fixes.
Testing on a different machine:
./configure make ./live_zap install # instead of 'make install' ./live_zap config # instead of 'make config' ./live_zap rsync root@remotehost ssh root@remotehost # in the remote host: cd /tmp ./live_zap unload ./live_zap load
live_zap also has a command called "exec" to execute commands from the installed environment. e.g.:
./live_zap exec lszaptel
This sets PATH, PERL5LIB (for the Zaptel-perl modules) and some other settings.
For Xorcom Astribank you may need to load a different version of firmware from that installed on the system. In this case, start with editing the real system's /etc/default/zaptel (on Debian) or /etc/sysconfig/zaptel (on RedHat/SUSE) and set:
XPP_HOTPLUG_DISABLED=yes
and then run:
./live_zap unload ./live_zap exec ./live/usr/share/zaptel/xpp_fxloader reset ./live_zap exec ./live/usr/share/zaptel/xpp_fxloader load # wait a few seconds, see the output of lsusb ./live_zap load
The configure script various several tests and based on them generates some files ( build_tools/menuselect-deps and makeopts). You can pass it —with options and variable settings, for instance:
./configure --without-ncurses CC="gcc-4.10"
If you just want to recreate the same files without a full detection run, use:
./config.status
To re-run ./configure with the same parameters it was run with last time, use:
./ocnfig.status --recheck
The main method to configure Zaptel devices is using the utility ztcfg. ztcfg reads data from the configuration file /etc/zaptel.conf , figures out what configuration to send to channels, and send it.
A sample annotated zaptel.conf is included in this directory and installed by default to /etc/zaptel.conf . Edit it to suit your configuration. Alternatively use the script genzaptelconf to generate one that should work with your system.
The configuration file of the zaptel init.d script is either /etc/default/zaptel (Debian systems) or /etc/sysconfig/zaptel (most others). That file is used to override defaults that are set at the beginning of the init.d script.
For instance, to define for the init.d script to load the modules wctdm and xpp_usb (in that order) add the following line to that file:
MODULES="wctdm xpp_usb"
Currently that file must set "TELEPHONY=yes" for the zaptel init.d to work.
The kernel modules can be configured through module parameters. Module parameters can optionally be set at load time. They are normally set (if needed) by a line in a file under /etc/modprobe.d/ or in the file /etc/modprobe.conf (Or /etc/modules.conf in kernel 2.4).
Example line:
options zaptel debug=1
The module parameters can normally be modified at runtime through sysfs:
pungenday:~# cat /sys/module/zaptel/parameters/debug 0 pungenday:~# echo 1 >/sys/module/zaptel/parameters/debug pungenday:~# cat /sys/module/zaptel/parameters/debug 1
Viewing and setting parameters that way is possible as of kernel 2.6 . In kernels older than 2.6.10, the sysfs "files" for the parameters reside directly under /sys/module/module_name .
Useful module parameters:
Sets debug mode / debug level. With most modules debug can be either disabled (0, the default value) or enabled (any other value). wctdm and wcte1xp print several extra debugging messages if the value of debug is more than 1. Some modules have "debugging flags" bits - the value of debug is a bitmask and several messages are printed if some bits are set:
ztdummy:
1: DEBUG_GENERAL - general error messages.
2: DEBUG_TICKS - Show that the module is alive :-)
wctdm24xxp:
1: DEBUG_CARD
2: DEBUG_ECHOCAN
wct4xxp:
1: DEBUG_MAIN
2: DEBUG_DTMF
4: DEBUG_REGS
8: DEBUG_TSI
16: DEBUG_ECHOCAN
32: DEBUG_RBS
64: DEBUG_FRAMER
xpp: Previously (before 1.2.26 / 1.4.11) it was called "print_dbg". See also README.Astribank:
1: GENERAL - General debug comments.
2: PCM - PCM-related messages. Tend to flood logs.
4: LEDS - Anything related to the LEDs status control. The driver produces a lot of messages when the option is enabled.
8: SYNC - Synchronization related messages.
16: SIGNAL - Zaptel signalling related messages.
32: PROC - Messages related to the procfs interface.
64: REGS - Reading and writing to chip registers. Tends to flood logs.
128: DEVICES - Device instantiation, destruction and such.
256 - COMMANDS - Protocol commands. Tends to flood logs.
The default size for the echo canceller. The number is in "taps", that is "samples", 1/8 ms. The default is 64 - for a tail size of 8 ms. Asterisk's chan_zap tends to pass its own value anyway, with a different default size. So normally setting this doesn't change anything.
To get a list of parameters supported by a module, use
modinfo module_name
Or, for a module you have just built:
modinfo ./module_name.ko
For the xpp modules this will also include the description and default value of the module. You can find a list of useful xpp module parameters in README.Astribank .
Zaptel Configuration File
This file is parsed by the Zaptel Configurator, ztcfg
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)
one of d4 or esf for T1 or cas or ccs for E1 and BRI. d4 could be referred to as sf or superframe
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
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 zaptel 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.
Next come the definitions for using the channels. The format is: <device>=<channel list>
Valid devices are:
Channel(s) are signalled using E&M signalling (specific implementation, such as Immediate, Wink, or Feature Group D are handled by the userspace library).
Channel(s) are signalled using FXS Loopstart protocol.
Channel(s) are signalled using FXS Groundstart protocol.
Channel(s) are signalled using FXS Koolstart protocol.
Channel(s) are signalled using FXO Loopstart protocol.
Channel(s) are signalled using FXO Groundstart protocol.
Channel(s) are signalled using FXO Koolstart protocol.
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.
No signalling is performed, each channel in the list remains idle
Channel(s) are bundled into a single span. No conversion or signalling is performed, and raw data is available on the master.
Like clear except all channels are treated individually and are not bundled. inclear is an alias for this.
The zaptel driver performs HDLC encoding and decoding on the bundle, and the resulting data is communicated via the master device.
The zaptel 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.
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.
The zaptel 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.
The zaptel driver cross connects the channels starting at the channel number listed at the end, after a colon
The zaptel 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
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/zap/* 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 zaptel/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
The PCI Radio Interface card interfaces up to 4 two-way radios (either a base/mobile radio or repeater system) to Zaptel 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 Zaptel 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
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
The file zonedata.c contains the information about the tone zones used in libtonezone (and hence also in ztcfg). Here is a list of those zones:
us United States / North America
au Australia
fr France
nl Netherlands
uk United Kingdom
fi Finland
es Spain
jp Japan
no Norway
at Austria
nz New Zealand
it Italy
us-old United States Circa 1950 / North America
gr Greece
tw Taiwan
cl Chile
se Sweden
be Belgium
sg Singapore
il Israel
br Brazil
hu Hungary
lt Lithuania
pl Poland
za South Africa
pt Portugal
ee Estonia
mx Mexico
in India
de Germany
ch Switzerland
dk Denmark
cz Czech Republic
cn China
ar Argentina
my Malaysia
th Thailand
bg Bulgaria
ve Venezuela
ph Philippines
ru Russian Federation
The directory xpp/utils has, in addition to helper utilities for the Xorcom Astribank, a collection of perl modules to provide information related to Zaptel. The perl modules themselves are under xpp/utils/zconf . In xpp/utils there are several utilities that use those modules: - xpp-specific: zt_registration, xpp_sync, xpp_blink . - General: lszaptel, zapconf, zaptel_hardware
The zaptel perl modules will currently only be automatically installed if you happen to isntall the xpp module. This should be the defualt, but you can also initiate it manually by running:
make -C xpp/utils install
Those utilities require the perl modules to be installed, however they will also look for them in the directory zconf, and thus can be run directly from the zaptel source tree. For example:
./xpp/utils/zaptel_hardware
To get usage information on a program, you can also use perldoc (sometimes provided in a package separate from perl itself). For instance:
perldoc ./xpp/utils/lszaptel
Some of them are specific for the Xorcom Astribank and described in its docuemntation. the others are:
A somewhat glorified cat /proc/zaptel/*.
An currently experimental and intended to eventually replace genzaptelconf by a more maintainable code.
A two-liner script (not installed by default) that simply returns the modules that should be modprobed on this system.
Uses the information from sysfs and its own knowledge to show what PCI/USB Zaptel hardware is connected and if it is currently used by a driver. Shows also some more information for Astrobanks from /proc/xpp .
Userspace programs will usually interact with Zaptel through device files under the /dev/zap directory (pedantically: characted device files with major number 196) . Those device files can be generated statically or dynamically through the udev system.
/dev/zap/ctl (196:0) - a general device file for various information and control operations on the zaptel channels.
/dev/zap/NNN (196:NNN) - for NNN in the range 1-249. A device file for zaptel channel NNN. It can be used to read data from the channel and write data to the channel.
/dev/zap/transcode (196:250) - Used to connect to a zaptel transcoding device.
/dev/zap/timer (196:253) - Allows setting timers. Used anywhere?
/dev/zap/channel (196:254) - Can be used to open an arbitrary zaptel channel. This is an alternative to /dev/zap/NNN that is not limited to 249 channels.
/dev/zap/pseudo (196:255) - A timing-only device. Every time you open it, a new Zaptel channel is created. That Zaptel channel is "pseudo" - Zaptel recieves no data in it, and only sends garbage data with the same timing as the Zaptel timing master device.
A PBX system should generally have a single clock. If you are connected to a telephony provider via a digital interface (e.g: E1, T1) you should also typically use the provider's clock (as you get through the interface). Hence one important job of Asterisk is to provide timing to the PBX.
Zaptel "ticks" once per millisecond (1000 times per second). On each tick every active zaptel channel reads and 8 bytes of data. Asterisk also uses this for timing, through a zaptel pseudo channel it opens.
However, not all PBX systems are connected to a telephony provider via a T1 or similar connection. With an analog connection you are not synced to the other party. And some systems don't have Zaptel hardware at all. Even a digital card may be used for other uses or is simply not connected to a provider. Zaptel cards are also capable of providing timing from a clock on card. Cheap x100P clone cards are sometimes used for that pupose.
If all the above fail, you can use the module ztdummy to provide timing alone without needing any zaptel hardware. It will work with most systems and kernels.
You can check the zaptel timing source with zttest, which is a small utility that is included with zaptel. It runs in cycles. In each such cycle it tries to read 8192 bytes, and sees how long it takes. If zaptel is not loaded or you don't have the device files, it will fail immedietly. If you lack a timing device it will hang forever in the first cycle. Eitherwise it will just give you in each cycle the percent of how close it was. Also try running it with the option -v for a verbose output.
To check the clock source that is built into ztdummy, you can either look at title of its span in /proc/zaptel file for a "source:" in the description. Or even run:
strings zaptel.ko | grep source:
Zaptel provides telephony channels to the userspace applications. Those channels are channels are incoreperated into logical units called spans.
With digital telephony adapters (e.g: E1 or T1), a span normally represents a single port. With analog telephony a span typically represents a PCI adapter or a similar logical unit.
Both channels and spans are identified by enumerating numbers (beginning with 1). The number of the channel is the lowest unused one when it is generated, and ditto for spans.
See also the span configuration directive.
A simple way to get the current list of spans and channels each span contains is the files under /proc/zaptel . /proc/zaptel is generated by zaptel as it loads. As each span registers to Zaptel, a file under /proc/zaptel is created for it. The name of that file is the number of that span.
Each file has a 1-line title for the span followed by an empty line and then a line for each channel of the span.
The title line shows the number of the span, its name and title, and (potentially) the alarms in which it is.
The title shows the span number and name, followed by any allarms the span may have: For example, here is the first span in my system (with no alarms):
Span 1: XBUS-00/XPD-00 "Xorcom XPD #0/0: FXS"
The channel line for each channel shows its channel number, name and the actual signalling assigned to it through ztcfg. Before being configured by ztcfg: This is Zaptel channel 2, whose name is XPP_FXS/0/0/1.
2 XPP_FXS/0/0/1
After being configured by ztcfg: the signalling FXOLS was added. FXS channels have FXO signalling and vice versa:
2 XPP_FXS/0/0/1 FXOLS
If the channel is in use (typically opened by Asterisk) then you will see an extra (In use):
2 XPP_FXS/0/0/1 FXOLS (In use)
Like any other kernel code, Zaptel strives to maintain a stable interface to userspace programs. The API of Zaptel to userspace programs, zaptel.h, has remained backword-compatible for a long time and is expected to remain so in the future. With the ABI (the bits themselves) things are slightly trickier.
Zaptel's interface to userspace is mostly ioctl(3) calls. Ioctl calls are identified by a number that stems from various things, one of which is the size of the data structure passed between the kernel and userspace.
Many of the Zaptel ioctl-s use some sepcific structs to pass information between kernel and userspace. In some cases the need arose to pass a few more data members in each call. Simply adding a new member to the struct would have meant a new number for the ioctl, as its number depends on the size of the data passed.
Thus we would add a new ioctl with the same base number and with the original struct.
So suppose we had the following ioctl:
struct zt_example { int sample; } #define ZT_EXAMPLE _IOWR (ZT_CODE, 62, struct zt_example)
And we want to add the field int onemore, we won't just add it to the struct. We will do something that is more complex:
/* The original, unchanged: */ struct zt_example_v1 { int sample; } /* The new struct: */ struct zt_example { int sample; int onemore; } #define ZT_EXAMPLE_V1 _IOWR (ZT_CODE, 62, struct zt_example_v1) #define ZT_EXAMPLE _IOWR (ZT_CODE, 62, struct zt_example)
We actually have here two different ioctls: the old ZT_EXAMPLE would be 0xC0044A3E . ZT_EXAMPLE_V1 would have the same value. But the new value of ZT_EXAMPLE would be 0xC0084A3E .
Programs built with the original zaptel.h (before the change) use the original ioctl, whether or not the kerenl code is actually of the newer version. Thus in most cases there are no compatibility issues.
When can we have compatibility issues? if we have code built with the new zaptel.h, but the loaded kernel code (modules) are of the older version. Thus the userspace program will try to use the newer ZT_EXAMPLE (0xC0084A3E). But the kernel code has no handler for that ioctl. The result: the error 25, ENOTTY, which means "Inappropriate ioctl for device".
As a by-product of that method, for each interface change a new #define is added. That definition is for the old version and thus it might appear slightly confusing in the code, but it is useful for writing code that works with both versions of Zaptel.
Semantics of ZT_LOADZONE. Using newer ztcfg with older modules will yield -EINVAL with the kernel message Invalid tone (96) defined
ZT_GET_PARAMS_V1
ZT_SET_PARAMS_V1
ZT_SPANINFO_V2
ZT_SPANINFO_V1
ZT_SPANINFO_V1 was originally called (up to zaptel 1.4.8) "ZT_SPANINFO_COMPAT".
Zaptel digital cards can provide data channels through ppp as point-to-point connections. This requires a plugin to the ppp daemon that is included in the ppp/ subdirectory. To install it:
Make sure you have the PPP source / headers installed. On Debian:
apt-get install ppp-dev
Run make on the ppp subdirectory:
make -C ppp make -C ppp install
Make sure your kernel has support for both PPP (which is common is distribution kernels and for HDLC (much less common) - CONFIG_PPP and CONFIG_HDLC .
This package is distributed under the terms of the GNU General Public License Version 2, except for some components which are distributed under the terms of the GNU Lesser General Public License Version 2.1. Both licenses are included in this directory, and each file is clearly marked as to which license applies.
If you wish to use the Zaptel drivers in an application for which the license terms are not appropriate (e.g. a proprietary embedded system), licenses under more flexible terms can be readily obtained through Digium, Inc. at reasonable cost.
Please report bug and patches to the Asterisk.org bug tracker at http://bugs.digium.com in the "Zaptel" category.
Yes, the Asterisk Open Source PBX does. http://www.asterisk.org
http://asterisk.org/ - The Asterisk PBX
http://www.zapatatelephony.org/ - A historical site.