> Allow me to prface the following with: I have little experience with
> the CID as delivered to analog phone lines between ring1 and ring2.
> I do have experience with CID as delivered to ISDN lines.
> CID can be delivered by the local phone company in different formats.
> On an ISDN line, this info is transmitted as a trailer to the Q931
> call setup packet after the codeshift as an ASCII string to be routed
> to the LCD display.
> For example, South Central Bell delivers an ASCII string in the format
> "FROM 615-482-1234". A call from the exact same line delivered by
> TDS one mile away is delivered as "D: 615 482-1234". Both telcos
> are using the same ATT #5ess and the same switch software. Note that one
> telco uses the word FROM and separates the NPA and NNX with a hyphen
> while the other telco prefixes the number with "D:" (for data call)
> and separates the NPA and NNX with a space. To a human observing
> the LCD display, this minor difference can easily go un-noticed. To
> code a program to parse the different CID possibilities would be, to say
> the least, a pain. To further complicate matters, as telco's change
> their OS's, I have noticed other changes in the delivery format, i.e.
> sometimes the date and time precede the CID string. Furthermore,
> there are feature options available to allow a caller to change
> the CID information delivered to the called party.
We too only have experience with CID on ISDN, and here in europe, it
is called CLI, calling line identification. This comes as an so-called
info element, a standardized element in ISDN setup procedures.
Why do not use this?
In X.31 cases (X.25 (network access) over ISDN), this element is
used as E.164 address, and appear in X.25 networks then as NUA in
escaped X.121, so it is close to X.25 addresses in terms of
> On the other hand, the calling party billing number (CPBN) (if the
> feature is activated on the called line) info is delivered in a
> separate and distinct field within the Q931 setup packet. The
> CPBN data is a string of pure digits and if optioned properly
> by the called line's telco, only indicates the exact line that
> originated the call.
As our thing.
In firewall terms (or WAN routers), this CLI information is used
to allow incoming calls at all. Others are ignored or rejected.
It may not be enough, but to my knowledge, the CLI cannot be
influenced by the normal non-telco user.
Even internationally, we do receive this number information, from
many different countries. Try calling +49.6074/812000 to check,
Oliver Korfmacher (okorf @
com, whois OK11