*** PAT: PLEASE MASK MY EMAIL ADDRESS! ***
> [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 c.o.codes, 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!
Anthony
[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 <control-c> 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]
Anthony Bellanga (anthonybellanga@spampoison.com)