So after strugling a LOT to make some ISDN equipment work, I figured I better write some of it down.
Update 2010/07/13: added section regarding the kernel modules, added note re one direction call abilities for BRI.
Update 2011/03/29: added cadence setting to chan_dahdi.conf for callerid purposes.
Update 2011/11/22: overlapdial causes problems for certain Telkom cpe_bri_ptmp links, update documentation as such.
Update 2016/08/17: fix timing + make note about CRC4 related noise problems.
Firstly, just the fact that you get OK from your Digium (Cologne/Duxbury HFC-S cards doesn’t report alarms at the moment …) cards doesn’t mean all is well in signaling land. It does, usually, mean that your cabling is OK. However, it should be noted that the opposite does not seem to be true – a RED or even YEL alarm doesn’t mean that you’ve got cabling problems, this does seem to potentially be related to signaling.
There are probably a few things that should be made clear, signaling is how things on the wire is interpreted. I don’t have all the answers with this but am learning quite a lot about it at the moment. Voice is a HUGE field and I don’t know any single person that knows everything, so please bear with me in this too, here is what I think I know.
Zones
The zones basically determines the tone zones (what busy, not available and all that stuff needs to sound like). For ZA you can just use the following in /etc/dahdi/system.conf:
loadzone=za
defaultzone=za
You shouldn’t need anything in chan_dahdi.conf, but I like to explicitly set the progzone to ZA (also enable callprogress – doesn’t always work for everybody, only applies to FXS ports) and tonezone to -1 like so:
callprogress=yes
progzone=za
tonezone=-1 ; use whatever is in /etc/dahdi/system.conf
cadence=400,2000,400,200
Note that even with the zone correctly set in indications.conf you still need to put the cadence line in chan_dahdi.conf. The cadences in indications.conf are for other purposes, I don’t know exactly what. Even without the cadence above you still get inbound calls no problem, however, I’ve had trouble with caller line identity working as expected. Adding the explicit cadence in chan_dahdi.conf resolved this problem for me.
From the looks of it indications.conf are used primarily for locally generated indications whereas the cadence in chan_dahdi.conf is used for cycling the ringing sequence etc, and importantly in this case, synching up the FSK caller id spill (if you’re seeing errors re the spill not completing then most likely you need to mess with this setting).
Modules to load
I only just discovered the easy way on figuring out the appropriate modules to load. I recommend just running dahdi_hardware, it’ll spit out lines like this:
pci:0000:00:0b.0 wctdm24xxp- d161:2400 Wildcard TDM2400P
The second column indicates the modules to load. Depending on the distro you’re using you can either update the dahdi startup script configuration, or add it to the distro’s list of modules to load (/etc/modules.autoload.d/kernel-2.6 on gentoo with a 2.6 kernel). Newer startup scripts seems to have learned how to properly auto-load (probably using the script mentioned here).
The – in the above line indicates that the module isn’t loaded at the moment, this would change to a + if the module is already loaded.
The first column indicates the logical location in the system bus, third column the vendor/product id pair, and then of course the card description.
FreePBX seems to generate an illegal /etc/modprobe.d/dahdi.conf, so herewith the file I use for dahdi.conf in that location (issue chattr +i /etc/modprobe.d/dahdi.conf after replacing so that FreePBX will be forced to leave it alone):
options wctdm24xxp opermode=SOUTHAFRICA boostringer=1 fastringer=1 latency=7
options wct4xxp t1e1override=0xFF
options wcte12xp t1e1override=0xFF
Note that these are the modules I’ve had to pass parameters for, wcb4xxp so far provided no problems, the TE2xx cards works with the wct4xxp module and the TE1xx cards with the wcte12xp module. There are hordes of others and I’ll happily update the above with additional info as I locate it or people provide to me (and I can confirm).
Analog Lines (Ports)
Analog ports comes in two flavors, FXS and FXO. An FXO port attaches to an FXS port, the differentiating factor is which one provides the Signaling. In particular, FXS provides a 48V “battery” and is the one that provides the signaling for the FXO port to use. This signaling comes in three flavors which are all minor variations of the others. ground-start, loop-start and kewl-start. I’m not a technical expert and thus can’t explain all the exact details, but from what I understand the FXO device (usually a handset) keeps the two wires in a Z state (disconnected) and then either grounds or shorts the two wires when the handset is picked up, kewl-start has some additional stuff which I don’t understand. There are explanations so just google. From what I gather ground-start isn’t used often any more and kewl-start is a superset of loop-start (ie, kewl-start is loop-start, but not the other way round). In South Africa we use kewl-start, and so does (from what I can gather) most of the rest of the world. It’s suggested to try kewl-start signaling and to only fall back to loop-start should that fail.
The configuration for an FXO port is simple and in my experience the most common case. Specifying an explicit signaling is in my experience not required, but probably safer anyway. I usually use users.conf to specify most of my dahdi blocks simply because I find the syntax and blocking features useful, most of this should work “as is” in chan_dahdi.conf too.
[line](!)
context=incoming
callgroup=1
pickupgroup=1
[groupname](line)(!)
group=1
[fxoports](groupname)
rxgain=??
txgain=??
signalling=fxs_ks
dahdichan=1,3-5
Note that for an FXO port you set the signaling to fxs_ks. In /etc/dahdi/system.conf you need this (note that I use oslec echo cancellation, you will either use hardware or probably mg2):
fxsks=1,3-5
echocanceller=oslec,1,3-5
The next thing is that when you bridge two FXS ports you’re stuck with two “dead” ports unless you can “time out” the call, or set up working busydetect. For busydetect to work you need two things, firstly, in indications.conf:
[general]
country=za
And make sure that you’ve got a [za] section. Note that Telkom blessed us with two types of switches. Also note that I have run into Alcatel switches even in Gauteng. So switch as per experimental testing (phone out, answer and hang up the called side, you should hear the telkom “busy” tone for two cycles before asterisk hangs up on you). In chan_dahdi.conf you need:
busydetect=yes
busycount=2
busypattern=500,500
This may also require some adjustment, I had one client so far where I could not make this work under any circumstances. Ideally we would have been able to use polarity switching, however, just about every analog PABX “expert” I’ve spoken to got the “huh?!? wtf?!?” expression on their faces when I asked them about polarity switching. Needless to say, to prevent asterisk from being funny about this, add this in chan_dahdi.conf:
; Telkom SUCKS!
answeronpolarityswitch=no
hanguponpolarityswitch=no
And lastly, callerid for analog (in chan_dahdi.conf):
usecallerid=yes
callerid=asreceived
cidsignalling=v23
cidstart=ring
useincomingcalleridondahditransfer=yes
ISDN
ISDN is a digital version of analog, and can also provide other services such as video calls etc… and some other fancy stuff. Please note that there is HORDES of conflicting information out on the internet regarding ISDN and some of it works, and some of it doesn’t. There is also information that seems to apply to both BRI and PRI (even in the Digium KB) which does NOT. Mostly when Digium talks about ISDN they mean PRI. As an example, their KB entry 17 makes it look like both BRI and PRI has RX and TX pins in the same location: THIS IS NOT TRUE. So this info here is based on stuff that worked for me. Your mileage may vary, but please do advise should you have additional information, or even evidence that conflicts with the information here – I’ll happily adjust and “fix” this entry with whatever info I can confirm to be accurate.
Firstly, a note regarding cabling. ISDN cables are NOT the same as ethernet cables. Some information seems to dictate that the “pairs” are 1/2, 3/4, 5/6, 7/8, this however doesn’t seem to make sense as far as I’m concerned. Additionally please note that ISDN BRI cables (at least) are “flat” and is definitely not the standard CAT-5 twisted pair (however, I do believe that CAT-5 or similar cable is in fact in use for PRI).
ISDN – BRI
I’m unable to locate the pinouts on the digium cards. The only thing I have managed to confirm (by visual inspection of the PC board) is that pins 3 thru 6 are in fact in use on the Telkom ISDN2a NTUs. According to a Telkom technician the pins should be 1/2, 3/6. Goes to show you how inaccurate the information is, even within the company that installs the equipment. An installer of Samsung PABX systems pointed this out. Chainsaw on IRC pointed out the “flat” vs “twisted” pair cabling. Either way. The rule seems to be “use a standard 8-wire “straight” cable, and if that doesn’t work, try a “flat cross”. A “flat cross” is a term I came up with to differentiate it from a standard “cross over” cable (ethernet cross) where 1/2 -> 3/6 and 3/6 -> 1/2 (ie, green and orange pair is swapped around on the one end). A “flat cross” just turns the entire thing around, so assuming you’ve crimped the one end with the “B” standard (orange/, orange, green/, blue, blue/, green, brown/, brown) then the other end all cables remains in the same relative order, but reversed, so you end up with brown, brown/, green, blue/, blue, green/, orange, orange/. Failing that … well, good luck.
These ports again comes in two flavors. NT (NeTwork) and TE (Terminal Equipment). I’ve only worked with TE ports so far, but there is a simple switch on the Digium hardware at least that switches ports between NT and TE. It seems that we need ccs framing and ami coding for BRI. The Digium cards provides more options, the HFC cards does not (more on HFC later on). in /etc/dahdi/system.conf this looks like:
# Span 16: B4/2/4 "B4XXP (PCI) Card 2 Span 4" AMI/CCS
span=16,4,0,ccs,ami
# termtype: te
bchan=158-159
hardhdlc=160
# echocanceller=oslec,158-159
This comes from a box with 4 quads in it, one of which is PRI, the last card, port 4, thus span 16, timing source preference is 4 and 0 lbo (line build out, cable is less than 133 feet, ~40m). The hardhdlc specifies the dchan (not sure why it’s not simply called dchan or whether dchan is PRI specific). I’ve disabled the echocan in this case entirely as all this box does is switch between different ISDN ports.
It should be noted that the timing source needs to be a value between 1 and 4! At a point the auto-generation code set this equal to span number, which is wrong. Every card does it’s own selection. Only CPE ports are eligible for this and NET ports (where we provide timing to the remote side) should have this value set to 0. If you’re using Gentoo, the dahdi-autoconf script I’ve included into the dahdi-tools package does the right thing here. You can get this script from the gentoo portage git repo browser: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/dahdi-tools/files – I periodically provide the package maintainer with an updated script if/when bugs are fixed here. You’ll presumably have to adapt that to your distribution.
From here these ports can be configured either in chan_dahdi.conf, or in users.conf. I use a split setup where I try to keep as much as possible of all the “common” stuff in chan_dahdi.conf:
; Overlap dialing provides a way for the CPE equipment to reserve a line - mostly you don't want this
; Only enable it for PRI or BRI channels connecting to downstream PABX units, if they have trouble dialing and you
; see short dial attempts like "082" in the logs (these PABX units will wait for some digits, then when a prefix is completed
; dial that prefix onto the destination trunk with overlap dial enabled so that it can send us one by one digit as the user types).
overlapdial = no
; ISDN switch types
; (it seems unknown just works best overall, with euroisdn):
pridialplan=unknown
prilocaldialplan=unknown
switchtype=euroisdn
internationalprefix=00
nationalprefix=0
Again, don’t ever ask traditional PABX folks (at least, not in ZA) about type of number (TON) and switchtype related stuff. The rule of thumb is that they won’t know what you’re going on about (Heck, I had the privilege of dealing with some of the guys doing peerings for some of the bigger players in the country and even some of them raise a few eyebrows).
In users.conf I then add something similar to this:
[dahdi-TE-158](groupname)
signalling=bri_cpe_ptmp
rxgain=0.0
txgain=0.0
dahdichan=158-159
This will set us up to use bri signalling in cpe mode with point-to-multi-point (cpe is basically the client side, the other option to be used with NT ports is bri_net_ptmp). In both cases you can drop the _pmtp to get simple point-to-point connectivity. The above seems to be working for me so far.
If you run into a situation where you can make outbound calls but not inbound chances are you need to flip from non-ptmp to ptmp, or vice versa. Also note that Telkom advertizes a NT2 as ISDN2a and an NT1 as ISDN2 … so when following other guides you know whether to follow directions for NT2 or NT1, so far all the ones I’ve run into required _ptmp.
ISDN – PRI
Firstly, the pinout on Digium hardware is as per http://kb.digium.com/entry/17/ as follows (on your RJ45):
1 - RX-
2 - RX+
3 - NC
4 - TX-
5 - TX+
6 - NC
7 - NC
8 - NC
Never had problems with using a “straight” cable here, and so far it “just worked” for me. You may need an “ISDN Cross” as per the KB article. In that case I like just pulling two pairs out of the sheathing so that I end up only wiring the two pairs that’s actually in use.
ISDN PRI is a different beast. It comes in E1 and T1. In ZA we use E1 (30 channels). So firstly, make sure the on-card jumper is set correctly. gen_dahdi_conf should generate E1 configs, not T1. We can operate in one of two modes again, NT or TE, however, this time it seems to be more subtle, and which end you are can be manipulated from dahdi/system.conf. For an NT port:
# Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" HDB3/CCS/CRC4 RED
span=3,0,0,ccs,hdb3,crc4
# termtype: nt
bchan=63-77,79-93
dchan=78
# echocanceller=oslec,63-77,79-93
Note that again I’ve switched off echocan. This is port 3 on my quad PRI, again we’re using ccs framing, but this time we’re using hdb3 coding, with crc4 error checking. Some premi-cell units doesn’t like crc4, in this case just remove the ,crc4. Not sure how to pick this up but trial and error seems to work quite well. You will NOT get link if these options aren’t set correctly. Not that dchan – bchan (first number anyway) is always 15, this is because channel 16 on the PRI (E1) is the d channel.
An example of TE port as follows:
# Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" HDB3/CCS/CRC4 RED
span=1,1,0,ccs,hdb3,crc4
# termtype: te
bchan=1-15,17-31
dchan=16
# echocanceller=oslec,1-15,17-31
Note that here we specify span 1, preferred timing source, lbo of 0 again (compare with previous block where preferred timing source was 0 to indicate that we need to provide timing to remote end). Framing and coding remains the same. bchan and dchan remains identical (obviously channel shifted to a different physical port). So the only real difference at the “lower” layer is from which side the timing comes. I suspect there is more going on regarding this on BRI, thus why the physical switches …
Note that the above uses CRC4 for checksumming data and error detection/correction (I’m not actually sure exactly what’s involved here). We’ve encountered at least two case now where with this option enabled we got major bad voice quality, presumably due to the remote end and the local end disagreeing about whether or not CRC4 should be used and/or how. Either way, if you get weird clicky noises try switching CRC4 off and see if that makes a difference (you’ll need to reconfigure the port, so stop asterisk + restart dahdi before starting asterisk again).
In chan_dahdi.conf you don’t need anything extra beyond what was already described for BRI channels, and your users.conf is very similar as well:
[dahdi-E1-1](groupname)
signalling=pri_cpe
rxgain=0.0
txgain=0.0
dahdichan=1-15,17-31
Note that cpe typically goes with TE mode, for running an NT port, just change pri_cpe to pri_net. And that is hopefully sufficient information to keep all things happy in ISDN land.
Many thanks for sharing, this information would have been tremendously helpfull when we first starting playing with Asterisk! You make mention of having connected a premicell to one of the quad PRI ports, could you possibly tell us where you tracked down a digital premicell bank style device which, I assume, provides signaling with regards to ringing, no answer, answered, etc?
The units in question was already on-site. I merely had to link up to them – which was partially what sparked this entry – I seriously prefer just using a VoIP uplink. And yes, they provide proper signaling information. Haven’t checked whether they provide early media in terms of ringing but whether they do or don’t doesn’t really matter. Please also keep in mind that ISDN doesn’t explicitly say “no answer”, “answered” etc … it basically has a few signal stages, similar to SIP, so it’ll acknowledge the request (100 Trying), it’ll then figure out how to pass it on (103 Trying – not 100 % sure about the code here), then hopefully we will get “ringing” (180 Ringing) and an “answered” (200 OK), and eventually the call will get terminated (from both sides) using some cause code. These ISDN Cause codes are another pain in the backside when you start investigating these things, but once you grok them they are actually very useful. It’s these hangup causes, in combination with the state that the channel was in that will determine your DIALSTATUS when returning from Dial(). This part is dealt with properly by asterisk so unless you’re doing really funky (cool) stuff, you shouldn’t need to worry about this.
I noted later on that there is another issue, not addressed here and which is actually a bug in dahdi_genconf, the timing source is local to a specific card, in other words, 0 thru 4 where 0 means we’re responsible for providing timing on the port (span) in question, 1 is highest priority and 4 is lowest. dahdi will use the first available card’s timing source for providing timing to asterisk. This isn’t critical information to know, but can possibly safe you another few headaches.
Hi do you have a site where i can download the Asterisk user manual ?
Asterisk itself doesn’t have a user manual. You can google for “Asterisk the future of telephony”, it’s an excellent and free book to get started with asterisk. It is, however, based on an older version of asterisk and a lot of the explanations and examples is no longer 100 % accurate. Newer information is mostly obtained by reading the documentation available through the “core show functions”, “core show function X”, “core show applications” and “core show application X” CLI commands, as well as through reading the source code. There are also a lot of examples, and you’re welcome to at any time join #asterisk on irc.freenode.org. Be warned though that IRC can get somewhat hostile, so please do feel free to also join #strowger – not always someone there but even though we’re pushing to fork asterisk we’re more than happy to attempt assisting with problems within reason. #gentoo-voip also has a few helpful (less hostile) residents that are always keen to assist as far as they can. As per always, do keep in mind that most of the knowledgeable people on IRC have full time jobs, they don’t want to have to do your work for you – they’ll happily push you in a direction, or help solve an interesting problem, but you need to make sure to ask intelligent guestions (how do I get started? is likely to get answered with “have you googled?” or something implying that, or possibly even silence).
Hey Jaco
Will you be willing to help me out for a (reasonable) fee? I’m having a hard time to get things working and I’ve tried everything you suggested here.
Its a Wildcard B410 card with Asterisk and Asterisk-GUI installed from svn.
I keep getting these messages in the asterisk console when trying to make a call:
— Executing [0443025713@DLPN_DialPlan1:1] Macro(“SIP/101-00000000”, “trunkdial-failover-0.3,DAHDI/g1/,,span_1,”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:1] GotoIf(“SIP/101-00000000”, “0?1-fmsetcid,1”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:2] GotoIf(“SIP/101-00000000”, “0?1-setgbobname,1”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:3] Set(“SIP/101-00000000”, “CALLERID(num)=101”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:4] GotoIf(“SIP/101-00000000”, “0?1-dial,1”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:5] Set(“SIP/101-00000000”, “CALLERID(all)=”) in new stack
— Executing [s@macro-trunkdial-failover-0.3:6] Goto(“SIP/101-00000000”, “1-dial,1”) in new stack
— Goto (macro-trunkdial-failover-0.3,1-dial,1)
— Executing [1-dial@macro-trunkdial-failover-0.3:1] Dial(“SIP/101-00000000”, “DAHDI/g1/”) in new stack
[May 11 09:27:25] WARNING[1524]: chan_dahdi.c:4638 dahdi_confmute: DAHDI confmute(0) failed on channel 1: Invalid argument
— Couldn’t call g1/
[May 11 09:27:25] WARNING[1524]: chan_dahdi.c:4638 dahdi_confmute: DAHDI confmute(0) failed on channel 1: Invalid argument
[May 11 09:27:25] WARNING[1524]: chan_dahdi.c:4581 restore_gains: Unable to restore gains: Invalid argument
[May 11 09:27:25] WARNING[1524]: chan_dahdi.c:4264 reset_conf: Failed to reset conferencing on channel 1: Invalid argument
— Hungup ‘DAHDI/1-1’
== Everyone is busy/congested at this time (0:0/0/0)
— Executing [1-dial@macro-trunkdial-failover-0.3:2] GotoIf(“SIP/101-00000000”, “0 > 0 ?1-CHANUNAVAIL,1:1-out,1”) in new stack
— Goto (macro-trunkdial-failover-0.3,1-out,1)
— Executing [1-out@macro-trunkdial-failover-0.3:1] Hangup(“SIP/101-00000000”, “”) in new stack
== Spawn extension (macro-trunkdial-failover-0.3, 1-out, 1) exited non-zero on ‘SIP/101-00000000’ in macro ‘trunkdial-failover-0.3’
== Spawn extension (DLPN_DialPlan1, 0443025713, 1) exited non-zero on ‘SIP/101-00000000’
help / ideas will be appreciated
You problem seems to be asterisk-gui related, something I’m not familiar with.
You can contact me via email (jaco at uls dot co dot za) and we can see what we can sort out.
Also, some things you should test first, is the spans listed in /proc/dahdi, and does dahdi_scan give you the results you expect (presumably something down these lines):
[1]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 1
name=B4/0/1
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 04 Slot 01
basechan=1
totchans=3
irq=17
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[2]
active=yes
alarms=OK
description=B4XXP (PCI) Card 0 Span 2
name=B4/0/2
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 04 Slot 01
basechan=4
totchans=3
irq=17
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[3]
active=yes
alarms=OK
description=B4XXP (PCI) Card 0 Span 3
name=B4/0/3
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 04 Slot 01
basechan=7
totchans=3
irq=17
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[4]
active=yes
alarms=OK
description=B4XXP (PCI) Card 0 Span 4
name=B4/0/4
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 04 Slot 01
basechan=10
totchans=3
irq=17
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
But preferably with all alarms=OK. Then from there you need to make sure that they are visible to asterisk (pri show spans for the above lists this):
PRI span 1/0: Provisioned, In Alarm, Down, Active
PRI span 2/0: Provisioned, Up, Active
PRI span 3/0: Provisioned, Up, Active
PRI span 4/0: Provisioned, In Alarm, Down, Active
Then if that’s there you need to make sure they are configured with asterisk, “dahdi show channels” should help with this:
Chan Extension Context Language MOH Interpret Blocked State
pseudo default default In Service
1 incoming en default In Service
2 incoming en default In Service
4 incoming en default In Service
5 incoming en default In Service
7 incoming en default In Service
8 incoming en default In Service
10 incoming en default In Service
11 incoming en default In Service
Note that on this particular machine span 1 is dead and span 4 is flapping like crazy. If you’ve got that, you need to make sure that when you dial out you need to actually give a number to dial, and this is where I think asterisk-gui is going wrong. If you look at the above you’re doing Dial(DAHDI/g1/) … which won’t tell Telkom what number you’re trying to dial. That should read Dial(DAHDI/g1/0443025713). After that Telkom should be able to actually complete the call as it will know what number to call. This is not an asterisk fault, it’s merely doing what asterisk-gui is telling it to do.
Jaco,
Thank you. Without your help I would’ve been screwed. It took 3 hours into the middle of the night but we got it in the end.
I have a transcript of our chat and will be editing it as a troubleshoot. I’ll send it to you once I’m done and you can post it.
Thanks again!
Howdy,
The Digium knowledge base article 17 has been updated to note the pins described relate to E1/T1 PRI connections.
Cheers
hello Jaco het jy dalk vir my die nuutste conf hoe om n isdn b410p card te installe ek werk nog op die ou manier wat misdn drivers vat en nie dhadi nie
groete kobus
Hi Jaco.
I have a new install of Elastix 2.0. I can make calls out but not getting calls in. We have a B410P card. Will setting the from signalling=fxs_ks to signalling=bri_cpe_ptmp fix the problem ?
Thx.
@ Kobus – DAHDI and MISDN is different. Based on my experience with mISDN I cannot recommend using it, please do consider using DAHDI.
@ Jaco – using signalling = fxs_ks will never work for ISDN lines. And yes, the difference between bri_cpe and bri_cpe_ptmp could very well be causing your problem.
Hi there,
I would just like to comment on Dahdi and the Digium B410p. I have a customer that I was having endless problems using the dahdi drivers with this card. For some reason the bri lines (Telkom ISDN2) would fail after a period of time on incoming calls. The orange light flashes quickly and the line is faulty until I pull the cable out and let the NT reset. I then setup the lines with mISDN and now I have perfect working lines.
My point here is either dahdi is not ready for the bri cards or there is some setting I am missing. Will continue to use mISDN.
Thought I would share my experience with you guys.
There has been a few recent commits into dahdi to address a few BRI specific issues, some of which I’ve encountered myself on high-utilization systems (3 x B410P + 1 x TE405P). All of these commits are to the best of my knowledge in DAHDI 2.4.0 and should address many (most) of these problems.
That is very interesting. The setup I have is almost exactly the same. 3 x b410p and 1 x quad PRI. The PRI is used to connect there legacy Siemens.
I will take a look and another go at dahdi after updating it.
Thanks!
Rather use ISDN BRI SIP Gateways in the future , such as a Patton SmartNode 4638.
They don’t use drivers, they don’t take up a PCI slot – often the problem due to power mismatch and irq issues , they have both licenses required (Type Approval and Signalling) they ALWAYS work ,they can be installed within the maximum range because they connect to the LAN and they are infact CHEAPER – simply a NO BRAINER !
I agree with you on this one. I have used a gateway from Farsouth (comma iTA) that is South African made and connects to the LAN with the advantage of hardware echo cancel and lightning protection on all ports (Key point if you live in SA I feel). It is also customizable to the point of mixing PRI, BRI, FXO and FXS all in one unit.
On big installs i go for the gateway option but in my case on this blog the customer already had the hardware from a previous vendor so had to make it work.
Lots of good info here – I am battling with the same issue as Jaco, I am using a B410P card with a single ISDN plugged into it and I can dial out just fine. Dialling in just refuses to pick up te line, I have configured everything as it should be and just created an incoming route with no CID or DID and it just rings away. Any suggestions would be a big help.
— my /etc/dahdi/system.conf has
span=1,1,0,ccs,ami
bchan=1,2
hardhdlc=3
loadzone = za
defaultzone = za
— and dahdi-channels.conf has
group=0,11
context=from-zaptel
switchtype = euroisdn
signalling = bri_cpe (have tried both versions here)
channel => 1-2
context = default
group = 63
Try changing your context in dahdi channels to context=from-pstn
Zaptel is the default context but you should always use from-pstn when using POTS or ISDN.
Hi,
I am using Elastix 1.6 and I am having a problem with my dahdi and Digium B410P setup.
I know the OS knows about the card :
[root@elastix asterisk]# dahdi_scan
[1]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 1
name=B4/0/1
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 06 Slot 01
basechan=1
totchans=3
irq=66
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[2]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 2
name=B4/0/2
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 06 Slot 01
basechan=4
totchans=3
irq=66
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[3]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 3
name=B4/0/3
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 06 Slot 01
basechan=7
totchans=3
irq=66
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[4]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 4
name=B4/0/4
manufacturer=Digium
devicetype=Wildcard B410P
location=PCI Bus 06 Slot 01
basechan=10
totchans=3
irq=66
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
Because I have installed the latest dahdi drivers, and it detects my card and all but when I go to asterisk using asterisk -vvr , and try the command : dahdi show channels I get the following :
elastix*CLI> dahdi show channels
No such command ‘dahdi show channels’ (type ‘help dahdi show’ for other possible commands)
What can I do to solve this problem.
My email is diabolixxx@gmail.com if anyone wants to contact me persoanlly about this.
All help would be appreciated!
Hi there
Just wanted to say the info supplied was extremely useful and helped me configure and understand Asterisk far greater than any other guide.
Hi Jaco, great info.
Do you have advice on setting up Sangoma A10x ISDN Cards with Wanpipe for South Africa?
Ryan,
Only worked with Sangoma Analog cards, FXS ports.
The asterisk portion should be identical to the above. The wanrouter portion … no clue, the underlying settings should be similar in nature to that described above, but I have no idea how to actually make them.
Hi Guys
Just want to say thanks for all the info on this site.. It helped me alot.. I setup a system with the Sangoma BRI card and the U100 USB FXO ports.. Biggest issues I had was the U100 usb no picking up after a reboot.. Sangoma says they only support CentOS for the device, so if anybody is thinking of using it, just keep that in mind (wouldnt recommend it).. Other then that the quality is good for a USB device and ISDN is work like a charm.. Had a few compaitiblity issues with the DAHDI and Wanpipe drivers but fiddled around and working perfectly now..
Hi Jaco,
I have installed B410P with Dahdi – thanks for help above. However I am struggling with it dropping calls all the time. Sometimes it rings twice & drops the call, other times it randomly drops calls that are in progress.
Running Asterisk 1.8 and drivers etc are all yum updates installed as of today.
What could be the problem?
Tempted to go to mISDN
Hi Cuan,
Busy working with Digium on a similar issue. It only seems to affect ISDN2a and not ISDN2. The reason for this seems to be timing related, we’re as of yet unsure of exactly why, but there seems to be timing slips going on when using the ISDN2a units for some reason (this is Digium’s theory).
Are you seeing HDLC errors at all? Can you enable HDLC debugging (echo 64 > /sys/module/wcb4xxp/parameters/debug) and please send me the dmesg output (email below)?
I just received a patch from them that makes DAHDI behave more like misdn in case of HDLC errors (don’t want to release publicly just yet), please email me (jaco@uls.co.za) and I’ll send it to you directly for testing.
chan_misdn is deprecated and if you intend to go to mISDN then you will need to use chan_lcr (Linux Call Router) which also does not seem to be recommended.
Hi Jaco
Awesome guide, thanks very much for it.
I’ve got a B410P with 3 ISDN Bri lines connected to it. I’ve tweaked the configs with the changes you mention above, but i’m still having the following issue:
Calls over the B410P go through, but there is no audio coming in from the external phone. After dialing the number, you hear the beginning of the ringing, but it gets cut. The person on the other side can hear you fine.
Another odd thing i have discovered, is the first call that goes through after a reboot is fine. All subsequent calls are flawed.
Any ideas? I’ve tried switching off echo cancellation wherever I can.
Hi,
An update form our situation :
We had a very weird static noise coming from our PRI on all inbound calls and no distro of asterisk fixed it, even tried different Digium cards (3 in fact).
Nothing worked for us and yes we changed absolutely every single setting, install every single version of dahdi etc.
Finally fixed the issue at 5am monday morning… by removing the “crc4” setting from system.conf and changing our echocanceller from olsec to mg2.
system.conf:
span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31
loadzone = za
defaultzone = za
We are based in Cape Town so perhaps the config with the CRC4 is different to that of Joburg etc.
Good luck to everyone else out there.
Will
hi Guys! i need your help please,
I have an OpenVox card b400p installed on my server with asterisk 1.8 and dahdi-linux 2.7,
now cover I can make calls from the fixed line (ISDN)
but my problem is that : on my headset the sound is impecable everything is impecable but there are noises on the receiver’s phone and just a little of my voice
here is my ‘dahdi_scan’
[1]
active=yes
alarms=OK
description=B4XXP (PCI) Card 0 Span 1
name=B4/0/1
manufacturer=Digium
devicetype=OpenVox B400P
location=PCI Bus 02 Slot 03
basechan=1
totchans=3
irq=0
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[2]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 2
name=B4/0/2
manufacturer=Digium
devicetype=OpenVox B400P
location=PCI Bus 02 Slot 03
basechan=4
totchans=3
irq=0
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[3]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 3
name=B4/0/3
manufacturer=Digium
devicetype=OpenVox B400P
location=PCI Bus 02 Slot 03
basechan=7
totchans=3
irq=0
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
[4]
active=yes
alarms=RED
description=B4XXP (PCI) Card 0 Span 4
name=B4/0/4
manufacturer=Digium
devicetype=OpenVox B400P
location=PCI Bus 02 Slot 03
basechan=10
totchans=3
irq=0
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI,HDB3
framing_opts=ESF,D4,CCS,CRC4
coding=AMI
framing=CCS
my chan_dahdi.conf
[trunkgroups]
[channels]
; Span 1: B4/0/1 “B4XXP (PCI) Card 0 Span 1” (MASTER) AMI/CCS
group=0,11
echocancel = yes
echocancelwhenbridged=no
echotraining=no
rxgain=0.0
txgain=0.0
context=from-isdn
switchtype = euroisdn
signalling = bri_cpe_ptmp
channel => 1-2
context = default
group = 63
the result of the command ‘dahdi show channels’
dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State
pseudo default default In Service
1 from-isdn default In Service
2 from-isdn default In Service
and when I call here what is written on asterisk cli, something like this
WARNING[4951]: chan_sip.c:6316 sip_write: Asked to transmit frame type alaw, while native formats is 0x4 (ulaw) read/write = 0x4 (ulaw)/0x4 (ulaw)
your help will be apreciated!!thanks
I would just like to thank you for this article since it helped me solve my problem with cell phone calls dropping after 2 rings…
Weird thing is its actually a simple solution that no one out there including the guy who set the system up could give me…
Thanx a mil!!
Hi
I’m wondering can you advise on the cable pinout for a telkom ISDN BRI NT1 to connect to a cisco BRI Card? I’ve tried several variations of cable but I can’t get the layer 1 to even come up.
Thanks!