Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: U5434122@ucsvc.ucs.unimelb.edu.au Newsgroups: comp.dcom.telecom Subject: Re: A New Feature One Might Build Into a Phone Message-ID: <10948@accuvax.nwu.edu> Date: 16 Aug 90 15:20:18 GMT Sender: news@accuvax.nwu.edu Organization: The University of Melbourne Lines: 73 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 574, Message 4 of 7 In article <10715@accuvax.nwu.edu>, synsys!jeffj@uunet.uu.net writes: > In Volume 10, Issue 547, Message 9 of 15, Message-ID: <10550@accuvax. > nwu.edu>, John Nagle posted: >> Now here's a thought. We all know the announcments which begin >>with a special three-tone sequence followed by "The number you have >>reached...". How about a voice recognition unit to recognize the new >>number and update your autodialer? The spoken digits are well > I'll go you one better: right after the tritone (that's called a SIT, > right?), transmit the data DIGITALLY with a modem, the same FSK as > used in Caller-ID. Rather than using a modem, DTMF signalling could be used. It is not as fast, but what's an extra couple of seconds, when you don't have to wait for the modems to CONNECT? > This is kind to machines: > The tritone is the header followed immediately by the data. Why not have the dialling machine respond with a DTMF (Touch tone) code which says, "Please inform of new number." This would necessitate putting a tone interpreter into the ANI (or whatever) system, but that can't be the hardest part of the exercise. Modems already have tone senders in them. A tone interpreter should not be too difficult, and the modem could inform the controlling software with messages like 'TONE 1' or 'TONE *' etc. > This is kind to humans: > The tritone is loud and annoying already so a little more screaming > won't hurt. > FAX/modem/autodialer manufacturers should love this: > If the machine recognizes the tritone and can act accordingly, you'll > prevent repeated failed calls. You could automatically update the > phone list when a new number is given. The retry mechanism could > adapt if the line is temporarily out of service or give up if it's > permanently out of service. > I'd expect a CCITT definition of the command to be something like a 16 > bit command followed by a variable length field. The commands would > be specified like: > command: 0000h Number out of service > following data: none CCITT could also define something like: Tritone - If you are a machine, press '* 0 #' to request status report. After the modem has dialled its '* 0 #' the CO can send: 1 - All lines busy 2 - Number out of service 3 - Number changed Modem responds with '*' New number is sent. etc. A really clever modem could conduct the conversation by itself, a more basic unit could simply report the tones received and allow software control. Of course, if there is no machine response after the initial tritone, a voice can inform the human of the number. Danny