ISDN D-channel disconnects for a minute every 5 minutes


#1

I have a problem with Asterisk-bristuffed using a zaphfc card.

I am located in the Netherlands, so I have an ISDN line from KPN. When I
start Asterisk, and plug in the ISDN line, everything works perfectly for
about 5 minutes. And then the ISDN line is down for 1 minute, and after that
minute, the line comes back up and works for another 5 minutes. Every time
the line goes down I get the error message:

asterisktest kernel: zaphfc: received d channel frame with bad CRC.
asterisktest kernel: zaphfc: empty HDLC frame received.
asterisktest kernel: zaphfc: received d channel frame with bad CRC.

I have read the following thread about 2 Dutch guys having the same problem:

This thread

I have watched the output of /proc/zaptel/1 closely with the command "while
true; do grep “(F” /proc/zaptel/1; sleep .1; done"
I can see the D-channel going to state F6 (DEACTIVATED) for a about 0.2
seconds every 10 seconds.
Then, after 5 minutes, the D-channel goes to state F6 (DEACTIVATED) for a
whole minute, and then returns to state F7 (ACTIVATED).

I have used Asterisk 1.2.0-Bristuffed-0.3.0-PRE-1 with the corresponding
florz patch and Asterisk 1.2.1-Bristuffed-0.3.0-PRE-1g with the
corresponding florz patch, but they both have the same problem.

I use Asterisk 1.0.9-BRIstuffed-0.2.0-RC8n as a live machine on the same NT1
with no problems at all. The D-channel goes down and up (like all KPN ISDN
lines do), but I have never had any problems with the machine not being
reachable or something.

When I have the “problematic” Asterisk 1.2.x testmachine on the same NT1
using another MSN-number, there is no problem. I can always reach the
testmachine, but as soon as the testmachine is the only machine on the NT1
box, and handling the main MSN-number, the above problem arises.

here’s the essential part of my zaptel.conf. There is only one hfc-s card in
the machine.

span=1,1,3,ccs,ami
bchan=1-2
dchan=3

and zapata.conf:

switchtype=euroisdn
pridialplan=dynamic
prilocaldialplan=local
signalling=bri_cpe_ptmp
rxwink=300
cidsignalling=dtmf
channel => 1-2

Any input wille be much appreciated, because i’m a bit stuck here…


#2

A little reply to self:

I have tested a few things more. I have had E-mail contact with one of the guys from the Google groups thread. He was very helpful (thanks for that, Francesco!) and he stated that there are 3 workarounds:

  1. Dial out with the zap channel through AMI with 100 ms timeout. Do that every 1 minute using cron and expect.

  2. Find a piece of hardware that keeps the D-channel up all the time.

  3. Call KPN (the ISDN provider) and ask if they want to set the D-channel to “always up”

I have tried all 3 workarounds. This is what I found:

  1. I have tried to call with an Expect script through AMI (got it from Francesco). It seems to work, but I haven’t tested it in a live situation. The drawback is that the CDR database gets all kinds of garbage from the “keepalive call” and it takes system resources every 1 minute.

  2. Well, I found a piece of hardware: The Asterisk 1.0.9 box with Bristuff 0.2.0 . When that box is on the same NT1 as the 1.2.x box with Bristuff 0.3.0, everything works perfectly. Have to find another piece of hardware to make it an atractive workaround though.

  3. I have called KPN, and after 10 minutes on the phone with a first-line helpdesk employee, i convinced him to log a call to an ISDN-engineer. About 3 hours later, the ISDN-engineer calls back, and says that it has been taken care of. I tested an 1.2.0-Bristuff-0.3.0-PRE1, and lo’ and behold, no problems whatsoever! So this is the best workaround so far I think.

I will try to find out more what causes this problem, but so far I at least have a working machine :smile: