t120p Problems

My calls throught pstn hangup unexpectly
here’s my log :

[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 2: Red Alarm
[Sep 29 12:03:43] ERROR[19216] chan_zap.c: Write to 27 failed: Unknown error 500
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 2
[Sep 29 12:03:43] ERROR[19216] chan_zap.c: Short write: 0/15 (Unknown error 500)
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 3: Red Alarm
[Sep 29 12:03:43] WARNING[19216] chan_zap.c: Detected alarm on channel 1: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 3
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 4: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 4
[Sep 29 12:03:43] NOTICE[18824] chan_zap.c: PRI got event: Alarm (4) on Primary D-channel of span 1
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 5: Red Alarm
[Sep 29 12:03:43] DEBUG[19216] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/1-1
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 5
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 6: Red Alarm
[Sep 29 12:03:43] DEBUG[19216] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/1-1
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 6
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Hungup ‘Zap/1-1’
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 7: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 7
[Sep 29 12:03:43] VERBOSE[19216] logger.c: == Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on ‘SIP/210-0930f0e8’ in macro ‘dialout-trunk’
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 8: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 8
[Sep 29 12:03:43] VERBOSE[19216] logger.c: == Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on ‘SIP/210-0930f0e8’
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 9: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 9
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 10: Red Alarm
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [h@macro-dialout-trunk:1] Macro(“SIP/210-0930f0e8”, “hangupcall|”) in new stack
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 10
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 11: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 11
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:1] ResetCDR(“SIP/210-0930f0e8”, “w”) in new stack
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 12: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 12
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 13: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 13
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 14: Red Alarm
[Sep 29 12:03:43] WARNING[18824] chan_zap.c: No D-channels available! Using Primary channel 16 as D-channel anyway!
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 14
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Detected alarm on channel 15: Red Alarm
[Sep 29 12:03:43] WARNING[18825] chan_zap.c: Unable to disable echo cancellation on channel 15
[Sep 29 12:03:43] DEBUG[19216] app_macro.c: Executed application: ResetCDR
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:2] NoCDR(“SIP/210-0930f0e8”, “”) in new stack
[Sep 29 12:03:43] DEBUG[19216] app_macro.c: Executed application: NoCDR
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:3] GotoIf(“SIP/210-0930f0e8”, “1?skiprg”) in new stack
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Goto (macro-hangupcall,s,6)
[Sep 29 12:03:43] DEBUG[19216] app_macro.c: Executed application: GotoIf
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:6] GotoIf(“SIP/210-0930f0e8”, “1?skipblkvm”) in new stack
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Goto (macro-hangupcall,s,9)
[Sep 29 12:03:43] DEBUG[19216] app_macro.c: Executed application: GotoIf
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:9] GotoIf(“SIP/210-0930f0e8”, “1?theend”) in new stack
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Goto (macro-hangupcall,s,11)
[Sep 29 12:03:43] DEBUG[19216] app_macro.c: Executed application: GotoIf
[Sep 29 12:03:43] VERBOSE[19216] logger.c: – Executing [s@macro-hangupcall:11] Hangup(“SIP/210-0930f0e8”, “”) in new stack
[Sep 29 12:03:43] VERBOSE[19216] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/210-0930f0e8’ in macro ‘hangupcall’
[Sep 29 12:03:43] VERBOSE[19216] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/210-0930f0e8’
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 1
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 2
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 3
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 4
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 5
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 6
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 7
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 8
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 9
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 10
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 11
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 12
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 13
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 14
[Sep 29 12:03:48] NOTICE[18825] chan_zap.c: Alarm cleared on channel 15
[Sep 29 12:03:48] NOTICE[18824] chan_zap.c: PRI got event: No more alarm (5) on Primary D-channel of span 1
[Sep 29 12:03:48] VERBOSE[18824] logger.c: == Primary D-Channel on span 1 up

Your T1\E1 lost its connection (Red Alarm) and then it was restored by the end of the log. Does this happen on every call? If so there must be some configuration issue between you and the service provider causing the line to drop. If not, how often does it happen and are there any patterns that you can find (i.e. time of day, number dialed, server load etc)?

this is my zapata.conf
[trunkgroups]

[channels]
language=escol
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO Lines
;
;usedistinctiveringdetection=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=1.0
txgain=1.0

group=0
overlapdial=yes
switchtype=euroisdn
pridialplan=local
prilocaldialplan=local
signalling=pri_cpe
context=from-zaptel
channel=>1-15
;Include genzaptelconf configs
#include zapata-channels.conf
#include zapata-auto.conf
;Include AMP configs
#include zapata_additional.conf

i think alll is ok, when a call hangup inexpectly i can see zttool in recovery alarm (REC no RED) and it happens randomly, my E1 is from Peru. I realize when the call drops due lost connection it recover just after hangup, that’s why i saw in zttool REC alarm instead of RED.

what does your zaptel.conf look like?

this is my zaptel:

Autogenerated by /usr/sbin/genzaptelconf – do not hand edit

Zaptel Configuration File

This file is parsed by the Zaptel Configurator, ztcfg

It must be in the module loading order

Span 1: WCT1/0 “Wildcard TE120P Card 0” (MASTER)

span=1,1,0,ccs,hdb3
bchan=1-15
dchan=16

Span 2: ZTDUMMY/1 “ZTDUMMY/1 (source: Linux26) 1”

Global data

loadzone = fr
defaultzone = fr

Please contact Digium support regarding this.

support@digium.com
+12564286161

here is a new log

[Oct 1 22:53:32] DEBUG[4264]: chan_zap.c:9049 pri_dchannel: Queuing frame from PRI_EVENT_PROGRESS on channel 0/1 span 1
– Zap/1-1 is making progress passing it to SIP/210-b7d073a8
– Zap/1-1 answered SIP/210-b7d073a8
[Oct 1 22:53:35] ERROR[5578]: chan_zap.c:8249 zt_pri_error: Write to 27 failed: Unknown error 500
[Oct 1 22:53:35] ERROR[5578]: chan_zap.c:8249 zt_pri_error: Short write: 0/15 (Unknown error 500)
[Oct 1 22:53:35] WARNING[5578]: chan_zap.c:3848 zt_handle_event: Detected alarm on channel 1: Red Alarm
[Oct 1 22:53:35] NOTICE[4264]: chan_zap.c:8535 pri_dchannel: PRI got event: Alarm (4) on Primary D-channel of span 1
[Oct 1 22:53:35] WARNING[4264]: chan_zap.c:2402 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway!
[Oct 1 22:53:35] DEBUG[5578]: chan_zap.c:2973 zt_setoption: Set option AUDIO MODE, value: ON(1) on Zap/1-1
[Oct 1 22:53:35] DEBUG[5578]: chan_zap.c:2969 zt_setoption: Set option AUDIO MODE, value: OFF(0) on Zap/1-1
– Hungup 'Zap/1-1’s-Ayacucho*CLI>
== Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on ‘SIP/210-b7d073a8’ in macro ‘dialout-trunk’
== Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on ‘SIP/210-b7d073a8’
– Executing [h@macro-dialout-trunk:1] Macro(“SIP/210-b7d073a8”, “hangupcall|”) in new stack
– Executing [s@macro-hangupcall:1] ResetCDR(“SIP/210-b7d073a8”, “w”) in new stack
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:6723 handle_init_event: Detected alarm on channel 2: Red Alarm
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:1472 zt_disable_ec: Unable to disable echo cancellation on channel 2
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:6723 handle_init_event: Detected alarm on channel 3: Red Alarm
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:1472 zt_disable_ec: Unable to disable echo cancellation on channel 3
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:6723 handle_init_event: Detected alarm on channel 4: Red Alarm
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:1472 zt_disable_ec: Unable to disable echo cancellation on channel 4
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:6723 handle_init_event: Detected alarm on channel 5: Red Alarm
[Oct 1 22:53:35] WARNING[4265]: chan_zap.c:1472 zt_disable_ec: Unable to disable echo cancellation on channel 5

i realize that drop on the call is due this ERROR’s chan_zap.c:8249 zt_pri_error: Write to 27 failed: Unknown error 500 and zt_pri_error: Short write: 0/15 (Unknown error 500), but still dont know why this is happening ,. i reaaly need some help to solve this problems.

That error isn’t what causes the problem. That error is printed due to it going into alarm.

At the Linux CLI run the command ‘dmesg’ and post the last 20 lines of the output.

Ok Angler, tanhks for the correction , here is the dmesg:

IA-32 Microcode Update Driver v1.14 unregistered
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
Registered tone zone 2 (France)
wcte12xp: Span configured for CCS/HDB3
ip_tables: © 2000-2002 Netfilter core team
ip_tables: © 2000-2002 Netfilter core team
MSI INIT SUCCESS
wcte12xp: Setting yellow alarm
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
lp0: using parport0 (polling).
lp0: console ready
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0349440(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
eth0: no IPv6 routers present
wcte12xp: Span configured for CCS/HDB3
wcte12xp: Clearing yellow alarm
wcte12xp: Span configured for CCS/HDB3
wcte12xp: Setting yellow alarm
wcte12xp: Clearing yellow alarm
wcte12xp: Setting yellow alarm
wcte12xp: Clearing yellow alarm

Ok Angler, tanhks for the correction , here is the dmesg:

IA-32 Microcode Update Driver v1.14 unregistered
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
Registered tone zone 2 (France)
wcte12xp: Span configured for CCS/HDB3
ip_tables: © 2000-2002 Netfilter core team
ip_tables: © 2000-2002 Netfilter core team
MSI INIT SUCCESS
wcte12xp: Setting yellow alarm
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
lp0: using parport0 (polling).
lp0: console ready
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0349440(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
eth0: no IPv6 routers present
wcte12xp: Span configured for CCS/HDB3
wcte12xp: Clearing yellow alarm
wcte12xp: Span configured for CCS/HDB3
wcte12xp: Setting yellow alarm
wcte12xp: Clearing yellow alarm
wcte12xp: Setting yellow alarm
wcte12xp: Clearing yellow alarm

Ok that looks good. I was suspecting something but thats not occuring. This looks more like a problem with something external to the TE120P. How often does it go into alarm? Best thing to do confirm if it’s the TE120P or not is to put a loop back plug into the card and run a pattern test for some time to see if it goes into alarm. If the alarm happens every 30min for example, you would want to run the pattern test for about 45min.

Ok Angler i will test with the loppback plug, i already contact with Digium support, and they told me that i must to update to the latest zaptel and librpri, can you tell me please whats the correct way to do the upgrade.

Upgrading should just consist of downloading the ource of Zaptel, Libpri, and Asterisk and then compiling each and reloading the Zaptel modules and restarting Asterisk.

I did the test with ./patlooptest

[root@asterisk-LosLibertadores-Ayacucho zaptel-1.4.12.1]# ./patlooptest /dev/zap/1 1200
Using Timeout of 1200 Seconds
Going for it…
Timeout achieved Ending Program

And didn’t show me any error.

1200 seconds id only 20 minutes. as angler said you should run it much longer than the frquency that you get errors. Were you getting alarms every 10-15 minutes? If not run the test longer. If so then your provider needs to do more testing of the circuit.

i’m getting alarms every 2-5 minutos, so i suposs that time is enough, thx for help , i already contact with digium support and they told me to run teh auttosupport script, i already did it nad send the output.