Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA22552; Thu, 20 Nov 1997 09:18:04 -0500 (EST) Date: Thu, 20 Nov 1997 09:18:04 -0500 (EST) From: editor@telecom-digest.org Message-Id: <199711201418.JAA22552@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V17 #321 TELECOM Digest Thu, 20 Nov 97 09:18:00 EST Volume 17 : Issue 321 Inside This Issue: Editor: Patrick A. Townson Book Review: "LAN Times Guide to Managing Remote Connectivity" (Rob Slade) COCOTs Misprogrammed (David Perrussel) PBX Prompting Woes (was: Phase Out of 10XXX Codes) (Al Hays) 800/888 Rationing Update (Judith Oppenheimer) SPAM: Usenet Bans CompuServe (Eric Florack) Video Conferencing to a GSM (Koos van den Hout) BCTel and 10xxx Codes (Babu Mengelepouti) SkyTel Blocks Access From Payphones (Bob Snyder) Re: Cell Phones,'Crime Fighters of the '90s,' Are Striking Out (L Hancock) 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: Wed, 19 Nov 1997 19:33:54 EST From: Rob Slade Subject: Book Review: "LAN Times Guide to Managing Remote Connectivity" BKLTGMRC.RVW 970713 "LAN Times Guide to Managing Remote Connectivity", Salvatore Salamone, 1997, 0-07-882267-X, U$34.99/C$49.99 %A Salvatore Salamone %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 1997 %G 0-07-882267-X %I McGraw-Hill Ryerson/Osborne %O U$34.99/C$49.99 905-430-5000 800-565-5758 905-430-5134 fax: 905-430-5020 %P 395 %T "LAN Times Guide to Managing Remote Connectivity" I guess the title does say it all, but how to explain what the title means? This is a quick overview of the data communications options and requirements for a remote, or possibly travelling, user, dialing in to a host, LAN, or WAN (wide area network). The emphasis is on breadth of options regarded, rather than specifics of the technology. The advice on management is sometimes hampered by the lack of detail, but is generally practical and helpful. As I read through this book, it appeared to be quite similar to many before it, aimed at the same audience, and to the same purpose. Then, I realized that these books have a short lifetime, given the rapid changes in the technologies. This is, then, a very serviceable successor to those previous, and covers the latest, up to date, possibilities. copyright Robert M. Slade, 1997 BKLTGMRC.RVW 970713 ------------------------------ From: David Perrussel Date: Wed, 19 Nov 97 19:38:24 -0500 Reply-To: David Perrussel Subject: COCOTs Misprogrammed >> That reminds me -- I was using a pay phone last night (at a >> high school in a somewhat rural area). I can't recall the carrier, I >> am vaguely thinking Universal Telecom or something similar. Anyway, I >> was trying to call home (we have an 888 number for such situations), >> and it rejected it. I first thought perhaps my dad had restricted the >> calling area, so I tried 1-800-CALL-ATT to use the calling card >> instead. Same thing. It simply didn't like toll-free calls. I've >> never seen this before, has anyone else? > I have, more than once. There's a shopping mall in Bethpage, New > York, suburb of New York City, that not only won't allow 800 calls, > but also won't call 911 without a cash deposit. Same thing happened > while using a pay phone in Chandler, Arizona. Couldn't use a 10XXX > code, and couldn't reach AT&T via a toll-free number. Happened again > with one of the few pay phones in Oradell, New Jersey (which is not > rural at all). Couldn't use a 10XXX code and 800 calls were blocked. > It's a common practice, even if illegal in some states. From the sounds of things in both of these posts - I think the COCOTS are either misprogrammed or they "forgot" their programming. I've seen several COCOTs that exhibit these symptoms and came to find out they wouldn't allow ANY toll calls at all. Local calls were only allowed if you deposited a large sum of money (it thinking it was a long distance call within the area code) - and any long distance (including 800/888) were "invalid" according to the COCOT. I've seen where people trying to make a call from a COCOT, wondering why a the pay phone wouldn't work. I told them to find a real telco pay phone. Most of the time I'd use a telco pay phone over a COCOT. The only exception may be a group of pay phones in Chicago outside a particular bus station (yes, this is in reference to Pat.) Dave Perrussel Webmaster - The BBS Corner http://thebbscorner.home.ml.org htttp://www.thedirectory.org [TELECOM Digest Editor's Note: Well really, I think COCOTS do have the potential of being serious and effective competition to telco if they are maintained properly. I know that Greyhound in Chicago got rid of all the COCOTS and went back to telco after an enormous number of complaints about the rip off phones. But something people do not seem to realize is there is no way *not* to make a good income from payphones -- even when operating them as liberally as you can in the user's favor -- so why not go ahead and make them as user-friendly as possible. Those phones I have referred to a couple of times here are programmed to do everything a genuine Bell phone does, but cheaper. There is no blocking of 800/888 nor any surcharge (losing a small bit of revenue; so what?); no blocking of carrier access codes like 10XXX; and whatever Bell charges, they charge five or ten cents less. For example local calls are 25 cents compared to Bell's 35 cents. Long distance calls are one dollar in coins for three minutes, anywhere in the USA, and I do not know of any Bell phone giving long distance coin paid calls that cheap. The owner of the phones can take certain types of precautions to prevent abuse such as billed number screening on the line and blocking (or actually carefully supervising) area codes like 809 in order to keep the public from ripping him off as well. The thing is, you can almost give the service away and still make huge amounts of money. That is how telephones are, and that is how telcos made so much money over the past century. Revenue (and subsequent commissions) lost from things like 800/888 calls is a very tiny part of it. There are not really that many people who go up to pay phones to call a toll-free number. I would venture to say about 95 percent of the calls on the COCOTS in question are local calls, one quarter after another dropped in the box or calls to Chicago which are fifty cents except for the far north end of 773 which is treated as local in this case. Maybe five percent of the users make a long distance call, and the very inviting one dollar in coins for three minutes to anywhere helps avoid a lot of calling card (which is non-revenue) situations. Now if the phones were consistently (or even quite often) used to call 800/888, 10XXX, and other non-revenue producing stuff I might re-think my position, but the fact is the boxes are full of quarters and the collector comes out once or twice a week to get them. They produce commissions of a few hundred dollars per month with little effort at all, and you do not have to rip off the public to get it. I'll grant you this is a good location, with nine Greyhound busses stopping daily and several local city bus routes pulling in the Greyhound driveway all day and all night, but still, there are three Bell phones just several feet away and a half-dozen more Bell phones at the train station in the same complex several yards away. I wish COCOT owners/managers would realize you do not have to rip off the public on phone service. It makes tons of money whether you like it or not ... so why not be friendly to your customers? PAT] ------------------------------ From: Al Hays Subject: PBX Prompting Woes (was: Phase Out of 10XXX Codes) Date: Wed, 19 Nov 1997 18:04:41 -0600 On Wed, 12 Nov 1997 02:24:00, chip76@ix.netcom.com (Jeff Vinocur) asks: > Speaking of phone trees,I've got a PBX question. My school's phone > tree (new, so I haven't had a chance to find out specs) prompts first > "If you know your extension...", but certain extensions for some > reason require an operator intermediary. This is generally a restriction placed on those "certain extensions" by the system administrator. I don't know what type of switch you have, but in the Lucent Definity G3 such restrictions are controlled by the COR (Class of Restriction). Each and every entity has a COR; Trunk Groups, Extensions, Vector Directory Numbers, Announcements, etc., and every COR can be restricted from calling and/or receiving a call from another COR. For instance, if you and I were on the same PBX and I didn't want any more annoying calls from you I could change your COR (or create a new one) that would disallow you from calling my extension altogether. ;) In the case of prompting, the Trunk Group COR has been restricted from calling the COR of the "certian extensions." So, in the switch's programming, when you enter the extension number of a restricted COR the step that routes the call to that extension fails and falls through to the next step (which in your case routes the call to an operator). > Is there any way around this? The operator has rather minimal hours > and we'll end up in a room with a perfectly good phone but no way to > receive calls. If it is the intent of the administrator to restrict inbound calls to "certain extensions" and he/she's done it properly, then there should be no easy way around it. There are several answers to your problem, however: 1) Talk to the administrator. Perhaps he/she is unaware of the problem. Sometimes Administrators cause these problems inadvertently (myself included) and they won't look for a problem unless someone reports it. 2) Ask the administrator to use time-of-day routing in the switch's programming to redirect the call to another extension that would act as a "night operator" during those hours that the regular operator is gone. Ask him/her how emergency calls are, or should be, handled after hours. Any PBX administrator worth a plugged nickel should at least examine the problem and/or offer you an alternative or an explanation. 3) Finally, if it's the way they want it, you're stuck. Your only other option would be for your callers to dial an extension that _can_ receive direct inbound calls, hope someone answers, and then have them transfer the call to you. This will work until they get annoyed. You should ask them for assistance prior to undertaking this step. regs, .al. ------------------------------ Date: Wed, 19 Nov 1997 09:17:24 -0500 From: Judith Oppenheimer Reply-To: joppenheimer@icbtollfree.com Organization: ICB TOLL FREE - 800/888 news... commentary... consulting... Subject: 800/888 Rationing Update Rationing Update. Toll-free number growth for the week ending November 15 was 52,233 combined 800 and 888 numbers, which under steady conditions (consistent amounts of numbers returned to "spare" -- ie available), should stretch the toll-free resource just long enough to get us to early April, when 877 is scheduled to be introduced. However, the amount of numbers returned to spare last week was down 10,000 from prior weeks for the second week in a row, indicating potential problems prior to April '98. The SNAC (SMS Number Administration Committee) has asked the industry to speed up the introduction of 877 by two months, but is not optimistic about the outcome. Meanwhile, at least one RespOrg seems to be overflowing with 800 numbers. On Tuesday this office received a sales call from Sprint residential service, offering a "free" 800 number for each residential phone line on the premises. No pins, not even the lowly 888's - "free" no-strings-attached, fully portable 800 numbers. Umm. Judith Oppenheimer Publisher ICB TOLL FREE NEWS http://www.icbtollfree.com ------------------------------ Date: Wed, 19 Nov 1997 05:47:46 PST From: Eric Florack Subject: SPAM: Usenet Bans CompuServe Usenet Bans CompuServe by Stannie Holt, InfoWorld Electric November 18, 1997 Usenet administrators have banned CompuServe, accusing the company of passing along unwanted and abusive bulk e-mail, or "spam," despite repeated requests that it stop the messages. On Monday night, an informal group of Usenet administrators and concerned users shut off all traffic coming from CompuServe servers and individual accounts to Usenet, which provides online discussion groups on thousands of subjects. The "Usenet Death Penalty" (UDP) was last applied in August to Internet service provider UUNet, which the Usenet administrators said was also too tolerant of spam. They subsequently lifted the penalty to negotiate with UUNet. "This is not a step we take lightly," said Usenet news administrator Rick Buchanan, who announced the CompuServe ban Tuesday morning. "CompuServe is not the enemy; spammers are the bad guys here. But inaction makes CompuServe a passive accomplice to the people who are trying to destroy Usenet. "We have made every possible attempt to inform CompuServe about their growing problem, and have repeatedly offered to assist them in dealing with it," Buchanan continued. "Their unresponsiveness has been . . . unprecedented in my experience as a spam fighter. The UDP was our last resort." Buchanan said CompuServe has ignored complaints and e-mail reports from several people for months, and has not taken any action to stop flagrant spammers. Currently, two types of abuse are occurring, Buchanan said. First, a large number of messages have been posted directly to CompuServe news servers from known, persistent, and destructive spammers. Second, and more seriously, a growing number of spammers are using CompuServe dial-up accounts to send unwanted mail to other news servers. Buchanan cited as an example a man calling himself "Sexjunky" who posts pornographic spam to sexual-abuse recovery newsgroups. Another man sends hundreds of forged and fraudulent ads for "business opportunities." Buchanan said the blocking will continue until CompuServe sets firm policies on acceptable usage and starts enforcing them--by responding to complaints sooner and terminating spammers, for example. "We don't set any specific criteria regarding spam volume," Buchanan said. "Even the most conscientious ISP can get flooded by a megaspammer. We just want them to do something." CompuServe officials were not available for comment. The company was sold in October and divided between America Online and WorldCom. AOL received CompuServe's online services, and WorldCom got its networking plumbing. ------------------------------ From: Koos van den Hout Subject: Video Conferencing to a GSM Date: 20 Nov 1997 10:48:53 GMT Organization: BBS Koos z'n Doos (http://koos.cyber.nl) According to my GSM, it is capable of receiving video conferencing calls. Quite.. interesting :) The following happened : I was trying to get our videoconferencing set in working order (which still needs a lot of voodoo to work) and as one of the tests I called my GSM number. It rang, so I answered, and got funny noises on my GSM and a videoconferencing telling me the connection was established and trying to set up a remote image. When I call a normal voice number (either POTS or ISDN) the set will tell me this can't be done. The set is a picturetel, the GSM is a Nokia 1611 on the Dutch libertel network. Koos van den Hout, Internetter, Unix freak, ISFJ and BBS SysOp at large koos@kzdoos.xs4all.nl (Home) BBS Koos z'n Doos (from Jan 21st 1997 : koos@pizza.hvu.nl (Work) <-- finger -l for PGPkey +31-30-2870244) http://www.cetis.hvu.nl/~koos/ Looking for a license plate with "RFC 822" ------------------------------ Date: Wed, 19 Nov 1997 15:06:18 -0500 From: Babu Mengelepouti Reply-To: dialtone@vcn.bc.ca Organization: US Secret Service Subject: BCTel and 10xxx Codes miind@hotmail.cam (Sebastien Kingsley) wrote: > Here in BC Tel country, dialing 10xxx will result in an intercept > message. Dialing a 950 dialup results in a similar fashion. People > at the telco tell me that they aren't used, but they cannot explain > why BC Tel are assigned a 10xxx code, and a 950 dialup. Unitel (now AT+T Canada I think) had a carrier access code which I used with success, if I remember correctly it is 10869. Dialling 10869+17005554141 got me (in Vancouver BC) and my friend (in Guelph, ON) a recording thanking us for choosing Unitel. There are numerous Canadian carriers which have 10xxx codes; if you call Sprint Canada, Unitel/AT+T/whatever, etc. and ask I'm sure they'll be happy to share them with you. As for the 950's... try 950-1022 and 950-1033; I am curious whether they work. They are MCI and Sprint's calling card 950 numbers, and the MCI one still works in the US. ------------------------------ Date: Wed, 19 Nov 1997 11:53:15 -0500 From: Bob Snyder Organization: Advanced Systems Consulting, Inc. Subject: SkyTel Blocks Access From Payphones Saw this on SkyTel's webpage (), and thought it would be interesting to the readers of TELECOM Digest ... Bob -------------- FCC Ruling Affects Pay Phone Users The Telecom Act of 1996 (Docket No. 96-128) has mandated that a fee be paid by phone companies (AT&T, MCI, Sprint) to Pay Phone Service Providers for all non-emergency calls originating from pay phones, effective Nov. 17, 1997. Pay phone service providers and long distance carriers will be charging a combined total $.30* access fee for each call to an 800/888 number made from a pay phone. For calls into the SkyTel system, these access fees will be passed on by the long distance provider and will appear on your monthly SkyTel invoice. *The pay phone service providers are charging $0.284 each, and the long distance carriers are charging an additional $0.016 each, for a combined total of $0.30 for each call. In order to minimize the impact of these new regulations on our customers, we have implemented the following policies for pay phone calls into the SkyTel system. SkyTel General Access Numbers Effective Monday, November 17, 1997, the following numbers will no longer be accessible from pay phones, however, they remain accessible from other telephones: 1-800-SKY8888 (1-800-759-8888) (The One-way SkyTel System for- SkyPager, SkyWord, SkyWord Plus) 1-800-SKYTEL2 (1-800-759-8352) (The Two-way SkyTel System for SkyWriter) Pay phone users can now reach the SkyTel system through the new SkyTel Pay Phone access numbers listed below. SkyTel Pay Phone Access # 601-960-9548 (use instead of 1-800-SKY8888) 601-969-6848 (use instead of 1-800-SKYTEL2) Note: The SkyTel Pay Phone Access numbers are charged to the caller as a normal long distance call if calling from outside the Jackson, MS area. Personal 800/888 Numbers Personal 800/888 numbers are still accessible from pay phones, and the $.30 access fee for each call will appear on your SkyTel invoice. If you do not wish to incur these charges, you may have your Personal 800/888 number blocked from pay phone access by submitting the authorization form or by contacting Customer Service at 1-800-SKYUSER (1-800-759-8737). Your request will be processed within 48 hours. Motorola Pre-Paid Paging numbers will be blocked from pay phone access. Please note that this does not apply to MCI Pre-Paid or Sony Grab 'n Go pre-paid packages. Corporate 800/888 Numbers Corporate 800/888 numbers are still accessible from pay phones, and the $.30 access fee for each call will appear on your SkyTel invoice. If your company does not want to incur these charges, you may block the Corporate 800/888 number from pay phone access by submitting the authorization form or by contacting Customer Service at 1-800-SKYUSER (1-800-759-8737). Your request will be processed within 48 hours. SkyTel Customer Service (SKYUSER) 1-800-SKYUSER (1-800-759-8737) remains available from pay phones. Call this number for service and support as you always have. The send-a-page option is no longer available from this number. SkyTel Offices & Administration 800 numbers to regional sales offices, corporate headquarters, and all 800 numbers in current advertising will remain available from pay phones. Your voice can make a difference. For more information, visit the FCC web site (www.fcc.gov). If you'd like to let the FCC know your opinion on the ruling, please send an email to fccinfo@fcc.gov, call 202-418-0200 or send a letter to: Federal Communications Commission 1919 M Street, NW Washington DC 20554 ------------------------------ From: hancock4@bbs.cpcn.com (Lisa or Jeff) Subject: Re: Cell Phones,'Crime Fighters of the '90s,' Are Striking Out Date: 20 Nov 1997 02:58:47 GMT Organization: Net Access BBS The article first said police were only blocks away, but then said calls were routed through the state police. If calls were routed first through the state police, there could've been a delay until help arrived. Centralized dispatching can slow things down, especially if the operator isn't familiar with the area. > One technical study she commissioned for a lawsuit that she filed > against L.A. Cellular, her service provider, indicates that the > company's signal is still too weak to carry a 911 call in the area of > National and Castle Heights -- Oh, I see, a lawsuit. While I'm certainly sorry for what happened, is it really the cellular carrier's fault? The fault was the thieves -- they were the ones who shot the woman. Cellular phones do not always work. In my short experience with them, I've been cut off in mid conversation and have had lots of trouble getting a call through. It's a radio, and radios have dead spots. Is the telephone company ever liable if a call fails to go through in an emergency? Suppose someone can't get a dial tone for whatever reason and time is lost securing an ambulance or fire. Suppose the woman stopped at a conventional pay phone, found it broken, and then was assaulted. Would the phone company be then liable? > Instead, many wireless companies favor their own customers by > deliberately blocking 911 calls made on their own signals by callers > using competitors' phones, by out-of-towners, or by users of phones > that have never been activated by a commercial service (so-called > non-initialized phones). Is the above really true? Sounds pretty far fetched to me. ------------------------------ End of TELECOM Digest V17 #321 ******************************