[asterisk-users] PRI Problem
I am having a problem with a new PRI turn-up on dahdi 2.5.0 and asterisk 1.8.5 that I have not seen before. The PRI is setup as B8ZS, ESF and the span shows up and ok. This PRI is merely a crossover T1 going into an old DC0 class 5 switch. I am getting the following errors over and over again [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 1 I am also showing CRC4 errors on span as well. # asterisk -rx dahdi show status Description Alarms IRQbpviol CRC4 Fra Codi Options LBO T2XXP (PCI) Card 0 Span 1OK 1 0 2938622 ESF B8ZS 0 db (CSU)/0-133 feet (DSX-1) I am leaning towards a misconfiguration on the span on the switch side but here is my setup. Can anyone point me in the right direction? # dahdi_hardware pci::06:08.0 wct4xxp+ d161:1220 Wildcard TE220 (5th Gen) /etc/dahdi/system.conf # Span 1: TE2/0/1 T2XXP (PCI) Card 0 Span 1 (MASTER) B8ZS/ESF ClockSource span=1,1,0,esf,b8zs # termtype: unknown bchan=1-23 dchan=24 echocanceller=mg2,1-23 /etc/asterisk/chan_dahdi [channels] language=en context=Incoming-Pri switchtype=dms100 signalling=pri_cpe group=1 channel = 1-23 Thanks, Eric Merkel -- _ -- 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] PRI Problem
On Tue, Aug 16, 2011 at 10:31:54AM -0400, Eric Merkel wrote: I am having a problem with a new PRI turn-up on dahdi 2.5.0 and asterisk 1.8.5 that I have not seen before. The PRI is setup as B8ZS, ESF and the span shows up and ok. This PRI is merely a crossover T1 going into an old DC0 class 5 switch. I'm not familiar with this switch however... I am getting the following errors over and over again [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 1 Do these errors start right away or does it take a little bit of time before they start appearing? I am also showing CRC4 errors on span as well. # asterisk -rx dahdi show status Description Alarms IRQbpviol CRC4 Fra Codi Options LBO T2XXP (PCI) Card 0 Span 1OK 1 0 2938622 ESF B8ZS 0 db (CSU)/0-133 feet (DSX-1) I am leaning towards a misconfiguration on the span on the switch side but here is my setup. Can anyone point me in the right direction? # dahdi_hardware pci::06:08.0 wct4xxp+ d161:1220 Wildcard TE220 (5th Gen) /etc/dahdi/system.conf # Span 1: TE2/0/1 T2XXP (PCI) Card 0 Span 1 (MASTER) B8ZS/ESF ClockSource span=1,1,0,esf,b8zs # termtype: unknown bchan=1-23 dchan=24 echocanceller=mg2,1-23 You have this configured for the switch to provide you timing. Is the switch really expecting to provide timing to the TE220? /etc/asterisk/chan_dahdi [channels] language=en context=Incoming-Pri switchtype=dms100 signalling=pri_cpe group=1 channel = 1-23 Thanks, Eric Merkel -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com www.asterisk.org -- _ -- 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] PRI Problem
On Tue, Aug 16, 2011 at 10:48 AM, Shaun Ruffell sruff...@digium.com wrote: On Tue, Aug 16, 2011 at 10:31:54AM -0400, Eric Merkel wrote: I am having a problem with a new PRI turn-up on dahdi 2.5.0 and asterisk 1.8.5 that I have not seen before. The PRI is setup as B8ZS, ESF and the span shows up and ok. This PRI is merely a crossover T1 going into an old DC0 class 5 switch. I'm not familiar with this switch however... I am getting the following errors over and over again [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [Aug 16 10:26:10] NOTICE[8002]: chan_dahdi.c:3043 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 1 Do these errors start right away or does it take a little bit of time before they start appearing? The error pretty much right away. I am also showing CRC4 errors on span as well. # asterisk -rx dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO T2XXP (PCI) Card 0 Span 1 OK 1 0 2938622 ESF B8ZS 0 db (CSU)/0-133 feet (DSX-1) I am leaning towards a misconfiguration on the span on the switch side but here is my setup. Can anyone point me in the right direction? # dahdi_hardware pci::06:08.0 wct4xxp+ d161:1220 Wildcard TE220 (5th Gen) /etc/dahdi/system.conf # Span 1: TE2/0/1 T2XXP (PCI) Card 0 Span 1 (MASTER) B8ZS/ESF ClockSource span=1,1,0,esf,b8zs # termtype: unknown bchan=1-23 dchan=24 echocanceller=mg2,1-23 You have this configured for the switch to provide you timing. Is the switch really expecting to provide timing to the TE220? I guess I was just assuming the switch would provide the timing as the telco normally provides this. Would you recommend just turning the timing off? /etc/asterisk/chan_dahdi [channels] language=en context=Incoming-Pri switchtype=dms100 signalling=pri_cpe group=1 channel = 1-23 Thanks, Eric Merkel -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com www.asterisk.org -- Thanks, Eric -- _ -- 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] PRI Problem
Eric Merkel wrote: The error pretty much right away. The first thing that comes to my mind is to check your cable. Doug -- Ben Franklin quote: Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- _ -- 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] PRI problem [SOLVED]
Thanks to all who replied. The problem was due to a faulty NTU box from the telco. It has been up for almost a week now without any downtime. Regards, Steve Steven J. Douglas wrote: Thanks for the tip, Harry. I will try that when I have exhausted all avenue. My problem is that if I upgrade to 1.4.24 and DAHDI, I'll break other stuffs. In my current set up, the PRI did work for a long period of time (7 hours) before going into this unreliable mode (up and down). I'm getting the telco technicians to check on this first because I believe the problem comes from their side. During the few hours when it is working, I am able to make and receive calls. So I don't think the issue lies with Asterisk. Regards, Steve Harry Vangberg wrote: I had the exact same problem and errors some time ago (search the archives for PRI dropping #2) using Asterisk 1.4.18, Zaptel and a Digium TE121. I tried all kind of things, had telco technicians come out and whatnot. The solution was two-folded - 1) I reinstalled my server, 2) I updated to Asterisk 1.4.24, replaced Zaptel with latest DAHDI. In the DAHDI case I even had to use latest Subversion revision due to some bug (but that was related to the TE121-cards I think). Since then I haven't had any issues at all, so consider updating Asterisk and Zaptel-DAHDI 2009/3/31 Steven J. Douglas stev...@moij.biz: Hi Brandon, When using the current straight cable, it sometimes worked i.e. I can make calls from the PSTN into the asterisk. Do you still think that I should try a crossover cable? Thanks. Regards, Steve. Brandon B. wrote: Try a T1 crossover cable: http://www.voip-info.org/wiki/view/crossover+T1+cable On Tue, Mar 31, 2009 at 12:37 AM, Steven J. Douglas stev...@moij.biz mailto:stev...@moij.biz wrote: Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on
Re: [asterisk-users] PRI problem
Thanks for the tip, Harry. I will try that when I have exhausted all avenue. My problem is that if I upgrade to 1.4.24 and DAHDI, I'll break other stuffs. In my current set up, the PRI did work for a long period of time (7 hours) before going into this unreliable mode (up and down). I'm getting the telco technicians to check on this first because I believe the problem comes from their side. During the few hours when it is working, I am able to make and receive calls. So I don't think the issue lies with Asterisk. Regards, Steve Harry Vangberg wrote: I had the exact same problem and errors some time ago (search the archives for PRI dropping #2) using Asterisk 1.4.18, Zaptel and a Digium TE121. I tried all kind of things, had telco technicians come out and whatnot. The solution was two-folded - 1) I reinstalled my server, 2) I updated to Asterisk 1.4.24, replaced Zaptel with latest DAHDI. In the DAHDI case I even had to use latest Subversion revision due to some bug (but that was related to the TE121-cards I think). Since then I haven't had any issues at all, so consider updating Asterisk and Zaptel-DAHDI 2009/3/31 Steven J. Douglas stev...@moij.biz: Hi Brandon, When using the current straight cable, it sometimes worked i.e. I can make calls from the PSTN into the asterisk. Do you still think that I should try a crossover cable? Thanks. Regards, Steve. Brandon B. wrote: Try a T1 crossover cable: http://www.voip-info.org/wiki/view/crossover+T1+cable On Tue, Mar 31, 2009 at 12:37 AM, Steven J. Douglas stev...@moij.biz mailto:stev...@moij.biz wrote: Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 20 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 21 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel
Re: [asterisk-users] PRI problem
I had the exact same problem and errors some time ago (search the archives for PRI dropping #2) using Asterisk 1.4.18, Zaptel and a Digium TE121. I tried all kind of things, had telco technicians come out and whatnot. The solution was two-folded - 1) I reinstalled my server, 2) I updated to Asterisk 1.4.24, replaced Zaptel with latest DAHDI. In the DAHDI case I even had to use latest Subversion revision due to some bug (but that was related to the TE121-cards I think). Since then I haven't had any issues at all, so consider updating Asterisk and Zaptel-DAHDI 2009/3/31 Steven J. Douglas stev...@moij.biz: Hi Brandon, When using the current straight cable, it sometimes worked i.e. I can make calls from the PSTN into the asterisk. Do you still think that I should try a crossover cable? Thanks. Regards, Steve. Brandon B. wrote: Try a T1 crossover cable: http://www.voip-info.org/wiki/view/crossover+T1+cable On Tue, Mar 31, 2009 at 12:37 AM, Steven J. Douglas stev...@moij.biz mailto:stev...@moij.biz wrote: Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 20 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 21 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 22 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 23 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 24 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 25 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 26 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 27 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event:
[asterisk-users] PRI problem
Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 20 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 21 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 22 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 23 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 24 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 25 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 26 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 27 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 28 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 29 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 30 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 31 Mar 31 14:34:07 NOTICE[2361]: chan_zap.c:9112 pri_dchannel: PRI got event: No more alarm (5) on Primary D-channel of span 1 == Primary D-Channel on span 1 up == Restart on requested on entire span 1 Mar 31 14:34:08 NOTICE[2361]: chan_zap.c:9112 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1 Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 1: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 2: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 3: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 4: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 5: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 6: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 7: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected
Re: [asterisk-users] PRI problem
Try a T1 crossover cable: http://www.voip-info.org/wiki/view/crossover+T1+cable On Tue, Mar 31, 2009 at 12:37 AM, Steven J. Douglas stev...@moij.bizwrote: Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 20 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 21 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 22 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 23 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 24 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 25 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 26 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 27 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 28 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 29 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 30 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 31 Mar 31 14:34:07 NOTICE[2361]: chan_zap.c:9112 pri_dchannel: PRI got event: No more alarm (5) on Primary D-channel of span 1 == Primary D-Channel on span 1 up == Restart on requested on entire span 1 Mar 31 14:34:08 NOTICE[2361]: chan_zap.c:9112 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1 Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 1: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 2: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 3: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 4: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899 handle_init_event: Detected alarm on channel 5: Red Alarm Mar 31 14:34:08 WARNING[2362]: chan_zap.c:6899
Re: [asterisk-users] PRI problem
Hi Brandon, When using the current straight cable, it sometimes worked i.e. I can make calls from the PSTN into the asterisk. Do you still think that I should try a crossover cable? Thanks. Regards, Steve. Brandon B. wrote: Try a T1 crossover cable: http://www.voip-info.org/wiki/view/crossover+T1+cable On Tue, Mar 31, 2009 at 12:37 AM, Steven J. Douglas stev...@moij.biz mailto:stev...@moij.biz wrote: Hi guys, I've been trying to get my ISDN-10 line up for the past few days, but its been going up and down. I am using OpenVox D110P card on asterisk version 1.4.21. It seems to me like a cable problem. I tried using Ethernet straight cable (12, 45, 36, 78) and also a straight cable where the twisted pairs are on 12, 34, 56 and 78. The problem remains the same. /*etc/zaptel.conf* loadzone=sg defaultzone=sg # PRI Span span=1,1,0,ccs,hdb3,crc4 bchan=1-15 dchan=16 bchan=17-31 */etc/asterisk/zapata.conf* language=en progzone=sg musiconhold=default ; PRI Set Up context=inbound-pri1 switchtype=euroisdn signalling=pri_cpe pridialplan=national overlapdial=yes immediate=no faxdetect=both overlapdial=no usecallerid=yes usecallingpres=yes callerid=asreceived group=9 channel = 1-15 channel = 17-31 The following are the messages that keep repeating. == Primary D-Channel on span 1 down Mar 31 14:34:05 WARNING[2361]: chan_zap.c:2682 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway! Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 1 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 2 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 3 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 4 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 5 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 6 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 7 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 8 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 9 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 10 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 11 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 12 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 13 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 14 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 15 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 17 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 18 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 19 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 20 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 21 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 22 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 23 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 24 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 25 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 26 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 27 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 28 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 29 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 30 Mar 31 14:34:07 NOTICE[2362]: chan_zap.c:6880 handle_init_event: Alarm cleared on channel 31 Mar 31 14:34:07 NOTICE[2361]: chan_zap.c:9112 pri_dchannel: PRI got event: No more alarm (5) on Primary D-channel of span 1 == Primary D-Channel on span 1 up == Restart on requested on entire span 1 Mar 31 14:34:08 NOTICE[2361]: chan_zap.c:9112
Re: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found? [SOLVED]
Ready (6) [ 02 01 01 0d ] Supervisory frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 006 P/F: 1 0 bytes of data -- Restarting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (6) [ 00 01 01 0d ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 006 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 b1 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 088 P/F: 1 0 bytes of data -- ACKing all packets from 87 to (but not including) 88 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter [ 02 01 72 2c 08 02 00 00 46 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 N(S): 057 0: 0 N(R): 022 P: 0 13 bytes of data -- ACKing all packets from 21 to (but not including) 22 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Originator) Message type: RESTART (70) [18 03 a1 83 88] 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: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] [ 00 01 2c 74 08 02 80 00 4e 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 N(S): 022 0: 0 N(R): 058 P: 0 13 bytes of data -- Restarting T203 counter Stopping T_203 timer Starting T_200 timer Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Terminator) Message type: RESTART ACKNOWLEDGE (78) [18 03 a1 83 88] 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: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] -- B-channel 0/8 restarted on span 2 [ 00 01 01 2e ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 0 0 bytes of data -- ACKing all packets from 21 to (but not including) 23 -- ACKing packet 22, new txqueue is -1 (-1 means empty) -- Since there was nothing left, stopping T200 counter -- Nothing left, starting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (58) [ 00 01 01 75 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 058 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 2f ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 1 0 bytes of data -- ACKing all packets from 22 to (but not including) 23 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter John Treble @ 24/05/2007 09:35 -0300 dixit: in a PRI setup, the receiving side is changing the B channel at proceeding. Please post the layer 3 trace for this call scenario so that members of this forum can help you debug your problem. John Treble Ottawa, Canada -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Carlos G Mendioroz Sent: May 24, 2007 7:53 AM To: asterisk-users@lists.digium.com Subject: [asterisk-users] PRI problem, pri_fixup_principle: Call specified,but not found? Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA
[asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?
Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA, -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?
in a PRI setup, the receiving side is changing the B channel at proceeding. Please post the layer 3 trace for this call scenario so that members of this forum can help you debug your problem. John Treble Ottawa, Canada -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Carlos G Mendioroz Sent: May 24, 2007 7:53 AM To: asterisk-users@lists.digium.com Subject: [asterisk-users] PRI problem, pri_fixup_principle: Call specified,but not found? Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA, -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?
-- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter [ 02 01 72 2c 08 02 00 00 46 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 N(S): 057 0: 0 N(R): 022 P: 0 13 bytes of data -- ACKing all packets from 21 to (but not including) 22 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Originator) Message type: RESTART (70) [18 03 a1 83 88] 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: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] [ 00 01 2c 74 08 02 80 00 4e 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 N(S): 022 0: 0 N(R): 058 P: 0 13 bytes of data -- Restarting T203 counter Stopping T_203 timer Starting T_200 timer Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Terminator) Message type: RESTART ACKNOWLEDGE (78) [18 03 a1 83 88] 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: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] -- B-channel 0/8 restarted on span 2 [ 00 01 01 2e ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 0 0 bytes of data -- ACKing all packets from 21 to (but not including) 23 -- ACKing packet 22, new txqueue is -1 (-1 means empty) -- Since there was nothing left, stopping T200 counter -- Nothing left, starting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (58) [ 00 01 01 75 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 058 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 2f ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 1 0 bytes of data -- ACKing all packets from 22 to (but not including) 23 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter John Treble @ 24/05/2007 09:35 -0300 dixit: in a PRI setup, the receiving side is changing the B channel at proceeding. Please post the layer 3 trace for this call scenario so that members of this forum can help you debug your problem. John Treble Ottawa, Canada -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Carlos G Mendioroz Sent: May 24, 2007 7:53 AM To: asterisk-users@lists.digium.com Subject: [asterisk-users] PRI problem, pri_fixup_principle: Call specified,but not found? Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA, -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI problem
Thanks for the suggestion, but I cant seem to get
this to work for some reason.
When I dial my zap channel it does not seem to go beyond the
first priority.
I have setup the following just as a test, but never see the
output of Noop:
exten = _0.,1,Dial(Zap/g1/${EXTEN:2},,f)
exten = _0.,2,Noop(${DIALSTATUS})
Id appreciate any suggestions along these lines.
Regards,
Joe
___
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI problem
On Sunday 08 January 2006 05:48, Joseph Rothstein wrote:
When I dial my zap channel it does not seem to go beyond the first
priority.
exten = _0.,1,Dial(Zap/g1/${EXTEN:2},,f)
exten = _0.,2,Noop(${DIALSTATUS})
No application continues upon hangup unless there are special conditions which
permit this. The Dial() option g does this.
-A.
___
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] PRI problem
If you mean the call keeps ringing, then the reason why is you have no
timeout in your dial statement. When there is no timeout the system
will never give up on line one so it can continue to the second
priority.
Thanks,
Steve
_
From: Joseph Rothstein [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 08, 2006 5:48 AM
To: asterisk-users@lists.digium.com
Subject: [Asterisk-Users] PRI problem
Thanks for the suggestion, but I can't seem to get this to work for some
reason.
When I dial my zap channel it does not seem to go beyond the first
priority.
I have setup the following just as a test, but never see the output of
Noop:
exten = _0.,1,Dial(Zap/g1/${EXTEN:2},,f)
exten = _0.,2,Noop(${DIALSTATUS})
I'd appreciate any suggestions along these lines.
Regards,
Joe
___
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI problem
We have an Asterisk server with a single Digium E1. Everzthign works as it should except for one minor issue. When we place a call to a number that is busy, Asterisk does not seem to properly send the busy signal back to the SIP phones. There is no indication on the phone of anything at all, just silence, like the call did not go through. As you might imagine, this can be quite frustrating. The only indication is that we see a 403 Forbidden SIP message on softphones. I would appreciate any ideas of how to solve this issue. I have yet to do extensive PRI debugging to see what the Telecom provider sends back, so I am assuming that it correct signaling. Regards, Joe ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI problem
Looks like you got a configuration issue, you should test for the
${DIALSTATUS} variable and set the signalling to the phones based on
that.
You can do:
exten = _X.,1,Dial(Zap/g1/${EXTEN})
exten = _X.,2,Goto,s-${DIALSTATUS},1)
exten = s-CANCEL,1,Playtones(congestion)
exten = s-CANCEL,2,Congestion
exten = s-NOANSWER,1,Goto(s-CANCEL,1)
exten = s-BUSY,1,Playtones(busy)
exten = s-BUSY,2,Busy
exten = s-CONGESTION,1,Goto(s-CANCEL,1)
exten = s-CHANUNAVAIL,1,Goto(s-CANCEL,1)
Check this:
http://www.voip-info.org/wiki-asterisk+cmd+dial
http://www.voip-info.org/wiki/index.php?page=Asterisk+variable+DIALSTATUS
On 1/6/06, Joseph Rothstein [EMAIL PROTECTED] wrote:
We have an Asterisk server with a single Digium E1. Everzthign works as it
should except for one minor issue.
When we place a call to a number that is busy, Asterisk does not seem to
properly send the busy signal back to the SIP phones. There is no indication
on the phone of anything at all, just silence, like the call did not go
through. As you might imagine, this can be quite frustrating. The only
indication is that we see a 403 Forbidden SIP message on softphones.
I would appreciate any ideas of how to solve this issue. I have yet to do
extensive PRI debugging to see what the Telecom provider sends back, so I am
assuming that it correct signaling.
Regards,
Joe
___
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
___
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI problem
currently we are able to use our USA sip phone to conenct into the E1 box, but still unable to dial out to chinese phone numbers. They said from their ISDN switch console, it shows D channel not connected to the voip server yet.here si the sip debug msg, we got a Message type: DISCONNECT (69) and unable to dial any numbers.Jul 12 12:56:26 WARNING[1523]: chan_zap.c:1931 pri_find_dchan: No D-channels available! Using Primary on channel anyway 16!-- Making new call for cr 32771 Protocol Discriminator: Q.931 (8) len=47 Call Ref: len= 2 (reference 3/0x3) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: A-Law (35) [18 04 e9 81 83 81] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0ChanSel: Reserved Ext: 1 DS1 Identifier: 1 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [28 08 4a 69 61 6e 20 4c 69 75] Display (len= 8) [ Jian Liu ] [6c 04 21 81 31 30] Calling Number (len= 6) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number passed network screening (1) '10' ] [70 0d a1 30 31 33 39 30 31 30 33 35 34 33 36] Called Number (len=15) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '013901035436' ]NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Initiated, peerstate Overlap sending Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 3/0x3) (Originator) Message type: DISCONNECT (69) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]NEW_HANGUP DEBUG: Destroying the call, ourstate Disconnect Request, peerstate Disconnect Indication 需要一个2000兆的免费邮箱吗？网易免费邮箱是中国最多人使用的电子邮箱。 ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI problem
On Tue, Jul 12, 2005 at 10:59:42PM +0800, matt001 wrote: currently we are able to use our USA sip phone to conenct into the E1 box, but still unable to dial out to chinese phone numbers. They said from their ISDN switch console, it shows D channel not connected to the voip server yet. here si the sip debug msg, we got a Message type: DISCONNECT (69) and unable to dial any numbers. Jul 12 12:56:26 WARNING[1523]: chan_zap.c:1931 pri_find_dchan: No D-channels available! Using Primary on channel anyway 16! -- Making new call for cr 32771 Protocol Discriminator: Q.931 (8) len=47 Call Ref: len= 2 (reference 3/0x3) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: A-Law (35) [18 04 e9 81 83 81] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 DS1 Identifier: 1 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [28 08 4a 69 61 6e 20 4c 69 75] Display (len= 8) [ Jian Liu ] [6c 04 21 81 31 30] Calling Number (len= 6) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number passed network screening (1) '10' ] [70 0d a1 30 31 33 39 30 31 30 33 35 34 33 36] Called Number (len=15) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '013901035436' ] NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Initiated, peerstate Overlap sending Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 3/0x3) (Originator) Message type: DISCONNECT (69) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] NEW_HANGUP DEBUG: Destroying the call, ourstate Disconnect Request, peerstate Disconnect Indication Have you played with the overlapdial settings any to see if that helps? -- Matthew Fredrickson ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI problem???
Tim, I would double check the timing. It seems odd that you would supply clock rather than the switch, and if you get clock slips, that could certainly account for what you are seeing. Feel free to contact me off-list if you need more info or have any questions. Bruce Komito High Sierra Networks, Inc. www.servers-r-us.com (775) 284-5800 ext 115 On Sun, 23 May 2004, Timothy R. McKee wrote: I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: pbx1*CLI -- B-channel 1 successfully restarted on span 2 -- B-channel 2 successfully restarted on span 2 -- B-channel 3 successfully restarted on span 2 -- B-channel 4 successfully restarted on span 2 -- B-channel 5 successfully restarted on span 2 -- B-channel 6 successfully restarted on span 2 -- B-channel 7 successfully restarted on span 2 -- B-channel 8 successfully restarted on span 2 -- B-channel 9 successfully restarted on span 2 -- B-channel 10 successfully restarted on span 2 -- B-channel 11 successfully restarted on span 2 -- B-channel 12 successfully restarted on span 2 -- B-channel 13 successfully restarted on span 2 -- B-channel 14 successfully restarted on span 2 -- B-channel 15 successfully restarted on span 2 -- B-channel 16 successfully restarted on span 2 -- B-channel 17 successfully restarted on span 2 -- B-channel 18 successfully restarted on span 2 -- B-channel 19 successfully restarted on span 2 -- B-channel 20 successfully restarted on span 2 -- B-channel 21 successfully restarted on span 2 -- B-channel 22 successfully restarted on span 2 -- B-channel 23 successfully restarted on span 2 pbx1*CLI (This is from an asterisk console started with -r.) Has anyone encountered similar behavior in the past? If so, what was the resolution? Thanks, Tim McKee configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national pridialplan = unknown signalling = pri_cpe callerid=asreceived group = 2 channel = 25-47 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] PRI problem???
I thought the timing priority setting was for which incoming timing signal was used as the primary clock source, so I set the PRI as the highest priority clock source. In the telco world this is that way it normally works. Does the priority setting mean something different in zaptel.conf? My apologies to the group re the B channel restarts issue. My searches must have been too specific. Timothy R. McKee -Original Message- From: Bruce Komito [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 08:30 To: Timothy R. McKee Cc: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] PRI problem??? Tim, I would double check the timing. It seems odd that you would supply clock rather than the switch, and if you get clock slips, that could certainly account for what you are seeing. Feel free to contact me off-list if you need more info or have any questions. Bruce Komito High Sierra Networks, Inc. www.servers-r-us.com (775) 284-5800 ext 115 On Sun, 23 May 2004, Timothy R. McKee wrote: I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: pbx1*CLI -- B-channel 1 successfully restarted on span 2 -- B-channel 2 successfully restarted on span 2 -- B-channel 3 successfully restarted on span 2 -- B-channel 4 successfully restarted on span 2 -- B-channel 5 successfully restarted on span 2 -- B-channel 6 successfully restarted on span 2 -- B-channel 7 successfully restarted on span 2 -- B-channel 8 successfully restarted on span 2 -- B-channel 9 successfully restarted on span 2 -- B-channel 10 successfully restarted on span 2 -- B-channel 11 successfully restarted on span 2 -- B-channel 12 successfully restarted on span 2 -- B-channel 13 successfully restarted on span 2 -- B-channel 14 successfully restarted on span 2 -- B-channel 15 successfully restarted on span 2 -- B-channel 16 successfully restarted on span 2 -- B-channel 17 successfully restarted on span 2 -- B-channel 18 successfully restarted on span 2 -- B-channel 19 successfully restarted on span 2 -- B-channel 20 successfully restarted on span 2 -- B-channel 21 successfully restarted on span 2 -- B-channel 22 successfully restarted on span 2 -- B-channel 23 successfully restarted on span 2 pbx1*CLI (This is from an asterisk console started with -r.) Has anyone encountered similar behavior in the past? If so, what was the resolution? Thanks, Tim McKee configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national pridialplan = unknown signalling = pri_cpe callerid=asreceived group = 2 channel = 25-47 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] PRI problem???
My experience has been that the telco is the one that supplies the clock, because they must keep all of their circuits and equipment in sync. In fact, they typically derive their clocking ultimately from a satellite source. At one time, we had a switch interconnected with trunks to the ILEC, and we had to buy a similar clock to drive our equipment so that all of our circuits were in sync with theirs, as well as the other telcos we connected to. Before we did this, our PRIs (which were used for data only) would work for a while, but the modems dialed in to the PRI would eventually drop off, as the clock slippage increased to the point of being out of tolerance. Eventually, the entire PRI had to be restarted. When we installed the clock, all of the problems disappeared. Bruce Komito High Sierra Networks, Inc. www.servers-r-us.com (775) 284-5800 ext 115 On Mon, 24 May 2004, Timothy R. McKee wrote: I thought the timing priority setting was for which incoming timing signal was used as the primary clock source, so I set the PRI as the highest priority clock source. In the telco world this is that way it normally works. Does the priority setting mean something different in zaptel.conf? My apologies to the group re the B channel restarts issue. My searches must have been too specific. Timothy R. McKee -Original Message- From: Bruce Komito [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 08:30 To: Timothy R. McKee Cc: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] PRI problem??? Tim, I would double check the timing. It seems odd that you would supply clock rather than the switch, and if you get clock slips, that could certainly account for what you are seeing. Feel free to contact me off-list if you need more info or have any questions. Bruce Komito High Sierra Networks, Inc. www.servers-r-us.com (775) 284-5800 ext 115 On Sun, 23 May 2004, Timothy R. McKee wrote: I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: pbx1*CLI -- B-channel 1 successfully restarted on span 2 -- B-channel 2 successfully restarted on span 2 -- B-channel 3 successfully restarted on span 2 -- B-channel 4 successfully restarted on span 2 -- B-channel 5 successfully restarted on span 2 -- B-channel 6 successfully restarted on span 2 -- B-channel 7 successfully restarted on span 2 -- B-channel 8 successfully restarted on span 2 -- B-channel 9 successfully restarted on span 2 -- B-channel 10 successfully restarted on span 2 -- B-channel 11 successfully restarted on span 2 -- B-channel 12 successfully restarted on span 2 -- B-channel 13 successfully restarted on span 2 -- B-channel 14 successfully restarted on span 2 -- B-channel 15 successfully restarted on span 2 -- B-channel 16 successfully restarted on span 2 -- B-channel 17 successfully restarted on span 2 -- B-channel 18 successfully restarted on span 2 -- B-channel 19 successfully restarted on span 2 -- B-channel 20 successfully restarted on span 2 -- B-channel 21 successfully restarted on span 2 -- B-channel 22 successfully restarted on span 2 -- B-channel 23 successfully restarted on span 2 pbx1*CLI (This is from an asterisk console started with -r.) Has anyone encountered similar behavior in the past? If so, what was the resolution? Thanks, Tim McKee configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national
RE: [Asterisk-Users] PRI problem???
On Mon, 2004-05-24 at 07:37, Timothy R. McKee wrote: I thought the timing priority setting was for which incoming timing signal was used as the primary clock source, so I set the PRI as the highest priority clock source. In the telco world this is that way it normally works. Does the priority setting mean something different in zaptel.conf? My apologies to the group re the B channel restarts issue. My searches must have been too specific. Tim McKee configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # Anything other than a 0 for timing means you are accepting timing from that source. Since you are connected to an outside provider, I would suggest not accepting timing from the channel bank as it doesn't know what timing the outside world is using. So try span=1,0,1,esf,b8zs # don't overdive what is probably a # short hall line. span=2,1,1,esf,b8zs # I think the length here is just # back to the smart jack, -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] PRI problem???
Hi Tim- Except for maybe eliminating the channel bank as a secondary source of timing, your conf files look fine. I notice that you've used 2 as the build-out (line length) parameter - I take it that your asterisk box is not right next to the switch. Anyway, I've never seen build-out make much difference, but maybe that's an issue. Although asterisk restarts B channels on a periodic basis, it's not supposed to do this if there's a call in progress, so there's something wrong. I noticed a problem recently that was causing D channels to drop under load, but after reporting this, Mark S fixed this on May 18th, so your more recent distr should cover it. Finally, in looking through libpri bugs on the bug list, Mark refers to some kind of firmware problem on some TE410P's (I think), so you might read through recent bug reports and see if any match your symptom (read the closed ones too) Is there anything remarkable in your /var/log/asterisk/messages log file? regards Scott M. Stingel President, Emerging Voice Technology, Inc. Palo Alto California London England www.evtmedia.com _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy R. McKee Sent: Sunday, May 23, 2004 7:52 PM To: [EMAIL PROTECTED] Subject:[Asterisk-Users] PRI problem??? I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national pridialplan = unknown signalling = pri_cpe callerid=asreceived group = 2 channel = 25-47 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] PRI problem???
Yes, my termination point is a good 100' run away (cat5) from the server. I have experimented with settings of 0, 1, and 2 with no difference. I had only put the channel bank in a backup timing source (since removed) to see if there was any impact. I appreciate the libpri comment, I'll search the bug reports. [nothing remarkable in the logs, I have not yet decided to become a masochist and turn on PRI debugging on a production sysmem maybe if the pain level goes higher] Timothy R. McKee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Stingel Sent: Monday, May 24, 2004 12:58 To: [EMAIL PROTECTED] Subject: RE: [Asterisk-Users] PRI problem??? Hi Tim- Except for maybe eliminating the channel bank as a secondary source of timing, your conf files look fine. I notice that you've used 2 as the build-out (line length) parameter - I take it that your asterisk box is not right next to the switch. Anyway, I've never seen build-out make much difference, but maybe that's an issue. Although asterisk restarts B channels on a periodic basis, it's not supposed to do this if there's a call in progress, so there's something wrong. I noticed a problem recently that was causing D channels to drop under load, but after reporting this, Mark S fixed this on May 18th, so your more recent distr should cover it. Finally, in looking through libpri bugs on the bug list, Mark refers to some kind of firmware problem on some TE410P's (I think), so you might read through recent bug reports and see if any match your symptom (read the closed ones too) Is there anything remarkable in your /var/log/asterisk/messages log file? regards Scott M. Stingel President, Emerging Voice Technology, Inc. Palo Alto California London England www.evtmedia.com _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy R. McKee Sent: Sunday, May 23, 2004 7:52 PM To: [EMAIL PROTECTED] Subject:[Asterisk-Users] PRI problem??? I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national pridialplan = unknown signalling = pri_cpe callerid=asreceived group = 2 channel = 25-47 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI problem???
I have just finished installing a new asterisk box at my work. The box is quite hefty, dual Zeon 2.8s with SCSI drives and 2Gb of memory. I have a 4 port Digium T1 card for channel bank and PRI access. I activated a PRI from a local CLEC (DMS-500 based, National protocol). This PRI is on slot 2 of the card and is set as the primary timing source. It is ESF/B8ZS. All the software is latest CVS HEAD as of 5/22/04. My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: pbx1*CLI -- B-channel 1 successfully restarted on span 2 -- B-channel 2 successfully restarted on span 2 -- B-channel 3 successfully restarted on span 2 -- B-channel 4 successfully restarted on span 2 -- B-channel 5 successfully restarted on span 2 -- B-channel 6 successfully restarted on span 2 -- B-channel 7 successfully restarted on span 2 -- B-channel 8 successfully restarted on span 2 -- B-channel 9 successfully restarted on span 2 -- B-channel 10 successfully restarted on span 2 -- B-channel 11 successfully restarted on span 2 -- B-channel 12 successfully restarted on span 2 -- B-channel 13 successfully restarted on span 2 -- B-channel 14 successfully restarted on span 2 -- B-channel 15 successfully restarted on span 2 -- B-channel 16 successfully restarted on span 2 -- B-channel 17 successfully restarted on span 2 -- B-channel 18 successfully restarted on span 2 -- B-channel 19 successfully restarted on span 2 -- B-channel 20 successfully restarted on span 2 -- B-channel 21 successfully restarted on span 2 -- B-channel 22 successfully restarted on span 2 -- B-channel 23 successfully restarted on span 2 pbx1*CLI (This is from an asterisk console started with -r.) Has anyone encountered similar behavior in the past? If so, what was the resolution? Thanks, Tim McKee configs: zaptel.conf # # span 1 is for channel bank (24 FXS) span=1,2,2,esf,b8zs # span 2 is for NuVox PRI (1-23B, 24D) span=2,1,2,esf,b8zs # span 3 is unused span=3,0,0,esf,b8zs # span 4 is unused span=4,0,0,esf,b8zs # # zapata.conf [channels] ; ; Default language ; language=en ; ; Default context ; context=dialnational ; signalling=fxo_ks use_callerid=yes callwaiting=no restrictcid=no usecallingpres=yes callwaitingcallerid=no threewaycalling=yes transfer=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=yes relaxdtmf=no rxgain=0.0 txgain=0.0 callgroup=1 pickupgroup=1 immediate=no amaflags=billing channels 1-24 omitted ; ; NuVox PRI context=sdnpri ; switchtype = national pridialplan = unknown signalling = pri_cpe callerid=asreceived group = 2 channel = 25-47 attachment: winmail.dat
Re: [Asterisk-Users] PRI problem???
On Sun, 2004-05-23 at 21:52, Timothy R. McKee wrote: My problem lies in random intermittent drops of calls. The entire PRI seems to disappear, dropping all current established calls. I see occasional printouts on an asterisk management console showing all 23 B channels resetting with no reason given: pbx1*CLI -- B-channel 1 successfully restarted on span 2 (This is from an asterisk console started with -r.) Has anyone encountered similar behavior in the past? If so, what was the resolution? Is there a problem with your google access? http://tinyurl.com/2fjkb This was answered as late as last month and covered about every 4 months for people to lame to do their own simple google search. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
