I am in a bit of a situation and need some advice/help on how to "fix it". Basically bellsouth, in a very rural town, installed us 3 CT1 circuits. We ordered these all provisioned the same. They had to reprovision them multiple times, because they couldn't get it right, and its really costed me alot of time, and our customers alot of patience in that particular pop. So, finally Bell is saying the provisioned right. I am not able to complete call on it however, the calls arrive, but don't complete. Smells of a bad start type to me........I can plug the other 2 CT1's into that same equipment and it works fine (3 hdm's all configured the same, 3 CT1's all configured the same). So basically, on Tuesday, I am having to go onsite with a bunch of engineers, which I know is just going to be one big pissing contest. I have assembled a list of information off the chassis/dsp's, to help me battle this, but I don't know if perhaps I am leaving out something critical that can really be of help. Some of the info I got is: Trunk Settings This shows all 3 CT1's configured identical Timeslot Service Configuration This shows all 3 CT1's channels inService Performance Monitor Physical States - All 3 psF1Operational Line Status - All 3 "1" No Idle Modem Available - All 3 "0" Transmit / Receive Carrier Levels The good channels all show about 1820 transmit and 1820 receive. The third CT1 shows 0 for transmit and 0 for receive Incoming Connecions established vs. terminated Good spans show about 900 for these Third span shows very messed up numbers for these Signal to Noise Ratios Third span shows signal to noise at like 65536!!! Whats the best data to throw at the telco? And as if this isn't enough. The 3 CT1's are in a hunt, first available. This town takes very few calls. But I can watch literally 5-10 calls per second come in on CT1 #3, yet 1 and 2 have idle channels! The amount of calls arriving on span3 HAVE to be a call simulator that the telco has hooked up to the line to test it........something they are doing without my permission, and something they are denying, I think they left it turned on and forgot to turn it off. At the end of the day, spans1 and 2 saw like maybe 500 calls, and span3 has seen like 50,000 calls. This is in an area with about 300 customers........sigh. I have no way of even dialing into span3, its only got 1 DID into the hunt. Which like I said is first available. ----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Is everyone else having individual modem problems on the latest DSP code? We seem to have modems always causing problems and going out on us. We never had modems do this in the past and never even considered a Bad Modem Script to let us know modems were out or having problems. Now it is something we HAVE to have or we can't sleep at nights... constantly getting calls from customers letting us know there are fast busy signals, no tone, terrible speeds, or just cannot connect. What is going on? Anyone know? Is this a bug in the latest code? Or better yet should 3com just scratch everything and give us all our money back? (getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for almost 4 years so we are fairly aware if it is Telco, TC or a config issue.... it's definitely the TC code or Hardware. Any work arounds or solutions known? Between the bad modems, the V90 issue and the support issues I don't see how anyone is happy with 3com right now... it's giving us one hell of a headache! Ed - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
My experience is that modems will no pick up/hang in ANY code. I just went from 2.0.19 to 2.0.81 and a modem hung this weekend. 1125 calls failed. Looking at the release notes for 2.0.81 they did fix the software reset issue (big plus) but you should expect to see a modem hang every now and then. Monitor the equipment (simple perl script) or have the NMC card fire off a trap or syslog and look at that. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 17 Oct 1999, Ed wrote:
Is everyone else having individual modem problems on the latest DSP code? We seem to have modems always causing problems and going out on us. We never had modems do this in the past and never even considered a Bad Modem Script to let us know modems were out or having problems. Now it is something we HAVE to have or we can't sleep at nights... constantly getting calls from customers letting us know there are fast busy signals, no tone, terrible speeds, or just cannot connect.
What is going on? Anyone know? Is this a bug in the latest code? Or better yet should 3com just scratch everything and give us all our money back? (getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for almost 4 years so we are fairly aware if it is Telco, TC or a config issue.... it's definitely the TC code or Hardware. Any work arounds or solutions known?
Between the bad modems, the V90 issue and the support issues I don't see how anyone is happy with 3com right now... it's giving us one hell of a headache!
Ed
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
participants (3)
-
Brian -
Ed -
farber@admin.f-tech.net