Caller ID/etc. (Dumb Question on Do Not Call)


[TELECOM Digest Editor's Note:

> The 'reject anonymous calls' condition only applies if the caller > _deliberatly_ inserted *67 to withhold his number. That condition > will not work if the failure to deliver ID is due to a telco > shortcoming, such as the type of switch used by the sending telco, > etc. The 'reject anonymous' condition relies on the sending telco > specifically saying 'do not say who is calling'. In your case the > sending telco is not saying that, it just does not know who the > caller is or else the details somehow got lost in the switching > matrix on the way. But it did not _deny_ or _hide_ anything at the > caller's request.

So far, so good.

You still have a way around it however. Subscribe through your telco > to *60 (I think that is called 'reject these callers' in many > places). *60 answers you and says 'enter the number to be rejected' > or words to that effect and from that point on _that_ caller gets a > message saying you are not taking calls at this time.

Well, still so good for now.

Now I heard your next question already: if you do not know _who_ is > calling, how are you supposed to block them? Good question. The *60 > recording also tells you 'to reject the last call you received, > whether or not you know the number, press (some) key.' I think > around here it is '01' or something. You press whatever you were > told, and the Operator-Bot responds, "Thank you! That number is a > _private_ entry." But none the less it has been blocked. Your telco > has a 'local cache' of the last call you placed/ received and it > uses that entry to do the blocking.

But this too works ONLY if the terminating telco has that number delivered to it along the way. IF the calling number is simply "not available" because of the various reasons you above itemized, you won't be able to "Call Block" that last incoming number. However, IF that caller deliberately used *67 to suppress delivery of their number at the called end, as long as the telcos along the line have that number, you can use "Call Block". However, in most cases, this will ONLY work on Intra LATA numbers.

The number has to be deliverable via the SS7 signaling network, (although the number might be suppressed for "final delivery", at the calling party's *67 request) for the called party to be able to add that "last incoming number" or specifically entered number on to their "Call Block" list. And the list is limited to anywhere from six to twelve entries, depending on local telco policy or your type of local switching equipment equipment (Lucent 5ESS vs. Nortel DMS-100, and even differences with different "generics").

If your telco offers 'return last call' service (*68 I think),

It's *69 in most places in the US and Canada, not *68.

then you can also use that service to return the last call and find > out what the 'important business matter' is all about. Both 'return > last call' and 'reject this caller' service are sold by most telcos > these days. PAT]

In most places, *69 will quote the number of the last incoming number if it isn't flagged as "private" with *69; AND the number must also have been properly "delivered" via the SS7 signaling network -- i.e., it can not be "unavailable" or "unknown" or "out of area". You are also allowed a "conenct back" option after the quote, by pressing or dialing (or saying?) "one", but this "connect back" will not work if the calling number was inter LATA. I don't know if the "connect back" option works if the calling number was flagged as "private" or "blocked" with *69.

Adding numbes to a "Call Block" list or doing a *69 "connect back" might also NOT be allowed on certain classes of lines/numbers, even if the "number" was delivered. Many times, such calling numbers (which have been delivered/deliverable) as payphones, cellphones, PBX lines (and various types of PBX lines, such as outbound trunk lines, billing number only lines, actual PBX extensions, etc), centrex lines, CLEC numbers, etc. are NOT allowed to be "queue'd back for a *69 connect back" nor to be added to a "Call Block" list.

You might be able to get a "quote back" (of some kind) on *69, and you might be able to see "some" kind of number on your CID box, but don't expect perfect inter-operation with *60 Call Blcck or *69 Quote-back/Connect-Back. And to even be "possible" to work, the number must be SS7-delivered (even if the calling party did *69 or their line is flagged as a *69 type line), and it must usually be intra-LATA, to be able to fully work.

About the only thing that MIGHT work on "unavailable" or "unknown" or "out-of-area" numbers (and remember that calls from overseas are usually flagged as "out of area" unless you have full ISDN or similar features as well as everyone else down the line too), is to get "Privacy Manager". This will divert the call to the local terminating telco's platform asking the calling party to enter their ten-digit telephone number, etc. Of course, I assume you remember that even this has drawbacks, such as invalid ten-digit strings (invalid area codes, invalid format, etc) being able to "pass through" the Privacy Manager restricor. Thus, a totally invalid number such as

000-000-0000 or 999-888-7777 or whatever can still bypass "Privacy Manager" and ring your phone!


[TELECOM Digest Editor's Note: An intertesting experiment to try is to 'ping' a distant number and see if it is in the type of central office where this can be done. Using the *60 function, dial some random number in anther area code on the opposite coast of the country, three thousand miles away. Please note how the equipment will sit there a bit longer than if it was in your own area. Apparently your central office has to 'ping' the other end to wake it up and see what it is about: After typically 15-20 seconds (a much longer time than if you were calling somewhere in your telco's operating territory) the Operator-Bot will return and say one of these things: (1) either you have, indeed, blocked out the requested number [in which case you can turn around and immediatly unblock it, if it matters] or (2) "I am sorry, but that number cannot be blocked" or (3) "I am sorry, that number cannot be blocked _at this time_, please try again in a few minutes." I think what response #3 means is that your telco went and knocked on the door there, was told at some previous point that yes, those numbers could be blocked, but the distant central office did not respond 'quick enough' to the 'ping message' and your central office got tired of waiting and walked away. But ask again, in a minute or two, your central office will be glad to go over there and knock on the door again, and maybe make it that time.

It sort of reminds me of how many years ago when the internet was newer and still in need of tweaking now and then, a large mailing list like this one (in the olden, text-message only days of email/Usenet, I had _thousands_ of names on the telecom list in the bcc area [still have several hundred readers via email, but many/most of you now read this on the 'web'])I would encounter difficulty in mailing. I'd get back notices from the postmaster-bot saying delivery had failed, during 'user open with' which meant that some site somewhere had opened its gate to let me and my list in, but before the entire list to that location got in the door, the other site got tired of waiting and closed the gate on me. I'd have to break the list into a few parts and mail specifically to that site only as a separate thing. When MCI Mail was a big thing, I had three or four hundred readers via MCI Mail which was notorious for closing the gate before all the readers at that site could get their copies.

I also had the same trouble with Usenet sometimes: I'd get to some 'backbone site' to drop off the current comp.dcom.telecom messages and in the middle of my posting of the new messages, a second or two after I got there, let's say UUNET as an example, some other newsgroup moderator with five or ten times as many messages that day as I had would arrive. The way the system was set up, the 'last' newsgroup to arrive inbound with new messages always took control of the process, so I could not get out of there and move on to my next stop until _he_ was finished with his drop as well. And sometimes it took _him_ a long time to make his drop; I had to sit and tap my toes waiting for him to finish his drop. Where many large-volume Usenet message posters (such as group moderators) drop everything in the stream at one location (where they work out of) and let it float down the news stream on its own, for quite a few years I have used software called 'nntpxmit' which speeds me along rapidly to the large Usenet distribution points where I have permission to post directly, the theory being that it is quicker to get back a response of 'SEEN IT' a dozen times to the new messages [because one of my other distribution points was quick and beat me to the punch in delivery before I could get to the next place on my own] than it is to say 'I HAVE' (message serial number) a dozen times and wait for acknowlegement from the other end. Even so, sometimes even today, I will fire up NNTPXMIT and start it making its rounds, get to one stop, tell it IHAVE (number), it will sit there looking at it for a couple seconds, some other newsgroup arrives, bumps me aside, takes over the process, and I may be awhile getting my deliveries done, in which case I just do and start over hoping for faster delivery. I get all the way around the world to my primary Usenet sites in less than a minute if I am lucky. PAT]

Reply to
Anthony Bellanga
Loading thread data ... Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.