Re: [asterisk-users] Dahdi interface flapping

2013-08-07 Thread Andre Goree
 Although, patlooptest ran clean. It's most likely either a)
 misconfiguration between the card settings and the provider b)
 cabling between the card and the smart jack or c) Just something bad
 on the provider's end. The probability of it being system / hardware
 related is low IMO.

 I take it though your old install still works fine? What was the
 reason you're replacing the old install anyway?

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

Sorry for the noise guys, but I'm still having trouble with this.  I
don't know a whole lot about T1/ISDN/PRI configuration (obviously),
but I'm finding it hard coming to terms with this being a
configuration issue on the provider's end when two cards (a TE405P and
a TE410P) work flawlessly with the same exact configuration.  The
provider explains that their tests from their equipment to the mux is
fine and that they can't go further than that.  I tend to believe them
since there are no issues on aforementioned cards...the issue only
occurs when trying to connect the new card (a T133 -- 1x PCI-e in a
rackmount server using a 16x riser, this shouldn't be an issue if my
hardware knowledge is worth anything, heh).

Still trying to trace down and see if there can be some sort of
cabling issue between the new box and the PRI port, but so far haven't
come across everything.

Could this at all have to do with brand-new hardware (TE133 was just
release, if I'm not mistaken) and/or some bug in the new dahdi (I used
dahdi-linux-complete-2.7.0+2.7.0)?  Also, the system is 64-bit CentOS,
and so I've had to place files in /usr/lib64 -- for instance, all
asterisk modules are in /usr/lib64/asterisk/modules...asterisk was
configured with ./configure CFLAGS=-mtune=native --libdir=/usr/lib64
 make menuselect.  Libpri-1.4 was build from source as well, the
files for it in /usr/lib64 are symlinks:

[root@asterisk-master ~]# ll /usr/lib64/libpri.so*
lrwxrwxrwx 1 root root 22 Aug 2 09:12 /usr/lib64/libpri.so -
/usr/lib/libpri.so.1.4
lrwxrwxrwx 1 root root 22 Aug 2 09:32 /usr/lib64/libpri.so.1.4 -
/usr/lib/libpri.so.1.4

I thought this might be an issue, so I did try installing the 64-bit
rpm, but the same issue occurred after having rebuilt dahdi and
asterisk.


I'm really trying to think outside the box and see if there's any
other possibilities here...I'm at my wits end, as you might imagine :/

--
_
-- 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] Dahdi interface flapping

2013-08-02 Thread Andre Goree
On Tue, Jul 30, 2013 at 3:55 PM, Shaun Ruffell sruff...@digium.com wrote:
 On Tue, Jul 30, 2013 at 11:46:04AM -0400, Andre Goree wrote:

 Thanks I'll definitely be contacting Digium support shortly.  For the
 hell of it, here's my dmesg output -- I'm seemingly safe from an IRQ
 issue, thankfully, ha:

 [root@asterisk-master dahdi]# dmesg | grep wcte13xp
 wcte13xp :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 wcte13xp :01:00.0: restoring config space at offset 0xf (was 0x1ff, 
 writing 0x10b)
 wcte13xp :01:00.0: restoring config space at offset 0x4 (was 0x0, 
 writing 0xdfb0)
 wcte13xp :01:00.0: restoring config space at offset 0x3 (was 0x0, 
 writing 0x10)
 wcte13xp :01:00.0: restoring config space at offset 0x1 (was 0x10, 
 writing 0x17)
 wcte13xp :01:00.0: setting latency timer to 64
 wcte13xp :01:00.0: Firmware version: 6f0017
 wcte13xp :01:00.0: FALC version: 5
 wcte13xp :01:00.0: Setting up global serial parameters for T1
 wcte13xp :01:00.0: firmware: requesting dahdi-fw-oct6114-032.bin
 wcte13xp :01:00.0: Echo cancellation for 32 channels
 wcte13xp :01:00.0: Reset octasic
 wcte13xp :01:00.0: VPM450: Present and operational servicing 1 span
 wcte13xp :01:00.0: irq 37 for MSI/MSI-X
 wcte13xp :01:00.0: Found a Wildcard TE133 (SN: 1TE133F - DF04132035402 - 
 B1 - 20130521)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Setting yellow alarm
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Clearing yellow alarm
 wcte13xp :01:00.0: Setting yellow alarm

 It's hard to tell from this output, but something isn't perhaps
 running dahdi_cfg in the background (or did you run it multiple
 times after loading the card?)  Normally I only see one Calling
 startup line.

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

Ran through a loopback test with Digium which seemingly proved that
there was no issue with their card.  I've contacted my telco for
assistance but so far have been unable to come up with
anything...though there may be a timing slip issue.  In any case, the
D-channel will indeed come up, but then after a while (at non-regular
intervals), the D-channel goes down after this message in the logs:
[2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
...
[2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (F): SABME in state 7(Multi-frame established)
[2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (F): SABME in state 7(Multi-frame established)
[2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer
recovery)
[2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer
recovery)


In the meantime I've been trying to adjust smp_affinity for the te133
IRQ (just for the hell of it and the fact that I'm running out of
things to try)  but it apparently it's being reset automatically by
something.  I.e., I'll run this:
[root@asterisk-master ~]# echo 8  /proc/irq/31/smp_affinity
[root@asterisk-master ~]# cat /proc/irq/31/smp_affinity
08

but then, 5-10 secs later:
[root@asterisk-master ~]# cat /proc/irq/31/smp_affinity
01

Have you ever seen something like that?  I'm using brand-newish
hardware w/both the server and the card, so I wouldn't be surprised if
I've run into some sort of new issue.  I'm about to shut the server
down now and give the BIOS settings a once-over just to make sure I'm
not actually running into something weird hardware-wise.

--
_
-- 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] Dahdi interface flapping

2013-08-02 Thread Andre Goree
On Fri, Aug 2, 2013 at 12:29 PM, Shaun Ruffell sruff...@digium.com wrote:
 On Fri, Aug 02, 2013 at 10:12:54AM -0400, Andre Goree wrote:

 Ran through a loopback test with Digium which seemingly proved that
 there was no issue with their card.  I've contacted my telco for
 assistance but so far have been unable to come up with
 anything...though there may be a timing slip issue.  In any case, the
 D-channel will indeed come up, but then after a while (at non-regular
 intervals), the D-channel goes down after this message in the logs:
 [2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 ...
 [2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 
 MDL-ERROR (F): SABME in state 7(Multi-frame established)
 [2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 
 MDL-ERROR (F): SABME in state 7(Multi-frame established)
 [2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 
 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer 
 recovery)
 [2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 
 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer 
 recovery)

 In the meantime I've been trying to adjust smp_affinity for the te133
 IRQ (just for the hell of it and the fact that I'm running out of
 things to try)  but it apparently it's being reset automatically by
 something.  I.e., I'll run this:
 [root@asterisk-master ~]# echo 8  /proc/irq/31/smp_affinity
 [root@asterisk-master ~]# cat /proc/irq/31/smp_affinity
 08

 but then, 5-10 secs later:
 [root@asterisk-master ~]# cat /proc/irq/31/smp_affinity
 01

 Have you ever seen something like that?

 irqbalance will adjust the smp_affinity of interrupts. If you shut
 it down you should be able to run your test.

OMG I remember disabling that before when testing, must've slipped my
mind this time...doh!

 I'm using brand-newish hardware w/both the server and the card, so
 I wouldn't be surprised if I've run into some sort of new issue.
 I'm about to shut the server down now and give the BIOS settings a
 once-over just to make sure I'm not actually running into
 something weird hardware-wise.

 Although, patlooptest ran clean. It's most likely either a)
 misconfiguration between the card settings and the provider b)
 cabling between the card and the smart jack or c) Just something bad
 on the provider's end. The probability of it being system / hardware
 related is low IMO.

 I take it though your old install still works fine? What was the
 reason you're replacing the old install anyway?

Asterisk 1.0.11.x  on a CentOS 4 box - Asterisk 11.4.x on CentOS6 was
the reason...just old archaic unsupported system that needed to be
upgraded to a supported LTS version and OS + GUI (FreePBX in my case).
 And I thought the hardest part would be the complete rebuild of the
dialplan!  :/

The last two companies I have worked for have both had this problem with a BT 
ISDN30 line at some point.
I also manage SS7 interconnects and its not unusual for there to be issues 
with them either. So dont assume its probably at your end :P

Thanks, this happens to be an Adtran MX2800 -- that no one knows to
whom or where it's connected on the far end.  I've gotten as far as I
can with the Telco who actually owns the equipment DS1...unfortunately
I'm at a loss as to wtf owns the other end and can thus assist in
testing (as is the co. who owns the T1), which doesn't make a lot of
sense.  But alas, here I am -___-

Thanks all for your input.

--
_
-- 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] Dahdi interface flapping

2013-07-30 Thread Andre Goree
Hello,

I seem to be having an issue with the configuration of my PRI on a new
asterisk server I've created to replace an old install that I have.
The card is Digium Wildcard TE133.  I continually get messages like
Primary D-Channel on span 1 down, rather irregularly:

[2013-07-29 17:31:39] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:31:39] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:32:52] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:32:52] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:16] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:16] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:50] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:50] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:34:05] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:34:05] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:34:32] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:34:32] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:35:37] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:35:37] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:02] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:02] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:21] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:21] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:36] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:36] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:51] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:51] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:37:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:37:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up

I've searched a lot regarding this problem and it seems that this
might simply be a configuration error, or an issue with the cable
(consequently, I used a straight-through cable from the PRI to the
Dahdi interface...is this correct?  Or should I have used a crossover
cable?  I'm waiting for a technician from my telco to contact me and
I'm sure he'll be able to give insight).

I've posted the configs and the output of a 'pri debug' below.  Please
let me know if I should include anything else to help troubleshoot.
I've tried both a standalone conifguration as well as the Dahdi module
in FreePBX, results with the same error(s).

/etc/dahdi/system.conf:
span=1,0,0,ESF,B8ZS
bchan=1-23
dchan=24
loadzone=us

/etc/asterisk/chan_dahdi.conf
[channels]
language=en
busydetect=yes
busycount=10
usecallerid=yes
callwaiting=yes
usecallingpres=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
immediate=no
faxdetect=no
rxgain=0.0
txgain=0.0

[root@asterisk-master ~]# dahdi_scan
[1]
active=yes
alarms=OK
description=Wildcard TE133 Card 0
name=WCT13x/0
manufacturer=Digium
devicetype=Wildcard TE133
location=PCI Bus 01 Slot 01
basechan=1
totchans=24
irq=0
type=digital-T1
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI
framing_opts=ESF,D4
coding=B8ZS
framing=ESF


[root@asterisk-master ~]# cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3   CPU4   CPU5
  CPU6   CPU7
  0:124  0  0  0  0  0
 0  0   IO-APIC-edge  timer
  1:  2  0  0  0  0  0
 0  0   IO-APIC-edge  i8042
  3:  2  0  0  0  0  0
 0  0   IO-APIC-edge
  4:  2  0  0  0  0  0
 0  0   IO-APIC-edge
  8:  1  0  0  0  0  0
 0  0   IO-APIC-edge  rtc0
  9:  0  0  0  0  0  0
 0  0   IO-APIC-fasteoi   acpi
 10:  2  0  0  0  0  0
 0  0   IO-APIC-edge
 12:  4  0  0  0  0  0
 0  0   IO-APIC-edge  i8042
 16: 62  0  0  0  0  0
 0  0   IO-APIC-fasteoi   ehci_hcd:usb1
 23:  

Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Andre Goree
On Tue, Jul 30, 2013 at 10:56 AM, Shaun Ruffell sruff...@digium.com wrote:
 On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:

 I seem to be having an issue with the configuration of my PRI on a new
 asterisk server I've created to replace an old install that I have.
 The card is Digium Wildcard TE133.

 In case you haven't, you should feel free to contact Digium customer
 support with installation assistance with your new card.

 http://www.digium.com/en/support/contact

 I've posted the configs and the output of a 'pri debug' below.  Please
 let me know if I should include anything else to help troubleshoot.
 I've tried both a standalone conifguration as well as the Dahdi module
 in FreePBX, results with the same error(s).

 /etc/dahdi/system.conf:
 span=1,0,0,ESF,B8ZS
 bchan=1-23
 dchan=24
 loadzone=us

 I think the span line above is wrong. I think you want:

 span=1,1,0,esf,b8zs

 The second 1 indicates that the span should recover the clock from
 the remote side (which should be your provider). However, normally
 when you have the timing misconfigured like this you'll get HDLC
 aborts, and not just the PRI going up and down.

 So before looking into any more or contacting customer support, it
 might be easy to change that one line and see if the behavior is
 different.

 --
 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 for the suggestions.  I did have the following before, with
similar errors:

[root@asterisk-master dahdi]# cat system.conf.ag
loadzone = us
defaultzone=us
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

From everything I've read, what you say makes complete sense and in
fact I'm surprised that's changed (FreePBX's DAHDI module created the
current config -- i.e. the one I posted in my original email).  I'll
change that back and see if that makes a difference, but I'm pretty
sure I used the above configuration in a previous attempt with the
same results.

Also, I have indeed received the following messages prior to the
interface going down and these errors are what I was initially
researching:

[root@asterisk-master dahdi]# grep HDLC /var/log/asterisk/full
...
[2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1

A lot of info I found while researching the above error mentioned
IRQ's, etc. and was one reason I posted the output of
/proc/interrupts, heh...but I'm pretty sure my issue is not one that
has to do with the IRQs.

Thanks for the suggestions!

--
_
-- 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] Dahdi interface flapping

2013-07-30 Thread Andre Goree
On Tue, Jul 30, 2013 at 11:40 AM, Shaun Ruffell sruff...@digium.com wrote:
 On Tue, Jul 30, 2013 at 11:13:55AM -0400, Andre Goree wrote:
 On Tue, Jul 30, 2013 at 10:56 AM, Shaun Ruffell sruff...@digium.com wrote:
  On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:
 
   I've posted the configs and the output of a 'pri debug' below.  Please
   let me know if I should include anything else to help troubleshoot.
   I've tried both a standalone conifguration as well as the Dahdi module
   in FreePBX, results with the same error(s).
  
   /etc/dahdi/system.conf:
   span=1,0,0,ESF,B8ZS
   bchan=1-23
   dchan=24
   loadzone=us
 
  I think the span line above is wrong. I think you want:
 
  span=1,1,0,esf,b8zs
 
  The second 1 indicates that the span should recover the clock from
  the remote side (which should be your provider). However, normally
  when you have the timing misconfigured like this you'll get HDLC
  aborts, and not just the PRI going up and down.
 
  So before looking into any more or contacting customer support, it
  might be easy to change that one line and see if the behavior is
  different.

 Thanks for the suggestions.  I did have the following before, with
 similar errors:

 [root@asterisk-master dahdi]# cat system.conf.ag
 loadzone = us
 defaultzone=us
 span=1,1,0,esf,b8zs
 bchan=1-23
 dchan=24

 From everything I've read, what you say makes complete sense and in
 fact I'm surprised that's changed (FreePBX's DAHDI module created the
 current config -- i.e. the one I posted in my original email).  I'll
 change that back and see if that makes a difference, but I'm pretty
 sure I used the above configuration in a previous attempt with the
 same results.

 Also, I have indeed received the following messages prior to the
 interface going down and these errors are what I was initially
 researching:

 [root@asterisk-master dahdi]# grep HDLC /var/log/asterisk/full
 ...
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1

 A lot of info I found while researching the above error mentioned
 IRQ's, etc. and was one reason I posted the output of
 /proc/interrupts, heh...but I'm pretty sure my issue is not one
 that has to do with the IRQs.

 Ok, that makes more sense. One more thing that is quick and easy to
 rule out in case there are interrupt handling issues is the check
 and see if there are any error messages in dmesg related to the
 driver.

   $ dmesg | grep wcte13xp

 If something on the system is preventing the wcte13xp's interrupt
 handler from running in a timely manner you'll see messages like:
 Underrun detected by hardware.  Latency bumped to: xms

 Typically I've seen this with systems that are configured to use
 framebuffers, disks that are operating in combined mode, systems
 with consoles on slow serial ports, or ill-behaved system management
 interrupts.

 A few of those messages about latency bumps are not a problem, and
 it is the drivers way of accommodating systems with less than ideal
 real time performance. However if you see any messages like Tried
 to increase latency past buffer size then the driver will not be
 able to accommodate the host system without some changes (if you're
 lucky).

 But...still...Digium's tech support I'm sure would be more than
 happy to help you troubleshoot.

 --
 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 I'll definitely be contacting Digium support shortly.  For the
hell of it, here's my dmesg output -- I'm seemingly safe from an IRQ
issue, thankfully, ha:

[root@asterisk-master dahdi]# dmesg | grep wcte13xp
wcte13xp :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
wcte13xp :01:00.0: restoring config space

[asterisk-users] Issue dialing out

2013-06-15 Thread Andre Goree
Hello all.

I'm having trouble resolving an issue with our Asterisk system that
seems to have popped up recently (no one knows for sure when the issue
started). I'm still somewhat of a Asterisk newb and have been tasked
with administrating the system as the previous administrator has left
the company.

Within asterisk, we have a Zap interface setup connected to a PRI that
we have through a telco. We have a certain extension setup to forward
to a users cellphone when the extension is dialed. This apparently is
no longer working, an we receive the following message when dialing
the extension:

The number you have dialed cannot be reached by the long-distance
company you've selected. Please check the code and dial again, or call
your long-distance company for assistance. P-U-A-M-I-2-3

This is what I see in the logs when this issue occurs (actual numbers redacted):

Jun 15 13:05:59 VERBOSE[30232]: -- Executing Answer(Zap/1-1, ) in new stack
Jun 15 13:05:59 VERBOSE[30232]: -- Executing Wait(Zap/1-1, 2) in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Executing Goto(Zap/1-1,
pri-in-dids|XX3730|1) in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Goto (pri-in-dids,XX3730,1)
Jun 15 13:06:01 VERBOSE[30232]: -- Executing Goto(Zap/1-1,
menu-v2|s|1) in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Goto (menu-v2,s,1)
Jun 15 13:06:01 VERBOSE[30232]: -- Executing BackGround(Zap/1-1,
firstintro) in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Playing 'firstintro' (language 'en')
Jun 15 13:06:05 VERBOSE[30232]: == CDR updated on Zap/1-1
Jun 15 13:06:05 VERBOSE[30232]: -- Executing Dial(Zap/1-1,
zap/g1/1XX|20|tT) in new stack
Jun 15 13:06:05 VERBOSE[30232]: -- Called g1/1XX
Jun 15 13:06:08 VERBOSE[30232]: -- Zap/2-1 answered Zap/1-1
Jun 15 13:06:08 VERBOSE[30232]: -- Attempting native bridge of Zap/1-1
and Zap/2-1
Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/2-1'
Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
exited non-zero on 'Zap/1-1'
Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/1-1'


I've contacted our PRI provider, however, they say that they do not
see the call reach their system. To me, it would seem like the call is
coming into our Asterisk system through our Zap interface on one
channel, then attempting to leave the system through the Zap interface
on another channel, and is failing to do so. Is there some sort of
functionality I need to enable to facilitate this? (I'd rather wait
till later to address the why this worked before and is no longer
working)

On thing I'll add, I can see where this DID work through what appears
to be a SIP call -- although this would be a different situation as it
comes through via SIP then leaves via the Zap interface vs. the call
coming through Zap and then also leaving via Zap:

Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetVar(SIP/4851-a8e0,
oexten=4851-a8e0) in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetVar(SIP/4851-a8e0,
extencid=4851) in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetCIDNum(SIP/4851-a8e0,
4851) in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing Goto(SIP/4851-a8e0,
extensions|4832|1) in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Goto (extensions,4832,1)
Jun 3 09:59:09 VERBOSE[21021]: -- Executing Dial(SIP/4851-a8e0,
zap/g1/1XX|20|tT) in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Called g1/1XX
Jun 3 09:59:12 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:12 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:18 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:23 VERBOSE[21021]: -- Zap/1-1 answered SIP/4851-a8e0
Jun 3 10:01:36 VERBOSE[21021]: -- Hungup 'Zap/1-1'
Jun 3 10:01:36 VERBOSE[21021]: == Spawn extension (extensions, 4832,
1) exited non-zero on 'SIP/4851-a8e0'

I'm not sure that the above is relevant, but thought I'd throw it out there.

--
_
-- 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] Issue dialing out

2013-06-15 Thread Andre Goree
On Sat, Jun 15, 2013 at 2:18 PM, Daniel Tryba dan...@tryba.nl wrote:
 Jun 15 13:06:05 VERBOSE[30232]: -- Executing Dial(Zap/1-1,
 zap/g1/1XX|20|tT) in new stack
 Jun 15 13:06:05 VERBOSE[30232]: -- Called g1/1XX
 Jun 15 13:06:08 VERBOSE[30232]: -- Zap/2-1 answered Zap/1-1
 Jun 15 13:06:08 VERBOSE[30232]: -- Attempting native bridge of Zap/1-1
 and Zap/2-1
 Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/2-1'
 Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
 exited non-zero on 'Zap/1-1'
 Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/1-1'


 I've contacted our PRI provider, however, they say that they do not
 see the call reach their system. To me, it would seem like the call is
 coming into our Asterisk system through our Zap interface on one
 channel, then attempting to leave the system through the Zap interface
 on another channel, and is failing to do so.

 They are either incompetant or lying to you. Call appears to succeed (it
 is answered) and gets disconnected after 23s. You are not generating the
 message, so the calls gets back to you telco.

 Most likely someone is filtering on callerID (which is a good thing IMHO).
 Set the callerid to one of your numbers before sending it back to Zap
 and try again.


You're right!  Forgot to update this thread, but a tech from their
side performed a trap on the line and attempted to recreate the issue.
From their switch, they're seeing the call go into our asterisk
system, then leave the asterisk system (as it tries to dial the
outside line when reaching the specific extensions 4832), then
receiving a disconnect from our asterisk system almost immediately. So
it would appear that asterisk attempts to forward the call as
expected, then immediately disconnects for some unknown reason, which
I guess is the specific issue I need to determine the cause of and
resolve.

I'm going to try what you've suggested and set the callerid to one of
our numbers.  Will let you know of the result.

Thanks!

--
_
-- 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] Issue dialing out

2013-06-15 Thread Andre Goree
 They are either incompetant or lying to you. Call appears to succeed (it
 is answered) and gets disconnected after 23s. You are not generating the
 message, so the calls gets back to you telco.

 Most likely someone is filtering on callerID (which is a good thing IMHO).
 Set the callerid to one of your numbers before sending it back to Zap
 and try again.


 You're right!  Forgot to update this thread, but a tech from their
 side performed a trap on the line and attempted to recreate the issue.
 From their switch, they're seeing the call go into our asterisk
 system, then leave the asterisk system (as it tries to dial the
 outside line when reaching the specific extensions 4832), then
 receiving a disconnect from our asterisk system almost immediately. So
 it would appear that asterisk attempts to forward the call as
 expected, then immediately disconnects for some unknown reason, which
 I guess is the specific issue I need to determine the cause of and
 resolve.

 I'm going to try what you've suggested and set the callerid to one of
 our numbers.  Will let you know of the result.

 Thanks!

Setting the CID did not work, unfortunately :(

Jun 15 14:50:31 VERBOSE[777]: -- Accepting call from 'XX6886' to
'XX3730' on channel 0/1, span 1
Jun 15 14:50:31 VERBOSE[31883]: -- Executing Answer(Zap/1-1, ) in new stack
Jun 15 14:50:31 VERBOSE[31883]: -- Executing Wait(Zap/1-1, 2) in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Executing Goto(Zap/1-1,
pri-in-dids|XX3730|1) in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Goto (pri-in-dids,XX3730,1)
Jun 15 14:50:33 VERBOSE[31883]: -- Executing Goto(Zap/1-1,
menu-v2|s|1) in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Goto (menu-v2,s,1)
Jun 15 14:50:33 VERBOSE[31883]: -- Executing BackGround(Zap/1-1,
firstintro) in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Playing 'firstintro' (language 'en')
Jun 15 14:50:39 VERBOSE[31883]: == CDR updated on Zap/1-1
Jun 15 14:50:39 VERBOSE[31883]: -- Executing SetCIDNum(Zap/1-1,
XX3730) in new stack
Jun 15 14:50:39 VERBOSE[31883]: -- Executing Dial(Zap/1-1,
zap/g1/1XX|20|tT) in new stack
Jun 15 14:50:39 VERBOSE[31883]: -- Called g1/1XX
Jun 15 14:50:42 VERBOSE[31883]: -- Zap/2-1 answered Zap/1-1
Jun 15 14:50:42 VERBOSE[31883]: -- Attempting native bridge of Zap/1-1
and Zap/2-1
Jun 15 14:50:58 VERBOSE[777]: -- Channel 0/1, span 1 got hangup
Jun 15 14:50:58 VERBOSE[31883]: -- Hungup 'Zap/2-1'
Jun 15 14:50:58 VERBOSE[31883]: == Spawn extension (menu-v2, 4832, 2)
exited non-zero on 'Zap/1-1'
Jun 15 14:50:58 VERBOSE[31883]: -- Hungup 'Zap/1-1'

I'm going to try another number that we have through them in hopes
that it'll complete and I'll let you know if that works.  Do you have
any other suggestions on what you think they might be filtering by?

In the trap given to me by the company, they show our system issuing a
disconnect from our end, rather than their end dropping the call.

Thanks for the assistance.

--
_
-- 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] Issue dialing out

2013-06-15 Thread Andre Goree
On Sat, Jun 15, 2013 at 4:03 PM, Daniel Tryba dan...@tryba.nl wrote:
 On Sat, Jun 15, 2013 at 03:02:41PM -0400, Andre Goree wrote:
 Setting the CID did not work, unfortunately :(
 [...]
 I'm going to try another number that we have through them in hopes
 that it'll complete and I'll let you know if that works.  Do you have
 any other suggestions on what you think they might be filtering by?

 In the trap given to me by the company, they show our system issuing a
 disconnect from our end, rather than their end dropping the call.

 Do a pri set debug (or whatever it is called in 1.4 (zap?)) Zap/Zap
 bridging should work, it did on my PRIs and still does with DAHDI. Only
 thing I can think of is the TON/NPI might be a problem (but doubt it
 since SIP/Zap works).



Thanks so much for your suggestions.

I'm running 1.0.x (yes, archaic, and in fact my actual task is
migrating this system to asterisk11+Freepbx -- very fun in and of
itself without regards to this issue...but I digress), and so I needed
to run pri debug span span, which I've now done.  I attempted the
call again have pasted the debug output here:
http://pastebin.com/cHHnMfh6

I can't thank you enough for your assistance, and I understand if you
wouldn't want to go through the debug output as it's LONG -- though
I'm thinking most of the pertinent info as towards the end.

--
_
-- 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] Issue dialing out

2013-06-15 Thread Andre Goree
 Do a pri set debug (or whatever it is called in 1.4 (zap?)) Zap/Zap
 bridging should work, it did on my PRIs and still does with DAHDI. Only
 thing I can think of is the TON/NPI might be a problem (but doubt it
 since SIP/Zap works).



 Thanks so much for your suggestions.

 I'm running 1.0.x (yes, archaic, and in fact my actual task is
 migrating this system to asterisk11+Freepbx -- very fun in and of
 itself without regards to this issue...but I digress), and so I needed
 to run pri debug span span, which I've now done.  I attempted the
 call again have pasted the debug output here:
 http://pastebin.com/cHHnMfh6

 I can't thank you enough for your assistance, and I understand if you
 wouldn't want to go through the debug output as it's LONG -- though
 I'm thinking most of the pertinent info as towards the end.


Dan, wanted to thank you again for your assistance.  I got this worked
out with our provider, it was actually an issue on their end that
they've now corrected.  Thanks again for your help!

--
_
-- 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] TE410P PCI card in 1U rackount server

2013-05-31 Thread Andre Goree
I was wondering if there is anyone following the list that has this or
similar PCI cards running in a 1U server.  If so, could you possibly
recommend a PCI card bus adapter?  I'm not sure exactly which kind I'll
need.

I plan on researching the different types of adapters I can purchase for
my specific mobo (Supermicro X9SCA-F), but I'd like to not waste time by
ordering an incorrect adapter and figured it might be prudent to ask you
good folks :)

Thanks in advance for any guidance you can provide.

-- 
Andre Goree
Linux Systems Administrator, Atlantic.Net
Toll Free: 1.800.540.4686
International: +1.321.206.3731
Mobile:  407.272.6886

--
_
-- 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] TE410P PCI card in 1U rackount server

2013-05-31 Thread Andre Goree
On 05/31/2013 03:42 PM, jg wrote:
 I have some 1-U servers running using Xeon processors with the Asus
 RS100-E7/PI2 barebone. There's only room for a single card and in my
 case I am using PCI-E Sangoma B500 cards.  Geometry is the basic
 problem. But this should not be a problem for your T1/E1 card. I had
 problems using a Sangoma B700 hybrid card. You do need an adapter (if it
 doesn't come with the board or barebone) as the cards are at least of
 2-U size.
 
 jg
 

Thanks!  Yeah I'll certainly need the adapter since one did not come
with the board, I guess I was looking for advice on which one's people
are using with their cards, but I suppose and ol' pci-e - 32-bit PCI
should work in the case of the TE410P, lol.


-- 
Andre Goree
Linux Systems Administrator, Atlantic.Net
Toll Free: 1.800.540.4686
International: +1.321.206.3731
Mobile:  407.272.6886

--
_
-- 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] Asterisk High-availability/failover solutions

2013-05-16 Thread Andre Goree

Hello all.

As part of a project I'm working on to migrate from Asterisk 1.0.11.1 to 
the latest LTS version, I'm looking into providing a HA/failover 
solution for the new Asterisk installation I'll be deploying.


It would appear my best bet would be to use the R850 Digium appliance.  
Does anyone have any experience running one of these devices along with 
AsteriskNOW?  I ask because apparently from what I gather from the 
rseries admin manual, it's required to use flat files vs. SQL -- and 
obviously AsteriskNOW uses SQL.


Failing that, I wonder if AsteriskNOW is nothing more than Asterisk 
11.3.0 + FreePBX?  Would I be fine installing 11.3+FreePBX?  I'm mainly 
wondering what the differences would be from AsteriskNOW vs. a vanilla 
install.  I'm currently trying to see if I can find any difference using 
virtual machines, but any info would be extremely helpful and 
time-saving :)


Thanks!

--
Andre Goree
-=-=-=-=-=-
Email - an...@drenet.net
Website   - http://blog.drenet.net
PGP key   - http://www.drenet.net/0x83ADAAAB.asc
-=-=-=-=-=-

--
_
-- 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] Upgrade from 1.0.x to AsteriskNOW 3.0

2013-05-14 Thread Andre Goree

On 2013-05-14 3:50 am, Dennis Dryden wrote:

AsteriskNOW 1 and 2 are both based on Centos 5 and I think the new
AsteriskNOW 3 is based on Centos 6 so upgrades are not supported by
the Linux OS distribution[1]. It's best to backup and reinstall with
the new version. It's a shame AsteriskNOW is not based on Debian so it
could be dist-upgraded between versions.

Cheers,
Dennis

[1] http://wiki.centos.org/HowTos/MigrationGuide/MigratingFiveToSix [6]




Thanks for the reply!  Keep in mind, I'm wanting to go from vanilla 
Asterisk 1.0.x to AsteriskNOW 3 -- or Asterisk 11 + FreePBX.  This will 
be on all new hardware -- which I guess actually answers my question 
regarding the feasibility of an in-place upgrade.  From what I can tell, 
my only choice will be to rebuild the configuration that is currently in 
the 1.0.x install using AsteriskNOW/Asterisk+FreePBX.  Probably won't be 
fun :/


Any insight on failover solutions?



On Mon, May 13, 2013 at 10:27 PM, Andre Goree an...@drenet.net wrote:

Hello all.  I was hoping someone out there might have some advice or 
suggestions regarding an upgrade from an archaic Asterisk version.


I've been given the daunting task of upgrading a very old 
Asterisk-1.0.x install to a recent LTS version.  I'll also need the 
install to have high-availability and failover support.


From my research, it would appear that AsteriskNOW-3.0 might be my best 
bet, as it seems to be running Asterisk-11.  I've previously installed 
Asterisk-11+FreePBX in a VM, and this appears to be very similar.  Is 
there any upside to using AsteriskNOW vs. Asterisk+FreePBX? Other than 
the obvious fact that everything is nicely placed on an iso for ease of 
installation?


As for the actual upgrade, is it possible to step through each of the 
UPGRADE*.txt files under the Asterisk-11 source?  I.e, UPGRADE-1.2.txt 
- UPGRADE-1.4.txt - UPGRADE-1.6.txt - UPGRADE-1.8.txt - 
UPGRADE.txt? Or would it be prudent to recreate my current 1.0.x 
configuration under Asterisk-11 instead?


Regarding HA/failover, is a hardware solution (such as Digium's 
R800/R850) my only option?  During my research I've found scripts on 
the internet that allow for failover using arp/nmap, however those 
appear to only work for hardware failures.  I would need something that 
can account for both hardware and software failures.


Thanks in advance for any advice that anyone can give on the subject. 
 Any suggestions, etc. would help immensely!


--
Andre Goree
-=-=-=-=-=-
Email     - an...@drenet.net
Website   - http://blog.drenet.net [1]
PGP key   - http://www.drenet.net/0x83ADAAAB.asc [2]
-=-=-=-=-=-

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com [3] 
--

New to Asterisk? Join us for a live introductory webinar every Thurs:
              http://www.asterisk.org/hello [4]

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users [5]



Links:
--
[1] http://blog.drenet.net
[2] http://www.drenet.net/0x83ADAAAB.asc
[3] http://www.api-digital.com
[4] http://www.asterisk.org/hello
[5] http://lists.digium.com/mailman/listinfo/asterisk-users
[6] http://wiki.centos.org/HowTos/MigrationGuide/MigratingFiveToSix

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


--
Andre Goree
-=-=-=-=-=-
Email - an...@drenet.net
Website   - http://blog.drenet.net
PGP key   - http://www.drenet.net/0x83ADAAAB.asc
-=-=-=-=-=-

--
_
-- 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] Upgrade from 1.0.x to AsteriskNOW 3.0

2013-05-13 Thread Andre Goree
Hello all.  I was hoping someone out there might have some advice or 
suggestions regarding an upgrade from an archaic Asterisk version.


I've been given the daunting task of upgrading a very old Asterisk-1.0.x 
install to a recent LTS version.  I'll also need the install to have 
high-availability and failover support.


From my research, it would appear that AsteriskNOW-3.0 might be my best 
bet, as it seems to be running Asterisk-11.  I've previously installed 
Asterisk-11+FreePBX in a VM, and this appears to be very similar.  Is 
there any upside to using AsteriskNOW vs. Asterisk+FreePBX? Other than 
the obvious fact that everything is nicely placed on an iso for ease of 
installation?


As for the actual upgrade, is it possible to step through each of the 
UPGRADE*.txt files under the Asterisk-11 source?  I.e, UPGRADE-1.2.txt 
- UPGRADE-1.4.txt - UPGRADE-1.6.txt - UPGRADE-1.8.txt - UPGRADE.txt? 
Or would it be prudent to recreate my current 1.0.x configuration under 
Asterisk-11 instead?


Regarding HA/failover, is a hardware solution (such as Digium's 
R800/R850) my only option?  During my research I've found scripts on the 
internet that allow for failover using arp/nmap, however those appear to 
only work for hardware failures.  I would need something that can 
account for both hardware and software failures.


Thanks in advance for any advice that anyone can give on the subject.  
Any suggestions, etc. would help immensely!


--
Andre Goree
-=-=-=-=-=-
Email - an...@drenet.net
Website   - http://blog.drenet.net
PGP key   - http://www.drenet.net/0x83ADAAAB.asc
-=-=-=-=-=-

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