atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's Fax problem caused by RX slips. (T1/Titan5500/5ESS)

Hello everyone! What a wonderful resource I seem to have found today. I'm hoping you can all point me in the right direction to troubleshoot this problem I have been experiencing.

It's long and boring so here's your chance to bail.

Ok so a little info to start.

I work for a CLEC that provides T1 voice and data service to the NJ,DE, and PA areas.

This customer has two T1s with us. One is used for data and the other for voice.

Both T1s come into a Tellabs Titan 5500 DACS over different DS3 facilities and cards. One T1 is then cross connected to a Cisco 7500 for data. The other goes to a 5ESS for voice.

At the customer side, the T1s go into a Carrier Access Adit 600. The data is routed connected to the router card in slot 6. Voice is terminated to a 66 block through FXS cards.

One day the customer calls in to us and complains that she cannot send long/large faxes. We do some homework and to cut right to the chase, find that the voice T1 is taking RX slips but nothing else. The data T1 in the same router is clean with no slips.

We go intrusive on the line and test to a tberd and see no errors at all. Not even slips.

We open tickets with the local carrier (Verizon) and have the line tested outside of normal business hours. They have the same results we do.

If the circuit is broken out to test, the errors stop. When it gets put back together, the errors return. Again, ONLY rx slips.

So, we dispatch out to the customer and replace hardware. Same problem. We then decide to move service from one t1 to another and essentially swap data and voice from one t1 to the other.

The errors followed the service meaning the t1 that was perfectly clean before with data now has rx slips on it with voice. The other circuit that was taking rx slip errors with voice is now 100% clean with data on it.

This is where I think I will stop. I could add more but I would like to see what everyone here may have to add to this.

I have a feeling that it is something simple and easy to many of you and it's probably staring us in the face here but it's being overlooked.

Thanks in advance for any assistance.

Fred

I'm not totally familiar with the Titan. We're using a 532-LS, which is similar. Clocking can be a real PITA in a network.

The first thing I would check would be the timing source on the DS-3's. Check the muxes to see if they are both the same.

From there, I would check the timing in the Titan on the DS-1's to make sure both circuits are provisioned the same. This may need to be checked on the HSPM cards as well.

Two things. By RX slips I assume you mean receive, slips are not directional. Pure slips can only be caused by end user equipment. I'll make it 3 things, if you test good to a T-Berd, I again assume you are removing the customer equipment and therefore removing the source of the slips. You would have to monitor the live circuit using the circuit timing to see the slips.

If you have a T-Berd 224, you can monitor the circuit in both directions.

The Titan 5500 is similar to the 532L, but it is a wideband DCS (3->1). Default setting for timing is "Thru", meaning the Titan will not provide a clock signal (it is transparent).

If the circuit facing the customer is set up as a CST, you can check the setting by using the "RTRV-T1::xxx-xx:(ctag);" command and look for the timing datafield. You could also check the connected side as well (I think DGRs also have the timing datafield).

If the problem follows the device, as opposed to following the T1 it might indicate a problem with a T1 card in the CPE (hardware or software) or even a marginal cable between the CSU (if one is there) and the PBX. Also have the CPE programming checked to make sure that it is timing off of the T1 span as opposed to its own internal clock (aka free-run).

An overnight or over the weekend monitor with the T-Berd might be helpful.

I will check the settings in the DACS when I get in to work in the AM. Thanks for the command.

As for the CPE and the T1 Circuits, please note the following from my original post:

So, we dispatch out to the customer and replace hardware. Same problem. We then decide to move service from one t1 to another and essentially swap data and voice from one t1 to the other.

The errors followed the service meaning the t1 that was perfectly clean before with data now has rx slips on it with voice. The other circuit that was taking rx slip errors with voice is now 100% clean with data on it.

This is what bothers me. The slips only appear on the circuit that is carrying "voice" traffic or terminates on the 5ESS. There's an overwhelming majority of people within my company that seem to believe that the 5E cannot be the problem or it would affect everyone using us for voice. I can sorta buy that but how can they explain movin voice from one T1 to the other T1 and having the errors follow the voice traffic?

Thanks so far for all of the help everyone! Keep it coming. I have a scheduled vendor meet with Verizon in the AM even though they have been testing both circuits clean.

Fred

The errors would follow the T1. You're taking the working T1 and putting it into the CPE that is causing the slips. Pure slips can only be caused by CPE equipment, that CPE can be a DACS, or whatever it terminates in. Once again take your TBerd, and time it off the good circuit while monitoring you will see the slips. The string command for checking for slips is fine, most carriers (Verizon) don't know how to test for slips, they don't care about slips, it's not their problem. If Verizon were causing slips than many thousands of T1's would be slipping. Make sense? The supplier of the clock can't slip.

Thats right, since the problem followed, it must be on the cpe side, or a wierd compatibilty issue between the cpe and CO equipment. Could also be as simple as the cable between the DTI card and the smart jack.

My guess is that you will find the CPE is not set to use the T1 as a timing source.

It is probably set to use an internal driver and unless that internal driver has stratum 0 or 1 accuracy, timing slips will be seen if you monitor the T1 long enough. It might be slow bit slipping, or it could be a full blown free-run condition.

Just to note, we verified that the customer router is configured to time off of the loop.

The 5E (on the opposite side) is a master timing source and is connected to a bits clock.

I did the command you suggested and it appears that both T1s are timing through. So the dacs and T1s are or appear to be configured correctly. The router at the customer prem is set to loop timing. The 5E is a master clock source using a bits clock.

Now what? Leaving in 30 minutes for a vendor meet.

M 8575 COMPLD
"0072-08:CST:PMAID=PM3-0072,TACC=0,IDLECDE=AIS,OOSCDE=AIS,FMT=ESF,GOS=99,ALM=ALW,ALMPF=99,LPRSP=YES,,,
FENDPMTYPE=ANSI403,DS1ADDR=C,CSUADDR=B,TMG=THRU,FLTRC=NONE:PST=IS-NR"
;
RTRV-T1::95-11:8576;


M 8576 COMPLD
"0095-11:CST:PMAID=PM3-0095,TACC=0,IDLECDE=AIS,OOSCDE=AIS,FMT=ESF,GOS=99
,ALM=ALW,ALMPF=99,LPRSP=YES,,,
FENDPMTYPE=ANSI403,DS1ADDR=C,CSUADDR=B,TMG=THRU,FLTRC=NONE:PST=IS-NR"