Groups | Search | Server Info | Login | Register

Groups > comp.dcom.telecom.tech > #359

Re: ANI versus CLID

Show all headers | View raw

On Monday, 6 April 1998 03:00:00 UTC-4, Arnette P. Schultz  wrote:
> 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

Back to comp.dcom.telecom.tech | Previous | Next | Find similar

Thread

Re: ANI versus CLID sledders416@gmail.com - 2019-08-29 10:58 -0700

csiph-web