asterisk users - Aug 2005 - TE110P flashing red/green when PRI connected ... continued

Perhaps everything isn't as spiffy as I thought

When running zttool the card still reports as internally clocked

Zaptel.conf:
# Global data
span=1,1,0,ccs,hdb3,crc4
bchan=1-15
dchan=16
bchan=17-31

loadzone=se
defaultzone=se

And as pointed out by Peter I do get a lot of D-channel warnings ...
Aug 9 16:21:25 NOTICE[1350]: PRI got event: HDLC Bad FCS (8) on Primary
D-channel of span 1

And furthermore, now I've discovered that all channels seem to reboot from
time to time
Aug 9 16:15:18 VERBOSE[1350]: -- B-channel 0/1 successfully restarted on span 1
...


Could this be a HW problem with either the wiring, the PC or something else?


-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Peter Svensson
Sent: den 9 augusti 2005 14:11
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] TE110P flashing red/green when PRI connected

On Tue, 9 Aug 2005, Andrew Kohlsmith wrote:
> On Tuesday 09 August 2005 04:32, Peter Svensson wrote:
> > A bitstream is present at the receiver, though it is unframed and 
> > invalid (i.e. the receiver is seeing a transmitter that does not 
> > quite know what to transmit). This is different from a red alarm 
> > where there is no bitstream at all.
> 
> I thought that red alarm was when it wasn't receiving a properly 
> framed signal, and it sent an unframed all-1s pattern to the far end.  
> Yellow alarm was when it was seeing an unframed all-1s pattern and was 
> then trying to send a properly framed signal to the far side?
I believe you are correct regarding the red alarm. Red alarm is declared when a
frame loss has persisted for more than 2.5s. It is a local alarm.
A framing error is a neccesary consequence of a LOS. :-)

Yellow alarm (Remote Alarm Indication) is sent when a frame error condition
exists in the receiver. On a T1 it is sent in bit 2 of every frame (for D4) or
through a pattern in ESF. For an E1 two separate errors indications are
collectivly known as yellow alarm, loss of framing (sets the A bit) or loss of
multiframeing (sets the Y bit).

Blue alarm (Alarm Indication Signal) is sent when the remote end does not want
to communicate. It is sent as unframed 1.
> I seem to remember blue and yellow alarm being the same thing bu tit's 
> 6am here and the mind is very much foggy.  :-)
Blue alarm - the other end is either administrativly down or there is a
disconnect between various layers somewhere along the receive path.

Peter


_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

On Tue, 9 Aug 2005, Fredrik Lith?n wrote:
> Perhaps everything isn't as spiffy as I thought
> 
> When running zttool the card still reports as internally clocked
> 
> Zaptel.conf:
> # Global data
> span=1,1,0,ccs,hdb3,crc4
> bchan=1-15
> dchan=16
> bchan=17-31
Zttool still shows the card as internally clocked and you have a working
connection at the same time? The only explaination I can come up with is 
that the changes to zaptel.conf have not taken effect. There have been a 
lot of talk about ztcfg requireing a full power cycle for come changes. 

It should not be possible for your card to be internally clocked given the 
above configuration. 
> And as pointed out by Peter I do get a lot of D-channel warnings ...
> Aug 9 16:21:25 NOTICE[1350]: PRI got event: HDLC Bad FCS (8) on Primary
D-channel of span 1
This can be related to bit slips. Another possibility is missed 
interrupts. These can be checked in /proc/zaptel/1.
> And furthermore, now I've discovered that all channels seem to reboot
from time to time
> Aug 9 16:15:18 VERBOSE[1350]: -- B-channel 0/1 successfully restarted on
span 1 ...
> 
> Could this be a HW problem with either the wiring, the PC or something
else?
Asterisk will reset unused channels once an hour by default. This is 
intended to keep channel state mismatches between the two endpoints from 
persisting indefinitly. The is harmless most of the time. 

Some equipment does not like these resets and there is some disagreement
whether it is fully within the specification to send these automatically.
The interval can be changed or the feature disabled with the
"resetinterval" option in zapata.conf. We have a pbx that resets the
whole
E1 span in response to these requests, including active channels, so we 
have had to disable these resets.

The resets will also be performed if the isdn signalling has been down on 
a span. If you get slips or irq misses bad enough this is a possibility.

Peter