[asterisk-users] PRI dropping #2

Thu Mar 26 16:06:44 CDT 2009

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