VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
gordon+asterisk at dro...
Guest
|
 Posted: Fri May 16, 2008 11:35 am Post subject: [asterisk-users] 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 |
|
| Back to top |
|
 |
gordon+asterisk at dro...
Guest
|
| Posted: Mon May 19, 2008 5:42 am Post subject: [asterisk-users] PRI debugging ... |
|
|
On Fri, 16 May 2008, Gordon Henderson wrote:
| Quote: | 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 |
|
| Back to top |
|
|
creslin at digium.com
Guest
|
| Posted: Mon May 19, 2008 10:45 am Post subject: [asterisk-users] PRI debugging ... |
|
|
Gordon Henderson wrote:
| Quote: | On Fri, 16 May 2008, Gordon Henderson wrote:
| Quote: | 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.
|
You might try turning off echo cancellation to see if your D-channel
performance improves. That would be a good test to tell if you should
look into perhaps getting either a faster CPU or a hardware echo
canceller. It's possible that you may be saturating your poor 1.3 Ghz
CPU by doing echo cancellation for too many channels on it.
--
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc. |
|
| Back to top |
|
|
tony at softins.clara....
Guest
|
| Posted: Mon May 19, 2008 5:00 pm Post subject: [asterisk-users] PRI debugging ... |
|
|
In article <4831A09A.6060807 at digium.com>,
Matthew Fredrickson <creslin at digium.com> wrote:
| Quote: |
You might try turning off echo cancellation to see if your D-channel
performance improves. That would be a good test to tell if you should
look into perhaps getting either a faster CPU or a hardware echo
canceller. It's possible that you may be saturating your poor 1.3 Ghz
CPU by doing echo cancellation for too many channels on it.
|
Yes, I tripped over this one a while ago. I couldn't understand why my
533MHz Celeron test system with a TE405P would start producing loads
of D-channel errors as soon as I got to about 6 or 7 calls through it.
Eventually I discovered echo cancellation was turned on, causing the
1ms interrupt service routines to take more than 1ms to execute!
It's much happier with no echo cancellation, although I haven't tried
running all 120 channels at once!
Cheers
Tony
--
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
