Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA22772; Tue, 3 Jun 1997 09:04:28 -0400 (EDT) Date: Tue, 3 Jun 1997 09:04:28 -0400 (EDT) From: editor@telecom-digest.org Message-Id: <199706031304.JAA22772@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V17 #148 TELECOM Digest Tue, 3 Jun 97 09:04:00 EDT Volume 17 : Issue 148 Inside This Issue: Editor: Patrick A. Townson Re: Call Forward No Answer Problem (Alan Boritz) Re: Of Course, If You Buy the Non-AOL Users Mailing List (Peter Morgan) ISDN Analogue Adaptors (Anbjrn Myren) Re: New, Very Fast Modem Available (Robert Holloman, Jr.) Toll-Free ANI Readback Number (Gordon S. Hlavenka) Re: Emergency Call Services (David Clayton) Cleaning Out the Mailbox (TELECOM Digest Editor) 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: * subscriptions@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 (WWW/http only!) 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. 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. ---------------------------------------------------------------------- From: aboritz@cybernex.net (Alan Boritz) Subject: Re: Call Forward No Answer Problem Date: Tue, 03 Jun 1997 01:16:54 -0400 In article , Michael Hayworth wrote: > We are having an odd problem and ending up with a great deal of > finger-pointing and very little help on the part of SWBT. Perhaps > someone can help me figure out what magic phrase I need to use to turn > on the light for either their repair or order department. > We have a local POTS line from SWBT which has call forward busy and > call forward no answer on it. The line forwards to an 800 line which > is on one of my WorldCom T-1s. > We get most calls in just fine and they forward okay. However, if we > get a call that forwards, then another one soon behind it (while the > first is still connected, it appears), the local line will simply ring > endlessly without forwarding. Bell, of course, can't find a problem, > so they're claiming that the problem has to be in my 800 lines.But we > know that we can stack multiple calls onto the 800 line just fine. The > only time we have the problem is with the forwarding from the CO line. It appears that your local telco's switch is not properly handling calls through the two call-forwarding features. In the scenario you described, was the first call passed to the 800 number via call-forward-on-no-answer? If it was, try busying out the line in question and try the experiment again. If the second forwarded call goes through on the second attempt, then you've narrowed down which feature is being corrupted by the other. > I am familiar with having to order multiple voice paths on an RCF > number, but my understanding was that on a local line with call > forward, this isn't something I have to do. One repair tech at Bell > told me that I DID need to order another voice path, and sent me to > business services... The repair tech didn't know what he was talking about. He probably told you that story to get you off his back. Your callers should either be getting your 800 number, or a busy signal. I found a similar problem with an older SL1's generic software package some years back. Northern Telecom wouldn't admit there was a problem, but I could demonstrate that secretarial override on a line with manual call-forwarding active, would wipe the switch's memory locations used to control call-forwarding for that station. > Or, maybe, the > problem is with SWBT, in which case I need to talk to the repair > department, even though they just sent me over. But, then, I'm sure I > don't need to elaborate on this cycle with the residents of these > groups. Forget about talking to repair department at SWB. They've blown you off, and probably will continue to do so as long as you listen. File a complaint with your state's equivalent of a Public Utilities Commission and tell them SWB knows they have a switch software problem, are refusing to fix it, are refusing to provide a tariff'd service for which you are paying, and ask them to order SWB to restore service immediately. Then, if they don't fix it, after hearing from the regulatory agency, wait 24 to 48 hours and file ANOTHER complaint. Don't forget to document every phone call with a SWB employee, you'll need it to document another complaint when they don't act. Don't be afraid to file complaints with the regulatory agency that oversees your local telco. Quite often, the volume of those complaints are used in a formula to calculate raises or other benefits for the telco's management employees (as they do in New York). ------------------------------ From: Peter Morgan Subject: Re: Of Course, If You Buy the Non-AOL Users Mailing List ... Date: Tue, 3 Jun 1997 01:41:15 +0100 In message henry mensch writes: > ... and you make it available freely on the web ... then having $60 > won't be the gating factor to send anyone on that list junk mail > anymore. In turn, this could open the floodgates to those folks > listed on that list. Agreed. 1) could be password protected (but that would be a headache) 2) I could do a search for any addresses recipients of this list want checked, and e-mail you back with a "found" or "not found" 3) I could (with a bit of help) put it in a script accessed via a web page but disallow any "match all" characters, so you can make a search without me being available [all our phone calls are chargeable here, and even local call rate to ISP mounts up ] I did suggest that copyright could prevent it being made available and Henry has identified a significant flaw that would occur if it was online for all to download. In the UK, some posters have completely abandoned showing any useful e-mail address. Let's hope that the law makers get rid of the problem, before we all throw our postings through anonymous forwarding services. Peter ------------------------------ From: Anbjrn Myren Subject: ISDN Analogue Adaptors Date: 3 Jun 1997 06:52:01 GMT Organization: Statoil I'm soon getting ISDN in my house. It a pure ISDN (2 lines), with no analogue lines. In order to still be able to use my USR33.6 voice/fax - modem,(as well as the wireless phone and the burglar-alarm system) I'll be needing an ISDN to analogue adapter. In Norway there is only one supplier of these adaptors (Telenor), and I feel that they are a bit overpriced. They charge 1490,- NOK for an adaptor with 2 analogue outputs, and 2490,- NOK for the one with 4 outputs. 1490,- NOK = 130 2490,- NOK = 216 However, these adaptors follow the European standard, so I'm free to buy any adaptor from another European country. Does anyone know how much these cost in UK or other countries? Please reply by email, mailto:amyren@online.no Anbjorn Myren, Norway, A4000 IRC: Anmy ------------------------------ From: Robert Holloman, Jr. Subject: Re: New, Very Fast Modem Available Date: Mon, 02 Jun 1997 13:16:11 -0400 Organization: MindSpring Enterprises Reply-To: holloman@mindspring.com Brett Frankenberger wrote: > However, most modem manufacturers today understate their effective > speeds (when running in async mode) anyway. The new "56KBps modem" > technonogy, when it actually runs at 56KBps on the wire, can handle > close to 70KBps "effective" async throughput *without compression*. Do you know where I can get my hands on a 56-kilo-BYTES-per-second modem? Mine's only a 56-kilo-BITS-per-second modem. > This is because "modern" modulation protocols are synchronous on the > analog side, so the start and stop bits don't need to be sent across > the wire. So if you stream 70000 bits per second out the serial port, > that's: > 70000 / (8 data bits + 1 stop bit + 1 start bit) = 7000 bytes per second > On the wire, that corresponds to 7000*8=56000 bits per second. Of > course, there is a bit of overhead ... so you might really only be able > to go 67000 ( :) ) async bits per second without compression. In other words, synchronous is a lot more efficient than asynchronous. All this means is that we need to set our serial ports at least 25% higher than the maximum DCE speed of our modern modems to prevent the port from being a bottleneck. (And or course, even higher when using data compression.) > So it wouldn't be too terribly inaccurate to call a 56K modem a 70K > modem. I'd say it would be terribly confusing and unnecessary. By this logic, we'd call it a 77Kbps modem if 11 (instead of 10) bits per character were normally used on the DTE side. Please, let's stick to RAW bit speeds when talking DCE (and DTE) speeds. (Remember the confusion when modem companies called their 9600bps MNP modems 19200bps, or some such?) Now, calling a 56Kbps modem a "modem that can, under ideal conditions and without compression, yield data throughput nearly as high as that of an asynchronous link operating at 70Kbps using 10-bit characters" would be pretty accurate. :) ------------------------------ From: Gordon S. Hlavenka Subject: Toll-Free ANI Readback Number Date: Mon, 02 Jun 1997 09:42:21 -0500 Organization: Crash Electronics, Inc. Reply-To: gordon@crashelex.com I received an email today from someone selling "Breakthrough" products. While I didn't order anything from them today, I did discover that they offer a free ANI readback service -- how very kind of them. When you dial (888) 212-8846 you will hear a message telling you that you have reached a "bulletproof" order line which will only accept two calls from your number. Then they read back your number. This should be useful for nailing down all those unmarked extensions in your wiring closet. It could also be useful for determining the number of any payphone you may be at, where the number tag is missing or illegible. Gordon S. Hlavenka www.crashelex.com gordon@crashelex.com Grammar and spelling flames welcome. Some of us still think it's important. ------------------------------ From: dcstar@acslink.aone.net.au (David Clayton) Subject: Re: Emergency Call Services Date: Tue, 03 Jun 1997 09:30:45 GMT Organization: Customer of Access One Pty Ltd, Melbourne, Australia Reply-To: dcstar@acslink.aone.net.au Chris Moffett contributed the following: > Raymond K.S. Yeung wrote: >> Does anyone know what a PBX would do when there's no resources >> (e.g. outgoing trunks) to support an emergency call (i.e. 911) from a >> local PBX subscriber? >> Would the PBX block the emergency call? Or would it bump out another >> "non-emergency" call to get the needed resources? Any publicized >> standards that specify this scenario? > I am not aware of a software feature that will do this automatically > but, in our Meridian PBX we have a single trunk that is not accessible > unless you dial 911. This guarantees that there will always be an > outgoing line available (we use smart trunks and in the event of a > power fail the analog trunk has a better chance of working that the > digital circuits) and it gives the 911 center a place to call back. > Any calls to that number will ring direct to the security desk in the > building. > If anyone does know of a software feature that will accomplish the > same thing (on a Nortel Meridian PBX) I would like to know. Switchview has a "Call Control" module that could probably be made to work in that way. I know it can detect when a "911" call is attempted, (by various "sneaky" ways), then it has the capability to go into the switch and disable and then enable trunks. It may be able to queue the original call and send it out when a trunk is free after the forced disabling. Regards, David Clayton, e-mail: dcstar@acslink.aone.net.au Melbourne, Victoria, Australia. ------------------------------ From: TELECOM Digest Editor Subject: Cleaning Out the Mailbox Date: Tue, 03 Jun 1997 08:56:00 EDT I really could not sleep very well last night so I decided to get up and do still another issue of the Digest and in the process clean out mail which had arrived overnight. From about two a.m. when I logged out until now -- about seven hours later -- fourteen pieces of spam and four legitimate messages, mostly from well-wishers. Amazing! I shudder to think of what my mailbox will look like if I in fact am off line for an extended period when I get back. If I get back; that's what bothers me a little right now. Anyway, keep up your good work and fight spam as long as you can. PAT ------------------------------ End of TELECOM Digest V17 #148 ******************************