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.
> 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.
Wasn't "PBX to network" known as AIOD and was used mainly for hotels for
Really? An 800/888 carrier that receives a restricted CPN, via SS7 ISUP,
with a different number in the CHG, will proceed to *stuff* the CHG
number into an unrestricted CPN, to pass to a LEC via SS7 ISUP, to pass
to the translated number's Caller ID box for display in real-time? Would
you expect a LEC in between the Caller ID box and the 800/888 provider
to cooperate with substitution of ANI for CLID, for presentation on a
POTS/BRI line's Caller ID display? I kind of doubt the LEC will do this
because the LEC will get no compensation for such effort. When the LEC
is selling a PBX T-1 that is the destination of the translated number,
then the trunks are provisioned for ANI delivery, or a PRI T-1 can also
be provisioned for CLID delivery, but not both.
When the CPN and CHG are the same number, I think only the CPN is passed
by ISUP. Do you really expect an 800/888 carrier to unveil a restricted
CPN, which will be exposed to someone who has not paid for real-time ANI
delivery when the intended translated number is call forwarded to
Any ANI-stuffing 800/888 carrier is asking for legal trouble unless they
are directly connected to the real-time display of the translated
number. I could see a LEC's 800/888 translation service doing this, but
I would think the LEC will make sure the translated number is unable to
be call forwarded. Does Lucent make some equipment that allows the
ANI-stuffing to be undone when the translated number is call forwarded,
or does every ISDN PBX have this capability inherently?
Real-time displays of translated 800/888 calls are either always ANI, or
always CLID. I'd be interested in any recent anecdotal evidence that
contradicts this statement.
Jeffrey Rhodes at jeffrey...@attws.com
You win -- I was enjoying a delicious KC BBQ variant of "Prime Rib",
(ribs with some prime meat attached) while you typed this. :)
I'd just add that, barring Toll-Free and other non-geographic numbers,
IXCs are unlikely to deliver ANI to the terminating network. The terminating
LEC doesn't need it (they bill the IXC, not the billed party) and there is
no official way for the LEC to deliver it to a called party, over analog,
ISDN or PBX trunks. Nor is it that useful (vs. CallerID) to the called
party. Nor does it necessarily represent who the IXC is actually charging
for the call (operator system, conferencing system, 500-number service,
etc. could bill to something other than the ANI number).
Nor is there even a valid ANI number associated with every call.
Calls from multi-party lines typically send only the NPA to the IXC.
And no CallerID. For Toll-Free calls, the IXC usually doesn't care who
is making the call (however, ANI NPA might affect which destination the
Toll-Free database selects). For caller-pays calls, the IXC has to ask
the caller their number, just as in the pre-ANI days.
If CallerID is available to the IXC for Toll-Free calls, it's better to
deliver that Number to the called party (as CallerID or whatever), since it
reflects the true originator of the call, even if call forwarding occurred.
In the case of called parties that are acting as "service providers", there
may be a need to deliver a real billing number (ANI) -- but there is no
standard protocol for delivering reliable ANI to CPE. Those folks make
whatever arrangement they can with the LEC/IXC and hope it works most of
>Really? An 800/888 carrier that receives a restricted CPN, via SS7 ISUP,
>with a different number in the CHG, will proceed to *stuff* the CHG
>number into an unrestricted CPN, to pass to a LEC via SS7 ISUP, to pass
>to the translated number's Caller ID box for display in real-time? Would
>you expect a LEC in between the Caller ID box and the 800/888 provider
>to cooperate with substitution of ANI for CLID, for presentation on a
>POTS/BRI line's Caller ID display?
Any ANI stuffing that might occur is done by the IXC, using whatever
rules they might dream up. On restricted CPN, they might "stuff" CHG
into CPN without changing the restricted status or they might block the
call, or they might deliver it with a "dummy" unrestricted CPN that tells
the destination the caller has blocked CallerID. And the rules might be
different for calls terminated via the LEC vs. calls terminated directly
to a PBX. Or for calls handled by IXC-network voice-response systems.
It's also possible that CPN is dropped by the originating LEC processing
of the Toll-Free call before it is delivered to the IXC. Or the call might
travel over MF facilities (with only ANI). ANI-stuffing could thus occur
when CPN wasn't even delivered to the IXC.
>When the CPN and CHG are the same number, I think only the CPN is passed
>by ISUP. Do you really expect an 800/888 carrier to unveil a restricted
>CPN, which will be exposed to someone who has not paid for real-time ANI
>delivery when the intended translated number is call forwarded to
Customers of ANI-stuffing want ANI delivery without the cost of directly-
connected IXC trunks. The IXC could ask that any forwarding be done as
a transferred call by CPE, if they worried about "unveiling" numbers.
Or they could require delivery only to PBX trunks (no forwarding by
>Any ANI-stuffing 800/888 carrier is asking for legal trouble unless they
>are directly connected to the real-time display of the translated
>number. I could see a LEC's 800/888 translation service doing this, but
>I would think the LEC will make sure the translated number is unable to
>be call forwarded. Does Lucent make some equipment that allows the
>ANI-stuffing to be undone when the translated number is call forwarded,
>or does every ISDN PBX have this capability inherently?
Once delivered to the LEC, "stuffed" calls have no ANI/CHG and there
is no indication that stuffing has occurred. If you believe this is
a valid means of delivering real-time ANI to Toll-Free customers, then
I don't see how forwarding the call changes the validity of the CPN
information. The customer paid for "real-time ANI delivery" and has
decided to forward that information and the call elsewhere.
>Real-time displays of translated 800/888 calls are either always ANI, or
>always CLID. I'd be interested in any recent anecdotal evidence that
>contradicts this statement.
Again, what an IXC does with directly-connected PBXs is its business.
It could, on a per-call basis, deliver ANI or CLID depending on Called
Number, ANI II digits, time-of-day, originating State or a random number.
In the case where a terminating LEC delivers the call, only CPN is delivered
to the LEC by the IXC (no CHG parameter). So in that case, it's always CLID
-- as far as the LEC knows.
Al Varney - my opinion only
That's it -- Automatic Identified Outward Dialing.
Hotels were big users, but so were big companies that wanted call
details provided from the LEC AMA data. (Back when PBXs didn't generate
call detail records.)
Why your Tuesday and Wednesday postings arrive here on Friday is really
a mystery to me. I do notice the path from your newsserver at Indian
Hill to mine at Claircom goes thru internetmci.com and bbnplanet.com ;-)
One disadvantage to the questionable practise of ANI-stuffing to a
POTS/BRI CLID device is that the (POTS) answerer has no idea how the
incoming call has been dialed. A directly connected PBX can receive what
AT&T calls DNIS (I think that stands for Dialed Number Incoming
Service). Can you please tell me what Q931 information element is used
when the ANI-stuffing is provided to a directly-connected PRI at an ISDN
After thinking about this some more, I would think DNIS-stuffing might
be a more appealing service to endusers, since the ANI will show up at
the end of the month anyway and the answerer at the translated number,
which could be serving more than one 800/888 translation without the
overhead/expense of additional Directory Numbers assigned to a BRI,
would know whether or not an 800/888 number has been dialed, or whether
the translated number has been dialed directly. Does Lucent make any
equipment that can stuff the called 800/888 number into an unrestricted
CPN? Does anyone?
Jeffrey Rhodes at jeffrey...@attws.com
Further evidence of the total separation between Lucent and AT&T?
>One disadvantage to the questionable practise of ANI-stuffing to a
>POTS/BRI CLID device is that the (POTS) answerer has no idea how the
>incoming call has been dialed. A directly connected PBX can receive what
>AT&T calls DNIS (I think that stands for Dialed Number Incoming
>Service). Can you please tell me what Q931 information element is used
>when the ANI-stuffing is provided to a directly-connected PRI at an ISDN
Several responses to your questions:
1) The IXC doing the "stuffing" can also translate individual 800-numbers
to individual BRI numbers, as well as do customer-specified screening
based on II-digits.
2) Re: Q.931 mapping for ANI/DNIS -- there is no standard.
What an IXC does with directly-connected PBXs is its business.
They don't have to use standard Q.931, nor do they have to use PRI.
>After thinking about this some more, I would think DNIS-stuffing might
>be a more appealing service to endusers, since the ANI will show up at
>the end of the month anyway and the answerer at the translated number,
Depends on what business the customer is in -- if quickly referencing
customer data based on ANI is essential, then the multiple-800-number
DNIS is less important. If your business is servicing many 800-numbers
with information that is not ANI-based, then you want DNIS over ANI.
If you want both, you can't get it with a single POTS DN and CallerID.
>.... Does Lucent make any
>equipment that can stuff the called 800/888 number into an unrestricted
>CPN? Does anyone?
Any INAP/AIN-based IXC or LEC could put this together with standard