asterisk users - May 2008 - PRI debugging ...

Have a problem with an ISDN30 line in the UK.

It mostly works though, but I get these messages on the output:

   -- SIP/211-081e5fa0 answered Zap/5-1
   Write to 35 failed: Unknown error 500
   Short write: 0/15 (Unknown error 500)

and this is followed immediately by:

   May 16 11:59:27 WARNING[17242]: chan_zap.c:3878 zt_handle_event:  Detected
alarm on channel 5: Red Alarm
   == Spawn extension (macro-dialInternal, s, 41) exited non-zero on
'Zap/5-1' in macro 'dialInternal'
   == Spawn extension (macro-dialInternal, s, 41) exited non-zero on
'Zap/5-1'

plus a whole host of other messages I see when I reset it - eg.

   May 16 11:59:27 WARNING[1227]: chan_zap.c:6532 handle_init_event: Detected
alarm on channel 6: Red Alarm
   May 16 11:59:27 WARNING[1227]: chan_zap.c:1584 zt_disable_ec: Unable to
disable echo cancellation on channel 6

All the way to channel 14, then:

   May 16 11:59:27 NOTICE[1226]: chan_zap.c:8365 pri_dchannel: PRI got event:
Alarm (4) on Primary D-channel of span 2
   May 16 11:59:27 WARNING[1226]: chan_zap.c:2441 pri_find_dchan: No D-channels
available!  Using Primary channel 20 as D-channel anyway!

and then it resets the whole thing, and is back again a few seconds later, 
but meanwhile all calls have been dropped.

Now the ISDN30 line has been running for some time (years) with a 
Panasonix PBX, so I'm fairly sure it's OK.

This is my little experimental box I mentioned recently - a TDM400 card 
and a TE120P card. They're on separate interrupts according to 
/proc/interrupts and lspci -v. The TE120P card is sharing an interrupt 
with the USB hardware, but there is nothing plugged into it (however the 
next time I can get console access, I'll disable USB in the BOIS)

The only thing I can see which might not be right is /proc/zaptel/2:

   Span 2: WCT1/0 "Wildcard TE120P Card 0" HDB3/CCS/CRC4
         IRQ misses: 690

So 690 misses since power up - 24 hours now, just over 1000 calls since 
9am today.

I can't find anything specific that triggers it - eg. it doesn't seem to
have anything to do with calls via the TDM400 card (2 fax machines and 2 
analogue trunks to a premicell GSM box)

So where to start trying to track this down... Any hints?

Config files are relatively sane, I hope:

/etc/zaptel.conf:

   fxoks=1
   fxoks=2
   fxsks=3
   fxsks=4

   span=2,1,0,ccs,hdb3,crc4
   bchan=5-19
   dchan=20
   bchan=21-35

   loadzone=uk
   defaultzone=uk

/etc/asterisk/zapata.conf:

   ; Channels 5-19, 21-35:
   ;       ISDN30 channels

   context=incoming
   resetinterval=never
   group=2
   usecallerid=yes
   faxdetect=none
   signalling=pri_cpe
   switchtype=euroisdn
   internationalprefix=00
   nationalprefix=0
   overlapdial=yes
   pridialplan=unknown
   immediate=no
   rxgain=0.0
   txgain=0.0
   channel => 5-14

We only have 10 channels "lit".

asterisk-1.2.26.1
zaptel-1.2.23
libpri-1.2.7

Also kernel 2.6.18 if that's any issues.


Cheers,

Gordon

On Fri, 16 May 2008, Gordon Henderson wrote:
> Have a problem with an ISDN30 line in the UK.
So following up my own post.. I've not solved this issue, but I think I 
know what causes it.

This was my experiment to put 2 cards in one 1.3GHz system - a TDM400 with 
2 x FXO and 2 x FSX and a TE120P - E1 card.

The PRI card loses interrupts, so I'm guessing it loses a frame of data 
when it loses an interrupt, and eventually it gives up and does a reset. 
The TDM card was rock solid. The system is using oslec too FWIW.

When I unloaded the wctdm module the PRI performend flawlessly.

So I'm suspecting the 1.3GHz processor and underlying IO is marginal for 
this application. The Mobo doesn't have an APIC, just old PIC hardware, 
although both cards were on separate IRQs - the TDM card had the higher 
priority IRQ though - didn't have time to test it with the cards swapped 
over, but loading the modules in a differnt order didn't make any 
difference. Turning off the USB hardware didn't help either.

The processor does seem to have a highish high-priority interrupt load (as 
seen by top). I'll be trying a newer kernel when I get a chance though 
(this is 2.6.18, compiled to match the motherboard exactly)

Making calls through the TDM card just made it worse.

However when it was working, it was working very well indeed, but the 
occasional time when it dropped all calls (about once an hour) wasn't 
good.

Gordon