Re: [asterisk-users] PRI Problem

[Doug Lytle]

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

[Eric Merkel]

On Tue, Aug 16, 2011 at 10:48 AM, Shaun Ruffell  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

[Shaun Ruffell]

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

[asterisk-users] PRI Problem

[Eric Merkel]

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 [SOLVED]

[Steven J. Douglas]

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 :
>>   
>> 
>>> 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 >>> > 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

Re: [asterisk-users] PRI problem

[Steven J. Douglas]

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 :
>   
>> 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 >> > 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 NOTI

Re: [asterisk-users] PRI problem

[Harry Vangberg]

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 :
> 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 > > 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
>>     c

Re: [asterisk-users] PRI problem

[Steven J. Douglas]

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  > 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 

Re: [asterisk-users] PRI problem

[Brandon B.]

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 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 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

[asterisk-users] PRI problem

[Steven J. Douglas]

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, pri_fixup_principle: Call specified, but not found? [SOLVED]

[Carlos G Mendioroz]

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

Re: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?

[Carlos G Mendioroz]

  EA: 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
-- Unsolicited RR with P/F bit, responding
Sending Receiver 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: 000    EA: 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
>> s

RE: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?

[John Treble]

> 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

[asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?

[Carlos G Mendioroz]

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

[Steve Totaro]

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

Re: [Asterisk-Users] PRI problem

[Andrew Kohlsmith]

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

[Asterisk-Users] PRI problem

[Joseph Rothstein]

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

Re: [Asterisk-Users] PRI problem

[C F]

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

[Joseph Rothstein]

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

[Matt Fredrickson]

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

[Asterisk-Users] PRI problem

[matt001]

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








需要一个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???

[Timothy R. McKee]

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



;
; 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

RE: [Asterisk-Users] PRI problem???

[Scott Stingel]

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



;
; 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???

[Steven Critchfield]

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???

[Bruce Komito]

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,

RE: [Asterisk-Users] PRI problem???

[Timothy R. McKee]

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
>
> 
>
> ;
> ; 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???

[Bruce Komito]

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
>
> 
>
> ;
> ; 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???

[Steven Critchfield]

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

[Asterisk-Users] PRI problem???

[Timothy R. McKee]

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



;
; NuVox PRI
context=sdnpri
;
switchtype = national
pridialplan = unknown
signalling = pri_cpe
callerid=asreceived
group = 2
channel => 25-47


<>