[cisco-voip] Clicking/popping noise on inbound side of PRI

[Mike Armstrong]

We can't bring the system down for 24 hours, unfortunately, since that's the
only voice link to the outside world.

Cisco and Verizon worked together for about 2 hours on a Friday afternoon a
week ago doing all sorts of loopbacks and Bert testing -- results were
apparently inconclusive, but Verizon replaced the HTU-R "SmartJack" out of
the goodness of their heart.  At the time, I didn't know squat about how
this circuit worked, so I just listened to the experts doing their thing.
However, now that I do know squat about it, I believe there's a giant
loophole in Verizon's diagnostic capabilities in this particular
installation, which I'll mention later.

The "certified cable" is a Cat5E-certifed Ethernet cable; I think it's good
for up to 350MHz or something like that.  Pairs are 1-2, 3-6, 4-5, 7-8, so
it should work fine in this application.  Hell, given the distance involved,
barbed-wire would probably work.  I have a friend who runs 10Mbps Ethernet
over about a 50' run using zip cord.

But I digress; we're deriving timing from the line.  Interestingly,
switching to clock source internal has little effect.

I talked with the manufacturer of the HTU-R for a while last night, and
looked more closely at how the Telco monitors the span.  Since the circuit
is actually an HDSL link, the main function of the HTU-R is to transform the
HDSL signal (2 loops) into a traditional DS1 for delivery to the customer.
Internal error monitoring is extensive, with logs kept for both loops on the
HDSL side, as well as incoming DS1 data.  See anything missing?  They do not
monitor or log conditions on the outgoing DS1 -- which is where we're seeing
all our errors.

However, the HTU-R has ports on it to allow passive monitoring of the DS1 on
the customer side of things.  Verizon is coming out Monday morning to
install their monitoring equipment and we'll let it cook for however long it
takes.  We've logged just under a million errors on the last 6 Mondays
(Monday is our 2nd-cleanest day), so we should be able to produce enough
events to see if the Verizon equipment sees the same errors the Cisco
equipment does.  If it does, I think Verizon will admit defeat; if it
doesn't, it's back to Cisco.

As I mentioned in a reply to Scott Voll, I've now got reason to suspect the
problem is at the other end of the span, where an HTU-C (CO side of the HDSL
span) supplies power to the HTU-R via the span.  I'll keep you posted.

Mike Armstrong
University of Florida CREC
Lake Alfred, FL
863.956.5891
----- Original Message ----- 
From: "Vance Shipley" <vances at motivity.ca>
To: "Mike Armstrong" <mfa at lal.ufl.edu>
Cc: <cisco-voip at puck.nether.net>
Sent: Friday, September 19, 2003 6:01 PM
Subject: Re: [cisco-voip] Clicking/popping noise on inbound side of PRI


> Mike,
>
> I would want to run a 24 BERT test from the CO to the Cisco.  Put the
> Cisco into remote loopback mode and have Verizon run a BERT test through
> that loopback.  This will test the Cisco LIU, the cable, the SmartJack
> and everything else out to the CO.  You need to do this for 24 hours
> 'cause you don't have a 100% failure rate.  If you could reproduce the
> eoors all the time you could draw conclusions earlier but as it is you'll
> need to run long enough to know that you would have seen the problem.
>
> If that test shows errors then you would want to restest with the loopback
> being provided by the SmartJack.  If it still shows errors Verizon will
> accept responsibility and fix it.  If not Cisco will blame your cable or
> take resonsibility.
>
> Now as far as the cable goes, what is a "certified cable"?  Is it a
> certified RJ-48C cable?  Or is it an ethernet cable?  I don't believe
> a lack of sheilding is going to cause this problem however you need
> to make sure you have your signals on twisted pairs.  RJ-48C uses pins
> 1&2 and pins 4&5.  You must have pins 1&2 use a twisted pair, and the
> same for pins 4&5.  A flat "silver satin" cable will not work.  A cable
> where the white-blue/blue-white, etc. pairs are not using the right pins
> will not work.  A combination of two wires where one is <color> with
> white stripes and the other is white with <color> stripes makes up a
> twisted pair (e.g. white-orange/orange-white).
>
> 99% of the time these sort of problems are caused by cabling/connector
> issues.
>
> Next question:  where are you deriving timing from?  You must be
> clocking off the incoming T1 from Verizon.  If you are using an internal
> clock, or clocking off another span which is not itself timed off
> Verizon (or a higher Stratum level) you will have problems.
>
> -Vance
>
>