Re: [asterisk-users] PRI dropping #2
This is kinda weird, but I did a fresh install of the box, upgraded from 1.4.18 to 1.4.24, replaced Zaptel with latest DAHDI. That kinda worked, but it had troubles recognizing both my TE121's, so I make a SVN checkout of DAHDI and installed that. It works fine. Not a single PRI drop in 11 hours. 2009/3/26 Harry Vangberg ha...@vangberg.name: It's 2 feet from the Nokia network terminal from the telco. 2009/3/26 Jared Smith jsm...@digium.com: On Thu, 2009-03-26 at 20:24 +0100, Harry Vangberg wrote: 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? How far is your Asterisk box from the demarcation point? If it's more than 133 feet (cable length), then you'll need to adjust the LBO setting on your span line in the DAHDI (or Zaptel) configuration file. -- Jared Smith Training Manager Digium, Inc. ___ -- 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
[asterisk-users] PRI dropping #2
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
Re: [asterisk-users] PRI dropping #2
From http://www.voip-info.org/wiki/view/E1: 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
Re: [asterisk-users] PRI dropping #2
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
Re: [asterisk-users] PRI dropping #2
Harry, Chill on the duplicate posts. Sometimes the listserv takes time to forward the message. -Dave -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Harry Vangberg Sent: Thursday, March 26, 2009 3:25 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] PRI dropping #2 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
Re: [asterisk-users] PRI dropping #2
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
Re: [asterisk-users] PRI dropping #2
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
Re: [asterisk-users] PRI dropping #2
On Thu, 2009-03-26 at 20:24 +0100, Harry Vangberg wrote: 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? How far is your Asterisk box from the demarcation point? If it's more than 133 feet (cable length), then you'll need to adjust the LBO setting on your span line in the DAHDI (or Zaptel) configuration file. -- Jared Smith Training Manager Digium, Inc. ___ -- 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
Re: [asterisk-users] PRI dropping #2
It's 2 feet from the Nokia network terminal from the telco. 2009/3/26 Jared Smith jsm...@digium.com: On Thu, 2009-03-26 at 20:24 +0100, Harry Vangberg wrote: 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? How far is your Asterisk box from the demarcation point? If it's more than 133 feet (cable length), then you'll need to adjust the LBO setting on your span line in the DAHDI (or Zaptel) configuration file. -- Jared Smith Training Manager Digium, Inc. ___ -- 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
