[asterisk-users] PRI Alarms, Comes Back, But Asterisk Won't Touch It!

[Tim Panton]

On 29 Jan 2008, at 11:08, George Pajari wrote:

> 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.