[asterisk-users] T1 PRI shows yellow/red alarm
We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on D-channel for span 2 /var/log/syslog reports: Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting yellow alarm on span 2 Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0! Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0! Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing yellow alarm on span 2 Intensive PRI debugging does not show any errors prior to the alarm. The other part to this is for a while it was pretty intermittent. One day we would get it 2 times, another 8-12 times. Today, however, it seems to be happening around every 11-13 minutes. Before this started, there were no errors for the 6 days prior. The first response from the telco 4 days ago said that it was an issue on their T3, then came back saying we were sending something to reset the circuit, but I interpret PRI got event as meaning we received something from them. They put a COM tracer in our building, on that circuit, since Friday afternoon. They took it with them to examine the results this morning, and are supposed to call me when they know something. While they are doing that, I want to make sure that I have all the information I need in order to diagnose it. I haven't found a way to trace the actual B8ZS/ESF frames, and was wondering if there was a way for me to log those events. It's not that I don't trust them, but by the same token I haven't changed anything on my end, the other port on the Digium card isn't reporting an issue, and a complete shutdown of the Asterisk server didn't change the results. Any advice would be greatly appreciated. Dean Hoover Milwaukee, Wisconsin -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] T1 PRI shows yellow/red alarm
Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on D-channel for span 2 /var/log/syslog reports: Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting yellow alarm on span 2 Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0! Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0! Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing yellow alarm on span 2 Intensive PRI debugging does not show any errors prior to the alarm. The other part to this is for a while it was pretty intermittent. One day we would get it 2 times, another 8-12 times. Today, however, it seems to be happening around every 11-13 minutes. Before this started, there were no errors for the 6 days prior. The first response from the telco 4 days ago said that it was an issue on their T3, then came back saying we were sending something to reset the circuit, but I interpret PRI got event as meaning we received something from them. They put a COM tracer in our building, on that circuit, since Friday afternoon. They took it with them to examine the results this morning, and are supposed to call me when they know something. While they are doing that, I want to make sure that I have all the information I need in order to diagnose it. I haven't found a way to trace the actual B8ZS/ESF frames, and was wondering if there was a way for me to log those events. It's not that I don't trust them, but by the same token I haven't changed anything on my end, the other port on the Digium card isn't reporting an issue, and a complete shutdown of the Asterisk server didn't change the results. Any advice would be greatly appreciated. Dean Hoover Milwaukee, Wisconsin -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello 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 -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] T1 PRI shows yellow/red alarm
Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on D-channel for span 2 /var/log/syslog reports: Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting yellow alarm on span 2 Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0! Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0! Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing yellow alarm on span 2 Intensive PRI debugging does not show any errors prior to the alarm. The other part to this is for a while it was pretty intermittent. One day we would get it 2 times, another 8-12 times. Today, however, it seems to be happening around every 11-13 minutes. Before this started, there were no errors for the 6 days prior. The first response from the telco 4 days ago said that it was an issue on their T3, then came back saying we were sending something to reset the circuit, but I interpret PRI got event as meaning we received something from them. They put a COM tracer in our building, on that circuit, since Friday afternoon. They took it with them to examine the results this morning, and are supposed to call me when they know something. While they are doing that, I want to make sure that I have all the information I need in order to diagnose it. I haven't found a way to trace the actual B8ZS/ESF frames, and was wondering if there was a way for me to log those events. It's not that I don't trust them, but by
Re: [asterisk-users] T1 PRI shows yellow/red alarm
I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: *yellow alarm on span 2* regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on D-channel for span 2 /var/log/syslog reports: Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting yellow alarm on span 2 Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0! Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0! Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing yellow alarm on span 2 Intensive PRI debugging does not show any errors prior to the alarm. The other part to this is for a while it was pretty intermittent. One day we would get it 2 times, another 8-12 times. Today, however, it seems to be happening around every 11-13 minutes. Before this started, there were no errors for the 6 days prior. The first response from the telco 4 days ago said that it was an issue on their T3, then came back saying we were sending something to reset the circuit, but I interpret PRI got event as meaning we received something from them. They put a COM tracer in our building, on that
Re: [asterisk-users] T1 PRI shows yellow/red alarm
Your message was: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 - m, I would change the timing sources of the spans: span=1,1,0,esf,b8zs span=2,2,0,esf,b8zs Have you try to plug the PRI into another Span that has been working properly?? Regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover kb7...@gmail.com wrote: This doesn't represent the 2nd span? span=2,1,0,esf,b8zs bchan=25-47 dchan=48 Dean On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz juanch...@gmail.com wrote: I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: yellow alarm on span 2 regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got
Re: [asterisk-users] T1 PRI shows yellow/red alarm
Ooops, my bad I Did not read the zaptel config file correctly, my apologize. span=1,0,0,esf,b8zs bchan=1-23 dchan=24 *span=2,1,0,esf,b8zs bchan=25-47 dchan=48* Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:34 PM, Juan David Diaz juanch...@gmail.comwrote: Your message was: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 - m, I would change the timing sources of the spans: span=1,1,0,esf,b8zs span=2,2,0,esf,b8zs Have you try to plug the PRI into another Span that has been working properly?? Regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover kb7...@gmail.com wrote: This doesn't represent the 2nd span? span=2,1,0,esf,b8zs bchan=25-47 dchan=48 Dean On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz juanch...@gmail.com wrote: I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: yellow alarm on span 2 regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are
Re: [asterisk-users] T1 PRI shows yellow/red alarm
have you check the PRI crossover cable? Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:35 PM, Juan David Diaz juanch...@gmail.comwrote: Ooops, my bad I Did not read the zaptel config file correctly, my apologize. span=1,0,0,esf,b8zs bchan=1-23 dchan=24 *span=2,1,0,esf,b8zs bchan=25-47 dchan=48* Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:34 PM, Juan David Diaz juanch...@gmail.comwrote: Your message was: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 - m, I would change the timing sources of the spans: span=1,1,0,esf,b8zs span=2,2,0,esf,b8zs Have you try to plug the PRI into another Span that has been working properly?? Regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover kb7...@gmail.com wrote: This doesn't represent the 2nd span? span=2,1,0,esf,b8zs bchan=25-47 dchan=48 Dean On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz juanch...@gmail.com wrote: I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: yellow alarm on span 2 regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a
Re: [asterisk-users] T1 PRI shows yellow/red alarm
That is certainly an option, but my query was more on the side of is it possible to trace/log the ESF frames. From what I have read, there are signals going back and forth from a lower level than the D-channel, and in ESF there are codes that can be sent to the other side to reset the frame. If that is the case, I would like to be able to log those frame messages. If the issue is on my side, then it is either Asterisk, libpri, zaptel or the card itself that is sending it. Dean On Mon, Feb 21, 2011 at 1:34 PM, Juan David Diaz juanch...@gmail.com wrote: Your message was: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 - m, I would change the timing sources of the spans: span=1,1,0,esf,b8zs span=2,2,0,esf,b8zs Have you try to plug the PRI into another Span that has been working properly?? Regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover kb7...@gmail.com wrote: This doesn't represent the 2nd span? span=2,1,0,esf,b8zs bchan=25-47 dchan=48 Dean On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz juanch...@gmail.com wrote: I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: yellow alarm on span 2 regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are
Re: [asterisk-users] T1 PRI shows yellow/red alarm
This doesn't represent the 2nd span? span=2,1,0,esf,b8zs bchan=25-47 dchan=48 Dean On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz juanch...@gmail.com wrote: I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel: yellow alarm on span 2 regards. Juan. Linux User #441131 On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover kb7...@gmail.com wrote: Here you go: /etc/zaptel.conf: loadzone = us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23 dchan=24 span=2,1,0,esf,b8zs bchan=25-47 dchan=48 #Added 2nd 2xT1 card span=3,0,0,d4,ami em=49-72 span=4,0,0,d4,ami fxoks=73-96 --- /etc/asterisk/zapata.conf: [channels] group=1 context=default signalling=pri_cpe switchtype=qsig channel=1-23 group=2 context=twtelecom-in signalling=pri_cpe switchtype=5ess echocancel=yes channel=25-47 group=3 context=definity-in signalling=em_w channel=49-72 group=10 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=73 group=11 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=74 group=12 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=75 group=13 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=76 group=14 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=77 group=15 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=78 group=16 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=79 group=17 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=80 group=18 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=81 group=19 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=82 group=20 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=83 group=21 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=84 group=22 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=85 group=23 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=86 group=24 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=87 group=25 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=88 group=26 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=89 group=27 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=90 group=28 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=91 group=29 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=92 group=30 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=93 group=31 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=94 group=32 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=95 group=33 context=testivr-in signalling=fxo_ks threewaycalling=yes transfer=yes channel=96 --- On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz juanch...@gmail.com wrote: Dean, what's your zaptel Zapata config_ regards Juan. Linux User #441131 On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover kb7...@gmail.com wrote: We are running Asterisk version 1.4.23-1, libpri-1.4.9 and zaptel-1.4.12.1 and two Digium TE220Ps. Debugs are set to 10. We have a T1 PRI connected to the telco. Over the last 4-5 days, we have getting Yellow/Red alarms coming from the T1 PRI. The other two ports in use are connected to internal test switches (Avaya Legend/Avaya Definity), and are not showing any errors. /var/log/asterisk/messages reports: [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4) on Primary D-channel of span 2 [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on D-channel for span 2 /var/log/syslog reports: Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting yellow alarm on span 2 Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0! Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0! Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing yellow alarm on span 2 Intensive PRI debugging does not show any errors prior to the alarm. The other part to this is for a while it was pretty intermittent. One day we would get it 2 times, another 8-12 times. Today, however, it seems to be happening around every 11-13 minutes. Before this started, there were no errors for the 6 days prior. The first response from the telco 4 days ago said that it was an issue on their T3, then came back saying we were
