summaryrefslogtreecommitdiff
path: root/LICENSE
diff options
context:
space:
mode:
authorTzafrir Cohen <tzafrir.cohen@xorcom.com>2011-02-08 13:09:45 +0000
committerTzafrir Cohen <tzafrir.cohen@xorcom.com>2011-02-08 13:09:45 +0000
commitccd1008682a4b08876b5dfb28452caa395faa139 (patch)
treed80e9638718e093773c5835bef1b371849f30dc3 /LICENSE
parent477475fc00afb81e04a531646cb21b15b8553a03 (diff)
Fixed up the loss of crc4-multiframe alignment logic
Loss of crc4-multiframe alignment on an E1 link is not a condition which brings the span down. The span will continue to run as long as it can maintain double frame alignment. Because of this, we cannot place the LMFA alarm in the usual spaninfo.alarms member, due to userspace programs using this as a catch-all for a span being up or down. We can detect the alarm by watching the frame error counter (fecount). If it continuously increments, the span is configured for crc4, and the span remains OK (alarms = 0), then we are in loss of crc4-multiframe state. In order to test this alarm, you'll need to synthesize a loss of crc4 alignment on the span. You can usually do this by configuring the local span to use crc4 and the remote end to not use crc4. I used the Fireberd 6000 in my lab to do this. dahdi-743 & dahdi-420 Acked-by: Shaun Ruffell <sruffell@digium.com> Merged revisions 9458 via svnmerge from http://svn.digium.com/svn/dahdi/tools/trunk git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/branches/2.4@9738 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Diffstat (limited to 'LICENSE')
0 files changed, 0 insertions, 0 deletions