[Asterisk-Dev] Getting ISDN line restart problem with TE110P

Nahid Hossain nahid at stitel.com
Tue Aug 2 02:14:00 MST 2005


Hello, 

Here are my observations / Report on what I see about the new Digium 
TE110P Card. 

- Recently we switched to the new TE110P card in replacement of the old 
E110P Interface. 

- Unlike previous times with the old E110P, this time we are seeing 
some Random Problems with the new Digium card as describe in the following 
report: 

- We have two sites where the problem show up involving the following 
equipment: 

      1.- Asterisk/Digium to Nortel Option-11 Switch with 620 users 
and 
      2.- Asterisk / Digium to Cirilium Euro-ISDN-PRI Analog/Digital 
Gateway/Call Manager 

- In both cases, after Power Up, we observe that PCM signal comes up 
very 
clean and Layer 2 and 3 start-up nicely as expected with the following 
characteristics: 

      Customer Site (Nortel)                Digium 

      L1 Clock= Slave                        Master 
      CRC = Enabled both sides 
      HDB3 = Enabled both sides 

      L2 = User                                  Network 

      L3 = Euro ISDN=PRI-E1 both sides....Channels: 0=Sync   1-15 
Bearer 
16= D channel    17-31= Bearer 

- We notice that Layer 1 (L1) stays up very clean for several hours 
before 
the proble shows up. 

- Layer 2 initializes correctly with a sequence like this: 

  SABME--> 
                  <---UA 
      RR---> 
                  <---RR 
      RR---> 
                  <---RR 
      RR---> 
                  <---RR 
And stays like that for a long time. Actually we don't see it to fail 
at all 

- At some point, we see that unexpectedly, Digium sends a Burst of CRC 
errors and then in returns to normal. This happens for about 2 seconds 
and 
it is short enouth to the point where Layers 2 and 3 stay up without 
noticing the media failure (Note we are using only certified Factory 
Made 
Cables...So wiring errors are discarded) 

If we restart manually our Euro-ISDN interface,  Layer 3 starts with a 
standard RESTART / RESTART ACK  Sequence including all 30 BEARER 
channels 
exchanged between both devices.. 

HOWEVER, at some point (usually after a few hours after restart), we 
see the 
following  two phenomenon: 

1.- All of a sudden, at Level 1, Digium sends a Burst of CRC and Frame 
Check 
Sequences (FCS) errors for about 2-3 seconds towards the Customer 
Premises. 
Please notice that Layer 2 ( In state RR >,,< RR) stay Up and L3 stay 
also 
Up. 

2.- In several other occasions (about 50% of the time), we notice that 
Digium, Unexpectedly Starts sending L3 Restarts (Restart-->  <--Restart 
Ack) 
for all 30 channels and at the Same time, Layer 1 sends a burst of 
Errors 
(CRC's and FCS's). This is the most worring situation because it 
trashes all 
calls. 

At the same time, the /var/log/asterisk/messages log, reports: 
Jun 24 04:44:58 NOTICE[7449]: PRI got event: HDLC Abort (6) on Primary 
D-channel of span 1 
Jun 24 04:44:58 DEBUG[7449]: Got event HDLC Abort (6) on D-channel for 
span 
1 
Jun 24 04:56:19 NOTICE[7449]: PRI got event: HDLC Bad FCS (8) on 
Primary 
D-channel of span 1 
Jun 24 04:56:19 DEBUG[7449]: Got event HDLC Bad FCS (8) on D-channel 
for 
span 1 
Jun 24 05:08:39 NOTICE[7449]: PRI got event: HDLC Bad FCS (8) on 
Primary 
D-channel of span 1 
Jun 24 05:08:39 DEBUG[7449]: Got event HDLC Bad FCS (8) on D-channel 
for 
span 1 

3.- Also, in about 20% of the cases, we have observed that sometimes 
(about 
every 40 minutes), Digium totally removes for about 2-3 seconds PCM 
signal 
apparently shortly after Layer 3 collapses and restarts with the 
following 
information: 

Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/17 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/1 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/2 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/3 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/4 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/5 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/6 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/7 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/8 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/9 successfully 
restarted on 
span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/10 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/11 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/12 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/13 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/14 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/15 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/18 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/19 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/20 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/21 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/22 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/23 successfully 
restarted 
on span 1 
Jun 24 07:21:11 VERBOSE[301]:     -- B-channel 0/24 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/25 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/26 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/27 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/28 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/29 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/30 successfully 
restarted 
on span 1 
Jun 24 07:21:12 VERBOSE[301]:     -- B-channel 0/31 successfully 
restarted 
on span 1 
Jun 24 07:23:33 NOTICE[301]: PRI got event: HDLC Abort (6) on Primary 
D-channel of span 1 
Jun 24 07:56:03 NOTICE[301]: PRI got event: HDLC Abort (6) on Primary 
D-channel of span 1 

In all cases the Link recovers but active calls drop. 

I am using Asterisk-1.0.7, zaptel-1.0.7 , zapata-1.0.1 and libpri-1.0.7 

If you think, you need to access my Asterisk server, I can give you my
server's login information. 

I would appreciate for help. 

Regards 

Nahid

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050802/a8ec716d/attachment.htm


More information about the asterisk-dev mailing list