[asterisk-bugs] [DAHDI-linux 0014429]: "Yellow" (RAI) alarm generation for E1 broken when in CRC4 mode

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14429 
====================================================================== 
Reported By:                gknispel_proformatique
Assigned To:                russell
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   14429
Category:                   wcte12xp
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     closed
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-02-07 19:10 CST
Last Modified:              2009-06-26 15:01 CDT
====================================================================== 
Summary:                    "Yellow" (RAI) alarm generation for E1 broken when
in CRC4 mode
Description: 
Under some conditions the RAI generation is broken when CRC4 is activated.

When this happens the generated alarm indication is periodically pulsed
high during something like few hundreds of ms with a period that I have not
been able to measure precisely but which is around one or few seconds. In
other cases the RAI is not generated at all while it should.

What should happen is a continuous emission of RAI.

(BTW, completely unrelated issue; the way Dahdi handles alarms has
absolutely nothing to do with ITU-T or ETSI specifications, but I guess
most people don't care, although this could probably be troublesome for
homologation if still necessary in some areas)

----

Sufficient steps to trigger the problem, but I don't know whether they are
necessary:

1. Cold boot a system containing a disconnected Wildcard TE122 configured
like that:
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
dchan=16

(and load the module and start the span with dahdi_cfg)

2. Connect it to a started compliant E1 interface configured like that:
span=1,0,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

3. The TE122 in CRC4 mode switch between BLUE RECOVERY alarm and RECOVERY
alone around twice per second, and correctly continuously maintain the RAI
high.

4. The TE122 in CRC4 mode continues to behave correctly even when
disconnecting and reconnecting the interface once or multiple times,
regardless of how fast it is disconnected and reconnected.

5. dahdi_cfg multiple times (quickly) while observing the status of the
received RAI on the other system, until it stops to be continuous.

6. The RAI should now be (incorrectly) pulsed (or maybe completely
absent).

7. The TE122 in CRC4 mode will now continue to behave incorrectly when
connected to a non CRC4 E1, either pulsing or not generating the RAI at all
when it should be continuously generated. Disconnecting and reconnecting
the cable does not help.

8. Connecting the TE122 in CRC4 mode to an E1 also in CRC4 mode make it
works correctly again: once the alarms have disappeared, reconnecting to a
non CRC4 line correctly result in continuous generation of RAI (we are now
back in step 3...)

====================================================================== 

---------------------------------------------------------------------- 
 (0107045) russell (administrator) - 2009-06-26 15:01
 https://issues.asterisk.org/view.php?id=14429#c107045 
---------------------------------------------------------------------- 
Please report this issue to Digium technical support.

That way, it can be reported and prioritized internally and get the
attention of the appropriate people.

Thank you! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-26 15:01 russell        Note Added: 0107045                          
2009-06-26 15:01 russell        Status                   new => resolved     
2009-06-26 15:01 russell        Resolution               open => suspended   
2009-06-26 15:01 russell        Assigned To               => russell         
2009-06-26 15:01 russell        Status                   resolved => closed  
======================================================================