Path: utzoo!telecom-request Date: Sun, 9 Jun 91 02:50:22 -0700 From: Steve Forrette Newsgroups: comp.dcom.telecom Subject: Re: Pet Peeve About Newer Modems (was Telephone Keypads) Message-ID: Organization: University of California, Berkeley Sender: Telecom@eecs.nwu.edu Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 446, Message 4 of 7 Lines: 109 In article Greg Andrews writes: > In article forrette@cory.berkeley.edu > (Steve Forrette) writes: >> This reminds me of a "pet peeve" (sic?) that I have with the newer >> modems. Both the Hayes 9600 V-series and the $74 2400 card-modem I >> have won't accept an ATS11 value (DTMF duration) of less than 50ms. > Hmmm. You want your modem to use 36 ms instead of 50? [stuff deleted] > How many switches in this country (and the world) can reliably handle > DTMF tones faster than 50 ms? How many can handle them even that > fast? The point is not how many switches can handle what, but what MY switch can handle. I believe that the telco published minimum (i.e. what they guarantee) is 50ms, so the 100ms default of the modem is plenty to allow for customers to not have problems. By changing the default, I am telling the modem that I don't want the default used, but want my own value used instead. > In my humble opinion, it's a little silly to get upset over such a > small amount of time. Of course, I happen to work for Telebit > technical support, so that may explain my viewpoint a little bit... Greg, I think that I can live with the .2 seconds extra. The point is that this attitude on the part of the manufacturer is all too common in the telecom industry today. It's this attitude that causes the Bay Area cellular carriers to require a "1" before dialing a long distance number, and not allowing the area code for local numbers. Just like the 36ms dialing, both of these once worked just fine, but now have been changed. Since all of these worked just fine at one time, there's no technical reason not to allow them. The attitude of "Sir, why do you need this?" gets really old after awhile. What good reason can you give for making these changes? It doesn't improve the service for those that follow the instructions and use the defaults, but makes things more difficult and annoying for those that know a little more and like to use the more obscure features. Here's another example: I recently ordered new phone service from Pacific Bell because of a move. I wanted a line with regular call waiting and busy transfer to my other number. I was told by the Business Office that this combination was not tariffed, and was even read a quote from the Handbook stating that call waiting cannot be on a line with either busy or no-answer transfer. I had exactly that setup a couple of years ago from US West in Seattle. Call waiting kicked in first, then a third call would busy transfer to the other number. And if I was dialing out on the modem and invoked cancel call waiting, the first incoming call would busy transfer. Is someone going to tell me that US West's 1AESS's and DMS-100's can to this, but Pacific Bell's cannot? Of course they can. But somebody decided "Nobody will need this, and it may be confusing anyway." So, I could not purchase this no matter how well I understood it. I was willing to pay for all these features, but they wouldn't take my money because somebody decided that this isn't what I really needed, and/or that I wouldn't understand it. I complained, and tracked somebody down in the department that makes the marketing decisions for Custom Calling features. First they tried to give me the line that it was not technically possible. Once that was dismissed, the complication and lack of need was brought up. Do you see the danger of this attitude? In article Dave Levenson writes: > Call*Return does not do its work by continually redialing, but by > queueing a request in a database common to your switch and the called > switch. This does not result in network blockage from busy attempts, > as CPE rapid-dialing does. Oh, but it does! When queueing a call, the calling switch sends a request every so often (around 30 to 45 seconds) over the SS7 network to the destination switch, asking it if the destination line is idle. If it is, then the caller is rung, and upon answer, a "fresh" call attempt is made (which could reach busy if the destination started another call in the meantime). It does NOT work by queueing a request at the destination switch. Why this is, I don't know. I've read several journal articles about SS7 and the implementation of the CLASS features, and they never mentioned the rationale behind this, but did clearly explain that this is the way it works. Steve Forrette, forrette@cory.berkeley.edu [Moderator's Note: A funny story about automatic redial here in Chicago: I used my phone to dial my own number, and of course I got a busy signal, not a call-waiting tone. I disconnected and dialed *66. The recording told me the number I had dialed was busy, but that it if became free in the next thirty minutes, I would be called back 'with a special ring'. Well of course a few seconds after disconnecting a second time, my line was observed to be 'free', so I got the special ring (two short and one long). When I answered, after a couple seconds of silence the recording advised me 'the number you are calling was free, but it has become busy again ... we will continue trying.' I hang up, a few seconds later I get the special ring, and the same routine. Apparently this would have gone on for some time -- 30 minutes probably, since that is the time limit it originally said it would use to try and get through -- but I dialed *86 and 'cancelled my repeat dialing and automatic callback requests.' :) PAT]