web statisticsweb stats

Business Phone Systems

Previous Thread
Next Thread
Print Thread
Rate Thread
Page 1 of 6 1 2 3 4 5 6
Joined: Oct 2006
Posts: 122
Member
OP Offline
Member
Joined: Oct 2006
Posts: 122
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. smile

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

Atcom VoIP Phones
VoIP Demo

Best VoIP Phones Canada


Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.

Joined: Oct 2005
Posts: 160
Member
Offline
Member
Joined: Oct 2005
Posts: 160
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.

Joined: May 2002
Posts: 17,722
Likes: 18
Member
****
Online Content
Member
****
Joined: May 2002
Posts: 17,722
Likes: 18
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.


Retired phone dude
Joined: Dec 2005
Posts: 9,167
Likes: 8
Spam Hunter
*****
Offline
Spam Hunter
*****
Joined: Dec 2005
Posts: 9,167
Likes: 8
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 Love FEATURE 00
Joined: Oct 2006
Posts: 122
Member
OP Offline
Member
Joined: Oct 2006
Posts: 122
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

Quote
Originally posted by dexman:
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.

Joined: May 2002
Posts: 17,722
Likes: 18
Member
****
Online Content
Member
****
Joined: May 2002
Posts: 17,722
Likes: 18
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.


Retired phone dude
Joined: Apr 2001
Posts: 1,390
Member
Offline
Member
Joined: Apr 2001
Posts: 1,390
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.

Joined: Dec 2005
Posts: 9,167
Likes: 8
Spam Hunter
*****
Offline
Spam Hunter
*****
Joined: Dec 2005
Posts: 9,167
Likes: 8
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.


I Love FEATURE 00
Joined: Oct 2006
Posts: 122
Member
OP Offline
Member
Joined: Oct 2006
Posts: 122
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.

Joined: Oct 2006
Posts: 122
Member
OP Offline
Member
Joined: Oct 2006
Posts: 122
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? smile 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"

Page 1 of 6 1 2 3 4 5 6

Moderated by  Silversam 

Link Copied to Clipboard
Forum Statistics
Forums84
Topics94,315
Posts638,924
Members49,775
Most Online5,661
May 23rd, 2018
Popular Topics(Views)
213,113 Shoretel
190,318 CTX100 install
188,696 1a2 system
Newest Members
Kahm310, PeterG, lyte, 4thright, dcl
49,775 Registered Users
Top Posters(30 Days)
Toner 17
jsaad 4
dans 4
Who's Online Now
3 members (nortelvoip, nonameyet, justbill), 115 guests, and 49 robots.
Key: Admin, Global Mod, Mod
Contact Us | Sponsored by Atcom: One of the best VoIP Phone Canada Suppliers for your business telephone system!| Terms of Service

Sundance Communications is not affiliated with any of the above manufacturers. Sundance Phone System Forums - VOIP & Cloud Phone Help
©Copyright Sundance Communications 1998-2024
Powered by UBB.threads™ PHP Forum Software 7.7.5