Article 30287 of comp.dcom.telecom.tech:
From: kityss@ihgp24.ih.lucent.com (Arnette P. Schultz)
Newsgroups: comp.dcom.telecom.tech
Subject: ANI versus CLID
Date: 6 Apr 1998 19:17:07 GMT
Organization: Lucent Technologies, Naperville, Il
Lines: 94
Distribution: na
Message-ID: <6gb9nj$53t@ssbunews.ih.lucent.com>
Reply-To: apschultz@lucent.com
NNTP-Posting-Host: ihgp24.ih.lucent.com
Path: news1.meer.net!nntp2.ba.best.com!news1.best.com!newshub.northeast.verio.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!news.sprintlink.net!Sprint!worldnet.att.net!nntphub.cb.lucent.com!ssbunews.ih.lucent.com!not-for-mail

Let's see who can get to this first, Al Varney or me. 

CLID versus ANI. 

First I speak from a network perspective, not just the PBX perspective.

Those that claim CLID and ANI are user-to-network only are incorrect,
especially when it comes to ANI.

Let's set the way back machine to the era of the cross bar, panel, and
SxS. ANI stands for Automatic Number Identification and replaced the
more traditional ONI (Operator Number Identification). The original
purpose of ONI was to bill "toll" calls to the originator. Back in
the early 1970s in a little town in central Illinois, any call outside
of the ~200 residences of the village of Towanda got you an operator requesting
"number please". She (always a she!) wanted the number you were calling
from for billing purposes. Along comes the whiz-bang stored program
controlled switches (ESS) and the age of ANI. No longer was a human
required, because the ANI (billing number) could now be sent in-band
over MF or DTMF trunks to the CAMA (Centralized Automatic Message
Accounting) switch that produced the "toll" billing records. That's
when the nice lady asking "number please" went away, along with 4-digit
dialing and the two minute limit on local (free) phone calls (stories
for another day).

In addition to CAMA and signaling to the operator system, AT&T
(as Ma Bell) started using ANI both on the PBX-to-network interface and the
network-to-PBX side. From the PBX it allowed the PBX to control
the billing number on a per-call basis. To the PBX was mostly
for inbound 800 type calls. Similar services were made available
to Centrex customers as well. 

Along comes SS7 in the early 1980s (well first there was CCIS6 in 
the Bell System, but I digress), and the addition of something you
call CLID. SS7 was an out of band call control protocol and one
data item transported by SS7 in the call set-up is ANI. Although the
parameter's used are the Charge Number (10 digit billing number) and
the OLI (the ANI II - "eye eye" digits that tell POTs, Coin, Hotel/Motel,
etc.). With the break up of AT&T in 1984 and the beginning of 
Carrier Interconnect (a.k.a Equal Access) signaling, both MF and
SS7 protocols were required to always carry the ANI for "long distance"
calls to an IXC.

In addition, to support the neat new "Custom Local Area Signaling
Service" (CLASS) features that Bell Labs was developing came the 
Calling Party Number (CPN) transport. However, the CPN (what you call
CLID) might be different than the ANI. The CPN was the listed
directory number, or dialable directory number of the calling party.
If the calling party was behind a Centrex or PBX, the CPN is very
likely different than the ANI (billing number). 
Since CPN was being used to "ID" the caller, even to get the caller's
name from a centralized data-base for the CLID services; the protocol
allows for it to be marked either "restricted" (blocked) or
"unrestricted". However, ANI (now known as CHG in SS7) is still not
blockable. Why? Well, "God created the world in 6 days, but he/she was
not working with an in-bedded base". (Quote from a Bell South fellow I 
know). ANI in the old MF world was not "blockable" because it was
used primarily for billing by the network. Since, MF will be with us
till the end of time (!), or almost, the SS7 protocol had to be
backwards compatible. If those people served from MF only capable
offices can not block their ANI (and let's face it, the phone company
really wants to bill those calls), then there was no "need" for CHG
to be blockable either.

So, the FCC stepped in (or stepped in it) in 1991 with their rule making
on Caller ID. In it they do address both CLID (Caller ID) and ANI
usage. They (correctly in my opinion) decided that ANI could and should
be used for billing purposes (both by the network and by 800/900
service's for "real time" ANI delivery). Caller ID (CPN) however must
be "blockable". The FCC ruled that only per-call blocking (*67) is required,
but many states allow per-line or default blocking too. 

All types of interfaces to the user support CPN delivery. Analog, ISDN BRI,
ISDN PRI, and even on many switch types MF or DTMF. So, CLID is not just
an "analog only" thing. If your phone company does not offer Caller ID
on ISDN BRI it is not "my" problem, I'll gladly sell them the software
to do it, or rather Lucent will. 

What about those 800 carriers that offer ANI via a Caller ID box? Well,
they are doing something referred to as "ANI stuffing". That is they are
taking the ANI data from the SS7 CHG parameter and placing it in the
CPN so that the Caller ID feature at the terminating end-office can
send it to the 800 user. For PBX trunk interfaces, there is no "stuffing"
required as the PBX is subscribed to "ANI delivery" for their incoming
800 number. Some 800 carriers may also deliver CPN if ANI is not
available (IXCs only are required to pass CPN not CHG according to
the IXC), and if the terminating interface is an analog line it will
show up on the Caller ID box. However, if what is being delivered is
really CPN, it can be "blocked". If what is being delivered is
ANI, according to the FCC, it can not be blocked. But the FCC pretty 
much limited ANI delivery to existing services for 800/900 numbers.

Arnette Schultz
Lucent Technologies