|
|
Message Digest
Volume 28 : Issue 144 : "text" Format
Messages in this Issue:
Re: FTC builds case against telemarketers
Re: ANI in real time
Re: ANI in real time
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI vs. Caller ID
Re: ANI in real time (was: FTC builds case against telemarketers)
Wikipedia (was ANI in real time)
Re: ANI vs CID {telecom}
====== 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: Tue, 26 May 2009 17:49:13 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: FTC builds case against telemarketers
Message-ID: <0oudnT4aQpd07IHXnZ2dnUVZ_r9i4p2d@posted.nuvoxcommunications>
In article <gvar17$jtq$1@news.albasani.net>,
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.
Uhm. [It] may, or may not. [The answer is] the proverbial "it
depends", on a _lot_ of things.
As I recall, real-time ANI is part of 'Feature Group D', that can be
provisioned on hi-cap customer tail circuits.
***** 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.
Bill Horne
------------------------------
Date: Tue, 26 May 2009 22:59:33 +0000 (UTC)
From: "Adam H. Kerman" <ahk@chinet.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time
Message-ID: <gvhs8l$k4j$6@news.albasani.net>
ranck@vt.edu wrote:
>Adam H. Kerman <ahk@chinet.com> wrote:
>> Privacy
>> 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.
>Uh, well they don't say instantly for residential. I have an 800
>number that I got when my kids were in college.
A toll-free number isn't residential phone service, not the way it's ever
been defined in tariff or any other industry document.
>It directs calls to whatever local phone number I choose.
Yes, it can certainly point to a residential phone number.
>My monthly bill tells me the phone numbers that have called my 800 number.
Receiving a print out of the ANI log is a feature of the bill for 800
service. It's the raw data for the bill!
>I got my 800 service from Broadwing (now Level 3), but I would assume
>other providers offer the same service.
You received the ANI call log on your bill for 800 service. You didn't
obtain access to it through a third party company. It's not possible
to interpret that sentence in the Wikipedia entry as factual.
------------------------------
Date: Tue, 26 May 2009 18:08:05 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time
Message-ID: <f5OdnU3ILIPI64HXnZ2dnUVZ_hmdnZ2d@posted.nuvoxcommunications>
In article <AqXSl.23180$as4.12740@nlpi069.nbdc.sbc.com>,
Steven Lichter <diespammers@ikillspammers.com> wrote:
>ranck@vt.edu wrote:
>> Adam H. Kerman <ahk@chinet.com> wrote:
>>
>>> Take this quote [from Wikipedia] for instance:
>>>
>>> Privacy
>>>
>>> ... 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.
>>
>> Uh, well they don't say instantly for residential. I have an 800
>> number that I got when my kids were in college. It directs calls to
>> whatever local phone number I choose. My monthly bill tells me the
>> phone numbers that have called my 800 number. I got my 800 service
>> from Broadwing (now Level 3), but I would assume other providers
>> offer the same service.
>>
>> I suppose like anything else, enough money thrown at some phone
>> company or another would yield real time ANI at your home. ;-)
>
>Years ago when I still had my BBS online; I had an 800 number for
>network calls since I was the server for our net. I had a friend
>build me a receiver that allowed me to see the incoming number. I
>still have it now, but when I hooked it on my phone line it does not
>work, I did this to be able to see blocked numbers. I have been told
>by at&t the ANI is not passed onto the subscriber, having worked in
>the industry since 1967 I don't understand how that could be blocked.
The only remote number signalling on tail-circuit POTS lines, regardless of
whether they are residential or business, is the protocol used for CLID.
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.
Typical real-time ANI (which presumes a multi-line incoming set-up) comes over
the D channel of a PRI, or a dedicated data circuit. Similar to, but not
identical to, the way SMDR data is output by a switch.
------------------------------
Date: Wed, 27 May 2009 07:04:19 -0700 (PDT)
From: hancock4@bbs.cpcn.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <fb020596-2fc4-447c-8918-1929e49c3888@n4g2000vba.googlegroups.com>
On May 27, 8:48 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. That is,
doesn't ANI and Caller-ID ultimately come from the same place? Where
and why do [these] "split off" to become two different things? How is it
possible that Caller ID can be "spoofed"? Why isn't this hole being
plugged?
Years ago "Blue Boxes" caused the Bell System to change the protocols
of long distance call handling so that the call details were handled
in a separate channel than the voice circuit; in this way a 'blue
boxer' couldn't interfere with the signal. That experience should've
made it clear that the telephone system had to be tightly insulated
from user abuse; and that caller-ID spoofing or outright fraud would
occur if the telephone system was vulnerable.
Much about his I simply don't understand.
I presume on ESS which everyone has today that ANI is easy to obtain
and pass along.
Indeed, giving a false number was always a crime. Why wouldn't
spoofing caller ID be a crime under that law and prosecuted as such?
(On electro-mechanical switches, ANI was harder to get. The Bell
System history describes various methods, some of which were too slow,
cumbersome, or expensive for high volume calling. Remember when DDD
came out "ONI" was widely used for many years (well into the 1970s)--
that's when an operator came on and requested the calling number. The
No. 4 ESS toll switch was equipped to handle ONI.)
------------------------------
Date: Wed, 27 May 2009 18:26:32 -0400
From: Bill Horne <bill@horneQRM.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <20090527222632.GB13680@telecom.csail.mit.edu>
(This is one of my all-time favorite subjects, so I'll "step out of
the chair" and speak for myself. [bh])
On Wed, May 27, 2009 at 07:04:19AM -0700, hancock4@bbs.cpcn.com wrote:
> On May 27, 8:48 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. That is,
> doesn't ANI and Caller-ID ultimately come from the same place? Where
> and why do [these] "split off" to become two different things? How is it
> possible that Caller ID can be "spoofed"? Why isn't this hole being
> plugged?
There's no public outcry to do so: most people are unaware that it's
possible, let alone that it might happen to _them_.
> Years ago "Blue Boxes" caused the Bell System to change the protocols
> of long distance call handling so that the call details were handled
> in a separate channel than the voice circuit; in this way a 'blue
> boxer' couldn't interfere with the signal. That experience should've
> made it clear that the telephone system had to be tightly insulated
> from user abuse; and that caller-ID spoofing or outright fraud would
> occur if the telephone system was vulnerable.
It wasn't Blue Boxes that caused the protocols to change: it was the
WATS customers. I think the Bell System was ignorant of Blue Box
hacking, because the WATS customers weren't aware that it was even
possible, and therefore paid "their" WATS bill without question.
(This is one of those "Some Beach" moments. Think about it.)
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.
> Much about his I simply don't understand.
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.
> I presume on ESS which everyone has today that ANI is easy to obtain
> and pass along.
Easy to obtain, yes. To pass along, no. The SS7 system passes ANI and
CLID info from node to node while setting up a call, but the switches
are almost always set up for "cookie cutter" service offerings, where
WATS customers are expected to buy a PRI line and more than a couple
of terminating circuits. AFAIK, there is no method available to pass
ANI info "in band", other than to convert it and send it as if it were
CLID data.
> Indeed, giving a false number was always a crime. Why wouldn't
> spoofing caller ID be a crime under that law and prosecuted as such?
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.
Bill Horne
(Filter QRM from my address for direct replies)
------------------------------
Date: Wed, 27 May 2009 20:23:53 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <XZKdnYfgofI0eoDXnZ2dnUVZ_rWdnZ2d@posted.nuvoxcommunications>
In article <fb020596-2fc4-447c-8918-1929e49c3888@n4g2000vba.googlegroups.com>,
<hancock4@bbs.cpcn.com> wrote:
>On May 27, 8:48 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. That is,
> doesn't ANI and Caller-ID ultimately come from the same place?
Nope.
> Where and why do [these] "split off" to become two different things?
No split is involved. [They are from] separate sources.
> How is it possible that Caller ID can be "spoofed"? Why isn't this
> hole being plugged?
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.
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.
[Moderator snip]
------------------------------
Date: Wed, 27 May 2009 17:50:31 -0400 (EDT)
From: Dan Lanciani <ddl@danlan.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <200905272150.RAA13661@ss10.danlan.com>
hancock4@bbs.cpcn.com wrote:
|On May 27, 8:48 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.
Years ago some companies (CLECs?) offered this as a feature to get
around blocking. I can't remember for sure but I think there were
some regulatory issues that put a stop to it for a while at least
in some states. Now with VOIP and all things seem to have opened
up again.
|That is,
|doesn't ANI and Caller-ID ultimately come from the same place? Where
|and why do [these] "split off" to become two different things?
In theory the ANI tells you who is paying for the leg of the call
that is connecting to you (or who would be paying if you weren't)
while the CLID identifies the original caller. At least that's
how it was always explained to me. In any case, the two values
can be different if, e.g., the call has been forwarded.
|How is it
|possible that Caller ID can be "spoofed"?
There are different ways to "spoof" CLID. Sending in-band data to
the display device after the call is answered is an approach that
can be prevented only by the display device itself. (None of the
ones I have will accept data except immediately after a ring so
I'm not sure how common this problem is in the first place.)
Allowing people with various trunk connections to set the CLID to
whatever they want is a matter of trust. For PBX-like end users
they could at least limit the allowed values to numbers associated
with the trunk. For other quasi-phone-company interconnects it's
likely a matter of which customer they want to please more.
|Why isn't this hole being
|plugged?
Probably because it doesn't affect telco's billing so they don't care
that much...
Dan Lanciani
ddl@danlan.*com
------------------------------
Date: Wed, 27 May 2009 20:03:12 EDT
From: Wesrock@aol.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <ccc.52cd8bdf.374f2ec0@aol.com>
In a message dated 5/27/2009 5:33:52 PM Central Daylight Time,
bill@horneQRM.net writes:
I think the Bell System was ignorant of Blue Box hacking, because the
WATS customers weren't aware that it was even possible, and therefore
paid "their" WATS bill without question.
---------------------------------Reply---------------------------------
The Bell System was well aware of Blue Boxes because of loss of
revenue. In fact, I know some telco engineers who built their own to
study their operation to better combat it. And it was one factor for
discontinuing In-Band signalling. SS-7 was the solution.
Wes Leatherock
wesrock@aol.com
wleathus@yahoo.com
***** Moderator's Note *****
I presume you're referring to the time after the Esquire article, when
WATS users started hiring auditing firms to match their internal call
records to the Bell billing statements. Prior to Esquire "outing" the
hackers, I doubt that Bell executives saw the problem as anything but
a nuisance.
Bill Horne
Temporary Moderator
------------------------------
Date: Wed, 27 May 2009 20:28:49 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs. Caller ID
Message-ID: <XZKdnYbgofJMdYDXnZ2dnUVZ_rWdnZ2d@posted.nuvoxcommunications>
hancock4@bbs.cpcn.com wrote:
|On May 27, 8:48 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.
***** Moderator's Note *****
The operating companies are _very_ reluctant to introduce _any_
non-standard feature or equipment.
Bill Horne
Temporary Moderator
------------------------------
Date: Tue, 26 May 2009 18:02:07 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI in real time (was: FTC builds case against telemarketers)
Message-ID: <UsednZQCdKdy6YHXnZ2dnUVZ_jydnZ2d@posted.nuvoxcommunications>
In article <gvgagd$gkk$1@news.albasani.net>,
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.
I've got no vendor names at this time, but it _is_ available.
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.
------------------------------
Date: Wed, 27 May 2009 06:48:40 -0500
From: Neal McLain <nmclain@annsgarden.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Wikipedia (was ANI in real time)
Message-ID: <4A1D2898.3030205@annsgarden.com>
Adam H. Kerman <ahk@chinet.com> wrote:
> 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.
Well, instead of complaining about Wikipedia, why don't you join the
effort to improve it? Click on "discussion" at the top of the page and
state your case.
Or click "edit" and make your own corrections. If you think a citation
is needed but don't know the source yourself, you can add a superscript
italic "[citation needed]" after the questionable text. Here's the
article that tells you how to do it:
http://en.wikipedia.org/wiki/Template:Fact
Neal McLain
------------------------------
Date: Wed, 27 May 2009 16:58:41 -0700
From: Steven Lichter <diespammers@ikillspammers.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: ANI vs CID {telecom}
Message-ID: <SskTl.17792$%54.11231@nlpi070.nbdc.sbc.com>
Robert Bonomi wrote:
> In article <AqXSl.23180$as4.12740@nlpi069.nbdc.sbc.com>,
> Steven Lichter <diespammers@ikillspammers.com> wrote:
>> ranck@vt.edu wrote:
>>> Adam H. Kerman <ahk@chinet.com> wrote:
>>>
>>>> Take this quote [from Wikipedia] for instance:
>>>>
>>>> Privacy
>>>>
>>>> ... 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.
>>>
>>> Uh, well they don't say instantly for residential. I have an 800
>>> number that I got when my kids were in college. It directs calls to
>>> whatever local phone number I choose. My monthly bill tells me the
>>> phone numbers that have called my 800 number. I got my 800 service
>>> from Broadwing (now Level 3), but I would assume other providers
>>> offer the same service.
>>>
>>> I suppose like anything else, enough money thrown at some phone
>>> company or another would yield real time ANI at your home. ;-)
>>
>> Years ago when I still had my BBS online; I had an 800 number for
>> network calls since I was the server for our net. I had a friend
>> build me a receiver that allowed me to see the incoming number. I
>> still have it now, but when I hooked it on my phone line it does not
>> work, I did this to be able to see blocked numbers. I have been told
>> by at&t the ANI is not passed onto the subscriber, having worked in
>> the industry since 1967 I don't understand how that could be blocked.
>
> The only remote number signalling on tail-circuit POTS lines,
> regardless of whether they are residential or business, is the
> protocol used for CLID. 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.
>
> Typical real-time ANI (which presumes a multi-line incoming set-up)
> comes over the D channel of a PRI, or a dedicated data circuit.
> Similar to, but not identical to, the way SMDR data is output by a
> switch.
I tried it on my regular phone; the first time was on my old BBS
number which is on a 5ESS. My other phone is on a DMS and when a call
came in, the box showed the area code and the exchange, not the phone
number, the CID box showed the complete number, the box was build by a
friend of mine years ago; he was an engineer for Automatic Electric.
I called my phone from the other line and got the same data, I then
called the phone from my Sprint Cell phone and all the data came to
the box as well as the CID box. I tried it blocking my CID on my cell
phone and could not get through the first time because I have no CID
numbers rejected. I turned it off and dialed my phone from the Cell
phone with CID blocked and no CID on the CID box, but my ANI receiver
worked fine. I just talked to him and he said that Sprints allows the
data to pass through their switch, where AT&T appears not to; that is
the only reason so he thought. Maybe I should have him build me
another one, but this one cost me over $800.00 for parts and that was
13 years ago.
It works ok, but not regular so I guess it might have something to do
the way SS7 is passed over the network.
--
The Only Good Spammer is a Dead one!! Have you hunted one down today?
(c) 2009 I Kill Spammers, Inc. A Rot In Hell Co.
------------------------------
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 (12 messages)
******************************
|
or 