Hi list,
Attempting to get an ISDN-BRI line connected using an HFC-S PCI card
together with Asterisk v1.4.14 and Zaptel 1.4.7 on a Debian etch
system, I find that I can't access the card's resources because the
channels are always be busy. An attempt to call out results in the
following CLI output:
== Primary D-Channel on span 1 down
== Primary D-Channel on span 2 down
-- Executing [0653214647 at phones:1] Dial("SIP/1000-081f3698",
"Zap/g0/0653214647 at channels||r") in new stack
[Jan 3 15:32:06] WARNING[9769]: app_dial.c:1130 dial_exec_full: Unable to
create channel of type 'Zap' (cause 34 -
Circuit/channel
congestion)
== Everyone is busy/congested at this time (1:0/1/0)
== Auto fallthrough, channel 'SIP/1000-081f3698' status is
'CONGESTION'
== Primary D-Channel on span 1 down
== Primary D-Channel on span 2 down
Hopefully, someone here with more experience can point me in the
direction of a solution. Here are hopefully some more clues:
# lsmod | grep zap
zaphfc 13660 1
vzaphfc 24984 1
zaptel 185956 9 xpp,zaphfc,vzaphfc
crc_ccitt 2560 1 zaptel
# cat /proc/zaptel/*
Span 1: ZTHFC1 "HFC-S PCI A Zaptel Driver card 0 [TE]" (MASTER)
AMI/CCS
1 ZTHFC1/0/1 Clear (In use)
2 ZTHFC1/0/2 Clear (In use)
3 ZTHFC1/0/3 HDLCFCS (In use)
Span 2: ZTHFC1 "HFC-S PCI A ISDN card 1 [TE]" AMI/CCS
4 ZTHFC1/0/1 Clear (In use)
5 ZTHFC1/0/2 Clear (In use)
6 ZTHFC1/0/3 HDLCFCS (In use)
It looks like the vzaphfc module creates a virtual interface. I have
only one HFC-S PCI card installed. Each channel is "(In use)"
immediately after Asterisk is started.
CLI> zap show channels
Chan Extension Context Language MOH Interpret
pseudo default en default
1 from-pstn en default
2 from-pstn en default
4 from-pstn en default
5 from-pstn en default
CLI> zap restart
Destroying channels and reloading zaptel configuration.
== Parsing '/etc/asterisk/zapata.conf': Found
== Parsing '/etc/asterisk/zapata-channels.conf': Found
[Jan 3 15:40:06] WARNING[9797]: chan_zap.c:1081 zt_open: Unable to
specify channel 1: Device or resource busy
[Jan 3 15:40:06] ERROR[9797]: chan_zap.c:7501 mkintf: Unable to
open channel 1: Device or resource busy
here = 0, tmp->channel = 1, channel = 1
[Jan 3 15:40:06] ERROR[9797]: chan_zap.c:12266 build_channels: Unable to
register channel '1-2'
[Jan 3 15:40:06] WARNING[9797]: chan_zap.c:11554 zap_restart: Reload
channels from zap config failed!
Not a good idea, because that results in...
CLI> zap show channels
Chan Extension Context Language MOH Interpret
the channels disappearing altogether. However, I can restore the
situation back to its original, albeit useless, state if I stop and
start Asterisk.
My configuration files are as follows:
/etc/asterisk/zapata-channels.conf (after running "genzaptelconf -sd -c
nl"):
group=0,11
context=from-pstn
switchtype = euroisdn
signalling = bri_cpe_ptmp
channel => 1-2
group context=default
group=0,12
context=from-pstn
switchtype = euroisdn
signalling = bri_cpe_ptmp
channel => 4-5
group context=default
/etc/asterisk/zapata.conf (supposed to work in the Netherlands):
[trunkgroups]
[channels]
language=en
context=isdn-in
switchtype=euroisdn
pridialplan=dynamic
prilocaldialplan=local
nationalprefix = 0
internationalprefix = 00
overlapdial=yes
signalling=bri_cpe_ptmp
rxwink=300
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=100
rxgain=4.5
txgain=-3
group=1
callgroup=1
pickupgroup=1
immediate=yes
#include zapata-channels.conf
Abbreviated /etc/asterisk/extensions.conf:
[globals]
[general]
[isdn-out]
exten => _X.,1,Dial(Zap/g0/${EXTEN}@channels,,r)
[internal]
exten => 1000,1,Verbose(1|Extension 1000)
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n,Hangup()
[phones]
include => internal
include => isdn-out
Any ideas?
TIA,
Jaap
On Thu, Jan 03, 2008 at 04:08:10PM +0100, Jaap Winius wrote:> Hi list, > > Attempting to get an ISDN-BRI line connected using an HFC-S PCI card > together with Asterisk v1.4.14 and Zaptel 1.4.7 on a Debian etch > system, I find that I can't access the card's resources because the > channels are always be busy. An attempt to call out results in the > following CLI output: > > == Primary D-Channel on span 1 down > == Primary D-Channel on span 2 down > -- Executing [0653214647 at phones:1] Dial("SIP/1000-081f3698", > "Zap/g0/0653214647 at channels||r") in new stack > [Jan 3 15:32:06] WARNING[9769]: app_dial.c:1130 dial_exec_full: Unable to > create channel of type 'Zap' (cause 34 - Circuit/channel > congestion) > == Everyone is busy/congested at this time (1:0/1/0) > == Auto fallthrough, channel 'SIP/1000-081f3698' status is 'CONGESTION' > == Primary D-Channel on span 1 down > == Primary D-Channel on span 2 downWhat is the output of: pri show spans (Yes, it is "pri" and not "bri"). Do incoming calls work?> > Hopefully, someone here with more experience can point me in the > direction of a solution. Here are hopefully some more clues: > > # lsmod | grep zap > > zaphfc 13660 1 > vzaphfc 24984 1 > zaptel 185956 9 xpp,zaphfc,vzaphfc > crc_ccitt 2560 1 zaptelInteresting... which one of those two is used? I suspect vzaphfc is loaded automatically by udev, unless you have zaphfc explicitly in /etc/modules .> > # cat /proc/zaptel/* > > Span 1: ZTHFC1 "HFC-S PCI A Zaptel Driver card 0 [TE]" (MASTER) AMI/CCS > > 1 ZTHFC1/0/1 Clear (In use) > 2 ZTHFC1/0/2 Clear (In use) > 3 ZTHFC1/0/3 HDLCFCS (In use) > Span 2: ZTHFC1 "HFC-S PCI A ISDN card 1 [TE]" AMI/CCS > > 4 ZTHFC1/0/1 Clear (In use) > 5 ZTHFC1/0/2 Clear (In use) > 6 ZTHFC1/0/3 HDLCFCS (In use) > > It looks like the vzaphfc module creates a virtual interface. I have > only one HFC-S PCI card installed. Each channel is "(In use)" > immediately after Asterisk is started. > > CLI> zap show channels > > Chan Extension Context Language MOH Interpret > pseudo default en default > 1 from-pstn en default > 2 from-pstn en default > 4 from-pstn en default > 5 from-pstn en default > > CLI> zap restartThis will not work with digital spans. Try restarting asterisk. e.g: asterisk -R restart now> > Destroying channels and reloading zaptel configuration. > == Parsing '/etc/asterisk/zapata.conf': Found > == Parsing '/etc/asterisk/zapata-channels.conf': Found > [Jan 3 15:40:06] WARNING[9797]: chan_zap.c:1081 zt_open: Unable to > specify channel 1: Device or resource busy > [Jan 3 15:40:06] ERROR[9797]: chan_zap.c:7501 mkintf: Unable to > open channel 1: Device or resource busy > here = 0, tmp->channel = 1, channel = 1 > [Jan 3 15:40:06] ERROR[9797]: chan_zap.c:12266 build_channels: Unable to > register channel '1-2' > [Jan 3 15:40:06] WARNING[9797]: chan_zap.c:11554 zap_restart: Reload > channels from zap config failed! > > Not a good idea, because that results in... > > CLI> zap show channels > > Chan Extension Context Language MOH Interpret > > the channels disappearing altogether. However, I can restore the > situation back to its original, albeit useless, state if I stop and > start Asterisk. > > My configuration files are as follows: > > /etc/asterisk/zapata-channels.conf (after running "genzaptelconf -sd -c nl"): > > group=0,11 > context=from-pstn > switchtype = euroisdn > signalling = bri_cpe_ptmp > channel => 1-2 > group> context=default > > group=0,12 > context=from-pstn > switchtype = euroisdn > signalling = bri_cpe_ptmp > channel => 4-5 > group> context=default > > /etc/asterisk/zapata.conf (supposed to work in the Netherlands): > > [trunkgroups] > > [channels] > language=en > context=isdn-in > switchtype=euroisdn > pridialplan=dynamic > prilocaldialplan=local > nationalprefix = 0 > internationalprefix = 00 > overlapdial=yes > signalling=bri_cpe_ptmp > rxwink=300 > usecallerid=yes > hidecallerid=no > callwaiting=yes > usecallingpres=yes > callwaitingcallerid=yes > threewaycalling=yes > transfer=yes > canpark=yes > cancallforward=yes > callreturn=yes > echocancel=yes > echocancelwhenbridged=yes > echotraining=100 > rxgain=4.5 > txgain=-3 > group=1 > callgroup=1 > pickupgroup=1 > immediate=yes > #include zapata-channels.conf > > Abbreviated /etc/asterisk/extensions.conf: > > [globals] > > [general] > > [isdn-out] > exten => _X.,1,Dial(Zap/g0/${EXTEN}@channels,,r) > > [internal] > exten => 1000,1,Verbose(1|Extension 1000) > exten => 1000,n,Dial(SIP/1000,30) > exten => 1000,n,Hangup() > > [phones] > include => internal > include => isdn-out > > Any ideas? > > TIA, > > Jaap > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
Quoting Tzafrir Cohen <tzafrir.cohen at xorcom.com>:> (if you set in /etc/default/zaptel: ZAPBRI_SIGNALLING="bri" > you'll get that from genzaptelconf.If I create a file like this, I end up with "signalling=bri_cpe" instead of "signalling=bri_cpe_ptmp".> Anyway, either you use zaphfc or vzaphfc. The first one that loads takes > everything.So far I have succeeded in starting up Asterisk without the zaphfc module (if channels 4-5 aren't defined in zapata.conf), but not without vzaphfc. Not having vzaphfc loaded always results in Asterisk starting up without Zaptel support. However, whether I run it with or without zaphfc, all of the available ISDN channels are always busy and the CLI still frequently shows "Primary D-Channel on span 1 down" messages.> What do you see on /proc/interrupts ?CPU0 0: 25025934 IO-APIC-edge timer 6: 3 IO-APIC-edge floppy 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 15: 129 IO-APIC-edge ide1 169: 286747 IO-APIC-level skge 177: 1014894 IO-APIC-level libata 185: 0 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, ... 193: 114700219 IO-APIC-level vzaphfc, zaphfc 201: 0 IO-APIC-level via82cxxx NMI: 0 LOC: 25024942 ERR: 0 MIS: 0> Which of those two modules you can't unload when Asterisk is running?If I declare all of the channels in zapata.conf, like this... channel => 1-2 channel => 4-5 then neither of the modules can be unloaded while Asterisk is running. If I comment out the first line then I can unload vzaphfc, while if I comment out the second I can unload zaphfc, so I guess this is how the channels are related to the modules. This makes sense, because when the zaptel modules are loaded with "genzaptelconf -d" (-d = hardware detection), vzaphfc is always loaded first. Regarding "genzaptelconf -d", I've found that it is essential for me to run this command first before starting Asterisk. If not, Asterisk will start, but without Zaptel support. During system bootup, only the zaptel van vzaphfc modules are loaded by the kernel, which is not enough. Instead, genzaptelconf's hardware detection loads these modules in the following order: Module Size Used by xpp 88512 0 zaphfc 12956 0 vzaphfc 24312 0 firmware_class 9600 0 zaptel 184740 3 xpp,zaphfc,vzaphfc This works. However, if I try to load these modules manually in the same order, Asterisk will start without Zaptel support. I don't know yet how genzaptelconf accomplishes this, but I suspect that it passes certain parameters to the zaptel and/or vzaphfc modules as it loads them. I say that because, after running "genzaptelconf -d", it's possible to remove the xpp, zaphfc (if channels 4-5 are not declared) and firmware_class modules before starting up Asterisk and still have Zaptel support, although all of the Zaptel channels will still be busy. Furthermore, it is therefore not my impression that zaphfc is interfering with vzaphfc to cause all the zap channels to be busy. FYI, my current /etc/asterisk/zapata.conf is as follows: ----------------------------------------- [trunkgroups] [channels] language=en context=isdn-in switchtype=euroisdn pridialplan=dynamic prilocaldialplan=local nationalprefix = 0 internationalprefix = 00 overlapdial=yes signalling=bri_cpe_ptmp rxwink=300 usecallerid=yes hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=yes echotraining=100 rxgain=4.5 txgain=-3 callgroup=1 pickupgroup=1 immediate=yes group=1 switchtype = euroisdn signalling = bri_cpe_ptmp channel => 1-2 channel => 4-5 ----------------------------------------- More information can be found in my previous posts in this thread. By the way, I've now duplicated my results on a new system with a different motherboard, a new HFC-S card and a fresh Debian etch install, etc., but unfortunately the results were exactly the same: all zap channels busy as soon as Asterisk starts. If anybody has a working Asterisk v1.4 configuration for ISDN-BRI using an HFC-S card and Zaptel software, I'd love to see it. Thanks, Jaap