Troubleshooting intermittent static on PRI phone calls VWIC 2MFT T1

Unanswered Question
May 20th, 2008

One of our locations is configured with a PRI circuit and the employees there are reporting to me that they experience intermittent problem with static on calls coming into and going out through the PRI.

If they hang up and dial back then they will typically get a clear circuit...although sometimes it takes 2 or 3 tries before the call is static free.

Everything in our router is configured correctly as far as I can tell (an incorrect configuration would not cause static anyway right?) and the PRI circuit has been up and running clean and clear for months.

Even now calls work well most of the time and we do not experience any service outages.

A few weeks ago is when I started getting reports of the intermittent static issue.

From what I can tell some days are worse than others.

My first instinct was to contact the telco(AT&T) and ask them to check the PRI circuit...and they did some testing which resulted in the default answer that the circuit is up and running.

They are saying the problem is on our equipment.

I replaced the VWIC 2MFT T1 card in our router and I also replaced the patch cable that is jacked into it...these changes did not eliminate the static.

If I contact the telco again is there anything particular to ask them regarding a problem like this?

Can a PRI have a bad channel or does it function in an all or none manner?

Also is there any way to monitor for problem internally and possible capture the problem as it is happening?

Has anybody had experience troubleshooting a problem like this?

Thanks in advance for your help!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Tue, 05/20/2008 - 10:30

Please send output of "show controllers T1". You might be missing network-clock-select commands.

phretbored Tue, 05/20/2008 - 10:43

Here you go:

hris5rt1#show controllers t1

T1 0/0/0 is up.

Applique type is Channelized T1

Cablelength is long gain36 0db

No alarms detected.

alarm-trigger is not set

Soaking time: 3, Clearance time: 10

AIS State:Clear LOS State:Clear LOF State:Clear

Version info Firmware: 20071009, FPGA: 20, spm_count = 0

Framing is ESF, Line Code is B8ZS, Clock Source is Line.

CRC Threshold is 320. Reported from firmware is 320.

Data in current interval (760 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Total Data (last 24 hours)

0 Line Code Violations, 0 Path Code Violations,

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

T1 0/0/1 is up.

Applique type is Channelized T1

Cablelength is long gain36 0db

Description: AT&T PRI circuit#:84HCQS000609-001

No alarms detected.

alarm-trigger is not set

Soaking time: 3, Clearance time: 10

AIS State:Clear LOS State:Clear LOF State:Clear

Version info Firmware: 20071009, FPGA: 20, spm_count = 0

Framing is ESF, Line Code is B8ZS, Clock Source is Line.

CRC Threshold is 320. Reported from firmware is 320.

Data in current interval (761 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Total Data (last 24 hours)

0 Line Code Violations, 0 Path Code Violations,

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

phretbored Tue, 05/20/2008 - 10:45

This is also configured on the router:

network-clock-participate wic 0

network-clock-participate aim 0

network-clock-select 1 T1 0/0/0

network-clock-select 2 T1 0/0/1

Paolo Bevilacqua Tue, 05/20/2008 - 11:56

That is all good. Which phones do you have and which FW on them? This info is accessible from settings menu.

phretbored Tue, 05/20/2008 - 12:10

The phones are 7961s

Actually over this past weekend I just did an upgrade on our CCMs to 6.0.1.2035-1 and a firmware upgrade was part of the process.

The phones are on SCCP41.8-3-4SR1S

Is it possible for static to exist on a PRI circuit for an individual channel?

I always thought that PRIs run very clean or they are down and do not run at all.

At the site there is about 15ft of wire going from the phone block over to our router.

I am wondering if this wiring is bad or if the RJ45 on the end of it is bad?

There are also some wire pairs that AT&T punched down on the phone blocks and I wonder if they could be bad?

Paolo Bevilacqua Tue, 05/20/2008 - 12:22

First of all, go over the following if you didn't that already:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800a9982.shtml

Then, I recall of bugs that introduced static in the ip phones, but can't find the details now.

You T1 circuits are fine, either you have 15ft or 15 miles of patch doesn't change, as the circuit shows 100% clean from show controller. Your understanding of phone t1 is correct.

Finally, there is a _slight_ chance that some telco problem is introducing the noise. To prove that, they would need to come onsite with a portable call generator and make test calls.

phretbored Tue, 05/20/2008 - 12:31

Thanks for the link I will check that out in detail.

For making test calls with a "portable call generator" do you mean a BUTT SET?

I have one of those.

Actually why did I not think of it before.

I might be able to clip onto the phone block PRI pair and make test calls to and from the BUTT SET and see if the static occurs.

Paolo Bevilacqua Tue, 05/20/2008 - 12:36

That is a expensive and sophisticated buttset that you need, a digital one. But if you can try that, it's a good test no doubt.

Paolo Bevilacqua Tue, 05/20/2008 - 12:42

Telco has te right one, worry not. They could be hesitant to make a truck roll for a test that 99.9% is negative, however.

phretbored Tue, 05/20/2008 - 14:39

I mentioned the problem to an colleague who has dealt with this type of problem before.

He suggested to make test calls after hours and monitor what channel is being used for the call.

If the test call is clear then shut down that channel and continue making test calls.

If one of the channels has static then that would isolate the trouble and it could be looked into further at that point.

I am going to try that and see what the results are.

Paolo Bevilacqua Tue, 05/20/2008 - 14:47

Well I'm not quite confident that these suggestions will help. First of all, on PRI unlike CAS, you cannot shutdown channels at will. For incoming calls, the switch will tell you on which channel the call comes, either you take it there or the call is lost. This said if you can find a channel where you consistently have static, that is a starting point. Easy to see wich channles is used with "debug isdn q931" and "term mon".

phretbored Thu, 05/29/2008 - 14:17

The decision was made in the last week to close down the facility where this static trouble is happening...so that means I do not have to pursue this fix any further,

I thought it might be possible to shut down individual B CHANNEL INTERFACES...but the router does not allow that.

Actions

This Discussion