home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 (Alt) / The_Hacker_Chronicles_Volume_II-CD2.iso / td2 / td14_128.txt < prev    next >
Encoding:
Text File  |  1995-01-03  |  22.2 KB  |  540 lines

  1. TELECOM Digest     Sat, 12 Mar 94 01:09:00 CST    Volume 14 : Issue 128
  2.  
  3. Inside This Issue:                           Editor: Patrick A. Townson
  4.  
  5.     Re: Competition and Technology (Andrew Hassell)
  6.     Re: Competition and Technology (Bob Goudreau)
  7.     Re: Question About Random Dialing (James Gray Walker)
  8.     Re: Question About Random Dialing (John R. Levine)
  9.     Re: Internet Conferencing (Lars Poulsen)
  10.     Re: Digital Cellular Phones (puma@netcom.com)
  11.     Re: Measuring Network Availability (Al Varney)
  12.     Re: ISDN BRI to IXC? (Al Varney)
  13.     Re: ISO Country Codes (Aaron Leonard)
  14.     Re: Why Caller-ID Instead of ANI? (Clarence Dold)
  15.     Re: Prisoner Starts Own 900 Number (Steve Forrette)
  16.     Re: New Area Code Change Question (Mike Quinlin)
  17.     Obscene Caller Nabbed by Voicemail (Milwaukee Journal via puma@netcom.com)
  18.  
  19. TELECOM Digest is an electronic journal devoted mostly but not
  20. exclusively to telecommunications topics. It is circulated anywhere
  21. there is email, in addition to various telecom forums on a variety of
  22. public service systems and networks including Compuserve and GEnie.
  23. Subscriptions are available at no charge to qualified organizations
  24. and individual readers. Write and tell us how you qualify:
  25.  
  26.                  * telecom-request@eecs.nwu.edu *
  27.  
  28. The Digest is compilation-copyrighted by Patrick Townson Associates of
  29. Skokie, Illinois USA. We provide telecom consultation services and
  30. long distance resale services including calling cards and 800 numbers.
  31. To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone 
  32. at 708-329-0571 and fax at 708-329-0572. Email: ptownson@townson.com.
  33.  
  34.     ** Article submission address only: telecom@eecs.nwu.edu **
  35.  
  36. Our archives are located at lcs.mit.edu and are available by using
  37. anonymous ftp. The archives can also be accessed using our email
  38. information service. For a copy of a helpful file explaining how to
  39. use the information service, just ask.
  40.  
  41. TELECOM Digest is gatewayed to Usenet where it appears as the moderated
  42. newsgroup comp.dcom.telecom. It has no connection with the unmoderated
  43. Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
  44. Digest" shares archives resources at lcs.mit.edu for the convenience
  45. of users. Please *DO NOT* cross post articles between the groups. All
  46. opinions expressed herein are deemed to be those of the author. Any
  47. organizations listed are for identification purposes only and messages
  48. should not be considered any official expression by the organization.
  49. ----------------------------------------------------------------------
  50.  
  51. From: synaptec@netcom.com (Andrew Hassell)
  52. Subject: Re: Competition and Technology
  53. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  54. Date: Sat, 12 Mar 1994 00:49:40 GMT
  55.  
  56.  
  57. Stewart Fist <100033.2145@CompuServe.COM> writes:
  58.  
  59. > Jerry Leichter <leichter@lrw.com> writes:
  60.  
  61. >> I have great respect for competition, but I have yet to see a sound
  62. >> argument that the advance in services available *since* deregulation
  63. >> is signficantly different from the advance *before* deregulation -
  64. >> AFTER CONTROLLING FOR THE EXTRAORDINARY ADVANCE IN APPLICABLE
  65. >> TECHNOLOGY. 
  66.  
  67. > I couldn't agree more.  I've just spent a lot of time analysing the 
  68. > long-distance charges (and the changes thereof) from country A to country B 
  69. > using a range of figures produced by the OECD, for a commissioned report.  
  70.  
  71. > It is difficult stuff to analyse, but one thing became quite clear.
  72. > There's been no more drop in international long-distance call prices
  73. > in advanced (OECD) countries with competitive regimes than there has
  74. > in those with monopoly regimes.  I must say I was surprised at these
  75. > findings, because the monopolies actually did slightly better --
  76. > although the difference wasn't significant.
  77.  
  78. Hmm. I would probably be in the contra camp based on recent Australian
  79. experience with the adjustment from monopoly to duopoly for mainstream
  80. long distance carrier services. Did your report cover this market
  81. Stewart?
  82.  
  83. > When you dig down to the bottom, the problem is that in an era where
  84. > long-distance connection abundance is the norm (except that in many
  85. > cases this is being deliberately knobbled) the normal competitive
  86. > market forces do not apply in the way that conventional economics says
  87. > it should.
  88.  
  89. I'd interested to know if your report will be available to folks
  90. outside your commissioning parties. For my 2c worth here, I think
  91. there is a lot of economic sense in monopolizing elements of
  92. infrastructure to take advantages of economies of scale. A beautiful
  93. example would be the information hype-a-highway. Does it make sense to
  94. have multiple fibre connection by multiple carriers? This must be
  95. regulated for sure. Maybe a first carrier in best dressed situation
  96. with Government regulated access and cross access provisions would be
  97. optimal. However, what about outlying areas, less economic areas,
  98. rural areas etc. Would some form of monopoly handle this more
  99. efficiently that a tightly regulated duopoly or oligopoly? Who knows.
  100. These issues are tough but I think you hit it on the head in part of
  101. your post. How can regulators ensure that excessive profit taking is
  102. eliminated in telecommunications? Argument one that you will probably
  103. never escape from alive is the politics of this, you communist! -)
  104. [sic] Argument two is how you actually achieve the objective through
  105. structuring the industry and regulating it. The objective could be to
  106. allow a small fair return on investment, thus encouraging maximum
  107. investment in capital works.
  108.  
  109.  ... but enough nonsense on a lazy Saturday morning. This is la la land.
  110.  
  111.  
  112. Andrew Hassell   synaptec@netcom.com   - a technology marketer
  113. Sydney NSW, Australia   Tel: +61 2 555 9560    Fax: +61 2 818 2878
  114.  
  115. ------------------------------
  116.  
  117. Date: Fri, 11 Mar 1994 16:32:02 -0500
  118. From: goudreau@dg-rtp.dg.com (Bob Goudreau)
  119. Subject: Re: Competition and Technology
  120.  
  121.  
  122. Stewart Fist <100033.2145@CompuServe.COM> writes:
  123.  
  124. > It is difficult stuff to analyse, but one thing became quite clear.
  125. > There's been no more drop in international long-distance call prices
  126. > in advanced (OECD) countries with competitive regimes than there has
  127. > in those with monopoly regimes.
  128.  
  129. Sure, but ask yourself what's driving those monopoly PTTs to cut their
  130. international calling prices: competition from the "competitive
  131. regimes"!  A recent example of this phenomenon showed up recently in
  132. the telecom newsgroups from an Italian reader, who noted that the
  133. Italian telco had recently cut its international rates to levels
  134. competitive with the international call-back services that had been
  135. recently capturing so much of its business.  The advent of those
  136. call-back services meant that Italtel effectively *lost* its monopoly
  137. and was thus forced to compete by cutting prices.  Now, how many
  138. people think those rates would have been cut in the absence of such
  139. competition?
  140.  
  141. A more interesting analysis would be to compare the costs of
  142. *intra*-national long distance calling.  Most monopoly PTTs still do
  143. enjoy true monopolies in that market, while there's certainly plenty
  144. of competition for that business in the US.
  145.  
  146.  
  147. Bob Goudreau  Data General Corporation
  148. goudreau@dg-rtp.dg.com 62 Alexander Drive 
  149. +1 919 248 6231  Research Triangle Park, NC  27709, USA
  150.  
  151. ------------------------------
  152.  
  153. From: walkerj@muc.de (James Gray Walker)
  154. Subject: Re: Question About Random Dialing
  155. Date: Sat, 12 Mar 1994 01:06:36 +0100
  156. Organization: MUC.DE e.V. - Individual Network in Muenchen (Munich)
  157.  
  158.  
  159. In article <telecom14.120.4@eecs.nwu.edu>,  <gaupkg@fnma.COM> wrote:
  160.  
  161. > Is there a shareware program or commercial program available that can
  162. > dial randomly within a given area code and when it comes across a fax
  163. > machine log that fax number into a database. If anyone has any
  164. > pointers I would appreciate it.
  165.  
  166. I find this idea appalling for reasons most anyone can imagine.
  167. Perhaps someone who lives closer to Fannie Mae than I could bring up
  168. the issue of the posting with the poster's employer directly.  I'm
  169. fairly sure Fannie Mae has a policy which would preclude the use of
  170. their equipment for a posting of such questionable ethicality for the
  171. friend of an employee.
  172.  
  173.  
  174. WALKER, James Gray - walkerj@muc.de
  175.  
  176. ------------------------------
  177.  
  178. Date: Fri, 11 Mar 94 19:13 EST
  179. From: John R. Levine <0001037498@mcimail.com>
  180. Subject: Re: Question About Random Dialing
  181.  
  182.  
  183. People planning to troll for fax numbers should keep in mind these two
  184. aspects of a recently passed Federal law:
  185.  
  186. -- All fax calls must have the caller's number displayed on the cover page
  187.    and/or at the top of each page.
  188. -- Sending junk faxes (generally described as faxes not requested or
  189.    permitted by the recipient) is forbidden.
  190.  
  191. Violations are punishable by fairly severe federal penalties.
  192.  
  193.  
  194. Regards from 9600 feet,
  195.  
  196. John Levine, johnl@iecc.com, jlevine@delphi.com, 1037498@mcimail.com
  197.  
  198. ------------------------------
  199.  
  200. From: lars@Eskimo.CPH.CMC.COM (Lars Poulsen)
  201. Subject: Re: Internet Conferencing
  202. Organization: CMC Network Products, Copenhagen DENMARK
  203. Date: Fri, 11 Mar 94 22:59:18 GMT
  204.  
  205.  
  206. In article <telecom14.122.5@eecs.nwu.edu> Ralph E. Todd <rtodd@mason1.gmu.
  207. edu> writes:
  208.  
  209. > Greetings.  I am a graduate student in the Telecommunications program
  210. > at George Mason University; Fairfax, Virginia.  In preparation for a
  211. > term project dealing with organizational learning, I am in search of
  212. > information regarding conferencing on the Internet.
  213.  
  214. > Specifically, I envision a moderated forum supporting concurrent
  215. > access for at least 30 user sessions.
  216. > Is anyone aware of the existence of such a forum?  Any knowledge of
  217. > technology or building blocks which could support it?
  218.  
  219. IRC = Internet Relay Chat is the distributed equivalent of CIS's "CB
  220. simulator" conference tool.
  221.  
  222. Setup a "private" channel, and there will be room for up to a couple
  223. hundred, located anywhere in the world. IRC has provisions for a
  224. moderator who can kick people out of the group if needed. It also has
  225. support for logging the session to a transcript file.
  226.  
  227.  
  228. Lars Poulsen   Internet E-mail: lars@CMC.COM
  229. CMC Network Products  Phone: (011-) +45-31 49 81 08
  230. Hvidovre Strandvej 72 B   Telefax:      +45-31 49 83 08
  231. DK-2650 Hvidovre, DENMARK Internets: designed and built while you wait
  232.  
  233. ------------------------------
  234.  
  235. From: puma@netcom.com (puma)
  236. Subject: Re: Digital Cellular Phones
  237. Date: Fri, 11 Mar 1994 23:18:20 GMT
  238.  
  239.  
  240. In article <telecom14.123.9@eecs.nwu.edu> stevef@wrq.com (Steve
  241. Forrette) writes:
  242.  
  243. > In <telecom14.96.1@eecs.nwu.edu>, jrg@rahul.net (John Galloway) writes:
  244. >> But if this key is fixed (since it is not transmited I assume it is)
  245. >> then all the cellular blue box builder need to is disect a phone to
  246. >> get it.  This might not be a trivial opeation, but these crooks are
  247. >> pretty smart fellows.
  248.  
  249. > Are you assuming that the key is the same for all phones?  If the key
  250. > is different for each phone, then the crook would have to get a hold
  251.  
  252. I think the intention here is that each phone has a unique key known
  253. to that phone and the home service provider.  When the phone makes a
  254. call, it encrypts part of the request using the key.  The system
  255. either has the key for that ESN/phone number or asks the home system
  256. for it, and uses it to decode the encoded portion of the request.  If
  257. the decode works, then obviously you are talking to the *real* phone.
  258.  
  259. Seems pretty foolproof, unless you have enough data and time to break
  260. the encryption for a particular phone, or inside information.  It
  261. would at least stop the casual grabbing of ESN/MIN combinations off
  262. the air.
  263.  
  264.  
  265. puma@netcom.com
  266.  
  267. ------------------------------
  268.  
  269. Date: Fri, 11 Mar 94 18:06:09 CST
  270. From: varney@uscbu.att.com
  271. Subject: Re: Measuring Network Availability
  272. Organization: AT&T Network Systems
  273.  
  274.  
  275. In article <telecom14.119.1@eecs.nwu.edu> stacy@sobeco.com (Stacy L.
  276. Millions) writes:
  277.  
  278. > I was involved in a project, where we helped to migrate a companies
  279. > user base from an IBM mainframe / SNA / 3270 terminal environment to a
  280. > UNIX / TCP/IP / vt220 / terminal server environment. I can remember
  281. > one of IBM network type people made a comment about how they guarantee
  282. > their users 99.8% network availability and he was skeptical that we
  283. > would be able to match that in the new environment.
  284.  
  285. > Now my question is simply this:
  286. > How do you
  287. >  a) define
  288. > and
  289. >  b) measure
  290. > 'network availability'? Particularly in the context of
  291. > LANs and WANs.
  292.  
  293.    For some insight into this issue within the public telephone
  294. network, I recommend:
  295.  
  296.    "Public Networks - Dependable", by John C. McDonald in April 1992
  297. issue of IEEE Communications Magazine.  He defines and defends the
  298. concept of measuring the "reliablilty" of public networks using a
  299. log(10) scale of "user lost Erlangs" times "outage time in hours".  In
  300. other words, it is a measure of user impact.
  301.  
  302.    The June 1993 issue of IEEE Communications magazine has several
  303. papers on the measurement of "dependability" and "availability" of
  304. telephone networks.  The consensus seems to be that one must measure
  305. this from the user (or user-to-user) perspective.  Network problems
  306. that have no user impact (because of redundancy, etc.) do not affect
  307. availability.  Problems that prevent a user-to-user connection of
  308. sufficient quality and duration to accomplish a "transaction" do have
  309. an effect on availability.
  310.  
  311.  
  312. Al Varney 
  313.  
  314. ------------------------------
  315.  
  316. Date: Fri, 11 Mar 94 18:25:31 CST
  317. From: varney@uscbu.att.com
  318. Subject: Re: ISDN BRI to IXC?
  319. Organization: AT&T Network Systems
  320.  
  321.  
  322. In article <telecom14.125.7@eecs.nwu.edu> John McHarry <mcharry@access.
  323. digex.net> writes:
  324.  
  325. > If I have an ISDN Basic Rate Interface (BRI) from my local exchange
  326. > carrier and want to place an interexchange data call, how does the LEC
  327. > interconnect with the IXC?  Somebody told me that this has to be
  328.                                                    ^^^^
  329.       Don't know what "this" refers to -- CPE, the LEC CO or what???
  330.  
  331. > hooked to a switched 56kb trunk, but I don't see why the LEC couldn't
  332. > just send it in a regular Feature Group D and tell the IXC it was a
  333. > data call in the SS7 message.  Am I missing something?
  334.  
  335.    Assuming the BRI SETUP specified 56K data rate, the call can travel
  336. over SS7 trunks to the IXC or over "switched 56K" MF trunks.  For the
  337. purposes of data transmission, these trunks are equivalent.  At the
  338. far end of the call, a BRI called party will receive an "ISDN
  339. originator" indication along with the 56K data rate request IF the
  340. call used only SS7 trunks.  A non-ISDN 56K destination will not know
  341. (or care) if the call was ISDN-originated.  In most cases, there
  342. should be no problem interworking with SS7 and/or "switched 56K" MF
  343. trunks.
  344.  
  345.    The opposite is also possible: A non-ISDN 56K originator can call
  346. an ISDN BRI/PRI number.  The SETUP delivered to the destination will
  347. indicate a "non-ISDN originator" and the 56K data rate request IF the
  348. call used only SS7 trunks.  Otherwise, the SETUP will just indicate
  349. 56K data rate request.  Again, the B-channel data looks the same as
  350. from an ISDN 56K origination.
  351.  
  352.    Note that whether or not the IXC wishes to accept such data calls
  353. is up to the IXC.  The LEC CO routing software can provide different
  354. routing for different bearer capabilities -- and it can block certain
  355. bearer capabilities if the IXC or trunk facility can't handle them.
  356.  
  357.    Also, "Feature Group D" usually refers to an MF-signaled trunk.
  358. For clarity, and to avoid confusion with MF-only FG-D tariffs, the
  359. preferred term is SS7 NI (Network Interconnect) trunk or SS7 EA (Equal
  360. Access) signaling/trunk.  I admit some documents use the expression
  361. FG-D trunk with the SS7 option or with SS7 signaling.
  362.  
  363.  
  364. Al Varney 
  365.  
  366. ------------------------------
  367.  
  368. Date: Fri, 11 Mar 1994 17:45:03 MST
  369. From: Aaron Leonard <LEONARD@Arizona.EDU>
  370. Subject: Re: ISO Country Codes
  371. Reply-To: Leonard@Arizona.EDU
  372.  
  373.  
  374. > A few issues back a woman asked for a list of the two-letter and
  375. > three-letter ISO 3166 codes for most countries.
  376.  
  377. > While it does not include the codes for the countries that have been 
  378. > created as a result of others being broken up (such as the Soviet Union 
  379. > and Czechslovakia) one place to look is in my Internet RFC 1394, which 
  380. > also shows international telex codes and worldwide telephone area codes.
  381.  
  382. RIPE maintains an up-to-date table of ISO 3166 codes.  It has all the
  383. FSU countries and everything.
  384.  
  385. The document is available via anonymous FTP from ftp.ripe.net, in 
  386. ripe/docs/iso3166-codes.
  387.  
  388.  
  389. Aaron Leonard (AL104), <Leonard@Arizona.EDU>
  390. University of Arizona Network Operations, Tucson AZ 85721
  391.  
  392. ------------------------------
  393.  
  394. From: dold@rahul.net (Clarence Dold)
  395. Subject: Re: Why Caller-ID Instead of ANI?
  396. Organization: a2i network
  397. Date: Fri, 11 Mar 1994 19:01:27 GMT
  398.  
  399.  
  400. Steve Forrette (stevef@wrq.com) wrote:
  401.  
  402. > In <telecom14.99.7@eecs.nwu.edu>, TELECOM Digest Editor noted in
  403. > response to baers@agcs.com (Scott Baer):
  404.  
  405. >> [TELECOM Digest Editor's Note: I think you misunderstood the results of
  406. >> your prepending 10222 to a local seven digit number. In all probability,
  407. >> your local telephone exchange probably *ignored* the 10222 and handled
  408. >> the call themselves. They have the right to do that.  PAT]
  409.  
  410. If you follow the carrier selection with #, you will actually draw
  411. dial tone from the carrier's switch.  I can dial 10xxx#, wait for dial
  412. tone from my switch, then follow with the rest of the number.  PcaBell
  413. never gets the opportunity to route the call, except to my switch,
  414. because they don't see the rest of the digits until after my switch
  415. has the connection.  Merely dialing the same 10xxx without the #,
  416. gives me a "not neccessary" message and SIT reorder.  Dialing one long
  417. string, with #, but no wait for dialtone, causes an incomplete phone
  418. number to be heard by my switch.
  419.  
  420. Some carriers don't allow such access.  10288# draws a reorder, but it
  421. is an AT&T reorder, not PacBell.
  422.  
  423.  
  424. Clarence A Dold - dold@rahul.net
  425.                 - Milpitas (near San Jose) & Napa CA.
  426.  
  427.  
  428. [TELECOM Digest Editor's Note: It used to be the case here that a couple
  429. of the 10xxx codes worked the way you mention, with # causing the call to
  430. be given the carrier's dial tone. This is not so any longer, at least on
  431. the two or three I tried at random just now. As you point out, 10288#
  432. gets re-order. You say it comes from AT&T, so I assume that is correct.
  433. 10333# got me a recording saying my call could not be completed as dialed
  434. and to try again or call 'customer service'.  10222# got me a re-order
  435. also. I think at one time, maybe in the early days of 10xxx what you say
  436. was more common; there might have been some tie-in with the equivilent
  437. 950-1xxx; ie, 10222 and 950-1222 both got MCI dial tone; the latter when
  438. you dialed it and the former when you allowed it to time out with no
  439. further digits. Illinois Bell seems to not allow it at all now.   PAT]
  440.  
  441. ------------------------------
  442.  
  443. From: stevef@wrq.com (Steve Forrette)
  444. Subject: Re: Prisoner Starts Own 900 Number
  445. Date: 12 Mar 1994 02:27:55 GMT
  446. Organization: Walker Richer & Quinn, Inc.
  447. Reply-To: stevef@wrq.com (Steve Forrette)
  448.  
  449.  
  450. The Moderator wrote:
  451.  
  452. > Now I do not have any love in my heart for prisoners and unlike some
  453. > liberal thinkers I could name (but won't) who are constantly whining
  454. > about 'all the innocent people in prison', my attitude is there are no
  455. > innocent people in prison, by definition absolutely, and most likely
  456. > in reality as well. 
  457.  
  458. But these AOS ripoffs are also found in jails, where newly-arrested
  459. people that have not been convicted or even charged are housed (in
  460. addition to convicted non-felons).  Many jails restrict the phones so
  461. they can't call an 800 number, can't use the arrestee's own calling
  462. card, can't use coins for a local call, or any other method than the
  463. AOS's collect call service.  I guess you could say that the jails have
  464. the inmates right where they want them.
  465.  
  466.  
  467. Steve Forrette, stevef@wrq.com
  468.  
  469.  
  470. [TELECOM Digest Editor's Note: In real practice, persons who have not been
  471. charged with a crime are usually held in police lockups, and the ones here
  472. all have Genuine Bell payphones. Those who have been charged with a crime
  473. are usually free on bond (either because they posted the bond or were given
  474. freedom based on their Recognizance). It is *hard* to get into Cook County
  475. Jail ... very hard. It helps if you are a murderer, a rapist and very violent
  476. as well as being a second or third time offender.
  477.  
  478. As with the prisons in the USA, there are no innocent people in jail. Despite
  479. this, I agree that the captive customer base consisting of families and
  480. loved ones of prisoners is getting shafted in the process where the phones
  481. are concerned.   PAT]
  482.  
  483. ------------------------------
  484.  
  485. From: mike.quinlan@phant.boise.id.us (Mike Quinlan)
  486. Date: Fri, 11 Mar 94 22:22:00 -0700
  487. Organization: Phantasia BBS
  488. Subject: Re: New Area Code Change Question
  489.  
  490.  
  491. In message <telecom14.112.4@eecs.nwu.edu>, TELECOM Digest Editor Noted:
  492.  
  493. > Since the general public has never probably understood the way area codes
  494. > were constructed in the past, the general public will probably not notice
  495. > the difference starting next year.
  496.  
  497. The general public may notice that they will have to dial the area
  498. code when making long-distance calls within the same area code.
  499.  
  500.  
  501. mike.quinlan@phant.boise.id.us (Mike Quinlan)
  502.  
  503. ------------------------------
  504.  
  505. Date: Fri, 11 Mar 1994 17:57:28 PST
  506. From: puma <puma@netcom.com>
  507. Subject: Obscene Caller Nabbed by Voicemail
  508.  
  509.  
  510. "System Snares Alleged Caller" from the {Milwaukee Journal}, Friday March
  511. 11, 1994
  512.  
  513. La Crosse (WI) - An obscene caller has been caught by his own call,
  514. thanks to some high-tech telephone equipment, police say.
  515.  
  516. The caller, 30 year-old Richard Armstrong of La Crosse (WI), had left
  517. sexually explicit messages on the victim's voice mail system,
  518. authorities said.
  519.  
  520. The system is similar to a telephone answering machine, but it
  521. includes a way of retrieving the caller's telephone number if that
  522. party also is a voice mail subscriber, which is what the victim said
  523. she did.
  524.  
  525.  
  526. puma grins >  Bravo!  One for the good guys!
  527.  
  528.  
  529. puma@netcom.com
  530.  
  531. ------------------------------
  532.  
  533. End of TELECOM Digest V14 #128
  534. ******************************
  535.  
  536.  
  537. -------------------------------------------------------------------------------
  538.  
  539. Downloaded From P-80 International Information Systems 304-744-2253
  540.