Zaptel lines permanently engaged

Hi,
I’m using Asterisk for an internal project, and I’m currently using zaptel 1.2.6 and Asterisk 1.0.7 (old, I know, but I have made some mods and right now its a bit too much of a pain to upgrade: its on the schedule).
The application is deployed in India (and not sure if it matters, but the phone lines are from BSNL). We’ve been having intermittent disconnect problems with the lines, and we thought it was a problem with the provider, but it turns out its a problem with our setup. We have a single TDM400P REV I board with 2 FXO boards (configured with the FXS kewlstart protocol) and although the configuration appears to be fine the lines are permanently engaged once they are plugged into the asterisk board, even if I unload the zaptel and wctdm modules. I’ve verified the lines are fine because when plugged into a regular phone I can call them and they ring and pick up, but only when plugged into the zaptel modules do they stop functioning (even more annoying is the fact that the provider periodically goes “this must be a malfunction: I’m going to reset the lines”, making it particularly difficult to debug).

The zaptel.conf is this:

loadzone=in
defaultzone=in
fxsks=3-4

and the zapata.conf is this:

[trunkgroups]

[channels]
context=default
signalling=fxo_ls
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=1.0
txgain=1.0
group=1
callgroup=1
pickupgroup=1
immediate=no
hanguponpolarityswitch=yes
answeronpolarityswitch=yes
busydetect=no
busycount=4
callprogress=no
progzone=in
context=default
signalling=fxs_ks
channel => 3
channel => 4

After bootup (or when I manually load/unload the modules), I get this from dmesg:

Zapata Telephony Interface Unloaded
Zapata Telephony Interface Registered on major 196
Zaptel Version: 1.2.6 Echo Canceller: KB1
ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 20 (level, low) -> IRQ 209
Freshmaker version: 73
Freshmaker passed register test
Module 0: Not installed
Module 1: Not installed
Module 2: Installed – AUTO FXO (INDIA mode)
Module 3: Installed – AUTO FXO (INDIA mode)
Found a Wildcard TDM: Wildcard TDM400P REV I (2 modules)
Registered tone zone 28 (India)
Registered tone zone 28 (India)

ztmonitor shows this:

( # = Audio Level * = Max Audio Hit )
<----------------(RX)----------------> <----------------(TX)---------------->
Rx: 29 ( 29) Tx: 0 ( 0)

regardless of whether or not I call the phone line or if the phone line is plugged in, which is rather confusing.

Any help/advice would be appreciated.

the 1.2 branch of zaptel is not compatible with versions of asterisk older than 1.0.9 - that has been my experience anyway.

we were running 1.0.7 for quite a while, and i could NOT get the newer versions of zaptel to work, we had to bump asterisk to 1.0.9 or 1.1.0…so we just moved to the 1.2 branch and called it good.

i know this isn’t the answer you wanted, but just go back to the 1.0 branch of zaptel and you should work out okay.

loadzone=in
defaultzone=in

try
loadzone=uk
defaultzone=uk
to see if this solves the problem

Gentlemen,
thank you. The UK change appears to not do anything different. And unfortunately, the kernel interfaces have changed and I can no longer compile zaptel 1.0.10 (I’m using kernel 2.6.15).
So it appears an upgrade is in order. Ugh.

So I’m back: I’ve updated the zaptel drivers to 1.2.7 and Asterisk itself to 1.2.10. I’m using the exact same configuration as before. Much better now is that the lines are no longer permanently engaged. However asterisk still fails to pick up the calls, and when I look at ztmonitor I either get the RX permantently set at 30 (on one channel) or permanently set at 215 with the max input indicated (it displays #* for the other channel). I’m kind of stumped at this point and would be grateful if anyone has suggestions or debugging hints I could use.

Thanks in advance.

EDIT: I’ve been able to adjust the gain up and down on both channel to eliminate the max input shown in ztmonitor, but still: when I call I should be getting a series of lines in ztmonitor that indicate the ringing, but I simply get nothing.

i know you’ve probably gone through this, but we had something kinda similar a while back that turned out to be signalling - zttool was showing bits being passed in both directions when the line wasn’t up, and that was because we were using loopstart when we needed to be using featd.

maybe try fxs_ls instead of fxs_ks? has the telco confirmed the line signalling?

Folks,
back again. Thanks for the support so far, and here’s hoping I can get some more helpful hints. I shipped a computer from the US to India (given that I don’t have complete control over the environment, I figured I’d send a completely configured machine). However, that plan didn’t work out as well as I might have liked: the lines still showed up as engaged on the new machines.
However, further digging around pointed towards problems with the interrupts and after much juggling of cards and PCI ports and /proc/interrupts I was able to get an X100P clone to function (partially) correctly. The line plugged into the X100P clone is no longer permanently engaged, and it will correctly pickup but it will not correctly detect hangups. I’ve tried using the us, uk and india zones in /etc/zaptel.conf, /etc/asterisk/zapata.conf and /etc/asterisk/indications.conf to no avail. All reports out there seem to indicate that the X100 clones are bad at detecting hangups: would a genuine X100 (assuming I could find one) do any better? I’ve been trying to get this solution up and running for almost a month and a half and I’m starting to get rather frustrated, so I’ll settle for ANYTHING at this point.
Thinking that perhaps the same PCI port would work, I swapped back in the TDM400 with the 2 FXO modules, and configured them to use fxs_ks signalling. After enabling debugging on both the zaptel and wctdm drivers I get this output in the logs:

Aug 10 04:50:47 orissahub kernel: Zapata Telephony Interface Registered on major 196
Aug 10 04:50:47 orissahub kernel: Zaptel Version: 1.2.7 Echo Canceller: KB1
Aug 10 04:51:13 orissahub kernel: ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 20 (level, low) -> IRQ 209
Aug 10 04:51:13 orissahub kernel: Registered Span 1 (‘WCTDM/0’) with 4 channels
Aug 10 04:51:13 orissahub kernel: Span (‘WCTDM/0’) is new master
Aug 10 04:51:13 orissahub kernel: Freshmaker version: 73
Aug 10 04:51:13 orissahub kernel: Freshmaker passed register test
Aug 10 04:51:13 orissahub kernel: ProSLIC on module 0, product 0, version 0
Aug 10 04:51:13 orissahub kernel: Module 0: Not installed
Aug 10 04:51:13 orissahub kernel: ProSLIC on module 1, product 0, version 0
Aug 10 04:51:13 orissahub kernel: Module 1: Not installed
Aug 10 04:51:13 orissahub kernel: ProSLIC on module 2, product 0, version 0
Aug 10 04:51:13 orissahub kernel: VoiceDAA System: 04
Aug 10 04:51:13 orissahub kernel: ISO-Cap is now up, line side: 03 rev 03
Aug 10 04:51:13 orissahub kernel: Module 2: Installed – AUTO FXO (INDIA mode)
Aug 10 04:51:13 orissahub kernel: ProSLIC on module 3, product 0, version 0
Aug 10 04:51:13 orissahub kernel: VoiceDAA System: 04
Aug 10 04:51:13 orissahub kernel: ISO-Cap is now up, line side: 03 rev 03
Aug 10 04:51:13 orissahub kernel: Module 3: Installed – AUTO FXO (INDIA mode)
Aug 10 04:51:13 orissahub kernel: Found a Wildcard TDM: Wildcard TDM400P REV I (2 modules)
Aug 10 04:51:13 orissahub kernel: Registered tone zone 28 (India)
Aug 10 04:51:13 orissahub kernel: 4301481 Polarity reversed (0 -> 1)
Aug 10 04:51:13 orissahub kernel: 4301482 Polarity reversed (0 -> 1)

which appears to indicate everything is working fine. I looked at /proc/interrupts and that looks fine

       CPU0

0: 6990627 IO-APIC-edge timer
1: 184 IO-APIC-edge i8042
7: 0 IO-APIC-edge parport0
8: 4 IO-APIC-edge rtc
9: 1 IO-APIC-level acpi
14: 62582 IO-APIC-edge ide0
169: 15649 IO-APIC-level uhci_hcd:usb3, yenta, pcmcia0.0
177: 43960 IO-APIC-level libata, uhci_hcd:usb2, eth0
185: 44 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5
193: 0 IO-APIC-level uhci_hcd:usb4
201: 0 IO-APIC-level Intel ICH6
209: 5393812 IO-APIC-level wctdm
217: 831 IO-APIC-level eth1
NMI: 0
LOC: 6990165
ERR: 0
MIS: 0

and the card is all by itself on an interrupt, so that appears to no longer be an issue. I tried loading the wctdm driver with reversepolarity=1, but no dice: the line is always engaged for some reason.
Thanks for any help you can give me.

OK I have seen issues like this when you are not using a REAL phone line.
(Using a third party reseller)

You can use a handset and think the line is fine but the Ports will not release or not go off hook…I would at the lines.

Hi
I am using Asterisk with one PSTN line from BSNL.
i use a X101p card which has ambient MD3200 chipset.

can you suggest me any solution for hangup detection. and call drop.

Pravin.

STOP creating multiple posts !!

you’ve been answered elsewhere. you posted repeatedly about CallerID only to find out that your telco doesn’t provide it, now you’re doing the same for this.

if you want instant answers then get a support contract with someone. if you want it free, 1) don’t be impatient, and 2) don’t annoy the people helping you.