[asterisk-users] PRI dropping #2

[Harry Vangberg]

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:

== /etc/zaptel.conf
loadzone=dk
defaultzone=dk

span=1,1,0,css,hdb3,crc4
bchan=1-15
dchan=16
bchan=17-31
==

== /etc/asterisk/zapata.conf
[channels]
switchtype=euroisdn
usecallerid=yes

group=1
signalling=pri_cpe
context=incoming
channel=>1-15
channel=>17-31
==

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!  Using 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  Link 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_ESTABLISHED
q931.c:2755 q931_restart: call 32768 on channel 1 enters state 62 (Restart)
> Protocol Discriminator: Q.931 (8)  len=13
> Call Ref: len= 2 (reference 0/0x0) (Originator)
> Message type: RESTART (70)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 1 ]
> [79 01 80]
> Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated Channel (0) ]
< Protocol Discriminator: Q.931 (8)  len=13
< Call Ref: len= 2 (reference 0/0x0) (Terminator)
< Message type: RESTART ACKNOWLEDGE (78)
< [18 03 a1 83 81]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0
Preferred  Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 1 ]
< [79 01 80]
< Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated
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 (Restart)
> Protocol Discriminator: Q.931 (8)  len=13
> Call Ref: len= 2 (reference 0/0x0) (Originator)
> Message type: RESTART (70)
> [18 03 a9 83 82]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 2 ]
> [79 01 80]
> Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated Channel (0) ]
< Protocol Discriminator: Q.931 (8)  len=13
< Call Ref: len= 2 (reference 0/0x0) (Terminator)
< Message type: RESTART ACKNOWLEDGE (78)
< [18 03 a1 83 82]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0
Preferred  Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 2 ]
< [79 01 80]
< Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated
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.