They didn't show up in the list archive. I'm terribly sorry. 2009/3/26 Steve Howes <st...@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 <ha...@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 >
_______________________________________________ -- 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