Detected alarm on channel 2: Red Alarm

Asterisk Asterisk Support
1

Three to five times an hour both of my two POTS lines generate this “Red Alarm”. I am also getting complaints of calls being dropped a few seconds after starting. This system is new and these may not be related. This system is an IVR and gets about 40 calls per hour. While the system is new it is a copy of server that has been running for months. Any idea if these are related? What steps should I take to troubleshoot either problem?

/var/log/asterisk/messages

[Nov 20 10:20:10] WARNING[2380] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
[Nov 20 10:20:11] NOTICE[2380] sig_analog.c: Alarm cleared on channel 1
[Nov 20 10:37:10] WARNING[2380] chan_dahdi.c: Detected alarm on channel 2: Red Alarm
[Nov 20 10:37:11] NOTICE[2380] sig_analog.c: Alarm cleared on channel 2
[Nov 20 10:50:28] WARNING[2380] chan_dahdi.c: Detected alarm on channel 2: Red Alarm
[Nov 20 10:50:29] NOTICE[2380] sig_analog.c: Alarm cleared on channel 2
[Nov 20 10:55:00] WARNING[2380] chan_dahdi.c: Detected alarm on channel 2: Red Alarm
[Nov 20 10:55:01] NOTICE[2380] sig_analog.c: Alarm cleared on channel 2
[Nov 20 11:12:14] WARNING[2380] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
[Nov 20 11:12:15] NOTICE[2380] sig_analog.c: Alarm cleared on channel 1
[Nov 20 11:29:40] WARNING[2380] chan_dahdi.c: Detected alarm on channel 2: Red Alarm
[Nov 20 11:29:41] NOTICE[2380] sig_analog.c: Alarm cleared on channel 2
[Nov 20 11:33:03] WARNING[2380] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
[Nov 20 11:33:04] NOTICE[2380] sig_analog.c: Alarm cleared on channel 1

Software:
CentOS release 6.3 (Final) - Linux version 2.6.32-279.5.2.el6.x86_64
dahdi-linux-complete-2.6.1+2.6.1 complied from source
asterisk-1.8.15.1 complied from source

Hardware:
07:01.0 Ethernet controller: Digium, Inc. Wildcard TDM410 4-port analog card (rev 11)

/etc/asterisk/chan_dahdi.conf

[trunkgroups]

[channels]

#include /etc/asterisk/dahdi-channels.conf
usecallerid=yes
callwaiting=no
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=no
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1

/etc/dahdi/system.conf

Span 1: WCTDM/0 “Wildcard TDM410P” (MASTER)

fxsks=1
echocanceller=mg2,1
fxsks=2
echocanceller=mg2,2
fxsks=3
echocanceller=mg2,3
fxsks=4
echocanceller=mg2,4

Global data

loadzone = us
defaultzone = us

DAHDI Tools Version - 2.6.1

DAHDI Version: 2.6.1
Echo Canceller(s): HWEC
Configuration

4 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2
Setting echocan for channel 4 to mg2

Span 1: WCTDM/0 “Wildcard TDM410P” (MASTER)

       1 WCTDM/0/0 FXSKS (In use) (EC: VPMOCT032 - ACTIVE) 
       2 WCTDM/0/1 FXSKS (In use) (EC: VPMOCT032 - ACTIVE) 
       3 WCTDM/0/2 FXSKS (In use) RED (EC: VPMOCT032 - INACTIVE) 
       4 WCTDM/0/3 FXSKS (In use) RED (EC: VPMOCT032 - INACTIVE)
2

anyone?

3

Why don’t you qualify for commercial support from Digium? If available, that is your best option.

4

Hi A red alarm on a alog trunk is usually down to wiring as it means the line disconnected.
could be interrupts what does Dahditest show., check the wiring, get the line tested by the PTO and try moving the card to another slot if possible

5

First, I agree that you should contact Digium’s support since they are in a position to work with you to quickly collect the information needed to trouble shoot.

That being said, I’ll second what ianplain said and check your wiring. The RED alarm on an analog port is generated when the driver detects a loss of voltage on the line for an extended period of time, which normally means that the port has been disconnected from the provider or the cable has an intermittent short somewhere. Also, it’s most likely this is the reasons for your dropped calls.