Where is Step-by-Step DAHDI Installation for 2.6.x

Unfortunately the procedure is not as cut and dry as you would like it to be.

When done you will no longer be able to update Asterisk from yum, I don't think this is a concern to you.

The procedure is essentially -

1. - Install Build Environment on target machine (kernel headers, gcc, bison etc)
2. - Download Asterisk, Asteerisk Add-ons and DAHDI complete from Digium
3. - Untar source in build directories
4. - Configure software
5. - Compile software (make)
6. - Install software
7. - Set FreePBX for DAHDI compat mode (might as well update to FreePBX 2.6 at the same time)

I know it seems as if we are holding back information however it is not a 1-2-3 process.

I have sent you a Private Message with another suggestion.

umm no it will however work with zaptel, infact the drivers are probably already there... try running setup-pstn see what happens

Honestly sounds like a configuration problem, setup-pstn (dahdi_gencong/genzaptelconfig) sets up a generic E! which enables CRC4. If your line does not have CRC4 it will be red. The configs generated are set as most common for the guy who wrote the script. We modified the script to write the files in a fashion that is most common for us. That said we install thousands of boxes so if your quantity is not that high no need to rewrite any code simply tune the generated configurations.

On Zaptel:
/etc/zaptel.conf
/etc/asterisk/zapata-auto.conf OR /etc/asterisk/zapata-channels.conf
Make sure at the bottom of your /etc/asterisk/zapata.conf you have #include zapata-auto.conf OR #include zapata-channels.conf

On DAHDI:
/etc/dahdi/system.conf
/etc/asterisk/dahdi-channels.conf
Make sure at the bottom of your /etc/asterisk/chan_dahdi.conf you have #include dahdi-channels.conf

NOTE: # in #include is NOT a comment it makes the keyword `include' a directive, DO NOT REMOVE THE #

Well, some progress here. I had a fault in the cable module at one end, so I had no reversal. I've replaced the module and the red light on the T122 card was instantly replaced with a yellow light, which cheered me up no end. I've now played with the /etc/dahdi/system.conf and altered the span settings and the Dahdi_tool is now saying this...

I need to get a hang of the config files now, but at least the physical is working. I have no Zapata config files apart from zapata_additional and zapata.template so I'm assuming zapata is now actually Dahdi and it's just the dahdi files I need to alter, right? I'll go see what tutorials I can find on them.

for the record, my files read thus. If you see a glaring problem please let me know. I'm off to try and educate myself some more.

CHAN_DAHDI.CONF
[trunkgroups]
switchtype=euroisdn
signalling=pri_cpe
context=incoming
echocancel=yes
channel=>1-15,17-31

[channels]
language=en
group=0
context=incoming
signalling=fxs_ks
rxwink=300

DAHDI_CHANNELS.CONF
; Span 1: WCT1/0 "Wildcard TE122 Card 0" (MASTER) HDB3/CCS/CRC4 REDClockSource
group=0,11
context=incoming
switchtype = euroisdn
signalling = pri_cpe
channel => 1-15,17-31

SYSTEM.CONF
span=1,0,0,ccs,hdb3,crc4
# termtype: te
bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31

loadzone =uk
defaultzone =uk

Sorry Scott, I cant answer the timing question as I have not yet received info on the Siemens configuration. We have to raise a case and request the info from Siemens support, which is chronic. Also you never said which particular config file I had the context wrong in. I have played around with the span settings trying to get a hit (now at span=1,1,0,ccs,hdb3,crc4), and I now have the dahdi_tool saying the following...

I assume the IRQ thing is a hardware issue, which shouldn't impact performace directly. I have no errors otherwise, but I have yet to see an active channel and I have no clue what the lines from the Tx/Rx areas actually represent. If I run dahdi show channels I get all the channels in service with context as 'from-internal'. I assume that once I get the trunk and routing set up correctly I'll see channels marked as active, but until then it will remain zero?

What is vexing me is how to actually set up the trunk in Trixbox. I have only ever set up SIP trunks with it before, not a Zaptel/DAHDI one, so I'm not too sure if I'm on the right track. The identifier defaults to g0 in the GUI, and says that the group or channel name is defined in zapata.conf, which I understand is actually now /etc/dahdi/system.conf. I have no group or channel identifier in there, should it be?

Just a note, interrupts flow at a rate of 1000/second so 43 is bad but relatively non existant, These misses could have been something wrong with the bus durring initialization but if the number is not climbing I would ignore it.

I'm no expert but, do see something that causes me to have an opinion. It still sounds like a timing or signaling issue. I see in the configs that you posted that your signaling is set to signalling = pri_cpe making it an FXO port which is the correct setting when you are receiving the trunk from the phone company. It is also very likely the setting on the HiCom's interface. They can't both be FXO ports so try switching the Te122B to FXS.

Try changing the signaling type in chan_dahdi.conf and dahdi_channels.conf to signalling=pri_net and see if you can achieve sync.

That's my 2 cents. Now, I'm out of money.

Edit: Changed typo from fxs_ks to pri_net as per manual

Confused is a common state for me but, he already has his config set to pri_cpe and it doesn't work. He's also got it configured to send timing span=1,0,0,ccs,hdb3,crc4 which would be appropriate for pri_net.

Try pri_net and then tell me I'm wrong.

I have tried pri_net and pri_cpe, I have tried setting the timing in the span to 0 and 1, and I'm still not getting there. I'll spend today going through all the permutations that I can think of and see if any of them make a difference to the link. I'll let you know what happens.

note a t1 crossover is NOT the same as an Ethernet crossover, That said if he had the wrong cable, or timing then he would be in alarm.

For giggles go in to the Asterisk CLI and type `pri intense debug span 1`

post the output

I fixed the cable issue already, I was using a crossover adaptor but it had gone faulty so I had to chop it and put on a new plug. No physical alarms now. The other end is a Siemens switch which is under a support contract, meaning Siemens have the passwords and wont give me them to check what the other end is doing. I have to raise a case with Siemens which will cost us a minimum of £180 for the first hour and £90 for every hour afterwards, and I have to get clearance from my boss to spend that cash first. I will start the process if I get no luck today.

I've done an intensive debug already, output is a regular as clockwork SABME packet being sent out towards the Siemens PBX. It reads the same every time...

Unnumbered Frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
M3: 3 P/F: 1 M2: 3 1: 3 [ SABME (set asynchronous balanced mode extended) ]

Agreed, it's reaching out and getting nothing. I can loop the link up with the Dahdi_tool and Asterisk will try and ring out, but it just rings and rings and rings and... Nothing from the other side, and dialing in to Asterisk gets me an engaged tone. Dahdi tool shows no alarms, everything ready to go, and I'm sick of trying different combinations of pri-cpe, pri_net, qsig, euroisdn, etc in the chan_dahdi and dahdi_channel configs. Time to go raise a case with Siemens to get them to check their end out.

Hi,

How do we do the last part?

"Set FreePBX for DAHDI compat mode (might as well update to FreePBX 2.6 at the same time) "

I as trying to install dahdi in 2.6.2.1.

I managed to install dahdi successfully but asterisk wouldn't load dahdi commands..

So my next steps should be to download/configure/install asterisk sources and set freepbx for dahdi compat mode roght?

I know to to deal with asterisk installation but not how to do the last part.

Thanks in advance.
Bruno Henriques