Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!texbell!vector!telecom-gateway From: nvuxr!deej@bellcore.bellcore.com (David Lewis) Newsgroups: comp.dcom.telecom Subject: Re: Caller ID Privacy Question Message-ID: Date: 5 Sep 89 13:52:10 GMT Sender: news@vector.Dallas.TX.US Organization: Bellcore, Livingston, NJ Lines: 55 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 356, message 6 of 6 In article , buster!rli@uunet.uu.net (Buster Irby) writes: > Access to *my* > unlisted phone number is something which *I* pay for and which *I* control, > not anyone else. Actually, no. Access to "your" unlisted (unpublished) phone number is something which the telco agrees to not provide in certain circumstances -- published paper directories (with a reasonable likelihood to also include "Electronic White Pages" -- machine-readable or online directories -- if and when telcos get around to providing them) and Directory Assistance. "Your" unlisted phone number is provided by the telco to Interexchange Carriers every time you make an inter-LATA call, beyond your control; provided to information providers every time you access an information (audiotext) service; there may be other cases which don't come to mind immediately. > [Moderator's Note: I wonder why no one has yet suggested simply having the > device transmit the *name* of the caller, rather than the phone number, > since this would (a) identify the caller by the name under which the telco > carried him in its records; (b) probably be the same name under which I > had made your aquaintence; and (c) protect the private phone number of the > caller. In other words, the little box would read out, "Dr. Brown at home" > or "Smith Telemarketing Co." etc...the same purpose would be served. PT] Actually, people have. Here at Bellcore we have some experimental service trials, one of which is Caller Name Delivery. (Don't have the CPE for it, so we've got a bit of a hack with a DecTalk board -- you pick up the phone, and it says "Call from so-and-so", then you press * to accept the call or hang up to reject it.) The problem is administering the database. You'd like to meet the emerging performance expectations from Calling Number Delivery -- deliver the name between the first and second rings. That means you have to have accessed the appropriate database and found the name before the first ring is finished. If you try to do it from the terminating end, you've got to find a database on the originating end, send back a query, and get a response, all in (probably) under 1-2 seconds. Not easy. If you do the database lookup on the originating end -- makes more sense, because that's where the information is -- you've got to send the information along with the call setup information. There's no place to put it in SS7 basic call setup, so you've got to either hack it in somewhere in SCCP (Signaling Connection Control Part) or go back to standards and modify the protocol. Also not fun. (In the experiment at Bellcore, it's simple -- if the call isn't from a station subtending the Red Bank CO, we don't get the caller name...) In other words, a very good idea, and probably one which is a desirable solution, but a bear to make work. -- David G Lewis ...!bellcore!nvuxr!deej "If this is paradise, I wish I had a lawnmower."