Pleas HELP - PRI random fail with TE110P

elastix 0.9.2
libpri - 1.4.0 Release 1.9
asterisk - 1.4.15 Release 4
zaptel 1.4.6 Release 3
with TE110P

I dont know from where to start in order to debug the problem
Hot telcom (Israel) had errors on the PRI
the claim to fixed it and eve showed it with a SUNRISE tester
but the line still fails randomly
even if they restaring Layer 1 the line wont come up until I rest asterisk

heres a shrot debug if thats any help

[ 00 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter

< [ 02 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Got RR response to our frame
– Restarting T203 counter

< [ 00 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (44)

[ 02 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter
– Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (44)

[ 00 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter

< [ 02 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Got RR response to our frame
– Restarting T203 counter

< [ 00 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (44)

[ 02 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter
– Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (44)

[ 00 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter

< [ 02 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Got RR response to our frame
– Restarting T203 counter

< [ 00 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (44)

[ 02 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (44)

[ 00 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter

< [ 02 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Got RR response to our frame
– Restarting T203 counter

< [ 00 01 01 55 ]
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (44)

[ 02 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter
– Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (44)

[ 00 01 01 59 ]
Supervisory frame:
SAPI: 00 C/R: 0 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter

< [ 02 01 01 55 ]

< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Got RR response to our frame
– Restarting T203 counter

< [ 00 01 01 55 ]

< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N®: 042 P/F: 1
< 0 bytes of data
– ACKing all packets from 41 to (but not including) 42
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (44)

[ 02 01 01 59 ]

Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N®: 044 P/F: 1
0 bytes of data
– Restarting T203 counter
– Restarting T203 counter

Pri debugs nice , But what does your zaptel.conf and zapata.conf looklike. also what alarms are you getting in the logs ?

Ian

zaptel.conf

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 “Digium Wildcard TE110P T1/E1 Card 0”

span=1,1,1,ccs,hdb3

termtype: te

bchan=1-15,17-31
dchan=16

Global data

loadzone = us
defaultzone = us


zapata.conf

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
priindication=outoffband
resetinterval=300

immediate=no

;Sangoma A102 port 1 [slot:2 bus:3 span:1]
switchtype=euroisdn
context=from-pstn
group=0
signalling=pri_cpe
channel =>1-15,17-31
;pritimer => t200,1000
;pritimer => t203,30000
;pritimer => t305,30000
;pritimer => t308,4000
;pritimer => t309,90000
;pritimer => t313,4000

; Including file containing the suggested configuration
; generated by the hardware detector tool
; Remove this line if you don’t want this feature
#include zapata-channels.conf;

I dont know how to check the alarms If you may direct me or I would google it

Hi

Change resetinterval=300
to resetinterval=never

having this at 300 will not be making them at the exchange very happy

Ian

[quote=“ianplain”]Hi

Change resetinterval=300
to resetinterval=never

having this at 300 will not be making them at the exchange very happy

Ian[/quote]

after making me miserable for the last week I will change it to
restinterval=0.000000001 :imp:

if thats what will make then unhappy
they configured the SDH to give a clock to my PRI
every 3.5 hours the D-chan simlpy disapperd
I tought if I’ll reset it every 5 minits it will keep it alaive
regards ,

Seeing a reset every 5 mins will in some cases cause the exchange to take you circuit out of service.

If you are loosing clock then you have a timing issue. out of interest what does zttest show ?
Ian

[quote=“ianplain”]Seeing a reset every 5 mins will in some cases cause the exchange to take you circuit out of service.

If you are loosing clock then you have a timing issue. out of interest what does zttest show ?
Ian[/quote]

Dear Ian
Pleas take a GOOD look at the PRI debug , the main reason I post it is because I’m not sure its normal !!!
pay attention to the fact that my asterisk is sending the same ACK meny times

[color=red]" – ACKing all packets from 41 to (but not including) 42 "[/color]

Is that normal ? :unamused:

The zttest shows a resault of 99.97 % the last time I checked it ,
but I will check it again since HOT Telecom change the source of the clock from the SDH to the Media Gateway and installed a new SDH transmision 1 meter from my ASTERISK thinking that maybe because it was 3 floors under in the basment , somthing inserts elctro magnetic interference to the copper line

regard ,

[quote=“ianplain”]Seeing a reset every 5 mins will in some cases cause the exchange to take you circuit out of service.

If you are loosing clock then you have a timing issue. out of interest what does zttest show ?
Ian[/quote]

[user@xxxxxxx ~]# zttest
Opened pseudo zap interface, measuring accuracy…
99.997459% 99.995308% 99.995399% 99.995995% 99.996193% 99.995995% 99.997650%
99.994820% 99.993652% 99.996292% 99.996094% 99.997849% 99.994919% 99.995216%
— Results after 14 passes —
Best: 99.998 – Worst: 99.994 – Average: 99.995917, Difference: 99.995917

any ideas ??? :unamused:

Is any other hardware on the server using the same IRQ? If so move the card or disable the other hardware if possible so that only the digium card is on that IRQ.

Howdy,

Please contact Digium support directly about your case.
support@digium.com

Cheers.