|
|
Message Digest
Volume 28 : Issue 145 : "text" Format
Messages in this Issue:
Re: ANI in real time (was: FTC builds case against telemarketers)
Re: ANI in real time
Re: ANI in real time (was: FTC builds case against telemarketers)
Feature Groups A, B, C, and D (was: FTC builds case against telemarketers)
Re: Feature Groups A, B, C, and D
Re: ANI in real time
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
====== 27 years of TELECOM Digest -- Founded August 21, 1981 ======
Telecom and VOIP (Voice over Internet Protocol) Digest for the
Internet. All contents here are copyrighted by Patrick Townson and
the individual writers/correspondents. Articles may be used in other
journals or newsgroups, provided the writer's name and the Digest are
included in the fair use quote. By using -any name or email address-
included herein for -any- reason other than responding to an article
herein, you agree to pay a hundred dollars to the recipients of the
email.
===========================
Addresses herein are not to be added to any mailing list, nor to be
sold or given away without explicit written consent. Chain letters,
viruses, porn, spam, and miscellaneous junk are definitely unwelcome.
We must fight spam for the same reason we fight crime: not because we
are naive enough to believe that we will ever stamp it out, but because
we do not want the kind of world that results when no one stands
against crime. Geoffrey Welsh
===========================
See the bottom of this issue for subscription and archive details
and the name of our lawyer, and other stuff of interest.
----------------------------------------------------------------------
Date: 28 May 2009 04:36:17 GMT
From: Steve Kostecke <steve@kostecke.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time (was: FTC builds case against telemarketers)
Message-ID: <slrnh1s561.pk1.steve@stasis.kostecke.net>
On 2009-05-26, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> On May 26, 9:51 am, "Adam H. Kerman" <a...@chinet.com> wrote:
>
>> Wikipedia entries often drive me nuts due to their lack of citations, or
>> citations to secondary sources that themselves cite no primary sources.
>
> Wikipedia is good for general background information, but it is not an
> authoritative source. Many people have reported finding material
> errors of fact in it, (as I did).
>
> I think it's good source for entertainment information.
Contributions from knowledgeable individuals would help make Wikipedia a
better source.
--
Steve Kostecke <steve@kostecke.net>
------------------------------
Date: Thu, 28 May 2009 12:32:31 -0500
From: John Mayson <john@mayson.us>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time
Message-ID: <alpine.LN8.2.00.0905281226510.3460@tintin.mayson.us>
This reminds me of an argument I have with my son from time to time. His
teachers forbid citing Wikipedia, which is understandable. But it's a
great source for learning the basics and background of a topic. Also most
articles have a list of authoratative sources at the end. I tell him he
can use Wikipedia to understand a new subject and find sources he can use,
but he stands by "teacher says I can't use Wikipedia".
I personally wouldn't stake my reputation on anything in Wikipedia, but
it's a good launch point.
John
--
John Mayson <john@mayson.us>
Austin, Texas, USA
------------------------------
Date: Thu, 28 May 2009 06:39:13 +0000 (UTC)
From: "Adam H. Kerman" <ahk@chinet.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time (was: FTC builds case against telemarketers)
Message-ID: <gvlbig$13v$1@news.albasani.net>
Robert Bonomi <bonomi@host122.r-bonomi.com> wrote:
>Adam H. Kerman <ahk@chinet.com> wrote:
>>Adam H. Kerman <ahk@chinet.com> wrote:
>>>hancock4@bbs.cpcn.com wrote:
>>>>The following article from the Phila Inqr describes some outrageous
>>>>stuff pulled by telemarketers in violation of multiple laws and how
>>>>people fought back. This includes spoofing the caller ID.
>>>>See: http://www.philly.com/philly/business/personal_finance/45231832.html
>>>>Would anyone know if Call Trace (1157) works when a telemarketer
>>>>calls? That is, does Call Trace send the real ANI or the caller-ID to
>>>>the Call Trace Bureau.
>>>Unfortunately, ANI doesn't make it to your switch.
>>For the hell of it, I read the Wikipedia entry on ANI.
>>http://en.wikipedia.org/wiki/Automatic_Number_Identification
>>Wikipedia entries often drive me nuts due to their lack of citations, or
>>citations to secondary sources that themselves cite no primary sources.
>>Take this quote, for instance:
>> Privacy
>>
>> Because ANI is unrelated to caller ID, the caller's telephone
>> number and line type are captured by ANI equipment even if
>> caller ID blocking is activated. The destination telephone
>> company switching office can relay the originating telephone
>> number to ANI delivery services subscribers. Toll-free Inward
>> WATS number subscribers and large companies normally have access
>> to ANI information, either instantly via installed equipment,
>> or from a monthly billing statement. Residential subscribers can
>> obtain access to ANI information through third party companies
>> that charge for the service.
>>On my home number, I can subscribe to a third-party service that will
>>provide me ANI instantly? I had no idea. Due to there being no source
>>provided, I still don't.
>Would you believe "it depends"? <wry grin>
>Some _facilities-based_ third-party dial-tone providers offer the option
>of real-time ANI delivered as CLID. You can't buy it separately, still
>getting dial-tone from your current preferred carrier.
You mean if my carrier is a reseller?
>I've got no vendor names at this time, but it _is_ available.
To a residential subscriber or a single-line business subscriber? That
would be pretty neat.
>Other providers _do_ offer real-time ANI for multi-line systems, delivered
>over a separate channel -- possibly the D channel of a PRI, possibly a
>dedicated data circuit.
Probably not going to have that at home.
Thank you for the information.
------------------------------
Date: Thu, 28 May 2009 07:58:15 +0000 (UTC)
From: "Adam H. Kerman" <ahk@chinet.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Feature Groups A, B, C, and D (was: FTC builds case against telemarketers)
Message-ID: <gvlg6n$88d$1@news.albasani.net>
>***** Moderator's Note *****
>I'd like to take a trip down memory lane: someone please explain what
>feature groups A, B, and C are, how they were used, and whether any of
>them (including feature group D) are still in use.
Too bad Mark Cuccia hasn't posted in a while; he'd know this by heart.
FgA: Caller would dial a 7-digit number. (In the '80's, at the office,
the long distance carrier, perhaps Sprint, called it InfoSwitch.) He'd then
have to dial the 10-digit number and an account number, don't recall
what the order was.
I found a note that the dial-up circuit was a two-wire connection.
FgB: Caller would dial 950-XXXX. The long distance carrier had a four
digit FgB code beginning with 0 or 1. The caller would then dial the 10
digit telephone number and account number. I really liked this service,
so many fewer digits to dial than calling cards, but a lot of switches
didn't implement it and pay phones often accidentally mishandled these
calls. 950 was chosen because it didn't spell anything and tended not to
be assigned as a prefix. It's not a 7-digit telephone number but a
routing code.
Abstract below notes that the Carrier Identification Code need no longer
begin with 0 or 1.
I found a note that the dial-up circuit was a four-wire connection, the
other two wires would signal ANI. I vaguely recall that when I used it
with my long distance carrier from home, I wouldn't dial an account
number, but when I used it elsewhere to bill the call to myself, I would.
FgC: No clue, something to do with signalling on network-controlled pay
phones deployed by AT&T.
FgD: Equal Access trunk line. Caller would dial 10XXX + 10 digit number,
no account number. With an explosion of such services, the code was
changed to 101-XXXX and existing codes had a 0 prepended, hence all the
1010-XXX advertising.
Note that the 4-digit Carrier Identification Codes were once assigned in
common between FgB and FgD, but the abstract below notes that it's no
longer the case.
>From Telcordia:
Feature Group A
LSSGR: Feature Group A, FSD 20-24-0200
Document Number GR-697
Feature Group provides to the patron (service purchaser) line-side
termination and a 7-digit access code (the directory number of the access
line) at the Feature Group A (FGA) Serving Office (FGASO). FGA consists of
line-terminated access circuits that will include, but are not limited to,
arrangements used to provide interLATA (Local Access and Transport Area)
Foreign Exchange (FX) service, Exchange Network for InterLATA Access
(ENFIA) A-type service, and interLATA off-network access lines from
private networks. This Generic Requirements document (GR) describes the
view of Telcordia on generic requirements for Feature Group A.
Feature Group B
LSSGR: Feature Group B, FSD 20-24-0300
Document Number GR-698
Feature Group B (FGB) access is being expanded to provide a uniform
950-XXXX code to reach carriers that have trunk-side interconnection to
Local Exchange Carrier (LEC) switches. This Generic Requirements document
(GR) modifies the format of the access code (formerly 950-WXXX, where W
= 0 or 1) and provides for a transition to the expanded format. Affected
switching systems must be updated to handle FGB 950-XXXX calls as described
in this document. In addition, the prior linkage between FGB and Feature
Group D (FGD) code assignments is being discontinued as this change is
introduced. This document also provides a modified view of the status
of the 'transitional' capability whereby calls bearing selected 950-WXXX
addresses can be served over a Feature Group D interface, and adds minor
footnotes regarding '950' dialing procedures for customers associated
with step-by-step switches.
I didn't spot similarly helpful abstracts for FgC or FgD.
Here's an excerpt from a textbook explanation of FgD, mentioning that
ANI may be received at the called party's switch!
http://www.nmscommunications.com/manuals/6709-13/chap8.htm
This document mentions Feature Group E, without explantion.
http://cpr.bellsouth.com/pdf/nc/filings/appr/NC2007-050.pdf
------------------------------
Date: Thu, 28 May 2009 14:27:29 +0000 (UTC)
From: Paul <pssawyer@comcast.net.INVALID>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: Feature Groups A, B, C, and D
Message-ID: <Xns9C196AB89F979Senex@85.214.105.209>
"Adam H. Kerman" <ahk@chinet.com> wrote in
news:gvlg6n$88d$1@news.albasani.net:
> FgA: Caller would dial a 7-digit number. (In the '80's, at the
> office, the long distance carrier, perhaps Sprint, called it
> InfoSwitch.) He'd then have to dial the 10-digit number and an
> account number, don't recall what the order was.
InfoSwitch was a long-distance calling and billing system from
Datapoint. We used it on campus from the mid-1970s through 1985 to
avoid using our CENTREX system for outgoing calls, using mostly WATS
and FX lines. It enabled us to bill directly to each individual
user (rather than by station) which policy is still in place. Some
of our older customers were still calling the authorization code the
"Infoswitch number" as recently as a few years ago!
--
Paul
------------------------------
Date: Thu, 28 May 2009 06:41:17 +0000 (UTC)
From: "Adam H. Kerman" <ahk@chinet.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time
Message-ID: <gvlbmd$13v$2@news.albasani.net>
Robert Bonomi <bonomi@host122.r-bonomi.com> wrote:
>With the right C.O. equipment, it is possible to capture the ANI data
>in the call set-up and pass *THAT* information via the CLID signalling
>to the end-user.
So, it's often the case that ANI makes it to the switch serving the
called party? I stand corrected, then.
***** Moderator's Note *****
You don't need to correct yourself: as others have pointed out,
ANI info per se is NOT a substitute for CLID data, since the ANI
might or might not match the CLID (as for forwarded calls), so
it's not a reliable substiture for CLID.
WATS subscribers get ANI info because SS7 wasn't in service when
WATS was introduced, so CLID data wasn't available either.
HTH.
Bill Horne
Temporary Moderator
------------------------------
Date: Thu, 28 May 2009 11:51:17 -0700 (PDT)
From: hancock4@bbs.cpcn.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <de0e98d1-5cb2-4eb2-a1bb-3c1a681c7354@u10g2000vbd.googlegroups.com>
On May 28, 12:12 am, bon...@host122.r-bonomi.com (Robert Bonomi)
wrote:
> There are many _legitimate_ reasons for businesses to send 'caller ID'
> info that is different from the actual line ID that the call is being
> placed from.
Could you elaborate on those reasons?
> For a -trivial- case, consider a call placed on an out-bound *only*
> trunk: providing the actual circuit ID for that trunk is
> [unproductive] in all cases where it is a legitimate call, since the
> call recipient *cannot* call that number to reach the party who called
> them.
Interesting you mention that. Over the last few days I've been
dealing with a business served by a PBX (not Centrex). They have one
listed number for all incoming calls. But when I get calls from that
business, the caller-ID could be anything (though in the exchange for
that town.) Indeed, in thinking about it, when I get calls from other
firms with a PBX the same thing happens. The caller-ID is telling me
what outward trunk line happened to be selected for that particular
call.
[Moderator snip]
Heck, say I was a small business with a simple key system, and my
lines were 555-2300, 555-2301, 555-2302. I call out on -2302. Now
someone could call me back on that, but the main number of my business
is -2300.
In any event, it seems to me that if any substitution must be done, it
should be done at the originating central office and nowhere else.
The idea of people hitting a button on their caller-id box to return a
call seems very foolish to me. Just because someone calls from a
particular phone does NOT mean they'll be at that particular phone
when the call is returned. Someone could be at a pay phone or a
stranger lending them a phone to use*. They could be leaving their
office or home headed somewhere else. They could be at a friend's
house.
* Now that pay phones are rare and calls are cheap, many businesses
will let a stranger make a quick local call as a courtesy. Many
people will lend their cell phone to stranger, say at a train station,
to make a quick call. This sort of thing happens quite frequently.
------------------------------
Date: Thu, 28 May 2009 12:44:07 -0700 (PDT)
From: hancock4@bbs.cpcn.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <3959ee3c-37f1-4505-bea8-1ea8d1d9a4fe@f16g2000vbf.googlegroups.com>
On May 28, 12:24 am, bon...@host122.r-bonomi.com (Robert Bonomi)
wrote:
> |> With the right C.O. equipment, it is possible to capture the ANI
> |> data in the call set-up and pass *THAT* information via the CLID
> |> signalling to the end-user.
> |What I don't understand why this isn't done universally.
>
> The issue to _all_ such questions is always "money": it costs a bunch
> more to do things that way. Caller-ID is a hard-enough sell, due to the
> prices that (particularly the former Baby Bells) charge, that the higher
> pricing to recover the extra cost of the extra gear would eliminate *most*
> of the customer base.
Again, I am confused. Isn't everything in a switch today done by
software, not hardware? It's not like the old days where they had to
wire in expensive relays and electronic circuits in a trunking circuit
to do a function. Given that the software would be used in thousands
of switches the software cost would be amortized over a wide base.
Further, the ongoing confusion from spoofing and other troubles
undoubtedly is a headache for both the local and toll carriers.
Accordingly, I don't understand why it would "cost a bunch more
money".
I also disagree that Caller ID is a "hard sell". IIRC, the price of
it has doubled in recent years ($3 to $6 per line) yet it remains very
popular. (I don't know actual subscriber base, but FWIW almost
everyone I know has it in both work and home and all cell phones have
it.) Indeed, some carriers offer it free as part of a package.
> ***** Moderator's Note *****
>
> The operating companies are _very_ reluctant to introduce _any_
> non-standard feature or equipment.
Sure, a "non-standard" feature. But it seems to me, given all the
problems of spoofing and misuse, that it ought to be a 'standard'
feature. Per above, I think the cost would be minimal.
>ANI info per se is NOT a substitute for CLID data, since the ANI
>might or might not match the CLID (as for forwarded calls), so
>it's not a reliable substiture for CLID.
I don't understand the relevance of "forwarded calls". If a call is
forwarded, that is, Amy calls Ben and Ben calls Caz, it seems to me
that Ben's number should appear on Caz's box. I believe that's how it
work's now. As the forwarder, Ben is the caller and responsible for
the call, not Amy.
***** Moderator's Note *****
Central Office design is an _extremely_ conservative
environment. Every software change is tested exhaustively, both for
its intended functionality and to reveal any unintended side-effects.
I'm not sure I can describe just _how_ conservative it is, so I'll ask
that you take my word for it: if it isn't going to be in the switch
until the heat death of the universe, they don't want it in there at
all.
Changing ANI into CLID just isn't something Nortel or Lucent is going
to do.
FWIW. YMMV.
Bill Horne
Temporary Moderator
------------------------------
Date: Thu, 28 May 2009 13:28:25 -0700 (PDT)
From: hancock4@bbs.cpcn.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <61467a47-f904-4790-b69b-3d463ad2a156@x6g2000vbg.googlegroups.com>
On May 27, 6:31 pm, Bill Horne <b...@horneQRM.net> wrote:
> Ma Bell only reacted when its revenues were in danger, but that wasn't
> until 800 subscribers (who were, after all, the ones writing the
> checks for the cost of Blue Box fraud) gained knowlege of Blue Boxes,
> and realized that they were paying for WATS calls that they were never
> able to answer. That knowlege became widespread with the now-infamous
> Esquire article "The Secrets of the Little Blue Box", and WATS
> subscribers threw a fit when they figured out what was going on:
> remember, Blue Boxes could only work by redirecting the routing of a
> call which the local (originating) switch had already marked as being
> made to an long-distance number, so when the call "completed", albeit
> to somewhere else besides the number on the ANI record, the Bell
> System blithely prepared and submitted bills for 800 service which had
> never occurred.
As I recall history, including some articles in the New York Times,
the Bell System was aware of and fighting Blue Boxes well before the
Esquire article was published. (A NYT article described complaints
about Bell System investigation tactics before Esquire publication.)
I believe at the time Blue Boxes were first used there weren't very
many 800 numbers out there. But one can get a 'free line' by calling
long distance information--1-NPA-555-1212.
> In a nutshell, it happened for the same reason that your email account
> suffers from spam: the engineers who designed the Long Distance
> network were academicians who never considered that someone might
> break the rules for commercial gain. Although the lessons of World War
> II were applied to the _layout_ of the network, e.g., by providing
> diversified routes and access to multiple tandems for business users,
> no one anticipated a need for measures to prevent sabotage.
While I don't know for sure, everything I've read and my own
experineces suggests the old Bell System always had a very different
mindset than those who developed the Internet:
The literature describing the development and implementation of the
Panel switching system back in the 1920s took into full consideration
that a subscriber accidently or intentionally could do something wrong
and the switch had to be protected. If a subscriber dialed a non
existent number or left their phone off the hook the system dealt with
it. The system provided a verification panel to check the given home
number for toll calls. There were special codes only operators could
enter.
This attitude continued with the introduction of Touch Tone and DDD.
With Touch Tone, they did extensive experimentation to come up with
tones that wouldn't accidently be duplicated. They also worked hard
to make the receivers very accurate.
Combined with all this was a very aggressive network management
approach (something critical to the success of the old Bell System and
taken for granted by critics). It wasn't until electronics dropped
radically in price in the late 1980s that trunk and switching capacity
could expand to be well above demand. Until then the Bell System
monitored system usage, both local and toll, very closely to ensure it
was running smoothly. This intense network management was an integral
part of the service and system.
Accordingly, I conclude the old _pre-divesture_ Bell System was quite
concerned about sabotage.
Now, _after_ divesture everything changed. The old Bell System ceased
to exist. There was NO "Ma Bell" after divesture. The local
carriers, toll carriers, and newcomers were each out for themselves
and to minimize costs and maximize revenues. It was a very different
business model than the past.
Complicating matters was the government orders to allow newcomers
direct access to the network. As a result we saw many subscribers
unknowingly and unwillingly get their long distance carrier changed
and the new carrier charging outrageous rates. We also saw PBX users
unable to make calls because the PBX tables didn't contain up-to-date
info about new exchanges. (We also saw PBX users without service
because the PBX vendor was garbage. On this newsgroup it was
frightening to see really stupid questions about basic from installers
who should've been a lot smarter).
I do not understand the detail's of today's trunking arrangements
between carriers, resellers, and large users, but I suspect as a
result of the above the protections that ought to have been in place
were never installed.
> It may be a crime to give a false number WITH INTENT TO DEFRAUD, but
> it's almost never illegal to do so with intent to _deceive_, i.e.,
> with the intent to influence a buyer and sell something, or the intent
> to collect a debt. IANALB, most statutes require fraudulent intent
> before a crime has been committed, and the fraud has to involve direct
> avoidance of costs. So long as Ma Bell gets paid, there's no
> motivation to even admit the problem exists - and you can stop me when
> this starts to sound familiar.
As mentioned, there is no "Ma Bell". Today there are, by govt order,
a multitude of carriers involved. Often a major carrier does NOT get
paid, but screwed by the failure of a sleazy or incompetment
reseller. (Remember the Newark scandal?)
Imagine a restaurant ordered to buy food from a questionable supplier
because the govt ordered it in the interests of "competition".
As to "fraud", my business law textbook defines it as follows: "the
making of a false statement of a past or existing fact with knowledge
of its falsity or with reckless indifference as to its truth with the
intent to cause another to rely thereon, and he does rely thereon to
his injury."
To me, passing a false number clearly meets the above definition.
Yes, the "injury" may be slight but that doesn't matter.
The carriers may also be liable since subscribers reasonably assume
the number displayed is the originating number. If the carriers fail
to advise all subscribers the callder ID box displays are not
reliable, or fail to take steps to ensure reliability, they are guilty
of fraudulent statements of expert fact. Sadly, it may take a nasty
tort lawsuit loss against a carrier to force the issue; I don't like
it when public policy is developed by the courts.
------------------------------
TELECOM Digest is an electronic journal devoted mostly to telecom-
munications topics. It is circulated anywhere there is email, in
addition to Usenet, where it appears as the moderated newsgroup
'comp.dcom.telecom'.
TELECOM Digest is a not-for-profit, mostly non-commercial educational
service offered to the Internet by Patrick Townson. All the contents
of the Digest are compilation-copyrighted. You may reprint articles in
some other media on an occasional basis, but please attribute my work
and that of the original author.
The Telecom Digest is currently being moderated by Bill Horne while
Pat Townson recovers from a stroke.
Contact information: Bill Horne
Telecom Digest
43 Deerfield Road
Sharon MA 02067-2301
781-784-7287
bill at horne dot net
Subscribe: telecom-request@telecom-digest.org?body=subscribe telecom
Unsubscribe: telecom-request@telecom-digest.org?body=unsubscribe telecom
This Digest is the oldest continuing e-journal about telecomm-
unications on the Internet, having been founded in August, 1981 and
published continuously since then. Our archives are available for
your review/research. We believe we are the oldest e-zine/mailing list
on the internet in any category!
URL information: http://telecom-digest.org
Copyright (C) 2008 TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.
************************
---------------------------------------------------------------
Finally, the Digest is funded by gifts from generous readers such as
yourself who provide funding in amounts deemed appropriate. Your help
is important and appreciated. A suggested donation of fifty dollars
per year per reader is considered appropriate. See our address above.
Please make at least a single donation to cover the cost of processing
your name to the mailing list.
All opinions expressed herein are deemed to be those of the
author. Any organizations listed are for identification purposes only
and messages should not be considered any official expression by the
organization.
End of The Telecom digest (9 messages)
******************************
|
or 