PRI Channel specific outgoing problems on Legend 4

[holly7wood]

Background: Legend with a PRI having no incoming DID problems, but there are sporadic outgoing completion problems. The PRI has been in place for 3 years problem free until the current problem came up and it seems to have progressed over the last month or so from mildly annoying to service affecting. The customer uses MLX sets with forced account code and there are acct. code buttons on every set. For LD calls the they dial an account code, #, 9, and the tel. no. There is also a "local" button programmed with the user's sta. no., #, 9 to speed up local calls.

On the error report, there are multiple hits to error code 7002 "PRI SVC STATE INCONSIST" on channels 23-18, with the most on chan 23 and less for each lower chan.

When you make a call, the display looks the same whether the call goes through or not. After the ARS determines the trunk group to use (all outbound uses the PRI) the trunk ID comes up and the number dialed. After a pause, fast busy is heard.

This problem is intermittent. Customer believes more prevalent on LD than local and occurs more often later in the day. I think their calling patterns tend toward more LD and later in the day anyway.

The DS1 card has been software reset, busied out/restored, removed and inserted, T1 connection removed, system cold restarted, and the programming checked .

I've done many PRI's and I don't remember one with problems that seem to be so channel specific. AT&T has busied out chan. 23 and 22 to see if the problem shifts and is monitering the line. Their current take on this issue is that there may have been some slips on the line, but the problem exists with the premise equipment. I have the customer trying to log problems noting the usual time,date,etc. perameters.

I have scanned all the postings at this site and I have not found the direction I seek. I do realize that the solution might be right in front of my eyes. Chastising and all manner of ribbing will gladly be accepted with your help.

Programming wizards, Legend experts, and network gurus unite and please come to my aid

 

[memphisribs]

It sounds like you are losing signaling across the PRI. I would ask AT&T to send out a tech for a out of service stress test on the T. Good luck

40 years in the business and counting.

 

[dagwoodsystems]

I'm with memphisribs on this one. If the span is having physical layer problems, then it makes sense that the D-Channel is falling down (probably the source of the PRI service state alarms). I would expect the errors to increase--and thus the amount of service affecting down time to increase--as the PRI gets filled. More phone calls=more instances of failure.

If you don't have an external CSU, make sure that the built-in CSU is activated. Check the CSU for for CRC errors, frame slips and the like. This will probably be done from the front panel of an external CSU, or with WinSPM on the built-in CSU.

But without having to know anything technical, you can certainly ask the carrier if they will perform loopback testing. This WILL affect your ability to make calls, so schedule it accordingly.

____________________________
Any sufficiently advanced technology is indistinguishable from Magix. --Arthur C. Clarke (imbellished).

 

[holly7wood]

Thank you memphisribs and dagwoodsystems. We have the D100 card with an external Verilink T1 ESF CSU. It can do some loopbacks, for and aft, and there are some status lights, but it isn't like the Paradyne CSU/DSU's with all the programming, etc. The status lights haven't told me anything is wrong. AT&T had no report on their monitoring yet, but they did say they could send a tech out for the end/end testing. Trying to schedule all of us on prem together.

The customer said that he was still having problems today so it looks like the busyout on those channels didn't change anything.

I'll probably be back out on site this PM.

28 years in the business--and feeling it!

 

[SYQUEST]

Do you know what design the DS1 loop has? Is it an HDSL or copper DS1?

If it is an HDSL design it could be a local loop problem, where an HDSL loop issue is affecting the DS1 payload on the HDSL path. This is a common occurance with HDSLs where the DS1 payload is affected but no DS1 alarms are generated because the only way to get one is for the HDSL to fail completely (no power). You might look at the NIU and see if it shows any CRC conditions (LEDs lit). Telco should be able to query the HTU-R module (NIU) and see what the history shows for HDSL performance.

Hope this helps!

....JIM....

 

[dagwoodsystems]

There are really two common ways to bring a standalone T1 to a customer site. One way is to use a true 4-wire T1, possibly with repeaters. SYQUEST is right; the combination of events he talks about doesn't occur on this type of T1.

The other way to do this is to use a HTU-R (Remote) two-wire to 4-wire converter. It's kinda like converting QAM DSL signalling to garden variety T1 signalling. Anyway, if you can "see the matrix" and know your way around a phone closet, look for a single wire pair on the line side of the NID. One pair on the "in" side is the teltale sign.

I don't recommend using Hyperterminal or ProComm with a serial cable to access the device history, unless you're fearless. q:^Þ That's best left for the telco.

____________________________
Any sufficiently advanced technology is indistinguishable from Magix. --Arthur C. Clarke (imbellished).

 

[SYQUEST]

Hi dagwoodsystems,

Actually, the HDSLs use 2B1Q modulation instead of QAM.

The example of how HDSL with a T1 payload works, that I like to use is: "spread spectrum on 2 copper pairs" (refering to spread spectrum microwave transmission).

An interesting observation I have made recently about 2-wire HDSLs in Pacific Bell territory, they have been replacing some of them with 4-wire HDSLs, when they have problems. Which by the way is the only way I would let them install one if I was ordering one. There is NO way I would trust a DS1 circuit to a single pair!

The conventional T1 on copper, I refer to as a "copper repeatered T1 or DS1". They have repeaters spaced about every 6000' of cable. In the HDSL world the "repeater" equivalent is called a "doubler" or an "HRE" as Adtran calls them.

....JIM....

 

[dagwoodsystems]

Ah yes, 4 bits per baud. I guess no one told me that my modem was showing. I see good times in an email exchange or two with you. Write me if you have a minute, Jim.

http://www.dagwoodsystems.com.

--Tim

____________________________
Any sufficiently advanced technology is indistinguishable from Magix. --Arthur C. Clarke (imbellished).

 

[holly7wood]

Belated greetings and thanks to memphisribs, SYQUEST, and dagwoodsystems.

Your posts all pointed to the operating company, which I suspected housed the problem all along. We have resolution! However, I waited to see if we had lasting resolution before I shared the verdict. I now humbly come to report - the rest of the story.

Bottom line, the circuit lost it's trouble and has remained trouble free for almost 30 days since I changed the processor.

AT&T monitered the circuit, sent someone onsite to test, and kept pointing the finger. Since I had tried everything else, I backed up the R7 and replaced it with a refurb from my trusty repair center.

I did find out that the circuit was 2 wire. I still am under the impression that they did something to the circuit, either in the testing process or by other means to correct the problem. All I know for sure is that when I left the site at 8:15PM (5'th visit) there were no problems and we're still clean. By the way, there were no other indications that the original processor had any other problems.

I know this resolution may not satisfy our technical curiousity, but it's not the first time. The customer is happy and still trusts me. Life is good.

I can only hope this thread helps someone else.

Thanks again,

holly7wood

 

[dagwoodsystems]

Thank you very much for posting back.

The processor could very well have been the problem. However, a three year trouble free history prior suggests that something is stinking in Denmark. Allow me to support your suspicion for a moment.

In nineteen years, I can count two handfuls of occasions where I've flat lied to the carrier. "Well, I've replaced the whole dang system and the CSU now. There's nothing more that I can do." I've even allowed the carrier to talk me into rebooting the switch a number of times (I just play dumb and say, "Well, it couldn't hurt I guess"). Low and behold, in the time it takes to reboot the switch a second or third time...the problem disappears. "Golly, Mr. Telco. I'm so sorry. It musta been my PBX all along."

I know. But all you can do is let 'em off the hook. Trust me, telco deals with PLENTY of idiots out there. It's really no wonder that they always suspect the CPE equipment first. Ultimately, this is just one of those pain-in-the-rear things that the good techs have to overcome once in a while.

I'm glad everything is working...regardless of the problem source.

____________________________
Any sufficiently advanced technology is indistinguishable from Magix. --Arthur C. Clarke (imbellished).

 

[oldavayaguy]

OK, I know I am rather late to add to this post, but here is my take:

ANOTHER TELEPHONE MIRACLE has happened.

Just as Dagwood said, I have told them I have re-booted, replaced and all other things, just to see there stuff MAGICALLY START TO WORK, with none of the above.

But, I can also admit to failing to set that "ONE THING" that fixed the problem.

More than often however, it was the "MIRACLE", much like you have experianced.

So, when you have a chance, and the Phone System is not that busy, PUT THE OLD PROCESSOR BACK IN, and see what happens.

GOOD LUCK!