George Pajari
2008-Jan-29 11:08 UTC
[asterisk-users] 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)
Tim Panton
2008-Jan-29 12:17 UTC
[asterisk-users] PRI Alarms, Comes Back, But Asterisk Won't Touch It!
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.