[asterisk-users] PRI dropping #2

Thu Mar 26 16:55:49 CDT 2009

They didn't show up in the list archive. I'm terribly sorry.

2009/3/26 Steve Howes <steve at geekinter.net>:
> The first and second times were sufficient.
>
> On 26 Mar 2009, at 19:24, Harry Vangberg wrote:
>
>> Okay. Trying third time, sorry for that, might just be my mail client,
>> anyways, from voip-info.org:
>>
>> "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:
>>>
>>> == /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.
>>>
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>