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

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?

-- 
George Pajari (dCAP), netVOICE communications 604 484 VOIP(8647) x102
   www.netvoice.ca  www.ip-centrex.ca  www.ip-pbx.ca  www.vpas.ca
     www.digium.ca www.grandstream.ca www.sipura.ca www.snom.ca
Open Source VoIP/Telephony Specialists  1 877 NET VOIP (638 8647 x102)

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.