No subject

"RED: Loss of signal (LOS): The equipment shall assume "loss of
signal" when the incoming signal amplitude is, for a time duration of
at least 1 ms, more than 20 dB below the nominal amplitude. The
equipment shall react within 12 ms by issuing AIS."

This sounds like what is happening, and is in order with what one of
the technicians said - I was about 20 dB below their amplitude, theirs
being 2048. Does this make *any* sense?

2009/3/26 Harry Vangberg <harry at vangberg.name>:
> Hey,
>
> I wrote yesterday about PRI dropping, which turned out to just be a
> regular reset of unused B-channels. This time there's a real issue. As
> noted earlier I have an ISDN-30 connection, a Digium TE-121 with
> VPMADT032 echo cancellation. These are my configurations files:
>
> =3D=3D /etc/zaptel.conf
> loadzone=3Ddk
> defaultzone=3Ddk
>
> span=3D1,1,0,css,hdb3,crc4
> bchan=3D1-15
> dchan=3D16
> bchan=3D17-31
> =3D=3D
>
> =3D=3D /etc/asterisk/zapata.conf
> [channels]
> switchtype=3Deuroisdn
> usecallerid=3Dyes
>
> group=3D1
> signalling=3Dpri_cpe
> context=3Dincoming
> channel=3D>1-15
> channel=3D>17-31
> =3D=3D
>
> The Asterisk console has this (repeating for every channel):
>
> [Mar 26 18:39:19] WARNING[3772]: chan_zap.c:6685 handle_init_event:
> Detected alarm on channel 1: Red Alarm
> [Mar 26 18:39:19] WARNING[3772]: chan_zap.c:1471 zt_disable_ec: Unable
> to disable echo cancellation on channel 1
> [Mar 26 18:39:19] WARNING[3772]: chan_zap.c:6685 handle_init_event:
> Detected alarm on channel 2: Red Alarm
> [Mar 26 18:39:19] WARNING[3772]: chan_zap.c:1471 zt_disable_ec: Unable
> to disable echo cancellation on channel 2
> ...
> ...
> [Mar 26 18:39:19] NOTICE[3771]: chan_zap.c:8486 pri_dchannel: PRI got
> event: Alarm (4) on Primary D-channel of span 1
> [Mar 26 18:39:19] WARNING[3771]: chan_zap.c:2401 pri_find_dchan: No
> D-channels available! =A0Using Primary channel 16 as D-channel anyway!
> [Mar 26 18:39:24] NOTICE[3771]: chan_zap.c:8486 pri_dchannel: PRI got
> event: No more alarm (5) on Primary D-channel of span 1
> [Mar 26 18:39:24] NOTICE[3772]: chan_zap.c:6678 handle_init_event:
> Alarm cleared on channel 1
> [Mar 26 18:39:24] NOTICE[3772]: chan_zap.c:6678 handle_init_event:
> Alarm cleared on channel 2
> ...
> ...
>
> See the full output at http://sprunge.us/cdFf
>
> I enabled PRI debugging for span 1, which gives this:
>
> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
> Sending Set Asynchronous Balanced Mode Extended
> q921.c:150 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH
> -- Got UA from network peer =A0Link up.
> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTAB=
LISHED
> q931.c:2755 q931_restart: call 32768 on channel 1 enters state 62 (Restar=
t)
>> Protocol Discriminator: Q.931 (8) =A0len=3D13
>> Call Ref: len=3D 2 (reference 0/0x0) (Originator)
>> Message type: RESTART (70)
>> [18 03 a9 83 81]
>> Channel ID (len=3D 5) [ Ext: 1 =A0IntID: Implicit =A0PRI =A0Spare: 0 =A0=
Exclusive =A0Dchan: 0
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ChanSel: Reserved
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Coding: 0 =A0Numbe=
r Specified =A0Channel Type: 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Channel: 1 ]
>> [79 01 80]
>> Restart Indentifier (len=3D 3) [ Ext: 1 =A0Spare: 0 =A0Resetting Indicat=
ed Channel (0) ]
> < Protocol Discriminator: Q.931 (8) =A0len=3D13
> < Call Ref: len=3D 2 (reference 0/0x0) (Terminator)
> < Message type: RESTART ACKNOWLEDGE (78)
> < [18 03 a1 83 81]
> < Channel ID (len=3D 5) [ Ext: 1 =A0IntID: Implicit =A0PRI =A0Spare: 0
> Preferred =A0Dchan: 0
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ChanSel: Reserved
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Coding: 0 =A0Numb=
er Specified =A0Channel Type: 3
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Channel: 1 ]
> < [79 01 80]
> < Restart Indentifier (len=3D 3) [ Ext: 1 =A0Spare: 0 =A0Resetting Indica=
ted
> Channel (0) ]
> -- Processing IE 24 (cs0, Channel Identification)
> -- Processing IE 121 (cs0, Restart Indicator)
> q931.c:3581 q931_receive: call 32768 on channel 1 enters state 0 (Null)
> q931.c:2755 q931_restart: call 32768 on channel 2 enters state 62 (Restar=
t)
>> Protocol Discriminator: Q.931 (8) =A0len=3D13
>> Call Ref: len=3D 2 (reference 0/0x0) (Originator)
>> Message type: RESTART (70)
>> [18 03 a9 83 82]
>> Channel ID (len=3D 5) [ Ext: 1 =A0IntID: Implicit =A0PRI =A0Spare: 0 =A0=
Exclusive =A0Dchan: 0
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ChanSel: Reserved
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Coding: 0 =A0Numbe=
r Specified =A0Channel Type: 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Channel: 2 ]
>> [79 01 80]
>> Restart Indentifier (len=3D 3) [ Ext: 1 =A0Spare: 0 =A0Resetting Indicat=
ed Channel (0) ]
> < Protocol Discriminator: Q.931 (8) =A0len=3D13
> < Call Ref: len=3D 2 (reference 0/0x0) (Terminator)
> < Message type: RESTART ACKNOWLEDGE (78)
> < [18 03 a1 83 82]
> < Channel ID (len=3D 5) [ Ext: 1 =A0IntID: Implicit =A0PRI =A0Spare: 0
> Preferred =A0Dchan: 0
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ChanSel: Reserved
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Coding: 0 =A0Numb=
er Specified =A0Channel Type: 3
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ext: 1 =A0Channel: 2 ]
> < [79 01 80]
> < Restart Indentifier (len=3D 3) [ Ext: 1 =A0Spare: 0 =A0Resetting Indica=
ted
> Channel (0) ]
> -- Processing IE 24 (cs0, Channel Identification)
> -- Processing IE 121 (cs0, Restart Indicator)
>
> Again, full output at http://sprunge.us/EcTA
>
> I even tried swapping the card with a spare TE121 I have. Exactly same
> error, so I don't think it's an hardware issue. I also have had two
> different telco guys out, both said the connection was fine, but one
> mentioned something about me being out of 'stroke'/sync - they're
> running at a 2048Mb frequency, I was some 20 below. He didn't explain
> too good.
>
> Any help appreciated.
>