<div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>On a Asterisk 1.8.12 system working OK for months (>100k calls proceed), users are complaining for bad audio.<br><br></div><div>My setup is:<br></div><div>
PSTN <--E1/PRI ---> Asterisk <--- E1/PRI---> Siemens  HiPath <---E1/PRI ---> PSTN<br><br>asterisk -rx "dahdi show version"<br>DAHDI Version: SVN-trunk-r10414 Echo Canceller: HWEC<br><br>asterisk -rx "pri show version"<br>
libpri version: 1.4.12<br><br><br></div><div><br></div>A quick glance at Asterisk logs shows lines like this:<br>[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<br>
[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<br>[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<br>
<br><br></div>I read an old thread inviting an admin to check for shared IRQs and timing slips.<br><br></div>My questions are:<br><br></div>1. cat /proc/interrupts 's output is:<br># cat /proc/interrupts <br>            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       <br>
   0:      90147          0          0          0          0          0          0          0   IO-APIC-edge      timer<br>   1:          2          0          0          0          0          0          0          0   IO-APIC-edge      i8042<br>
   8:          0          0          1          0          0          0          0          0   IO-APIC-edge      rtc0<br>   9:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   acpi<br>
  12:          4          0          0          0          0          0          0          0   IO-APIC-edge      i8042<br>  14:         93          0          0          0          0          0          0          0   IO-APIC-edge      ata_piix<br>
  15:          0          0          0          0          0          0          0          0   IO-APIC-edge      ata_piix<br>  16: 3378646209 3378695076 3378691115 3378697362 3378691116 3378706831 3378710635 3378702358   IO-APIC-fasteoi   wct2xxp<br>
<br></div>Can I positively conclude that my Dahdi PRI board IS NOT sharing IRQ (which is good) ?<br><br></div><div>2. What would you suggest reading the following output ?<br><br></div><div>cat /proc/dahdi/2<br>Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS <br>
    Timing slips: 175319<br><br>      32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE) <br>      48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
      59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>      62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE) <br>
<br></div><div>3. As shown above, my box has two connections with PSTN (same provider for both): one direct, one through an HiPath PBX.<br></div><div>How can I double check timing slips don't come from "inconsistency between both clock sources" ?<br>
</div><div>My first thought would be to unplug the link between Asterisk and HiPath and compare two /pro/dahddi/1 outputs.<br></div><div>Thoughts ?<br></div><div><br></div><div><div><div><div>Regards<br></div><div><div><div>
<div><div><div><div><div><br><br></div></div></div></div></div></div></div></div></div></div></div></div>