Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Misdialed (extra) Digits over T-1 point to point

Status
Not open for further replies.

Goodbytes

MIS
Oct 9, 2003
30
US
We have 2 systems tied together via pt to pt T-1, shared with data on Adtran TSU 120 units.

The T-1 rides on channels 13-24, all auto answer lines. Side B pulls dial tone from side A line pool via route/dest codes.

A Side = 6.1 MR XC & 6.1 MR MICS (wi 6.10)
B side = 6.1 MR MICS (I think it's also wi 6.10)

Our problem is that side B is getting alot of wrong numbers when dialing long distance numbers across the T-1. We have confirmed extra digits are somehow inserted into the dialing string. These are double digits that might appear randomly, anywhere in the dialing stream, but typically after the 9,1 is dialed to access the Side A local analog line pool. So it doesn't seem like anything is inherently wrong with the way we programmed our route/destination codes. This problem happens from multiple phones on side B so it's not a touchtone pad issue.

Also, the wierd part is that when dialing across LOCAL analog lines from side B (which is supposed to be only for backup if the T-1 goes down), there is NO misdialing problem. And dialing specific extensions from B to A never miss a digit. And side A calling Side B has no problems.
We have swapped combo (timing) cards on both sides with no luck.

Any ideas about where the problem lies?? We want to fix this problem b4 we upgrade to PRI pt to pt & Centralized VM.

I know we should upgrade the NVRAM (side A) to Rel 02 though I'm a bit gun shy based upon previous negative experiences.

There seems to be conflicting information regarding NVRAM upgrades and too many people wind up losing programming. Is it true that the system programming is stored on the KSU backplane and that only the Services Modes are stored on the NVRAM?

I've got the NRU 10.0 that is currently available on Nortel's website, + 8 additional map files that allowed me to do a simple backup (though I could not get the Workbook to back up due to a map file issue). Don't have access to NRU 11.0 so I'm REALLY hoping that my version doesn't leave me in a bad spot when it comes time to do a Restore.

Can anyone confirm the proper step by step procedure for this? Should an upgrade tool be used?

Sorry for the long post. Any input would be very much appreciated.



 
Did you enable the remote packages on site A that is are you allowing the trunks that site b dials out on (in to site a) to access the outside trunks on site a? also have you put a digit grabber on the outside lines on site a and seen exactly what digits are showing up on you? can you duplicate the digits outpulsed to the digits dialed each time? and also look closely at the route and destination codes at site a.

----------------------------
JerryReeve
Communications Systems Int'l
com-sys.com

 
jerryreeve,

Thanks for your input. We have enabled remote packages on site A. We're trying to line up a digit grabber for further testing but can't try that one just yet. The lines do not seem to behave predictably when dialing out from side B. Sometimes we'll reach 3 different wrong numbers for the same number dialed.

However, if we use the redial button, we have not seen it misdial so the system seems to like fast digits as opposed to slower, manual dialing. I've played just a little with the T-1 line build settings but haven't had a chance to give that a really thorough test.

I still plan on taking a harder look at the route/destination codes, perhaps eliminating all of them and then rebuilding them. Also tweaking the absorb settings.

Hoping it's not a marginal T-1 issue or a software glich on either side.

So there's still a few things to try. We're currently routing all LD calls over the local analog lines on side B until we can get some answers.

I'll keep you posted....
 
What type of device are you dialing from? SPecifically are you doing this from a digital phone or from an ATA attached device?
 
Blotnik, we are typically dialing from T7316e sets or a m7324 set. I do have access to several Polycom's connected to ATA's. Perhaps I should try those just to see if they exhibit problems as well...
 
Have you looked at your Error Logs? especially your T-1 log. Look for timing issues, slips, etc. What is your clocking source?
You mentioned working on your routing and dest. codes. Either they are right, and work, or they are wrong and won't route properly. Have never seen routing behave intermittently.

MarvO said it
 
It actually sounds like a timing problem, not the T1 timing but rather the timing of how long it may take for the telco to get dial tone to you after you go off hook. (maybe not either)

Try to connect up a butt set and digit grabber to your outgoing trunk on your main site (the copper telco lines) and listen to calls that are made out from the other site. I'll bet you will hear what is happening when the calls go to dial tone hell.

then when you have exact symptoms you/we will be able to take a stab at eliminating the problem

----------------------------
JerryReeve
Communications Systems Int'l
com-sys.com

 
jerryreeve,

I've done the butt set test on the outgoing trunk and confirmed the following:

- The T-1 circuit is not the problem. We have the same problem when we put the 2 ksu's side by side (completely eliminating the T-1 circuit, data and Adtran units) with a T-1 crossover cable connecting the T-1 cards together.

- Extra digits ARE being generated at random when calling through to the pool A on the primary system.

- There are no route/destination codes for side A. Just a line pool access code.

- The clocking source is the Adtran units. But we have tried different combinations of csu on/off, primary/secondary, etc. No luck there so far.

- The error logs on side A show
EVT 889 (remote access timed out waiting for a response
from parser)
EVT 825-00FC001700 (network monitor error)
EVT 656 (? internal software error, but I'm not clear on this one)

- We can duplicate the condition of extra digits being pulsed out, though it's completely random (we hit a 7, the system pulses out 2 sevens in sequence).

So I think I'm getting down to either a hardware problem, or a software glich. Guess I'll pick up another DTI card and swap it out on each side to see what happens.

Wondering if something about the analog lines in line pool A is marginal, so that when we add in any extra variables they hiccup. But we have never seen them fail when calling out directly from side A so doubt that would yield anything.

Not relishing the thought of completely reprogramming this system by hand (just to eliminate the possible variable of a glich in the software).

Thanks for your previous ideas. Guess I'm still open to suggestions....
 
Let's look at this problem this way.

follow a routed call all the way thru your site B and then thru your site A. by that look at and verify the programming for each step that a call will go thru.

ie: Site B
Extension 221 dials number 918885551212
Destination code 91 handles the call by passing it to Route 91
Route 91 does dialout 91 using PoolA
Pool A (trunk of T1)
Public DN for 91 is 12

then go thru the same for site A

Post this back here and we can go thru it item by item for your routing.

----------------------------
JerryReeve
Communications Systems Int'l
com-sys.com

 
If you have not upgraded to the NVRAM 2, you should really do this despite what you have heard. If you follow the guidelines given to you, everything should go ok.
 
NorstarWiz, I did the NVRAM 2 upgrade (I'm thankful that it went smoothly). Still have same problem.

jerryreeve, I think I might have found at least part of the problem. All of the analog RBOC lines (Side A) are measuring higher than specified milliamp current (mid 30's and higher readings). I placed some resistors on several of the lines and noted some improvement. It also seems that when I moved all of my lines out of Pool A, things improved as well. Some of the line cards may be marinally damaged? My next step is to call in SBC to try to get them to bring them into proper spec.

So the saga continues but I'll keep you posted...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top