We've got a dedicated T1 with two trunks running into our ILECs selective router for 911. Split out of the T1 into two MF CAMA trunks on ILEC side.
I'm trying to use asterisks e911 signaling, but I'm having trouble with the dial command. (== Everyone is busy/congested at this time (1:1/0/0))
I'm missing something and I'm thinking it has to do with the hookstate of the dahdi channel.
If anyone has a similar situation and want to provide some guidance, I'd sure appreciate it.
Here's my config:
DAHDI version 184.108.40.206
[root@e911 dahdi]# dahdi_hardware
pci:0000:02:01.0 wct1xxp+ e159:0001…
What is dahdi.auto_assign_spans and why should you care?
In later versions the kernel module dahdi[Q] includes a new parameter: auto_assign_spans. It defaults to 1, and if you set it to 0, DAHDI can start behaving in strange and completely expected ways. Chances are the default will be set to 1 in a future version. Here is why you'll want to set it yourself.
Up until DAHDI 2.5, hardware drivers for DAHDI presented DAHDI with spans[W]. The device would initialize the hardware, identify the spans in it, and register them with the dahdi core. The dahdi core assigns each span the first…
The Asterisk Development Team has announced the releases of:
This release is available for immediate download at: http://downloads.asterisk.org/pub/telephony/dahdi-linux http://downloads.asterisk.org/pub/telephony/dahdi-tools http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete
*** THIS RC FIXES CentOS 6.5 "PDE_DATA" build issue ***
In version 2.8 we have introduced two new drivers: wcte43x - For Digium's new line of 2/4 span T1/E1 cards wcaxx - For Digium's new line of analog fxs/fxo cards
We introduced a common library called "wcxb" which ties the previous two drivers, plus the recently introduced wcte13xp driver, together into one common base.
dahdi-linux-complete tarballs now include all firmware necessary to build without an internet connection.
Issues closed in this release: https://issues.asterisk.org/jira/browse/DAHLIN-331
I've got a Digium Wildcard TDM410P with one POTS line and three extensions. One of the extensions is connected to a fax modem. This kind of works, but there's a gotcha. If I set faxdetect=incoming in chan_dahdi.conf, then incoming faxes do get routed to the modem and this all works, but outbound faxes fail, with a message like this:
[Oct 29 21:57:09] WARNING[C-00000000] app_dial.c: Unable to create channel of type 'DAHDI' (cause 17 - User busy)
If I set faxdetect=no, then outbound faxes work, but of course incoming faxes do not get routed to the modem. I'm guessing that what is happening…
With setvar statements in chan_dahdi.conf, we have a convenient way to store DAHDI channels specific values.
Unfortunately, we don't have a function to access this data from the dialplan as easily as SIPPEER ou IAXPEER would for SIP or IAX trunks.
Using AST_CONFIG, you can access DAHDI setvar value but: 1. only one setvar value (see bellow) 2. AST_CONFIG reads values from current config file not previously loaded file (this is obviously what you would expect from this function).
What do you think of this ? Would you qualify this as useful ?
PS: In chan_dahdi.conf, I add this:
I wanted to switch from using Dialogic/Eicon cards to using Digium's T-1 cards. When I purchased a sample card the salesperson assured me there was documentation specific to the DAHDI interface. Now that I'm digging in, I'm finding it's documented a lot like Linux -- one must read the fairly uncommented source code.
I don't have a problem with this generally, but here I just don't understand the divisions of labor between Asterisk, DAHDI Hardware, DAHDI kernel modules and Userland (me). (BTW, I do not wish to use Asterisk as we have numerous projects based on Dialogic/Eicon spanning some 20 years.…