thp at westhawk.co.uk Guest
|
Posted: Tue Jan 29, 2008 7:17 am Post subject: [asterisk-users] PRI Alarms, Comes Back, But Asterisk Won't |
|
|
On 29 Jan 2008, at 11:08, George Pajari wrote:
Quote: | Here is the scenario: Asterisk 1.14.13; zaptel 1.4.6; Digium TE120P
(same problem with various previous versions; same problem with
different TE120P cards).
The customer has a partial (10 B-Channel) PRI that when it is busy
(eight or more B channels in use), tends to fail as shown below...
[Jan 26 23:00:31] ERROR[31893] chan_zap.c: Write to 28 failed: Unknown
error 500
[Jan 26 23:00:31] ERROR[31893] chan_zap.c: Short write: 0/15 (Unknown
error 500)
[Jan 26 23:00:31] WARNING[31893] chan_zap.c: Detected alarm on channel
1: Red Alarm
we then see every channel fail with a write error followed by a Red
Alarm. Then....
[Jan 26 23:00:34] VERBOSE[7646] logger.c: == Primary D-Channel on
span
1 down
[Jan 26 23:00:34] WARNING[7646] chan_zap.c: No D-channels available!
Using Primary channel 24 as D-channel anyway!
[Jan 26 23:00:36] NOTICE[7647] chan_zap.c: Alarm cleared on channel 1
(alarm cleared messages for all channels deleted)
[Jan 26 23:00:36] NOTICE[7646] chan_zap.c: PRI got event: No more
alarm
(5) on Primary D-channel of span 1
Yet even with all alarms cleared, a "pri show span 1" command shows
"Status: Provisioned, Down, Active". It appears that Asterisk is not
recovering from the errors.
Restarting Asterisk will not bring the PRI back up -- that requires
the
zaptel drivers to be unloaded and reloaded.
Why is this happening and what can be done about it?
-
|
What are the Telco techs seeing? I my experience (in the UK at least)
it is always
worth having a chat with them to see how a PRI problem looks from
their end.
At a guess (and an un-informed one at that) I'd say that they are
waiting to
see the line cycle completely before attempting to recover from the
red alarm.
Reloading the zaptel drivers does something pretty low level (drops
then brings back the carrier?) which they see and respond to.
We had one (failover) circuit which was configured to only recover when
physically unplugged!
Tim. |
|