forked from asterisk/dahdi-linux
-
Notifications
You must be signed in to change notification settings - Fork 2
/
README
1265 lines (954 loc) · 43.9 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
DAHDI Telephony Interface Driver
=================================
Fork by Osmocom, re-introduces support for old hardware and
adds support for Osmocom icE1usb adapter.
Additional drivers:
- icE1usb:
* Osmocom icE1usb
- wcte11xp:
* Digium TE11xP: PCI single-port T1/E1 card
- wcte12xp:
* Digium TE12xP: PCI single-port T1/E1 card
- zaphfc:
* CologneChip HFC-S-based PCI cards
-----------------
Asterisk Development Team <asteriskteam@digium.com>
$Revision$, $Date$
DAHDI stands for Digium Asterisk Hardware Device Interface.
This package contains the kernel modules for DAHDI. For the required
userspace tools see the package dahdi-tools.
Supported Hardware
------------------
Digital Cards
~~~~~~~~~~~~~
- wcte43x:
* Digium TE435: PCI express quad-port T1/E1/J1
* Digium TE436: PCI quad-port T1/E1/J1
* Digium TE235: PCI express dual-port T1/E1/J1
* Digium TE236: PCI dual-port T1/E1/J1
- wcte13xp:
* Digium TE131: PCI express single-port T1/E1/J1
* Digium TE133: PCI express single-port T1/E1/J1 with echocan
* Digium TE132: PCI single-port T1/E1/J1
* Digium TE134: PCI single-port T1/E1/J1 with echocan
- 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
* Digium TE820: PCI-Express eight-port T1/E1/J1
- wcb4xxp:
* Digium B410: PCI quad-port BRI
* Digium B233: PCI-Express dual-port BRI with echo can
* Digium B234: PCI dual-port dual-port BRI with echo can
* Digium B433: PCI-Express quad-port BRI with echo can
* Digium B434: PCI quad-port BRI with echo can
Analog Cards
~~~~~~~~~~~~
- wcaxx:
* Digium A8A: PCI up to 8 mixed FXS/FXO ports
* Digium A8B: PCI express up to 8 mixed FXS/FXO ports
* Digium A4A: PCI up to 4 mixed FXS/FXO ports
* Digium A4B: PCI express up to 4 mixed FXS/FXO ports
- wctdm24xxp:
* Digium TDM2400P/AEX2400: up to 24 analog ports
* Digium Hx8 Series: Up to 8 analog or BRI ports
- xpp: Xorcom Astribank: a USB connected unit of up to 32 ports
(including the digital BRI and E1/T1 modules)
Other Drivers
~~~~~~~~~~~~~
- wctc4xxp: Digium hardware transcoder cards (also need dahdi_transcode)
- dahdi_dynamic_eth: TDM over Ethernet (TDMoE) driver. Requires dahdi_dynamic
- dahdi_dynamic_loc: Mirror a local span. Requires dahdi_dynamic
Installation
------------
If all is well, you just need to run the following:
make
make install
You'll need the utilities provided in the package dahdi-tools to
configure DAHDI devices on your system.
If using `sudo` to build/install, you may need to add /sbin to your PATH.
If you still have problems, read further.
Build Requirements
~~~~~~~~~~~~~~~~~~
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.
Kernel Source / "Headers"
^^^^^^^^^^^^^^^^^^^^^^^^^
- Building DAHDI-linux 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 and Ubuntu this is
+++ linux-headers-`uname -r` +++
* On Fedora, RHEL and compatibles (e.g. CentOS) and SUSE 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.
* 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 or KVERS to the exact kernel version (if "headers" are
available for a different version). This parameter must be run on
every calls to 'make' (e.g.: 'make clean', 'make install').
make KVERS=2.6.18.Custom
make KSRC=/home/tzafrir/kernels/linus
Kernel Configuration
^^^^^^^^^^^^^^^^^^^^
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".
- DAHDI will work if you disable module unloading. But you may need
extra reboots.
- DAHDI needs the BKL (Big Kernel Lock). This may be annoying in
>=2.6.37 kernels. Make sure you enable CONFIG_BKL on those kernels.
Installing to a Subtree
~~~~~~~~~~~~~~~~~~~~~~~
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 the 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
Extra Modules
~~~~~~~~~~~~~
To build extra modules / modules directory not included in the DAHDI
distribution, use the optional variables MODULES_EXTRA and
SUBDIRS_EXTRA:
make MODULES_EXTRA="mod1 mod2"
make MODULES_EXTRA="mod1 mod2" SUBDIRS_EXTRA="subdir1/ subdir1/"
Static Device Files
~~~~~~~~~~~~~~~~~~~
Userspace programs communicate with the DAHDI modules through special
device files under /dev/dahdi . Those are normally created by udev, but
if you use an embedded-type system and don't wish to use udev, you can
generate them with the following script, from the source directory:
./build_tools/make_static_devs
This will generate the device files under /dev/dahdi . If you need to
generate them elsewhere (e.g. `tmp/newroot/dev/dahdi`) use the option -d
to the script:
./build_tools/make_static_devs -d tmp/newroot/dev/dahdi
DKMS
~~~~
DKMS, Dynamic Kernel Module Support, is a framework for building Linux
kernel modules. It is used, among others, by several distributions that
package the DAHDI kernel modules.
DKMS is designed to provide updates over drivers installed from original
kernel modules tree. Thus it installed modules into /lib/modules/updates
or /lib/modules/VERSION/updates . This is generally not an issue on
normal operation. However if you try to install DAHDI from source on
a system with DAHDI installed from DKMS this way (potentially of an
older version), be sure to remove the DKMS-installed modules from the
updates directory. If you're not sure, the following command will give
you a clue of the versions installed:
find /lib/modules -name dahdi.ko
===== LINUX_DIR
The relative path to the dahdi-linux tree. The default is '.' and normally
there's no reason to override it.
===== TOOLS_DIR
The relative path to the dahdi-tools tree. The default is 'dahdi-tools'.
===== XPP_SYNC
Set a syncing astribank. See xpp_sync(8). Default is 'auto'.
===== AST_SCRIPT
The command for an init.d script to start/stop Asterisk. Should accept
'start' and 'stop' commands. Use 'true' if you want to make that a
no-op. Defaults to '/etc/init.d/asterisk' .
===== MODULES_LOAD
Manual list of modules. They will be loaded by insmod. If reside in a
subdir, add it explicitly. Modules for the drivers that are detected on
the system will be added by the script. Default: 'dahdi
dahdi_echocan_mg2'
===== REMOVE_MODULES
A list of modules to remove when unloading. Will be resolved
recursively. The default is 'dahdi'. You may also want to have 'oslec'
or 'hpec' there if you use them.
===== KVERS
If you want to build DAHDI for a different kernel version than the one
currently running on the system (mostly useful for a remote install).
Note that you will normally need to export this, in order for this to
take effect on the 'make' command. In live/live.conf itself have the line:
export KVERS="2.6.39-local"
===== KSRC
Alternatively, if you want to point to an exact kernel source tree,
set it with KSRC. Just like KVERS above, it needs to be explicitly exported.
export KSRC="/usr/src/tree/linux"
Module Parameters
-----------------
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.
Example line:
options dahdi debug=1
The module parameters can normally be modified at runtime through sysfs:
pungenday:~# cat /sys/module/dahdi/parameters/debug
0
pungenday:~# echo 1 >/sys/module/dahdi/parameters/debug
pungenday:~# cat /sys/module/dahdi/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:
=== debug
(most modules)
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:
To get a list of parameters supported by a module, use
modinfo module_name
Or, for a module you have just built:
modinfo ./drivers/dahdi/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 .
- 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: 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 - DAHDI 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 script xpp_debug in the source tree can help settting them at run
time.
=== deftaps
(dahdi)
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_dahdi tends to pass its own value anyway, with a
different default size. So normally setting this doesn't change
anything.
=== max_pseudo_channels
(dahdi)
The maximum number of pseudo channels that dahdi will allow userspace to
create. Pseudo channels are used when conferencing channels together.
The default is 512.
=== auto_assign_spans
(dahdi)
See <<_span_assignments,Span Assignments>> below.
XPP (Astribank) module parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==== debug
(all modules) - see above.
==== dahdi_autoreg
(xpp)
Deprecated. See dahdi.<<_auto_assign_spans,auto_assign_spans>> above.
Originally had a somewhat similar (but xpp-specific and more limited)
role to auto_assign_spans. For backward compatibility this variable is
still kept, but its value is unused. Astribanks will auto-register
with dahdi if auto_assign_spans is not set.
==== tools_rootdir
(xpp)
Defaults to /. Passed (as the variable DAHDI_TOOLS_ROOTDIR) to generated
events (which can be used in udev hooks). Also serves as the base of
the variable DAHDI_INIT_DIR (by default: $DAHDI_TOOLS_DIR/usr/share/dahdi).
==== initdir
(xpp)
Deprecated. Setting both initdir and tools_rootdir will generate an error.
A directory under tools_rootdir containing the initialization scripts.
The default is /usr/share/dahdi .
Setting this value could be useful if that location is inconvenient for you.
==== rx_tasklet
(xpp)
Enable (1) or disable (0) doing most of the packets processing in
separate tasklets. This should probably help on higher-end systems with
multiple Astribanks.
==== vmwi_ioctl
(xpd_fxs)
Does userspace support VMWI notification via ioctl? Default: 1 (yes).
Disable this (0) to have the driver attempt to detect the voicemail
message waiting indication status for this port from FSK messages
userspace (Asterisk) sends. Set the ports to use AC neon-lamp style
message waiting indication. The detection from the FSK messages takes
extra CPU cycles but is required with e.g. Asterisk < 1.6.0 .
Also note that in order for this parameter to take effect, it must be
set before the span is registered. This practically means that it
should be set through modprobe.d files.
See also Voicemail Indication in README.Astribank.
==== usb1
(xpp_usb)
Enable (1) or disable (0) support of USB1 devices. Disabled by default.
USB1 devices are not well-tested. It seems that they don't work at all
for Astribank BRI. Generally they should work with the current code, but
we expect the voice quality issues. Hence we would like to make it
very clear that you if you have a USB1 port (rather than a USB2 one, as
recommended) you will have to take an action to enable the device.
==== poll intervals
(various)
There are various values which the driver occasionally polls the
device for. For instance, the parameter poll_battery_interval for
xpd_fxo to poll the battery, in order to know if the telco line is
actually connected.
The value of those parameters is typically a number in milliseconds.
0 is used to disable polling. Under normal operation there should be
no reason to play with those parameters.
==== dtmf_detection
(xpd_fxs)
Enable (1) or disable (0) support of hardware DTMF detection by the
Astribank.
==== caller_id_style
(xpd_fxo)
Various types of caller ID signalling styles require knowing the PCM
even when the line is on-hook (which is usually a waste of CPU and
bandwidth). This parameter allows fine-tuning the behaviour here:
* 0 (default) - Don't pass extra PCM when on-hook.
* 1 ETSI-FSK: Wait for polarity reversal to come before a ring and
then start passing PCM until the caller ID has been passed.
* 2 ETSI-DTMF: Always pass PCM and generate a DTMF if polarity reversal is
detected before ring.
* 3 Passthrough: Always pass PCM as-is.
This parameter is read-only. It cannot be changed at run-time.
==== battery_threshold
(xpd_fxo)
Minimum voltage that shows there is battery. Defaults to 3. Normally you
should not need to change this, unless dealing with a funky PSTN
provider.
==== battery_debounce
(xpd_fxo)
Minimum interval (msec) for detection of battery off (as opposed to e.g.
a temporary power denial to signal a hangup). Defaults to 1000. As with
battery_threshold above, there's normally no need to tweak it.
==== use_polrev_firmware
(xpd_fxo)
Enable (1, default) or disable (0) support for polarity reversal
detection in the hardware. Only has effect with PIC_TYPE_2.hex rev. >=
11039 and with the initialization changes (init_card_2_30) in rev.
949aa49.
This parameter is read-only. It cannot be changed at run-time.
Internals
---------
DAHDI Device Files
~~~~~~~~~~~~~~~~~~
Userspace programs will usually interact with DAHDI through device
files under the /dev/dahdi directory (pedantically: character device files
with major number 196) . Those device files can be generated statically
or dynamically through the udev system.
* /dev/dahdi/ctl (196:0) - a general device file for various information and
control operations on the DAHDI channels.
* /dev/dahdi/chan/N/M - A device file for channel M in span N
- Both N and M are zero padded 3 digit numbers
- Both N and M start at 001
- M is chanpos - numbering relative to the current span.
* /dev/dahdi/NNN (196:NNN) - for NNN in the range 1-249. A device file for
DAHDI channel NNN. It can be used to read data from the channel
and write data to the channel. It is not generated by default but may
be generated as a symlink using udev rules.
* /dev/dahdi/transcode (196:250) - Used to connect to a DAHDI transcoding
device.
* /dev/dahdi/timer (196:253) - Allows setting timers. Used anywhere?
* /dev/dahdi/channel (196:254) - Can be used to open an arbitrary DAHDI
channel. This is an alternative to /dev/dahdi/NNN that is not limited to
249 channels.
* /dev/dahdi/pseudo (196:255) - A timing-only device. Every time you open
it, a new DAHDI channel is created. That DAHDI channel is "pseudo" -
DAHDI receives no data in it, and only sends garbage data with the
same timing as the DAHDI timing master device.
DAHDI Timing
~~~~~~~~~~~~
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.
DAHDI "ticks" once per millisecond (1000 times per second). On each tick every
active DAHDI channel reads and 8 bytes of data. Asterisk also uses this for
timing, through a DAHDI 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 DAHDI hardware at all. Even a digital card
may be used for other uses or is simply not connected to a provider. DAHDI
cards are also capable of providing timing from a clock on card. Cheap x100P
clone cards are sometimes used for that purpose.
If a hardware timing source either cannot be found or stops providing timing
during runtime, DAHDI will automatically use the host timer in order provide
timing.
You can check the DAHDI timing source with dahdi_test, which is a small
utility that is included with DAHDI. It runs in cycles. In each such cycle it
tries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded
or you don't have the device files, it will fail immediately. If you lack a
timing device it will hang forever in the first cycle. Otherwise 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.
Spans and Channels
~~~~~~~~~~~~~~~~~~
DAHDI provides telephony *channels* to the userspace applications.
Those channels are channels are incorporated 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.
There are up to 128 spans and 1024 channels. This is a hard-wired limit
(see dahdi/user.h . Several places throuout the code assume a channel
number fits in a 16 bits number). Channel and span numbers start at 1.
Span Assignments
~~~~~~~~~~~~~~~~
A DAHDI device (e.g. a PCI card) is represented within the DAHDI drivers
as a 'DAHDI device'. Normally (with auto_assign_spans=1 in the module
dahdi, which is the default), when a device is discovered and loaded,
it registers with the DAHDI core and its spans automatically become
available. However if you have more than one device, you may be
interested to set explicit spans and channels numbers for them. To use
manual span assigment, set 'auto_assign_spans' to 0 . e.g. in a file
under /etc/modprobe.d/ include the following line:
options dahdi auto_assign_spans=0
You will then need to assign the spans manually at device startup. You
will need to assign a span number and channel numbers for each
available span on the system. On my test system I have one BRI PCI card
and one Astribank BRI+FXS:
# grep . /sys/bus/dahdi_devices/devices/*/spantype
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:1:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:2:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:3:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:4:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:5:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:6:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:7:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:8:BRI
/sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:9:FXS
/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:1:TE
/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:2:TE
/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:3:NT
/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:4:NT
All spans here, except the FXS one, are BRI spans with 3 channels per span.
In order to assign a span, we write three numbers separated by colns to
the file 'assign_span' in the SysFS node
local_num:span_num:base_chan_num
Thus:
echo 9:5:10 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span
echo 2:8:40 >/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span
echo 1:1:1 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span
echo 4:6:20 >/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span
echo 3:2:5 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span
As you can see, the order of span numbers or local span number is
insignificant. However the order of channel numbers must be the same as
that of span numbers.
Which indeed produced:
# head -n3 -q /proc/dahdi/*
Span 1: XBUS-00/XPD-00 "Xorcom XPD [usb:LAB-0003].1: BRI_NT"
1 XPP_BRI_NT/00/00/0
Span 2: XBUS-00/XPD-02 "Xorcom XPD [usb:LAB-0003].3: BRI_TE"
5 XPP_BRI_TE/00/02/0
Span 5: XBUS-00/XPD-10 "Xorcom XPD [usb:LAB-0003].9: FXS" (MASTER)
10 XPP_FXS/00/10/0
Span 6: B4/0/4 "B4XXP (PCI) Card 0 Span 4" RED
23 B4/0/4/1 YELLOW
Span 8: B4/0/2 "B4XXP (PCI) Card 0 Span 2" RED
40 B4/0/2/1 RED
Likewise spans can be unassigned by writing to the 'unassign-span'
"file".
Dynamic Spans
~~~~~~~~~~~~~
Dynamic spans are spans that are not represented by real hardware.
Currently there are two types of them:
tdmoe::
TDM over Ethernet. A remote span is identified by an ethernet (MAC)
address.
local::
Generates a span that is actually a loopback to a different local
span.
Modules that support the dynamic spans are typically loaded at the time
the ioctl DAHDI_DYNAMIC_CREATE is called. This is typically called by
dahdi_cfg when it has a line such as:
dynamic,somename,params
in /etc/dahdi/system.conf . In that case it will typically try to load
(through modprobe) the modules dahdi_dynamic and
dahdi_dynamic_'somename'. It will then pass 'params' to it.
Dynamic spans are known to be tricky and are some of the least-tested
parts of DAHDI.
Echo Cancellers
~~~~~~~~~~~~~~~
(To be documented later)
Tone Zones
~~~~~~~~~~
(To be documented later)
PROCFS Interface: /proc/dahdi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A simple way to get the current list of spans and channels each span contains
is the files under /proc/dahdi . /proc/dahdi is generated by DAHDI as it
loads. As each span registers to DAHDI, a file under /proc/dahdi 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 a few optional
general counter lines, 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 alarms 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"
There are several extra optional keywords that may be added there:
(Master)::
This span is the master span. See <<_dahdi_timing,DAHDI Timing>>.
ClockSource::
The clock source among several spans that belong to a single E1/J1/T1
card.
RED/YELLOW/RED/NOTOPEN/LOOP/RECOVERING::
The span is in alarm
Following that line there may be some optional lines about IRQ misses,
timing slips and such, if there are any.
The channel line for each channel shows its channel number, name and the
actual signalling assigned to it through dahdi_cfg. Before being configured by
dahdi_cfg: This is DAHDI channel 2, whose name is 'XPP_FXS/0/0/1'.
2 XPP_FXS/0/0/1
After being configured by dahdi_cfg: 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)
SysFS Interface
~~~~~~~~~~~~~~~
DAHDI exposes several interfaces under the SysFS virtual file system.
SysFS represents kernel objects in nodes - directories. There properties
are often files. They may also contain other nodes or include symlinks
to other nodes.
Class DAHDI
^^^^^^^^^^^
Under /sys/class/dadhi there exists a node for the non-channel DAHDI
device file under /dev/dahdi. The name is 'dahdi!foo' for the file
'/dev/dahdi/foo' (udev translates exclamation marks to slashes). Those
nodes are not, for the most part, proper SysFS nodes, and don't include
any interesting properties. The files in this class `ctl`, `timer`,
`channel`, `pseudo` and (if exists) `transcode`.
Devices Bus
^^^^^^^^^^^
Each DAHDI device (a physical device, such as a PCI card) is represented
by a node under /sys/bus/dahdi_devices/devices named with the name of
its device.
Its attributes include:
===== /sys/bus/dahdi_devices/devices/DEVICE/assgin-span
Write-only attribute: this device's spans should now be assigned
("registered"). See section about <<_span_assignments>>.
===== /sys/bus/dahdi_devices/devices/DEVICE/auto-assign
Write-only attribute. Spans in the device auto-assign ("register" as in
the original interface). See section about <<_span_assignments>>.
===== /sys/bus/dahdi_devices/devices/DEVICE/hardware_id
A unique hardware-level identifier (e.g. serial number), if available.
===== /sys/bus/dahdi_devices/devices/DEVICE/manufacturer
The name of the manufacturer. Freeform-string.
===== /sys/bus/dahdi_devices/devices/DEVICE/registration_time
The time at which the device registered with the DAHDI core. Example
value: "0005634136.941901429".
===== /sys/bus/dahdi_devices/devices/DEVICE/spantype
A line for each available span: <num>:<type>. This has to be provided
here as in the case of manual assignment, userspace may need to know
it before span nodes are created.
===== /sys/bus/dahdi_devices/devices/DEVICE/spantype
Device type.
===== /sys/bus/dahdi_devices/devices/DEVICE/unassign-span
Write-only attribute: the span whose device-local number is written
should now be unassigned ("unregistered"). See section about
<<_span_assignments>>.
Spans Bus
^^^^^^^^^
Each DAHDI span is represented by a node under
/sys/bus/dahdi_spans/devices with the name 'span-N' (where N is the
number of the span). Spans of each device also reside under the node of
the device.
Useful attributes in the span node:
===== /sys/bus/dahdi_spans/devices/span-N/alarms
The alarms of the span. Currently this is a numeric representation.
This may change in the future.
===== /sys/bus/dahdi_spans/devices/span-N/basechan
The channel number of the first channel. The channel numbers of the
following channels are guaranteed to follow it.
===== /sys/bus/dahdi_spans/devices/span-N/channels
The number of the channels in the span.
===== /sys/bus/dahdi_spans/devices/span-N/desc
A free-form description of the span.
===== /sys/bus/dahdi_spans/devices/span-N/is_digital
1 if the span is digital, 0 if it isn't.
===== /sys/bus/dahdi_spans/devices/span-N/is_sync_master
1 if the span is the sync master, 0 if it isn't.
===== /sys/bus/dahdi_spans/devices/span-N/lbo
LBO setting for the channel.
===== /sys/bus/dahdi_spans/devices/span-N/lineconfig
The framing and coding of the span, for a digital span. Textual
represenation:
<B8ZS|AMI|HDB3>/<D4|ESF|CCS>[/CRC4]
===== /sys/bus/dahdi_spans/devices/span-N/local_spanno
The number of the span within the DAHDI device.
===== /sys/bus/dahdi_spans/devices/span-N/name
A concise name for this span.
===== /sys/bus/dahdi_spans/devices/span-N/spantype
A very short type string.
===== /sys/bus/dahdi_spans/devices/span-N/syncsrc
Current sync source.
==== sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span
All spans in the bus are handled by a single driver. The driver has one
non-standard attribute: master_span. printing it shows the current DAHDI
master span writing a number to it forces setting this span as the master
span.
Channels Bus
^^^^^^^^^^^^
Each DAHDI channel is represented by a node under
/sys/bus/dahdi_channels/devices with the name 'dahdi!channels!N!M'
(where N is the number of the span and M is the number of the channel
in the span - chanpos). Channels of each span also reside under the node
of the span.
Useful attributes in the channel node (All attributed listed below are
read-only):
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/alarms
List of names of the current active alarms (space separated). Normally
(no alarms) empty. Example:
RED YELLOW
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/blocksize
The block size set by userspace.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/channo
The (global) channel number.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/chanpos
The channel number within the span.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/dev
Major and minor device numbers.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_factory
The name of the echo canceller to be used in the channel, if one is
configured. Example:
MG2
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_state
State of the echo canceller. ACTIVE: configured and inuse. INACTIVE
otherwise.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/in_use
1 if the channel is in use (was opepend by userspace), 0 otherwise.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/name
A name string for the channel
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sig
The signalling types set for the channel. A space-separated list of
signalling types.
===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sigcap
The signalling types this channel may be configured to handle. A space-
separated list of signalling types.
User-space Interface
~~~~~~~~~~~~~~~~~~~~
User-space programs can only work with DAHDI channels. The basic
operation is 'read()' to read audio from the device and write() to write
audio to it. Audio can be encoded as either alaw (G.711a) or (m)ulaw
(G.711u). See the ioctl DAHDI_SETLAW.
While it is technically possible to use /dev/dahdi/NUMBER directly, this
will only work for channel numbers up to 249. Generally you should use:
int channo = CHAN_NUMBER_TO_OPEN;
int rc;
int fd = open("/dev/dahdi/channel", O_RDRW, 0600);
// Make sure fd >= 0
rc = ioctl(fd, DAHDI_SPECIFY, &channo) < 0);
// Make sure this rc >= 0
FIXME: there's more to tell about the user-space interface.
Configuration
~~~~~~~~~~~~~
Most of the configuration is applied from userspace using the tool
'dahdi_cfg' in the package dahdi_tools. This section will not cover the
specifics of that file. Rather it will cover the way configuration from
this file is applied. Also note that there are other methods to
configure DAHDI drivers: there are <<_module_parameters,Module
Parameters>>. The xpp driver have their own separate initialization
scripts and xpp.conf that arecovered in README.Astribank.
When a span is registered, it is considered "unconfigured". Only after
dahdi_cfg has been run to apply configuration, the span is ready to run.
Some of the configuration is handled by the DAHDI core. Some of it is
handled by callbacks, which are function pointers in the `struct
dahdi_span': 'spanconfig', 'chanconfig' and (in a way) 'startup'.
Dahdi_cfg starts by reading the configuration from the configuration
file ('/etc/dahdi/system.conf', by default), and creating a local
configuration to apply. If you use -v, at this stage it will pront the
configuration that is "about to be configured". Then it will start to
actually apply the configuration.
Before actually applying configuration, it destroys any existing
<<_dynamic_spans,dynamic spans>> and generates new ones (if so
configured. FIXME: what about running DAHDI_SPANCONFIG for new dynamic
spans?).
Next thing it will do is apply the parameters from *span* lines using
the ioctl DAHDI_SPANCONFIG. Some generic processing of parameters passed
in DAHDI_SPANCONFIG is done in the DAHDI core, in the callback function
spanconfig in , but most of it is left to 'spanconfig' callback of the
span (if it exists. This one typically does not exists on analog cards).
Now dahdi_cfg will ask each existing channel for its existing
configuration and apply configuration if configuration changes are
needed. Configuration is applied to the channels using the ioctl call
DAHDI_CHANCONFIG ioctl. As in the case of the span configuration, part
of it is applied by the DAHDI core, and then it is handed over to the
span's chanconfig callback. Typically all spans will have such a
callback.
<<_echo_cancellers,Echo cancellers>> and <<_tone_zones,tone-zones>> are
handled separately later.
Once everything is done, the ioctl DAHDI_STARTUP is called for every
span. This is also translated to a call to the optional span callback
'startup'.
Finally the ioctl DAHDI_HDLC_RATE is called for every channel (that is:
if '56k' is not set for the channel, it will be explicitly set to the
standard HDLC rate of 64k).
Low-Level Drivers
~~~~~~~~~~~~~~~~~
Low-level drivers create spans ('struct dahdi_span'). They register the
spans with the DAHDI core using 'dahdi_device_register()'.
'struct dahdi_span' has a number of informative members that are updated
solely by the low-level driver:
name::
A concise span name. E.g.: Foo/1
desc::
A slightly longer span name.
spantype::
Span type in text form.
manufacturer::
Span's device manufacturer
devicetype::
Span's device type
location::
span device's location in system
irq::
IRQ for this span's hardware
irqmisses::
Interrupt misses
timingslips::
Clock slips
There are various function pointers in the struct 'dahdi_span' which are
used by the DAHDI core to call the low-level driver. Most of them are
optional.
The following apply to a span:
setchunksize::
FIXME: seems to be unused.
spanconfig::
Basic span configuration (called from dahdi_cfg).
startup::
Last minute initialization after the configuration was applied.
shutdown::
Explicit shutdown (e.g. for dynamic spans). Normally not needed.
maint::
Enable/disable maintinance mode (FIXME: document).