Gary Franczyk
2004-Jun-03 06:43 UTC
[Asterisk-Users] Problem with T1 PRI line resetting/dropping calls.
I am having a serious problem with my Asterisk system. Every few days, my PRI line resets and drops all calls. I get these errors in the messages log: Jun 3 02:41:11 WARNING[11276]: PRI: Read on 39 failed: Unknown error 500 Jun 3 02:41:11 NOTICE[11276]: PRI got event: 6 on span 1 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 1: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 1 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 2: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 2 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 3: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 3 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 4: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 4 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 5: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 5 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 6: Red Alarm and so on... Jun 3 02:41:11 WARNING[11276]: PRI: Read on 39 failed: Unknown error 500 Jun 3 02:41:11 NOTICE[11276]: PRI got event: 4 on span 1 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 1 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 2 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 3 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 4 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 5 and so on... I just noticed it the other day, but it seems like it may have been happening since I installed the software and brought the system on line several months ago. I have upgraded to the latest stable release as of 6/1/2004. The system is a Dell 1650 running RedHat 7.3 (running the single processor kernel). I am running a single PRI T1 line into a T400P (tor2) card. Sprint provides the line timing and my zaptel.conf is as follows: loadzone = us defaultzone=us span=1,1,0,esf,b8zs bchan=1-23 dchan=24 The zapata.conf is as follows: [channels] context=default switchtype=national rxwink=300 ; Atlas seems to use long (250ms) winks usecallerid=yes hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=yes rxgain=10.0 txgain=3.0 group=1 callgroup=1 pickupgroup=1 immediate=no signalling = pri_cpe relaxdtmf=yes channel => 1-23 Asterisk seems to run perfectly otherwise. Can someone guide me to figure out what is causing this? Let me know if I need to provide any other information. Thanks Gary F.
Gary Franczyk
2004-Jun-04 10:09 UTC
[Asterisk-Users] Problem with T1 PRI line resetting/dropping calls.
I am having a serious problem with my Asterisk system. Every few days, my PRI line resets and drops all calls. I get these errors in the messages log: Jun 3 02:41:11 WARNING[11276]: PRI: Read on 39 failed: Unknown error 500 Jun 3 02:41:11 NOTICE[11276]: PRI got event: 6 on span 1 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 1: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 1 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 2: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 2 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 3: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 3 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 4: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 4 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 5: Red Alarm Jun 3 02:41:11 WARNING[12301]: Unable to disable echo cancellation on channel 5 Jun 3 02:41:11 WARNING[12301]: Detected alarm on channel 6: Red Alarm and so on... Jun 3 02:41:11 WARNING[11276]: PRI: Read on 39 failed: Unknown error 500 Jun 3 02:41:11 NOTICE[11276]: PRI got event: 4 on span 1 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 1 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 2 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 3 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 4 Jun 3 02:41:16 NOTICE[12301]: Alarm cleared on channel 5 and so on... I just noticed it the other day, but it seems like it may have been happening since I installed the software and brought the system on line several months ago. I have upgraded to the latest stable release as of 6/1/2004. The system is a Dell 1650 running RedHat 7.3 (running the single processor kernel). I am running a single PRI T1 line into a T400P (tor2) card. Sprint provides the line timing and my zaptel.conf is as follows: loadzone = us defaultzone=us span=1,1,0,esf,b8zs bchan=1-23 dchan=24 The zapata.conf is as follows: [channels] context=default switchtype=national rxwink=300 ; Atlas seems to use long (250ms) winks usecallerid=yes hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=yes rxgain=10.0 txgain=3.0 group=1 callgroup=1 pickupgroup=1 immediate=no signalling = pri_cpe relaxdtmf=yes channel => 1-23 Asterisk seems to run perfectly otherwise. Can someone guide me to figure out what is causing this? Let me know if I need to provide any other information. Thanks Gary F.
Steven Critchfield
2004-Jun-09 08:17 UTC
[Asterisk-Users] Problem with T1 PRI line resetting/dropping calls.
On Wed, 2004-06-09 at 08:38, Andrew Kohlsmith wrote:> On Monday 07 June 2004 09:09, Steven Critchfield wrote: > > So once again, have you verified with zttool where the card is getting > > its timing from? If it says internal, or any non PSTN connected span, > > you will have found the error. and will need to power off the machine, > > not just reboot it. > > Will that give you red alarms though? Clock slips, sure, but RA?If it slips enough it will loose sync and you will get a red alarm -- Steven Critchfield <critch@basesys.com>