home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / dcom / telecom / 12481 < prev    next >
Encoding:
Internet Message Format  |  1992-12-13  |  6.1 KB
  1. Path: sparky!uunet!spool.mu.edu!telecom-request
  2. Date: Sat, 12 Dec 92 16:45:00 -0600
  3. From: bill.garfield@yob.sccsi.com (Bill Garfield)
  4. Newsgroups: comp.dcom.telecom
  5. Subject: Re: Wanted: Help With Multi-Tech/Courier Modem Problem
  6. Reply-To: bill.garfield@yob.sccsi.com (Bill Garfield)
  7. Message-ID: <telecom12.901.5@eecs.nwu.edu>
  8. Organization: Ye Olde Bailey BBS - Houston, TX - 713-520-1569
  9. Sender: Telecom@eecs.nwu.edu
  10. Approved: Telecom@eecs.nwu.edu
  11. X-Submissions-To: telecom@eecs.nwu.edu
  12. X-Administrivia-To: telecom-request@eecs.nwu.edu
  13. X-Telecom-Digest: Volume 12, Issue 901, Message 5 of 5
  14. Lines: 108
  15.  
  16. description of modem dialback problem deleted ...
  17.  
  18. > Is it possible that the local telephone lines are affecting the
  19. > signal, whereas the long-distance has *some* difference that would
  20. > account for the weird behavior?
  21.  
  22. Yes -- but good luck in attempting to prove it to the phone company.
  23.  
  24. I just SUCCESSFULLY solved a long-standing similar problem with a
  25. local customer here in Houston (but two telco central offices away)
  26. who, often as not, could *NOT* get a facsimile transmission to go
  27. through from their office to mine. The failure rate was an alarming
  28. 60% on the average. We fought it for almost a year, different fax
  29. machines, different extensions, same deal, only this ONE customer
  30. could not fax to us, and the problem was only one direction.
  31. Practically drove us cuckoo.
  32.  
  33. The problem turned out to be inter-machine trunk (IMT) trouble between
  34. two of Bell's larger Houston central offices. (We suspected this was
  35. the problem some months ago, but were in a quandry as to how to
  36. convincingly pose our dilemma to the teledroids answering the phones
  37. at Repair Service) ;)
  38.  
  39. My solution involved having the fellow at the other end "route" or
  40. "call forward always" an extension on his PBX to an extension on my
  41. pbx via the public-switched telephone network.  I then dialed the
  42. "remote" telephone number which caused the phone on the other side of
  43. my desk to ring. When I answered the call, it naturally passed VOICE
  44. flawlessly.  I called it several more times, flawless voice every
  45. call.  Finally, for grins, on one of the calls, I held down the 9 and
  46. # buttons on 1 phone (1477hz) and LISTENED to the tone coming through
  47. the other phone.  One direction the tone came through fine.  Going the
  48. other way, the tone had suddenly acquired a pulsating
  49. "bling-bling-bling-bling-bling" about 10db down from the tone and at
  50. approx 2 ips.  I tried holding down the 1 and 2 buttons (697hz), and
  51. the pulsations were still there, but now you had to really listen to
  52. hear them.
  53.  
  54. Over on my mdf, I connected a Halcyon Transmission Test Set (tone
  55. generator) to the outgoing line (set for -13dbm) and put my Sage 930A
  56. D & I test set on the inbound T-1 span coming from Bell. With the
  57. Halcyon generating standard 1004hz test tone, the pulsations were
  58. barely noticeable.  These became very pronounced as the frequency was
  59. raised above 1300hz. By the time I got up to 2000hz the
  60. "bling-bling-bling" was _very_ distinct ... you couldn't miss it.
  61.  
  62. I called the PBX tech at the other end and had him listen in on his
  63. incoming and outgoing trunks.  As expected, the tone passing through
  64. his office was clear.  I next removed my tone generator and had the
  65. pbx tech at the other end put his generator on the circuit toward me.
  66. I was still getting the "bling-bling-bling" pulsations.  I had him
  67. decrease his level by 20db, still "bling-bling-bling-bling".
  68.  
  69. I got Southwestern Bell's special services folks in on it and asked
  70. them to trace the call through the various central offices, making
  71. note of the fact that the "bling-bling-bling" wasn't there at the
  72. originating end, and emphasizing that the whole purpose of the trace
  73. was to try and determine at what point in the call's routing were the
  74. pulsations being introduced.  I emphasized to them, "It is not an
  75. errant call, please do not knock it down, just trace it cable and
  76. pair, span and channel."
  77.  
  78. After some 4-1/2 hours and a visit to my office by a SWB Special
  79. Services tech (after I escalated the problem up to a third level
  80. supervisor), the problem suddenly cleared, just like magic.  "Came
  81. clear while checking" was the response.  Horsefeathers!  Something
  82. that has haunted us for the past 11 months doesn't magically go away.
  83.  
  84. Back on the phone to the third level supervisor, I was adamant that I
  85. had to have a logical and plausible resolution report, and that "Came
  86. clear while testing" wouldn't sit well upstairs with my people.
  87.  
  88. The following day I received a call from a first line supervisor
  89. informing me that a Bell interoffice tech found and pulled down a
  90. loopback off of an unused but "mated" T-1c (48 channel) system.  They
  91. (Bell) had been taking "density errors" on an inter-office T-3 span
  92. for a long time but had ignored the alarm condition as seemingly no
  93. one had complained, and of course ordinary voice passed through just
  94. fine.  (Mated systems cannot be placed in loopback because of clocking
  95. problems, or so I'm told).
  96.  
  97. Well now, all of a sudden everyone's fax machine works just fine.
  98. 14.4k bps modems which had trouble staying linked at 2400 began
  99. working at full speed and two local bbs' report remarkable
  100. improvements in callers' ability to link with them.
  101.  
  102. FYI:  I coincidently happen to be a Multi-Tech field beta test site
  103.       and the MT1432BA/A is, IMHO, one of the finest products they have
  104.       ever built.  1.02A firmware is the current release & is stable.
  105.       It uses an AT&T data pump.  I am unfamiliar with the Courier
  106.       2400E.
  107.  
  108. Something else you might try.  On the Multi-Tech, disable v.42 error
  109. checking in favor of plain vanilla MNP-4.  The Multi-Tech string to do
  110. this is; AT&E1&E14#L1 and be sure to "store" it with AT&W0. This has
  111. _frequently_ worked with some unfriendly USR's.
  112.  
  113.  
  114. bill.garfield@yob.sccsi.com (Bill Garfield) | Standard disclaimer applies.
  115. PBX/Datacom Specialist                      | Opinions are my own and not
  116. Panhandle Eastern Corp                      | those of my employer. I speak
  117. Voice: 713.627.5228                         | for no one.  I am not an
  118. Data:  713.520.1569                         | employee nor representative
  119. FAX:   713.627.5285                         | of Multi-Tech Systems, Inc.
  120.  
  121. Ye Olde Bailey BBS   Houston,Texas   Node 1: 1 713 520 1569  yob.sccsi.com
  122.  
  123.