Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id VAA01893; Thu, 9 Oct 1997 21:40:35 -0400 (EDT) Date: Thu, 9 Oct 1997 21:40:35 -0400 (EDT) From: editor@telecom-digest.org Message-Id: <199710100140.VAA01893@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V17 #277 TELECOM Digest Thu, 9 Oct 97 21:40:00 EDT Volume 17 : Issue 277 Inside This Issue: Editor: Patrick A. Townson Book Review: "The Web Page Recipe Book" by Sosinsky/Parker (Rob Slade) UCLA Short Course on "Digital Signal Processing" (Bill Goodin) Number's Up On Credit Card Scam (Joey Lindstrom) MCI and Spam (Dave Harrison) New Book on the Internet (Jud Wolfskill) Re: 101-XXXX For Traditional Intra-LATA LEC Toll (Jack Decker) Re: Bell Atlantic Toll Alerting in Massachusetts (Greg Monti) Re: Baltimore's 3-1-1 Service (John McGing) Re: Combining Analog Lines (Jeff Carter) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@telecom-digest.org * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-727-5427 Fax: 773-539-4630 ** Article submission address: editor@telecom-digest.org ** Our archives are available for your review/research. The URL is: http://telecom-digest.org They can also be accessed using anonymous ftp: ftp hyperarchive.lcs.mit.edu/telecom-archives/archives (or use our mirror site: ftp ftp.epix.net/pub/telecom-archives) A third method is the Telecom Email Information Service: Send a note to archives@telecom-digest.org to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ************************************************************************* Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. Please make at least a single donation to cover the cost of processing your name to the mailing list. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- Date: Thu, 09 Oct 1997 11:09:48 EST From: Rob Slade Subject: Book Review: "The Web Page Recipe Book" by Sosinsky/Parker BKWBPGRC.RVW 970328 "The Web Page Recipe Book", Barrie Sosinsky/Elisabeth Parker, 1996, 0-13-460296-X, U$29.95/C$38.00 %A Barrie Sosinsky %A Elisabeth Parker %C One Lake St., Upper Saddle River, NJ 07458 %D 1996 %G 0-13-460296-X %I Prentice Hall %O U$29.95/C$38.00 +1-201-236-7139 fax: 201-236-7131 beth_hespe@prenhall.com %P 352 %T "The Web Page Recipe Book" About a year ago, there was a discussion on the NETTRAIN mailing list about the best Web page creation software. My favorite response was the one that suggested Notepad: HTML (HyperText Markup Language) is really quite simple, and if you can't be bothered to learn it, then you probably aren't willing to do the design work necessary to keep your page out of the hundred million garbage pages already on the Web. So, I am not predisposed to like a book recommending the use of canned Web pages with "paint by numbers" drop-ins. On the other hand, the book does start off with a background on the basics. On the third hand, right off the bat, page eight parses the wrong URL (Uniform Resource Locator), page ten gets the relationship between HTML and SGML (Standard Generalized Markup Language) wrong, and page twelve gets the name of a recommended program wrong. In fact, the "paint by numbers" aspect is not strongly emphasized: while the sample pages are available on disk, the book annotates them well enough to be a workable tutorial on HTML. By using the "mailto" function, the authors are even able to provide simple and workable forms, something that most other HTML books signally fail to do. The explanations are clear, and the basic page creation is developmental so that functions can be added and pages improved as the reader progresses. Still, there are a number of annoying aspects to the book. The strongest is that the formatting of the HTML code (designated by underlining, and often run together) makes reading much more difficult than it needed to be. The advice is inconsistent at times: page twenty-three promotes the important design rule that Web pages should allow for the use of non-graphical browsers and promises that all pages are checked with Lynx, but if there is a Lynx screen shot buried in the book, I couldn't find it. Even the screens of browsers with graphics turned off are not good examples, since the pages used are done "properly", and don't show how annoying a page of undistinguished image tags is. While I couldn't recommend it as a solid guide to HTML, it has enough of interest to be considered as an inclusion on the bookshelf. copyright Robert M. Slade, 1997 BKWBPGRC.RVW 970328 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca ------------------------------ From: Bill Goodin Subject: UCLA Short Course on "Digital Signal Processing" Date: Thu, 9 Oct 1997 10:00:44 -0700 On January 5-9, 1998, UCLA Extension will present the short course, "Digital Signal Processing: Theory, Algorithms and Implementations", on the UCLA campus in Los Angeles. The instructor is Robert W. Stewart, PhD, Faculty Member, Department of Electronic and Electrical Engineering, University of Strathclyde, Glasgow, Scotland. Each participant receives a Digital Signal Processing Reference Glossary (500 pages); multimedia reference CD-ROM featuring algorithms, DSP sample problems, graphs, and comprehensive notes; software and hardware workbook and manuals; and lecture notes. This course presents the core theory and algorithms of DSP and demonstrates through laboratory sessions the real-time and real-world implementation of digital signal processing strategies. It is intended for engineers, computer scientists and programmers, and project management staff. After presenting the mathematical tools and theory of DSP, the course features practical laboratory sessions that allow participants to simulate and implement advanced DSP systems such as acoustic echo cancellers, psychoacoustic compression strategies, or software systems. Participants should obtain the tools and materials necessary to apply DSP methods immediately at their workplace, as well as: o Analyze discrete time systems using time domain mathematics o Analyze discrete time systems using frequency domain/Z-domain mathematics o Understand the fundamental theory relating to sampling rate, quantization noise and the architecture of a generic DSP system o Design and implement FIR, IIR, and adaptive digital filters for real-world applications in digital audio and acoustics and telecommunications o Understand the theory of adaptive signal processing systems and how to apply to real-world problems o Understand the DSP theory of signal coding and compression o Understand the key theory and achievable advantages of oversampling, multirate, noise shaping, and undersampling strategies o Undertake DSP system design using advanced analysis and design software o Implement real-time digital filters, and adaptive digital filters using DSP simulation software, and real-time DSP processor hardware o Apply DSP theory and algorithms in the application domains of modern computing, multimedia systems, and communication systems o Integrate theoretical and practical skills to undertake a DSP design project. SystemView software (running on Windows 3.1/95) will be used for the DSP software laboratory sessions. This advanced software provides a comprehensive, state-of-the-art DSP toolbox for modern signal processing. An evaluation license will be available to participants so that they can continue to use the software after the course. The course fee is $1495, which includes extensive course materials. These materials are for participants only, and are not for sale. For a more information and a complete course description, please contact Marcus Hennessy at: (310) 825-1047 (310) 206-2815 fax mhenness@unex.ucla.edu http://www.unex.ucla.edu/shortcourses This course may also be presented on-site at company locations. ------------------------------ From: Joey Lindstrom Date: Thu, 09 Oct 97 05:11:35 -0700 Reply-To: Joey Lindstrom Subject: Number's Up On Credit Card Scam By Bill Kaufmann Calgary Sun (c) 1997 Sun Media City Police have lowered the boom on a credit card scam that has bilked thousands of victims of at least $2 million. The Golden Globe Investment Club solicited $100 US from customers across North America with poor or non-existent credit, promising them either Visa or Mastercard from offshore banks. None of the estimated 2,000 applicants has received a credit card. A downtown Calgary office - once operated by Globe - was raided by City Police who discovered courier packages containing cash enroute to Nassau, Bahamas. The company is operating an Internet website, said police, who are seeking several Golden Globe staffers in Calgary. The operation's kingpin, believed to be in the Bahamas, is wanted on seven counts of fraud in Edmonton. From: The Desk Of Joey Lindstrom +1 403-606-3853 EMAIL: joey@lindstrom.com numanoid@ab.imag.net lindstrj@cadvision.com WEBB: http://www.ab.imag.net/worldwidewebb/ ------------------------------ From: Davew@cris.com (Dave Harrison) Subject: MCI and Spam Date: 9 Oct 1997 08:57:58 GMT Organization: Concentric Internet Services Since AGIS pulled the plug on Spamford, the amount of unwanted email in my box seems to have dropped about 80%, which is still way too much. Lately, I've seen an increase from sites connected thru MCI. As MCI has conditions of service that prohibit Spam activities, and MCI hasn't pulled the plug on the Spammers, I can only assume that money means more to MCI than their reputation. As a person responsible for a 96 line Centrex group, with MCI as the pic, I have decided to select another carrier and dump MCI like a carton of Spam. Our average MCI 1+ bill (and lately some of our lata traffic) is only about 5k a month, but hey, dropping MCI lets me express my displeasure with them. And before anyone admonishes me for not bypassing ... we bill calls to clients, so saving a few cents a minute isn't worth investing in a switch. ------------------------------ Date: Wed, 8 Oct 97 11:25:24 EDT From: wolfskil@MIT.EDU (Jud Wolfskill) Subject: New Book on the Internet The following is a book which readers of this list might find of interest. For more information please visit: http://mitpress.mit.edu/mitp/recent-books/new-releases.html Coordinating the Internet edited by Brian Kahin and James H. Keller For years, the world saw the Internet as a creature of the U.S. Department of Defense. Now some claim that the Internet is a self-governing organism controlled by no one and needing no oversight. Although the National Science Foundation and other government agencies continue to support and oversee critical administrative and coordinating functions, the Internet is remarkably decentralized and uninstitutionalized. As it grows in scope, bandwidth, and functionality, the Internet will require greater coordination, but it is not yet clear what kind of coordinating mechanisms will evolve. The essays in this volume clarify these issues and suggest possible models for governing the Internet. The topics addressed range from settlements and statistics collection to the sprawling problem of domain names, which affects the commercial interests of millions of companies around the world. One recurrent theme is the inseparability of technical and policy issues in any discussion involving the Internet. A publication of the Harvard Information Infrastructure Project September 1997 500 pp. ISBN 0-262-61136-8 MIT Press * 5 Cambridge Center * Cambridge, MA 02142 * (800)356-0343 ------------------------------ Date: Tue, 07 Oct 1997 20:51:38 -0400 From: Jack Decker Subject: Re: 101-XXXX For Traditional Intra-LATA LEC Toll Mark J. Cuccia wrote: > GTE doesn't have any LATAs of their own in the state of Michigan. All > LATAs in Michigan are considered to be Ameritech (formerly Michigan > Bell). 'Traditional' Independent telcos which provide service within > a BOC LATA have toll-homings to the BOC tandem switch in that LATA > for intra-LATA toll calls. Some independents do have their own toll > or tandem switch, if that independent has a large number of exchanges > within a small region in the same LATA, but not all of the traffic > between the exchanges is local. Well, GTE may not have their own LATAs but they do have their own intraLATA toll. A toll call between two GTE points in the same LATA generally never sees an Ameritech switch. Further, GTE has their own toll operators. Independent telephone companies in Michigan have the option of obtaining intraLATA toll service from either Ameritech or GTE, and if they choose GTE their customers talk to GTE operators, not Ameritech operators. If you live in California or someplace like that you may think that this is a bad thing, but actually GTE service has improved considerably in Michigan in the last decade or so, and unless you happen to live in an area "served" by a subscriber carrier system (also known as an incredibly obsolete and substandard excuse for phone service, unfortunately still foisted on an unlucky few GTE rural customers), chances are that you will get phone service about on a par with what you would expect from Ameritech, AND you don't suffer the slimey tricks that Ameritech pulls on their customers (such as adding unwanted and co$tly "per-use" custom calling features to your line without warning). Where GTE really falls down is in their customer service - it is still very difficult to get a correct answer about anything without jumping through a lot of hoops (trying to find the correct 101XXXX code for GTE's intraLATA toll is a perfect example; even their "Action Line" couldn't seem to pry this bit of information loose from the switch technicians. I suppose I could bug some of the local upper management to get the number, but GTE management personnel seem to change so frequently that every time I get a "good" contact there, it seems that they are gone by the next time I try to contact them, and I haven't had time this week to play telephone tag with them). > Ameritech does have some 101-XXXX codes, which _might_ happen to be > dialable for intra-LATA calls from those GTE central offices. The > following 101-XXXX+ codes are assigned to Ameritech, according to the > FCC's latest list of US/NANP numbering/dialing information: > 101-5475+, 101-5606+, 101-6123+; and for Ameritech's "Long-Distance" > (future inTER-LATA toll? Ameritech's Cellular inTER-LATA toll?) there > is 101-0113+ (10-113+ in the older/shorter, soon to be obsolete format). None of these work here - after dialing the code it immediately cuts to an "I'm sorry, your call cannot be completed as dialed" recording. Except for a very short period of time a few years back when GTE experimented with letting Ameritech handle their toll calls, Ameritech toll has never been accessible from GTE exchanges (at least not in this area, although I think there were a few geographically isolated GTE exchanges that have always connected to Ameritech for toll). The thing that I am curious about is this: As I understand it (and feel free to correct me if I am wrong), if you do not have GTE as your default toll carrier, they have to load a PIC code into the switch for your preferred carrier. And it is possible to have NO default toll carrier (both interLATA and intraLATA), in which case no toll call will go through unless you dial an access code first. So, it would seem that there MUST be a code for GTE intraLATA toll, that would be the default code used in the switch if you don't ask for another carrier or specify that you don't want a default carrier. I would guess that the switch technicians know what that code is, but apparently they aren't telling! Jack When replying via e-mail, remove the "bogus" part of my e-mail address - I get WAY too much spam as it is, and I NEVER buy anything from spammers! ------------------------------ Date: Tue, 07 Oct 1997 22:28:58 -0400 From: Greg Monti Subject: Re: Bell Atlantic Toll Alerting in Massachusetts On 03 Oct 1997, The Old Bear wrote: > Something is going on with the Bell Atlantic/NYNEX consolidation of > billing functions where customers on 'unlimited' dialing plans are > suddenly finding themselves improperly billed for calls which should > be included in their dialing area. This may be exacerbated by the > number of new exchanges being created by the new entrant LECs which > are not always located where the LEC indicates that they are. So, this is even worse than the problem I had described before. In a state with toll alerting, the callers are not getting the alert in some cases, but are being billed toll rates anyway. [Example 1] > ... Customer service at my ISP assures > me that they pay for the forwarding from Quincy - but I'm scared of > what my next bill will look like - This one sounds like just plain bad switch programming. The standard rule is that, when forwarding from A to B to C, A pays for the call from A to B. B pays for the call from B to C. Sounds like a tariff violation to me. Complain loudly. Or better yet, sue. Sometimes it takes a two-by-four to get the mule's attention. [Example 2] > Moral here is to recheck all those numbers your ISP says are local > calls, if they have foreign exchanges, in other words exchanges that > don't match the other exchanges in the town you are supposed to be > calling, call Bell Atlantic to be sure they aren't toll calls for you. If this was in Massachusetts, the disputed calls must have crossed area code boundaries, where there is currently (or was until recently) no toll alerting. So the calling party could not have known at the time of dialing whether it was toll. On 3 Oct 97, shadow@krypton.rain.com (Leonard Erickson) wrote: > Why not do like US West does here in Oregon? We get "full toll > alerting", and it works for basic service *and* for all three (or is > it four?) levels of "extended area" calling. > It's doable that way and *not* confusing. It may require some extra > programming in the phone switch, but it *is* doable. Exactly. Of course it can be done. But Bell Atlantic wants out of the toll alerting business. All the local exchange carriers do. And they are using controversies like this as possibile opportunities to extricate themselves from toll alerting. > I suspect that many of the folks who are against "toll alerting" have > never had to deal with equipment that dials numbers from a directory > maintained elsewhere. With such a setup, you want the default to be > trying to dial 7 digits if the exchange isn't explicitly listed in the > translation table as a "local" prefix. That way you don't inadvertently > make LD calls. It depends on what your objective is. If you want it to be cheap above all other criteria, you want toll alerting. If you want it to be fast above all other criteria (all calls go through on the first try), you don't want alerting. For better or for worse, four states were converted to full non-alerting during the 1994 preparation for interchangeable area codes: PA, NY, CA and IL (some of these had partial alerting before). Something like one third of all US phones are now non-toll-alerted. > And trying to find out where an exchange that doesn't belong > to your LEC is can be *very* frustrating ... Some earlier posts on this Digest noted that in some areas (Illinois, I think), the local Bell company is refusing to tell (even when asked) whether any particular prefix belonging to a competitor is local or toll. Messy. Greg Monti Jersey City, New Jersey, USA gmonti@mindspring.com http://www.mindspring.com/~gmonti ------------------------------ From: John McGing Subject: Re: Baltimore's 3-1-1 Service Date: Thu, 9 Oct 1997 09:01:44 -0400 Organization: DIGEX, Inc. On Thu, 2 Oct 1997, The Old Bear wrote: > This came to me from Robert Vroman who > particiaptes in an Emergency Services Discussion List. He says > original source was the {New York Times} web site on 10/2/97. > I personally find this a worrysome idea. It would seem that the 911 > staff should be able to better triage incoming calls. I wonder what > will happens when someone calls 3-1-1 because they only have a "small > fire" or didn't want to call the regular 9-1-1 number because they > were not absolutely sure they were having a heart attack. The fact > that Baltimore was dispatching emergency personnel to non-emergency > situations sounds more like a staff training problem in their dispatch > center than any kind of technological issue. > 311 Takes Pressure Off Overburdened > Emergency Phone System Well, then you should try living in an area where to contact the police ALL calls go through 911, meaning you get put on hold. My inlaws live in Baltimore, I live outside it. They have had to contact 911 a few times and got put on hold more than once. Now with 311, the call gets answered right away at 911 because those non-emergency calls don't suck up the time of the 911 call center personnel. Can you imagine waiting on hold while the fire gets bigger or the intruder is breaking the door while a call of lesser importance is being serviced? Where I used to live you called 911 even to report a lost cat. And I never got a good answer why I was sucking up the time and energy of personnel who should be jumping on calls responding to real crimes, not neighborhood concerns. The point is that most reasonable people know if a call requires 911 or if it doesn't and by helping make 911 the number for emergencies, everyone gets better service. And even still, if you call 911 because of a cat in a tree, they still take the call. Might wish you used 311, but you still get service. jmcging@dm.net <== New e-mail address New web page at http://www.dm.net/~jmcging Soon to be inactive==>> http://www.access.digex.net/~jmcging [TELECOM Digest Editor's Note: In Chicago, the police tell people to call 911 for everything. Even if you call for some non-emergency matter and call direct to the station house, the people who answer there say if you want to talk to a police officer you need to dial 911 to get one dispatched. Meanwhile, the people who staff the 911 center constantly complain about how people call them for even the most minor things and blame the citizens for abusing 911. So if you call back to the station house they refer you right back to 911, etc. I wish they could get their act together. PAT] ------------------------------ From: Jeff Carter Subject: Re: Combining Analog Lines Date: Thu, 09 Oct 1997 11:25:01 -0400 Organization: The Open Software Foundation / The Open Group Cameron Smith wrote: > I live in a rural area where digital service is all but unavailable. > We have, here on-island, an ISP who brings in a T-1 signal. In order > to get that T-1 (or any fraction thereof) to my home, I would have to > pay the telco a $1400 setup fee and over $1200 per month! Plus, of > course, the connection fee to the ISP. > The ISP, however, is willing to let me co-locate a machine on his > premises. What I can do is set up a standard analog line from that > machine to my home with a couple of 56K modems. So far so good. > What I *want* to do, however, is set up *two* analog lines with 56k > modems and combine or concentrate them somehow. Something like this: > --> 56K modem <--> > Analog Line > / > -T1--> ISP <--Ethernet--> My Comp. <--> device <--< > @ ISP \ > --> 56K modem <--> > Analog Line > > Analog Line <--> 56K modem <-- > \ > >--> device <--> My > Computer > / @ > home > Analog Line <--> 56K modem <-- > > So what is the "device" that I need and what are some of the brand > names? If you're talking TCP/IP, you run PPP (point-to-point protocol) on each of the two modem links, and use "Multilink PPP" channel bonding to treat them as a single line between the local and remote computers. This is essentially the technique used by ISDN with two B channels at 56/64K each to get 112 or 128K aggregate. The technique is not limited to ISDN, though. I don't believe (but am willing to be corrected) that WinDoze directly supports MLPPP, but most routers and unix-type systems would support this. Jeff Carter Interware, Inc. jeffc@shore.net ------------------------------ End of TELECOM Digest V17 #277 ******************************