<div dir="ltr"><div><div>I had a late phone call yesterday with provider's level-1 support team.<br><br></div>As strange as it seems, the guy said he could "read clock slips in his box logs though his box is supposed to provide clock and not to use my PBX's one".<br>
I'm 100% sure my PBX is configured to use provider's clock (but I won't swear my PBX is currently using provider's clock).<br><br></div><div>I think I will insert a new Patton box between my provider's one and my PBX to see what happens.<br>
The setup would be:<br></div><div>PSTN --> provider's equipment <----> Patton GW <----> Asterisk<br><br></div><div>Then I'll also replace the card inside my PBX to see if things are changing.<br></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/14 Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 9, 2014 at 12:01 PM, Olivier <<a href="mailto:oza.4h07@gmail.com">oza.4h07@gmail.com</a>> wrote:<br>

> Hi,<br>
><br>
> On a Asterisk 1.8.12 system working OK for months (>100k calls proceed),<br>
> users are complaining for bad audio.<br>
><br>
> My setup is:<br>
> PSTN <--E1/PRI ---> Asterisk <--- E1/PRI---> Siemens  HiPath <---E1/PRI ---><br>
> 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>
><br>
> A quick glance at Asterisk logs shows lines like this:<br>
> [2014-01-09 17:19:34] NOTICE[26034]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 1<br>
> [2014-01-09 17:19:35] NOTICE[26035]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 2<br>
> [2014-01-09 17:19:49] NOTICE[26035]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 2<br>
><br>
><br>
> I read an old thread inviting an admin to check for shared IRQs and timing<br>
> slips.<br>
><br>
> My questions are:<br>
><br>
> 1. cat /proc/interrupts 's output is:<br>
> # cat /proc/interrupts<br>
>             CPU0       CPU1       CPU2       CPU3       CPU4       CPU5<br>
> CPU6       CPU7<br>
>    0:      90147          0          0          0          0          0<br>
> 0          0   IO-APIC-edge      timer<br>
>    1:          2          0          0          0          0          0<br>
> 0          0   IO-APIC-edge      i8042<br>
>    8:          0          0          1          0          0          0<br>
> 0          0   IO-APIC-edge      rtc0<br>
>    9:          0          0          0          0          0          0<br>
> 0          0   IO-APIC-fasteoi   acpi<br>
>   12:          4          0          0          0          0          0<br>
> 0          0   IO-APIC-edge      i8042<br>
>   14:         93          0          0          0          0          0<br>
> 0          0   IO-APIC-edge      ata_piix<br>
>   15:          0          0          0          0          0          0<br>
> 0          0   IO-APIC-edge      ata_piix<br>
>   16: 3378646209 3378695076 3378691115 3378697362 3378691116 3378706831<br>
> 3378710635 3378702358   IO-APIC-fasteoi   wct2xxp<br>
><br>
> Can I positively conclude that my Dahdi PRI board IS NOT sharing IRQ (which<br>
> is good) ?<br>
><br>
> 2. What would you suggest reading the following output ?<br>
><br>
> 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>
> 3. As shown above, my box has two connections with PSTN (same provider for<br>
> both): one direct, one through an HiPath PBX.<br>
> How can I double check timing slips don't come from "inconsistency between<br>
> both clock sources" ?<br>
> My first thought would be to unplug the link between Asterisk and HiPath and<br>
> compare two /pro/dahddi/1 outputs.<br>
> Thoughts ?<br>
><br>
> Regards<br>
><br>
</div></div>I basically had the same issue as you for one of my sites. I tried<br>
everything under the sun to figure it out, change cables, loop back<br>
test, change out hardware, clocking, etc.<br>
<br>
In the end I had to upgrade dahdi to 2.7+ and the issue went away.<br>
Never did figure out the real problem, but to this day I think the<br>
issue was a delay on the frames from the PCI bus into the software.<br>
<br>
All that to say, try upgrading DAHDI and see what happens.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
               <a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br></div>