On Thu, Jan 9, 2014 at 12:01 PM, Olivier <oza.4...@gmail.com> wrote: > Hi, > > On a Asterisk 1.8.12 system working OK for months (>100k calls proceed), > users are complaining for bad audio. > > My setup is: > PSTN <--E1/PRI ---> Asterisk <--- E1/PRI---> Siemens HiPath <---E1/PRI ---> > PSTN > > asterisk -rx "dahdi show version" > DAHDI Version: SVN-trunk-r10414 Echo Canceller: HWEC > > asterisk -rx "pri show version" > libpri version: 1.4.12 > > > > A quick glance at Asterisk logs shows lines like this: > [2014-01-09 17:19:34] NOTICE[26034]: chan_dahdi.c:3099 > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of > span 1 > [2014-01-09 17:19:35] NOTICE[26035]: chan_dahdi.c:3099 > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of > span 2 > [2014-01-09 17:19:49] NOTICE[26035]: chan_dahdi.c:3099 > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of > span 2 > > > I read an old thread inviting an admin to check for shared IRQs and timing > slips. > > My questions are: > > 1. cat /proc/interrupts 's output is: > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 > CPU6 CPU7 > 0: 90147 0 0 0 0 0 > 0 0 IO-APIC-edge timer > 1: 2 0 0 0 0 0 > 0 0 IO-APIC-edge i8042 > 8: 0 0 1 0 0 0 > 0 0 IO-APIC-edge rtc0 > 9: 0 0 0 0 0 0 > 0 0 IO-APIC-fasteoi acpi > 12: 4 0 0 0 0 0 > 0 0 IO-APIC-edge i8042 > 14: 93 0 0 0 0 0 > 0 0 IO-APIC-edge ata_piix > 15: 0 0 0 0 0 0 > 0 0 IO-APIC-edge ata_piix > 16: 3378646209 3378695076 3378691115 3378697362 3378691116 3378706831 > 3378710635 3378702358 IO-APIC-fasteoi wct2xxp > > Can I positively conclude that my Dahdi PRI board IS NOT sharing IRQ (which > is good) ? > > 2. What would you suggest reading the following output ? > > cat /proc/dahdi/2 > Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS > Timing slips: 175319 > > 32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE) > 48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE) > 62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE) > > 3. As shown above, my box has two connections with PSTN (same provider for > both): one direct, one through an HiPath PBX. > How can I double check timing slips don't come from "inconsistency between > both clock sources" ? > My first thought would be to unplug the link between Asterisk and HiPath and > compare two /pro/dahddi/1 outputs. > Thoughts ? > > Regards > I basically had the same issue as you for one of my sites. I tried everything under the sun to figure it out, change cables, loop back test, change out hardware, clocking, etc.
In the end I had to upgrade dahdi to 2.7+ and the issue went away. Never did figure out the real problem, but to this day I think the issue was a delay on the frames from the PCI bus into the software. All that to say, try upgrading DAHDI and see what happens. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _____________________________________________________________________ -- 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