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)?
[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
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.
[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.
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.
[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
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.