{"id":13850748,"url":"https://github.com/asterisk/dahdi-linux","last_synced_at":"2025-04-05T06:04:22.337Z","repository":{"id":5884167,"uuid":"7102005","full_name":"asterisk/dahdi-linux","owner":"asterisk","description":"This is the official dahdi-linux repository. All issues and PR should be raised here.","archived":false,"fork":false,"pushed_at":"2025-01-02T06:33:07.000Z","size":9268,"stargazers_count":54,"open_issues_count":11,"forks_count":70,"subscribers_count":16,"default_branch":"master","last_synced_at":"2025-03-29T05:05:11.786Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/asterisk.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2012-12-10T22:31:43.000Z","updated_at":"2025-03-19T13:37:59.000Z","dependencies_parsed_at":"2023-01-11T17:01:45.623Z","dependency_job_id":"ad19f719-f28f-4e2e-b364-5b0bcd5f68b5","html_url":"https://github.com/asterisk/dahdi-linux","commit_stats":{"total_commits":1050,"total_committers":32,"mean_commits":32.8125,"dds":0.4161904761904762,"last_synced_commit":"648016d6b3a06f7ec75c17ef94ffa17be59eebcf"},"previous_names":[],"tags_count":87,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asterisk%2Fdahdi-linux","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asterisk%2Fdahdi-linux/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asterisk%2Fdahdi-linux/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asterisk%2Fdahdi-linux/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/asterisk","download_url":"https://codeload.github.com/asterisk/dahdi-linux/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247294527,"owners_count":20915340,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-04T21:00:17.587Z","updated_at":"2025-04-05T06:04:22.321Z","avatar_url":"https://github.com/asterisk.png","language":"C","funding_links":[],"categories":["C"],"sub_categories":[],"readme":"DAHDI Telephony Interface Driver\n=================================\nAsterisk Development Team \u003casteriskteam@digium.com\u003e\n$Revision$, $Date$\n\nDAHDI stands for Digium Asterisk Hardware Device Interface.\n\nThis package contains the kernel modules for DAHDI. For the required \nuserspace tools see the package dahdi-tools.\n\nSupported Hardware\n------------------\nDigital Cards\n~~~~~~~~~~~~~\n- wcte43x:\n  * Digium TE435: PCI express quad-port T1/E1/J1\n  * Digium TE436: PCI quad-port T1/E1/J1\n  * Digium TE235: PCI express dual-port T1/E1/J1\n  * Digium TE236: PCI dual-port T1/E1/J1\n- wcte13xp:\n  * Digium TE131: PCI express single-port T1/E1/J1\n  * Digium TE133: PCI express single-port T1/E1/J1 with echocan\n  * Digium TE132: PCI single-port T1/E1/J1\n  * Digium TE134: PCI single-port T1/E1/J1 with echocan\n- wct4xxp:\n  * Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1\n  * Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1\n  * Digium TE220: PCI-Express dual-port T1/E1/J1\n  * Digium TE420: PCI-Express quad-port T1/E1/J1\n  * Digium TE820: PCI-Express eight-port T1/E1/J1\n- wcte12xp:\n  * Digium TE120P: PCI single-port T1/E1/J1\n  * Digium TE121: PCI-Express single-port T1/E1/J1\n  * Digium TE122: PCI single-port T1/E1/J1\n- wcte11xp:\n  * Digium TE110P: PCI single-port T1/E1/J1\n- wct1xxp:\n  * Digium T100P: PCI single-port T1\n  * Digium E100P: PCI single-port E1\n- wcb4xxp:\n  * Digium B410: PCI quad-port BRI\n  * Digium B233: PCI-Express dual-port BRI with echo can\n  * Digium B234: PCI dual-port dual-port BRI with echo can\n  * Digium B433: PCI-Express quad-port BRI with echo can\n  * Digium B434: PCI quad-port BRI with echo can\n\n\nAnalog Cards\n~~~~~~~~~~~~\n- wcaxx:\n  * Digium A8A: PCI up to 8 mixed FXS/FXO ports\n  * Digium A8B: PCI express up to 8 mixed FXS/FXO ports\n  * Digium A4A: PCI up to 4 mixed FXS/FXO ports\n  * Digium A4B: PCI express up to 4 mixed FXS/FXO ports \n- wctdm24xxp:\n  * Digium TDM2400P/AEX2400: up to 24 analog ports\n  * Digium Hx8 Series: Up to 8 analog or BRI ports\n- wctdm:\n  * Digium TDM400P: up to 4 analog ports\n- xpp: Xorcom Astribank: a USB connected unit of up to 32 ports\n  (including the digital BRI and E1/T1 modules)\n- wcfxo: X100P, similar and clones. A simple single-port FXO card\n\n\nOther Drivers\n~~~~~~~~~~~~~\n- wctc4xxp: Digium hardware transcoder cards (also need dahdi_transcode)\n- dahdi_dynamic_eth: TDM over Ethernet (TDMoE) driver. Requires dahdi_dynamic\n- dahdi_dynamic_loc: Mirror a local span. Requires dahdi_dynamic\n\nInstallation\n------------\nIf all is well, you just need to run the following:\n\n  make\n  make install\n\nYou'll need the utilities provided in the package dahdi-tools to \nconfigure DAHDI devices on your system.\n\nIf using `sudo` to build/install, you may need to add /sbin to your PATH.\n\nIf you still have problems, read further.\n\n\nBuild Requirements\n~~~~~~~~~~~~~~~~~~\ngcc and friends. Generally you will need to install the package gcc.\nThere may be cases where you will need a specific version of gcc to build\nkernel modules.\n\nKernel Source / \"Headers\"\n^^^^^^^^^^^^^^^^^^^^^^^^^\n- Building DAHDI-linux requires a kernel build tree.\n- This should basically be at least a partial kernel source tree and\n  most importantly, the exact kernel .config file used for the build as\n  well as several files generated at kernel build time.\n- KERNEL_VERSION is the output of the command `uname -r`\n- If you build your own kernel, you need to point to the exact kernel\n  build tree. Luckily for you, this will typically be pointed by the\n  symbolic link /lib/modules/KERNEL_VERSION/build which is the location\n  zaptel checks by default.\n- If you use a kernel from your distribution you will typically have a\n  package with all the files required to build a kernel modules for your\n  kernel image.\n  * On Debian and Ubuntu this is\n    +++ linux-headers-`uname -r` +++\n  * On Fedora, RHEL and compatibles (e.g. CentOS) and SUSE this is\n    the kernel-devel package. Or if you run kernel-smp or kernel-xen,\n    you need kernel-smp-devel or kernel-xen-devel, respectively.\n  * In some distributions (e.g.: in RHEL/CentOS, Fedora, Ubuntu) the\n    installation of the kernel-devel / kernel-headers package will\n    be of a version that is newer than the one you currently run. In\n    such a case you may need to upgrade the kernel package itself as\n    well and reboot.\n- To point explicitly to a different build tree: set KSRC to the kernel\n  source tree or KVERS to the exact kernel version (if \"headers\" are\n  available for a different version). This parameter must be run on\n  every calls to 'make' (e.g.: 'make clean', 'make install').\n\n  make KVERS=2.6.18.Custom\n  make KSRC=/home/tzafrir/kernels/linus\n\n\nKernel Configuration\n^^^^^^^^^^^^^^^^^^^^\nIf you build a custom kernel, note the following configuration items:\n\n- CONFIG_CRC_CCITT must be enabled ('y' or 'm'). On 2.6 kernels this can\n  be selected These can be selected from the \"Library Routines\" submenu\n  during kernel configuration via \"make menuconfig\".\n- DAHDI will work if you disable module unloading. But you may need\n  extra reboots.\n- DAHDI needs the BKL (Big Kernel Lock). This may be annoying in\n  \u003e=2.6.37 kernels. Make sure you enable CONFIG_BKL on those kernels.\n\n\nInstalling to a Subtree\n~~~~~~~~~~~~~~~~~~~~~~~\nThe following may be useful when testing the package or when preparing a\npackage for a binary distribution (such as an rpm package) installing\nonto a subtree rather than on the real system. \n\n  make install DESTDIR=targetdir\n\nThis can be useful for any partial install target of the above (e.g:\ninstall-modules or install-programs).\n\nthe targetdir must be an absolute path, at least if you install the\nmodules. To install to a relative path you can use something like:\n\n  make install-modules DESTDIR=$PWD/target\n\n\nExtra Modules\n~~~~~~~~~~~~~\nTo build extra modules / modules directory not included in the DAHDI \ndistribution, use the optional variables MODULES_EXTRA and\nSUBDIRS_EXTRA:\n\n  make MODULES_EXTRA=\"mod1 mod2\"\n  make MODULES_EXTRA=\"mod1 mod2\" SUBDIRS_EXTRA=\"subdir1/ subdir1/\"\n\n\nStatic Device Files\n~~~~~~~~~~~~~~~~~~~\nUserspace programs communicate with the DAHDI modules through special\ndevice files under /dev/dahdi .  Those are normally created by udev, but\nif you use an embedded-type system and don't wish to use udev, you can\ngenerate them with the following script, from the source directory:\n\n  ./build_tools/make_static_devs\n\nThis will generate the device files under /dev/dahdi . If you need to\ngenerate them elsewhere (e.g. `tmp/newroot/dev/dahdi`) use the option -d\nto the script:\n\n  ./build_tools/make_static_devs -d tmp/newroot/dev/dahdi\n\n\nDKMS\n~~~~\nDKMS, Dynamic Kernel Module Support, is a framework for building Linux\nkernel modules. It is used, among others, by several distributions that\npackage the DAHDI kernel modules.\n\nDKMS is designed to provide updates over drivers installed from original\nkernel modules tree. Thus it installed modules into /lib/modules/updates\nor /lib/modules/VERSION/updates . This is generally not an issue on\nnormal operation. However if you try to install DAHDI from source on\na system with DAHDI installed from DKMS this way (potentially of an\nolder version), be sure to remove the DKMS-installed modules from the\nupdates directory. If you're not sure, the following command will give\nyou a clue of the versions installed:\n\n  find /lib/modules -name dahdi.ko\n\n\n===== LINUX_DIR\nThe relative path to the dahdi-linux tree. The default is '.' and normally\nthere's no reason to override it.\n\n===== TOOLS_DIR\nThe relative path to the dahdi-tools tree. The default is 'dahdi-tools'.\n\n===== XPP_SYNC\nSet a syncing astribank. See xpp_sync(8). Default is 'auto'.\n\n===== AST_SCRIPT\nThe command for an init.d script to start/stop Asterisk. Should accept \n'start' and 'stop' commands. Use 'true' if you want to make that a\nno-op. Defaults to '/etc/init.d/asterisk' .\n\n===== MODULES_LOAD\nManual list of modules. They will be loaded by insmod. If reside in a \nsubdir, add it explicitly. Modules for the drivers that are detected on\nthe system will be added by the script. Default: 'dahdi\ndahdi_echocan_mg2'\n\n===== REMOVE_MODULES\nA list of modules to remove when unloading. Will be resolved\nrecursively. The default is 'dahdi'. You may also want to have 'oslec'\nor 'hpec' there if you use them.\n\n===== KVERS\nIf you want to build DAHDI for a different kernel version than the one\ncurrently running on the system (mostly useful for a remote install).\nNote that you will normally need to export this, in order for this to\ntake effect on the 'make' command. In live/live.conf itself have the line:\n\n  export KVERS=\"2.6.39-local\"\n\n===== KSRC\nAlternatively, if you want to point to an exact kernel source tree,\nset it with KSRC. Just like KVERS above, it needs to be explicitly exported.\n\n  export KSRC=\"/usr/src/tree/linux\"\n\n\nModule Parameters\n-----------------\nThe kernel modules can be configured through module parameters. Module\nparameters can optionally be set at load time. They are normally set (if\nneeded) by a line in a file under /etc/modprobe.d/ or in the file\n/etc/modprobe.conf.\n\nExample line:\n\n  options dahdi debug=1\n\nThe module parameters can normally be modified at runtime through sysfs:\n\n  pungenday:~# cat /sys/module/dahdi/parameters/debug \n  0\n  pungenday:~# echo 1 \u003e/sys/module/dahdi/parameters/debug\n  pungenday:~# cat /sys/module/dahdi/parameters/debug \n  1\n\nViewing and setting parameters that way is possible as of kernel 2.6 .\nIn kernels older than 2.6.10, the sysfs \"files\" for the parameters\nreside directly under /sys/module/'module_name' .\n\nUseful module parameters:\n\n=== debug\n(most modules)\n\nSets debug mode / debug level. With most modules 'debug' can be either\ndisabled (0, the default value) or enabled (any other value). \n\nwctdm and wcte1xp print several extra debugging messages if the value\nof debug is more than 1.\n\nSome modules have \"debugging flags\" bits - the value of debug is a\nbitmask and several messages are printed if some bits are set:\n\nTo get a list of parameters supported by a module, use \n\n  modinfo module_name\n\nOr, for a module you have just built:\n\n  modinfo ./drivers/dahdi/module_name.ko\n\nFor the xpp modules this will also include the description and default\nvalue of the module. You can find a list of useful xpp module parameters\nin README.Astribank .\n\n\n- wctdm24xxp:\n  * 1: DEBUG_CARD\n  * 2: DEBUG_ECHOCAN\n- wct4xxp:\n  * 1: DEBUG_MAIN\n  * 2: DEBUG_DTMF\n  * 4: DEBUG_REGS\n  * 8: DEBUG_TSI\n  * 16: DEBUG_ECHOCAN\n  * 32: DEBUG_RBS\n  * 64: DEBUG_FRAMER\n- xpp: See also README.Astribank:\n  * 1: GENERAL - General debug comments.\n  * 2: PCM - PCM-related messages. Tend to flood logs.\n  * 4: LEDS - Anything related to the LEDs status control. The driver\n    produces a lot of messages when the option is enabled.\n  * 8: SYNC - Synchronization related messages.\n  * 16: SIGNAL - DAHDI signalling related messages.\n  * 32: PROC - Messages related to the procfs interface.\n  * 64: REGS - Reading and writing to chip registers. Tends to flood\n        logs.\n  * 128: DEVICES - Device instantiation, destruction and such.\n  * 256 - COMMANDS - Protocol commands. Tends to flood logs.\n  +\n  +\n  The script xpp_debug in the source tree can help settting them at run\n  time.\n\n=== deftaps\n(dahdi)\n\nThe default size for the echo canceller. The number is in \"taps\", that\nis \"samples\", 1/8 ms. The default is 64 - for a tail size of 8 ms.\n\nAsterisk's chan_dahdi tends to pass its own value anyway, with a\ndifferent default size. So normally setting this doesn't change\nanything.\n\n=== max_pseudo_channels\n(dahdi)\n\nThe maximum number of pseudo channels that dahdi will allow userspace to\ncreate.  Pseudo channels are used when conferencing channels together.\nThe default is 512.\n\n=== auto_assign_spans\n(dahdi)\n\nSee \u003c\u003c_span_assignments,Span Assignments\u003e\u003e below.\n\nXPP (Astribank) module parameters\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n==== debug\n(all modules) - see above.\n\n==== dahdi_autoreg\n(xpp)\n\nDeprecated. See dahdi.\u003c\u003c_auto_assign_spans,auto_assign_spans\u003e\u003e above.\n\nOriginally had a somewhat similar (but xpp-specific and more limited)\nrole to auto_assign_spans. For backward compatibility this variable is\nstill kept, but its value is unused. Astribanks will auto-register\nwith dahdi if auto_assign_spans is not set.\n\n==== tools_rootdir\n(xpp)\n\nDefaults to /. Passed (as the variable DAHDI_TOOLS_ROOTDIR) to generated\nevents (which can be used in udev hooks). Also serves as the base of\nthe variable DAHDI_INIT_DIR (by default: $DAHDI_TOOLS_DIR/usr/share/dahdi).\n\n==== initdir\n(xpp)\n\nDeprecated. Setting both initdir and tools_rootdir will generate an error.\n\nA directory under tools_rootdir containing the initialization scripts.\nThe default is /usr/share/dahdi .\nSetting this value could be useful if that location is inconvenient for you.\n\n==== rx_tasklet\n(xpp)\n\nEnable (1) or disable (0) doing most of the packets processing in\nseparate tasklets. This should probably help on higher-end systems with\nmultiple Astribanks.\n\n==== vmwi_ioctl\n(xpd_fxs)\n\nDoes userspace support VMWI notification via ioctl? Default: 1 (yes).\n\nDisable this (0) to have the driver attempt to detect the voicemail\nmessage waiting indication status for this port from FSK messages\nuserspace (Asterisk) sends. Set the ports to use AC neon-lamp style\nmessage waiting indication. The detection from the FSK messages takes\nextra CPU cycles but is required with e.g. Asterisk \u003c 1.6.0 .\n\nAlso note that in order for this parameter to take effect, it must be\nset before the span is registered. This practically means that it\nshould be set through modprobe.d files.\n\nSee also Voicemail Indication in README.Astribank.\n\n==== usb1\n(xpp_usb)\n\nEnable (1) or disable (0) support of USB1 devices. Disabled by default.\n\nUSB1 devices are not well-tested. It seems that they don't work at all\nfor Astribank BRI. Generally they should work with the current code, but\nwe expect the voice quality issues. Hence we would like to make it\nvery clear that you if you have a USB1 port (rather than a USB2 one, as\nrecommended) you will have to take an action to enable the device.\n\n==== poll intervals\n(various)\n\nThere are various values which the driver occasionally polls the\ndevice for. For instance, the parameter poll_battery_interval for\nxpd_fxo to poll the battery, in order to know if the telco line is\nactually connected.\n\nThe value of those parameters is typically a number in milliseconds.\n0 is used to disable polling. Under normal operation there should be\nno reason to play with those parameters.\n\n==== dtmf_detection\n(xpd_fxs)\n\nEnable (1) or disable (0) support of hardware DTMF detection by the\nAstribank.\n\n==== caller_id_style\n(xpd_fxo)\n\nVarious types of caller ID signalling styles require knowing the PCM\neven when the line is on-hook (which is usually a waste of CPU and\nbandwidth). This parameter allows fine-tuning the behaviour here:\n\n* 0 (default) - Don't pass extra PCM when on-hook.\n* 1 ETSI-FSK: Wait for polarity reversal to come before a ring and\n  then start passing PCM until the caller ID has been passed.\n* 2 ETSI-DTMF: Always pass PCM and generate a DTMF if polarity reversal is\n  detected before ring.\n* 3 Passthrough: Always pass PCM as-is.\n\nThis parameter is read-only. It cannot be changed at run-time.\n\n==== battery_threshold\n(xpd_fxo)\n\nMinimum voltage that shows there is battery. Defaults to 3. Normally you\nshould not need to change this, unless dealing with a funky PSTN\nprovider.\n\n==== battery_debounce\n(xpd_fxo)\n\nMinimum interval (msec) for detection of battery off (as opposed to e.g.\na temporary power denial to signal a hangup). Defaults to 1000. As with\nbattery_threshold above, there's normally no need to tweak it.\n\n==== use_polrev_firmware\n(xpd_fxo)\n\nEnable (1, default) or disable (0) support for polarity reversal\ndetection in the hardware. Only has effect with PIC_TYPE_2.hex rev. \u003e=\n11039 and with the initialization changes (init_card_2_30) in rev.\n949aa49.\n\nThis parameter is read-only. It cannot be changed at run-time.\n\n\nInternals\n---------\nDAHDI Device Files\n~~~~~~~~~~~~~~~~~~\nUserspace programs will usually interact with DAHDI through device\nfiles under the /dev/dahdi directory (pedantically: character device files \nwith major number 196) . Those device files can be generated statically\nor dynamically through the udev system.\n\n* /dev/dahdi/ctl (196:0) - a general device file for various information and\n  control operations on the DAHDI channels.\n* /dev/dahdi/chan/N/M - A device file for channel M in span N\n  - Both N and M are zero padded 3 digit numbers\n  - Both N and M start at 001\n  - M is chanpos - numbering relative to the current span.\n* /dev/dahdi/NNN (196:NNN) - for NNN in the range 1-249. A device file for\n  DAHDI channel NNN. It can be used to read data from the channel\n  and write data to the channel. It is not generated by default but may\n  be generated as a symlink using udev rules.\n* /dev/dahdi/transcode (196:250) - Used to connect to a DAHDI transcoding\n  device.\n* /dev/dahdi/timer (196:253) - Allows setting timers. Used anywhere?\n* /dev/dahdi/channel (196:254) - Can be used to open an arbitrary DAHDI\n  channel. This is an alternative to /dev/dahdi/NNN that is not limited to\n  249 channels.\n* /dev/dahdi/pseudo (196:255) - A timing-only device. Every time you open\n  it, a new DAHDI channel is created. That DAHDI channel is \"pseudo\" -\n  DAHDI receives no data in it, and only sends garbage data with the\n  same timing as the DAHDI timing master device.\n\n\nDAHDI Timing\n~~~~~~~~~~~~\nA PBX system should generally have a single clock. If you are connected to a\ntelephony provider via a digital interface (e.g: E1, T1) you should also\ntypically use the provider's clock (as you get through the interface). Hence\none important job of Asterisk is to provide timing to the PBX. \n\nDAHDI \"ticks\" once per millisecond (1000 times per second). On each tick every\nactive DAHDI channel reads and 8 bytes of data. Asterisk also uses this for\ntiming, through a DAHDI pseudo channel it opens.\n\nHowever, not all PBX systems are connected to a telephony provider via a T1 or\nsimilar connection. With an analog connection you are not synced to the other\nparty. And some systems don't have DAHDI hardware at all.  Even a digital card\nmay be used for other uses or is simply not connected to a provider. DAHDI\ncards are also capable of providing timing from a clock on card. Cheap x100P\nclone cards are sometimes used for that purpose.\n\nIf a hardware timing source either cannot be found or stops providing timing\nduring runtime, DAHDI will automatically use the host timer in order provide\ntiming.\n\nYou can check the DAHDI timing source with dahdi_test, which is a small\nutility that is included with DAHDI. It runs in cycles. In each such cycle it\ntries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded\nor you don't have the device files, it will fail immediately. If you lack a\ntiming device it will hang forever in the first cycle. Otherwise it will just\ngive you in each cycle the percent of how close it was. Also try running it\nwith the option -v for a verbose output.\n\n\nSpans and Channels\n~~~~~~~~~~~~~~~~~~\nDAHDI provides telephony *channels* to the userspace applications. \nThose hannels are incorporated into logical units called\n*spans*.\n\nWith digital telephony adapters (e.g: E1 or T1), a span normally \nrepresents a single port. With analog telephony a span typically\nrepresents a PCI adapter or a similar logical unit.\n\nBoth channels and spans are identified by enumerating numbers (beginning\nwith 1). The number of the channel is the lowest unused one when it is\ngenerated, and ditto for spans.\n\nThere are up to 128 spans and 1024 channels. This is a hard-wired limit\n(see dahdi/user.h . Several places throuout the code assume a channel\nnumber fits in a 16 bits number). Channel and span numbers start at 1.\n\n\nSpan Assignments\n~~~~~~~~~~~~~~~~\nA DAHDI device (e.g. a PCI card) is represented within the DAHDI drivers\nas a 'DAHDI device'. Normally (with auto_assign_spans=1 in the module\ndahdi, which is the default), when a device is discovered and loaded,\nit registers with the DAHDI core and its spans automatically become\navailable. However if you have more than one device, you may be\ninterested to set explicit spans and channels numbers for them. To use\nmanual span assigment, set 'auto_assign_spans' to 0 . e.g. in a file\nunder /etc/modprobe.d/ include the following line:\n\n  options dahdi auto_assign_spans=0\n\nYou will then need to assign the spans manually at device startup. You\nwill need to assign a span number and channel numbers for each\navailable span on the system. On my test system I have one BRI PCI card\nand one Astribank BRI+FXS:\n\n  # grep . /sys/bus/dahdi_devices/devices/*/spantype\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:1:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:2:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:3:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:4:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:5:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:6:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:7:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:8:BRI\n  /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:9:FXS\n  /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:1:TE\n  /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:2:TE\n  /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:3:NT\n  /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:4:NT\n\nAll spans here, except the FXS one, are BRI spans with 3 channels per span.\n\nIn order to assign a span, we write three numbers separated by colons to\nthe file 'assign_span' in the SysFS node\n\n  local_num:span_num:base_chan_num\n\nThus:\n\n  echo 9:5:10 \u003e/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span\n  echo 2:8:40 \u003e/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span\n  echo 1:1:1  \u003e/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span\n  echo 4:6:20 \u003e/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span\n  echo 3:2:5  \u003e/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span\n\nAs you can see, the order of span numbers or local span number is\ninsignificant. However the order of channel numbers must be the same as\nthat of span numbers.\n\nWhich indeed produced:\n\n  # head -n3 -q /proc/dahdi/*\n  Span 1: XBUS-00/XPD-00 \"Xorcom XPD [usb:LAB-0003].1: BRI_NT\"\n\n             1 XPP_BRI_NT/00/00/0\n  Span 2: XBUS-00/XPD-02 \"Xorcom XPD [usb:LAB-0003].3: BRI_TE\"\n\n             5 XPP_BRI_TE/00/02/0\n  Span 5: XBUS-00/XPD-10 \"Xorcom XPD [usb:LAB-0003].9: FXS\" (MASTER)\n\n            10 XPP_FXS/00/10/0\n  Span 6: B4/0/4 \"B4XXP (PCI) Card 0 Span 4\" RED\n\n            23 B4/0/4/1 YELLOW\n  Span 8: B4/0/2 \"B4XXP (PCI) Card 0 Span 2\" RED\n\n            40 B4/0/2/1 RED\n\nLikewise spans can be unassigned by writing to the 'unassign-span'\n\"file\".\n\n\nDynamic Spans\n~~~~~~~~~~~~~\nDynamic spans are spans that are not represented by real hardware.\nCurrently there are two types of them:\n\ntdmoe::\n  TDM over Ethernet. A remote span is identified by an ethernet (MAC)\n  address.\n\nlocal::\n  Generates a span that is actually a loopback to a different local\n  span.\n\nModules that support the dynamic spans are typically loaded at the time\nthe ioctl DAHDI_DYNAMIC_CREATE is called. This is typically called by\ndahdi_cfg when it has a line such as:\n\n  dynamic,somename,params\n\nin /etc/dahdi/system.conf . In that case it will typically try to load\n(through modprobe) the modules dahdi_dynamic and\ndahdi_dynamic_'somename'. It will then pass 'params' to it.\n\nDynamic spans are known to be tricky and are some of the least-tested\nparts of DAHDI.\n\n\nEcho Cancellers\n~~~~~~~~~~~~~~~\n(To be documented later)\n\n\nTone Zones\n~~~~~~~~~~\n(To be documented later)\n\n\nPROCFS Interface: /proc/dahdi\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nA simple way to get the current list of spans and channels each span contains\nis the files under /proc/dahdi . /proc/dahdi is generated by DAHDI as it\nloads. As each span registers to DAHDI, a file under /proc/dahdi is created\nfor it. The name of that file is the number of that span.\n\nEach file has a 1-line title for the span followed by a few optional\ngeneral counter lines, an empty line and then a line for each channel of\nthe span. \n\nThe title line shows the number of the span, its name and title, and \n(potentially) the alarms in which it is.\n\nThe title shows the span number and name, followed by any alarms the\nspan may have: For example, here is the first span in my system (with no\nalarms):\n\n  Span 1: XBUS-00/XPD-00 \"Xorcom XPD #0/0: FXS\"\n\nThere are several extra optional keywords that may be added there:\n\n(Master)::\n  This span is the master span. See \u003c\u003c_dahdi_timing,DAHDI Timing\u003e\u003e.\nClockSource::\n  The clock source among several spans that belong to a single E1/J1/T1\n  card.\nRED/YELLOW/RED/NOTOPEN/LOOP/RECOVERING::\n  The span is in alarm\n\nFollowing that line there may be some optional lines about IRQ misses,\ntiming slips and such, if there are any.\n\nThe channel line for each channel shows its channel number, name and the\nactual signalling assigned to it through dahdi_cfg. Before being configured by\ndahdi_cfg: This is DAHDI channel 2, whose name is 'XPP_FXS/0/0/1'.\n\n           2 XPP_FXS/0/0/1\n\nAfter being configured by dahdi_cfg: the signalling 'FXOLS' was added. FXS\nchannels have FXO signalling and vice versa:\n\n           2 XPP_FXS/0/0/1 FXOLS\n\nIf the channel is in use (typically opened by Asterisk) then you will\nsee an extra '(In use)':\n\n           2 XPP_FXS/0/0/1 FXOLS (In use)\n\n\nSysFS Interface\n~~~~~~~~~~~~~~~\nDAHDI exposes several interfaces under the SysFS virtual file system.\nSysFS represents kernel objects in nodes - directories. There properties\nare often files. They may also contain other nodes or include symlinks\nto other nodes.\n\nClass DAHDI\n^^^^^^^^^^^\nUnder /sys/class/dadhi there exists a node for the non-channel DAHDI\ndevice file under /dev/dahdi. The name is 'dahdi!foo' for the file\n'/dev/dahdi/foo' (udev translates exclamation marks to slashes). Those\nnodes are not, for the most part, proper SysFS nodes, and don't include\nany interesting properties. The files in this class `ctl`, `timer`,\n`channel`, `pseudo` and (if exists) `transcode`.\n\n\nDevices Bus\n^^^^^^^^^^^\nEach DAHDI device (a physical device, such as a PCI card) is represented\nby a node under /sys/bus/dahdi_devices/devices named with the name of\nits device.\n\nIts attributes include:\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/assgin-span\nWrite-only attribute: this device's spans should now be assigned\n(\"registered\"). See section about \u003c\u003c_span_assignments\u003e\u003e.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/auto-assign\nWrite-only attribute. Spans in the device auto-assign (\"register\" as in\nthe original interface). See section about \u003c\u003c_span_assignments\u003e\u003e.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/hardware_id\nA unique hardware-level identifier (e.g. serial number), if available.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/manufacturer\nThe name of the manufacturer. Freeform-string.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/registration_time\nThe time at which the device registered with the DAHDI core. Example\nvalue: \"0005634136.941901429\".\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/spantype\nA line for each available span: \u003cnum\u003e:\u003ctype\u003e. This has to be provided\nhere as in the case of manual assignment, userspace may need to know\nit before span nodes are created.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/spantype\nDevice type.\n\n===== /sys/bus/dahdi_devices/devices/DEVICE/unassign-span\nWrite-only attribute: the span whose device-local number is written\nshould now be unassigned (\"unregistered\"). See section about\n\u003c\u003c_span_assignments\u003e\u003e.\n\n\nSpans Bus\n^^^^^^^^^\nEach DAHDI span is represented by a node under\n/sys/bus/dahdi_spans/devices with the name 'span-N' (where N is the\nnumber of the span). Spans of each device also reside under the node of\nthe device.\n\nUseful attributes in the span node:\n\n===== /sys/bus/dahdi_spans/devices/span-N/alarms\nThe alarms of the span. Currently this is a numeric representation.\nThis may change in the future.\n\n===== /sys/bus/dahdi_spans/devices/span-N/basechan\nThe channel number of the first channel. The channel numbers of the\nfollowing channels are guaranteed to follow it.\n\n===== /sys/bus/dahdi_spans/devices/span-N/channels\nThe number of the channels in the span.\n\n===== /sys/bus/dahdi_spans/devices/span-N/desc\nA free-form description of the span.\n\n===== /sys/bus/dahdi_spans/devices/span-N/is_digital\n1 if the span is digital, 0 if it isn't.\n\n===== /sys/bus/dahdi_spans/devices/span-N/is_sync_master\n1 if the span is the sync master, 0 if it isn't.\n\n===== /sys/bus/dahdi_spans/devices/span-N/lbo\nLBO setting for the channel.\n\n===== /sys/bus/dahdi_spans/devices/span-N/lineconfig\nThe framing and coding of the span, for a digital span. Textual\nrepresenation:\n\n\u003cB8ZS|AMI|HDB3\u003e/\u003cD4|ESF|CCS\u003e[/CRC4]\n\n===== /sys/bus/dahdi_spans/devices/span-N/local_spanno\nThe number of the span within the DAHDI device.\n\n===== /sys/bus/dahdi_spans/devices/span-N/name\nA concise name for this span.\n\n===== /sys/bus/dahdi_spans/devices/span-N/spantype\nA very short type string.\n\n===== /sys/bus/dahdi_spans/devices/span-N/syncsrc\nCurrent sync source.\n\n==== sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span\nAll spans in the bus are handled by a single driver. The driver has one\nnon-standard attribute: master_span. printing it shows the current DAHDI\nmaster span writing a number to it forces setting this span as the master\nspan.\n\n\nChannels Bus\n^^^^^^^^^^^^\nEach DAHDI channel is represented by a node under\n/sys/bus/dahdi_channels/devices with the name 'dahdi!channels!N!M'\n(where N is the number of the span and M is the number of the channel\nin the span - chanpos). Channels of each span also reside under the node\nof the span.\n\nUseful attributes in the channel node (All attributed listed below are\nread-only):\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/alarms\nList of names of the current active alarms (space separated). Normally\n(no alarms) empty. Example:\n\n  RED YELLOW\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/blocksize\nThe block size set by userspace.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/channo\nThe (global) channel number.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/chanpos\nThe channel number within the span.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/dev\nMajor and minor device numbers.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_factory\nThe name of the echo canceller to be used in the channel, if one is\nconfigured. Example:\n\n  MG2\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_state\nState of the echo canceller. ACTIVE: configured and inuse. INACTIVE\notherwise.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/in_use\n1 if the channel is in use (was opepend by userspace), 0 otherwise.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/name\nA name string for the channel\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sig\nThe signalling types set for the channel. A space-separated list of\nsignalling types.\n\n===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sigcap\nThe signalling types this channel may be configured to handle. A space-\nseparated list of signalling types.\n\n\nUser-space Interface\n~~~~~~~~~~~~~~~~~~~~\nUser-space programs can only work with DAHDI channels. The basic\noperation is 'read()' to read audio from the device and write() to write\naudio to it. Audio can be encoded as either alaw (G.711a) or (m)ulaw\n(G.711u). See the ioctl DAHDI_SETLAW.\n\nWhile it is technically possible to use /dev/dahdi/NUMBER directly, this\nwill only work for channel numbers up to 249. Generally you should use:\n\n  int channo = CHAN_NUMBER_TO_OPEN;\n  int rc;\n  int fd = open(\"/dev/dahdi/channel\", O_RDRW, 0600);\n  // Make sure fd \u003e= 0\n  rc = ioctl(fd, DAHDI_SPECIFY, \u0026channo) \u003c 0);\n  // Make sure this rc \u003e= 0\n\nFIXME: there's more to tell about the user-space interface.\n\n\nConfiguration\n~~~~~~~~~~~~~\nMost of the configuration is applied from userspace using the tool\n'dahdi_cfg' in the package dahdi_tools. This section will not cover the\nspecifics of that file. Rather it will cover the way configuration from\nthis file is applied. Also note that there are other methods to\nconfigure DAHDI drivers: there are \u003c\u003c_module_parameters,Module\nParameters\u003e\u003e. The xpp driver have their own separate initialization\nscripts and xpp.conf that arecovered in README.Astribank.\n\nWhen a span is registered, it is considered \"unconfigured\". Only after\ndahdi_cfg has been run to apply configuration, the span is ready to run.\n\nSome of the configuration is handled by the DAHDI core. Some of it is\nhandled by callbacks, which are function pointers in the `struct\ndahdi_span': 'spanconfig', 'chanconfig' and (in a way) 'startup'.\n\nDahdi_cfg starts by reading the configuration from the configuration\nfile ('/etc/dahdi/system.conf', by default), and creating a local\nconfiguration to apply. If you use -v, at this stage it will pront the\nconfiguration that is \"about to be configured\". Then it will start to\nactually apply the configuration.\n\nBefore actually applying configuration, it destroys any existing\n\u003c\u003c_dynamic_spans,dynamic spans\u003e\u003e and generates new ones (if so\nconfigured. FIXME: what about running DAHDI_SPANCONFIG for new dynamic\nspans?).\n\nNext thing it will do is apply the parameters from *span* lines using\nthe ioctl DAHDI_SPANCONFIG. Some generic processing of parameters passed\nin DAHDI_SPANCONFIG is done in the DAHDI core, in the callback function\nspanconfig in , but most of it is left to 'spanconfig' callback of the\nspan (if it exists. This one typically does not exists on analog cards).\n\nNow dahdi_cfg will ask each existing channel for its existing\nconfiguration and apply configuration if configuration changes are\nneeded. Configuration is applied to the channels using the ioctl call\nDAHDI_CHANCONFIG ioctl. As in the case of the span configuration, part\nof it is applied by the DAHDI core, and then it is handed over to the\nspan's chanconfig callback. Typically all spans will have such a\ncallback.\n\n\u003c\u003c_echo_cancellers,Echo cancellers\u003e\u003e and \u003c\u003c_tone_zones,tone-zones\u003e\u003e are\nhandled separately later. \n\nOnce everything is done, the ioctl DAHDI_STARTUP is called for every\nspan. This is also translated to a call to the optional span callback\n'startup'.\n\nFinally the ioctl DAHDI_HDLC_RATE is called for every channel (that is:\nif '56k' is not set for the channel, it will be explicitly set to the\nstandard HDLC rate of 64k).\n\n\nLow-Level Drivers\n~~~~~~~~~~~~~~~~~\nLow-level drivers create spans ('struct dahdi_span'). They register the\nspans with the DAHDI core using 'dahdi_device_register()'.\n\n'struct dahdi_span' has a number of informative members that are updated\nsolely by the low-level driver:\n\nname::\n  A concise span name. E.g.: Foo/1\ndesc::\n  A slightly longer span name.\nspantype::\n  Span type in text form.\nmanufacturer::\n  Span's device manufacturer\ndevicetype::\n  Span's device type\nlocation::\n  span device's location in system\nirq::\n  IRQ for this span's hardware\nirqmisses::\n  Interrupt misses\ntimingslips::\n  Clock slips\n\nThere are various function pointers in the struct 'dahdi_span' which are\nused by the DAHDI core to call the low-level driver. Most of them are\noptional.\n\nThe following apply to a span:\n\nsetchunksize::\n  FIXME: seems to be unused.\n\nspanconfig::\n  Basic span configuration (called from dahdi_cfg).\n\t\nstartup::\n  Last minute initialization after the configuration was applied.\n\t\nshutdown::\n  Explicit shutdown (e.g. for dynamic spans). Normally not needed.\n\t\nmaint::\n  Enable/disable maintinance mode (FIXME: document).\n\nsync_tick::\n  Get notified that the master span has ticked.\n\nThe following apply to a single channel.\n\nchanconfig::\n  Configure the channel (called from dahdi_cfg).\n\nopen::\n  Channel was opened for read/write from user-space.\n\nclose::\n  Channel was closed by user-space.\n\nioctl::\n  Handle extra ioctls. Should return -ENOTTY if ioctl is not known to\n  the channel\n\nechocan_create::\n  Create a custom echo canceller. Normally used for providing a hardware\n  echo canceller. If NULL, the standard DAHDI echo canceller modules\n  will be used.\n\nrbsbits::\n  Copy signalling bits to device. See below on signalling.\n\nhooksig::\n  Implement RBS-like signalling-handling. See below on signalling.\n\nsethook::\n  Handle signalling yourself. See below on signalling.\n\nhdlc_hard_xmit::\n  Used to tell an onboard HDLC controller that there is data ready to\n  transmit.\n\naudio_notify::\n  (if DAHDI_AUDIO_NOTIFY is set) - be notified when the channel is (or\n  isn't) in audio mode. Which may mean (for an ISDN B-channel) that its\n  data need not be sent.\n\nThere are several alternative methods for a span to use for\nsignalling. One of them should be used.\n\nSignalling: rbsbits\n^^^^^^^^^^^^^^^^^^^\nIf the device is a CAS interface, the driver should copy the signalling\nbits to and from the other side, and DAHDI will handle the signalling.\nThe driver just need to provide a 'rbsbits' and set DAHDI_FLAG_RBS in\nthe span-\u003eflags.\n\nNote that 'rbs' (Robed Bits Signalling) here merely refers to the (up\nto) 4 signalling bits of the channel. In T1 they are transmitted by\n\"robbing\" bits from the channels and hence the name. In E1 they are\ntransmitted in a timeframe of their own.\n\nThe driver should then signal a change in the signalling bits in a\nchannel using dahdi_rbsbits().\n\n\nSignalling: hooksig\n^^^^^^^^^^^^^^^^^^^\nIf the device does not know about signalling bits, but has their\nequivalents (i.e. can disconnect battery, detect off hook, generate\nring, etc directly) then the driver can specify a 'sethook' function and\nset DAHDI_FLAG_RBS in span-\u003eflags. In that case DAHDI will call that\nfunction whenever the signalling state changes.\n\nThe hooksig function is only used if the rbsbits function is not set.\n\nThe span should notify DAHDI of a change of signalling in a channel using\ndahdi_hooksig().\n\n\nSignalling: sethook\n^^^^^^^^^^^^^^^^^^^\nAlternatively, if DAHDI_FLAG_RBS is not set in the flags of the span (to\nuse either rbsbits or hooksig), the DAHDI core will try to call the\n'sethook' function of the span (if it exists) to handle individual hook\nstates.\n\nThe span should then notify DAHDI of a change in the signalling state\nusing dahdi_sethook().\n\nFIXME: anybody using this one?\n\n\nABI Compatibility\n~~~~~~~~~~~~~~~~~\nLike any other kernel code, DAHDI strives to maintain a stable interface to\nuserspace programs. The API of DAHDI to userspace programs, dahdi/user.h, has\nremained backward-compatible for a long time and is expected to remain so in\nthe future. With the ABI (the bits themselves) things are slightly trickier.\n\nDAHDI's interface to userspace is mostly ioctl(3) calls. Ioctl calls\nare identified by a number that stems from various things, one of which\nis the size of the data structure passed between the kernel and\nuserspace. \n\nMany of the DAHDI ioctl-s use some specific structs to pass information\nbetween kernel and userspace. In some cases the need arose to pass a few\nmore data members in each call. Simply adding a new member to the struct\nwould have meant a new number for the ioctl, as its number depends on\nthe size of the data passed.\n\nThus we would add a new ioctl with the same base number and with the\noriginal struct.\n\nSo suppose we had the following ioctl:\n----------------------------------\nstruct dahdi_example {\n\tint sample;\n}\n\n#define DAHDI_EXAMPLE     _IOWR (DAHDI_CODE, 62, struct dahdi_example)\n----------------------------------\n\nAnd we want to add the field 'int onemore', we won't just add it to the\nstruct. We will do something that is more complex:\n------------------------------------\n/* The original, unchanged: */\nstruct dahdi_example_v1 {\n\tint sample;\n}\n\n/* The new struct: */\nstruct dahdi_example {\n\tint sample;\n\tint onemore;\n}\n\n#define DAHDI_EXAMPLE_V1  _IOWR(DAHDI_CODE, 62, struct dahdi_example_v1)\n#define DAHDI_EXAMPLE     _IOWR(DAHDI_CODE, 62, struct dahdi_example)\n------------------------------------\nWe actually have here two different ioctls: the old DAHDI_EXAMPLE would be\n0xC004DA3E . DAHDI_EXAMPLE_V1 would have the same value. But the new value\nof DAHDI_EXAMPLE would be 0xC008DA3E .\n\nPrograms built with the original dahdi/user.h (before the change) use the\noriginal ioctl, whether or not the kernel code is actually of the newer\nversion. Thus in most cases there are no compatibility issues.\n\nWhen can we have compatibility issues? If we have code built with the new\ndahdi/user.h, but the loaded kernel code (modules) are of the older version.\nThus the userspace program will try to use the newer DAHDI_EXAMPLE (0xC008DA3E).\nBut the kernel code has no handler for that ioctl. The result: the error 25,\nENOTTY, which means \"Inappropriate ioctl for device\".\n\nAs a by-product of that method, for each interface change a new #define is\nadded. That definition is for the old version and thus it might appear\nslightly confusing in the code, but it is useful for writing code that works\nwith all versions of DAHDI. \n\nPast Incompatibilities\n^^^^^^^^^^^^^^^^^^^^^^\n.DAHDI 2.3:\nDAHDI_SPANINFO_V1 (extra members added). This will typically only be\nused on ISDN (PRI/BRI) spans in Asterisk.\n\n.DAHDI 2.2:\n* DAHDI_GET_PARAMS_V1, DAHDI_GETCONF_V1, DAHDI_SETCONF_V1,\n  DAHDI_GETGAINS_V1 ('direction' changed from 'R' to 'RW' to fix\n  FreeBSD support).\n* DAHDI_CONFDIAG_V1, DAHDI_CHANDIAG_V1 (fixed direction).\n\n\nAlarm Types\n~~~~~~~~~~~\nAn alarm indicates that a port is not available for some reason. Thus it\nis probably not a good idea to try to call out through it.\n\n\nRed Alarm\n^^^^^^^^^\nYour T1/E1 port will go into red alarm when it cannot maintain\nsynchronization with the remote switch.  A red alarm typically\nindicates either a physical wiring problem, loss of connectivity, or a\nframing and/or line-coding mismatch with the remote switch.  When your\nT1/E1 port loses sync, it will transmit a yellow alarm to the remote\nswitch to indicate that it's having a problem receiving signal from\nthe remote switch.\n\nThe easy way to remember this is that the R in red stands for \"right\nhere\" and \"receive\"... indicating that we're having a problem right\nhere receiving the signal from the remote switch.\n\n\nYellow Alarm \n^^^^^^^^^^^^\n(RAI -- Remote Alarm Indication)\n\nYour T1/E1 port will go into yellow alarm when it receives a signal\nfrom the remote switch that the port on that remote switch is in red\nalarm. This essentially means that the remote switch is not able to\nmaintain sync with you, or is not receiving your transmission.\n\nThe easy way to remember this is that the Y in yellow stands for\n\"yonder\"... indicating that the remote switch (over yonder) isn't able\nto see what you're sending.\n\n\nBlue Alarm\n^^^^^^^^^^\n(AIS -- Alarm Indication Signal)\n\nYour T1/E1 port will go into blue alarm when it receives all unframed\n1s on all timeslots from the remote switch.  This is a special signal\nto indicate that the remote switch is having problems with its\nupstream connection.  dahdi_tool and Asterisk don't correctly indicate\na blue alarm at this time.  The easy way to remember this is that\nstreams are blue, so a blue alarm indicates a problem upstream from\nthe switch you're connected to.\n\n\nRecovering from Alarm\n^^^^^^^^^^^^^^^^^^^^^\nTODO: explain.\n\n\nLoopback\n^^^^^^^^\nNot really an alarm. Indicates that a span is not available, as the port \nis in either a local or remote loopback mode.\n\n\nNot Open\n^^^^^^^^\nSomething is not connected. Used by e.g. the drivers of the Astribank to\nindicate a span that belongs to a device that has been disconnected \nbut is still being used by userspace programs and thus can't e\ndestroyed.\n\n\nLicense\n-------\nThis package is distributed under the terms of the GNU General Public License\nVersion 2, except for some components which are distributed under the terms of\nthe GNU Lesser General Public License Version 2.1. Both licenses are included\nin this directory, and each file is clearly marked as to which license applies.\n\nIf you wish to use the DAHDI drivers in an application for which the license\nterms are not appropriate (e.g. a proprietary embedded system), licenses under\nmore flexible terms can be readily obtained through Digium, Inc. at reasonable\ncost.\n\nKnown Issues\n------------\n\nKB1 does not function when echocancel \u003e 128\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nKB1 was not designed to function at greater than 128 taps, and if configured\nthis way, will result in the destruction of audio.  Ideally DAHDI would return\nan error when a KB1 echocanceller is configured with greater than 128 taps.\n\n\nReporting Bugs\n--------------\nPlease report bug and patches to the Asterisk bug tracker at\nhttp://issues.asterisk.org in the \"DAHDI-linux\" category.\n\nLinks\n-----\n- http://asterisk.org/[] - The Asterisk PBX\n- http://docs.tzafrir.org.il/dahdi-linux/README.html[Up-to-date HTML version\n  of this file]\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fasterisk%2Fdahdi-linux","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fasterisk%2Fdahdi-linux","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fasterisk%2Fdahdi-linux/lists"}