Craig,
You wrote:
> Sounds like he's getting a comission from ISDN sales.
No, I am not in any way affiliated with the phone companies.
> While it is possible to spoof any scheme, CID is actually pretty good.
> If you don't build the decoder properly (i.e., get lazy), it may not
> work, but that doesn't count.
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.
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.
> Let's see, these bits are tagged in some fashion that, after this
> "special device" pulls them out, they cannot be sent to an LCD? Those
> are some weird bits.
It's not a matter of tagging, its a matter of what the CPE is (usually
firmware) coded to display. I am not aware of any CPE sets that allow
the user to reconfigure the LCD feature to switch from the DISPLAY
bits that come down the line to the CPBN bits.
> If the phone company guys are this clueless, why do you believe them
> at all.
While I might tend not to argue with you that most of the telco folks
the public is forced to interact with ARE clueless, the switch engineers
that code the OS's that I have had the opportunity to work with,
do have a pretty good "clue" as to what's going on.
> I wouldn't believe this guy unless he outlines a specific method.
If your comment "this guy" refers to me, I really don't care what you
believe. I believe what I have personaly observed from the displays
of packet analyzers I have connected to the lines and the successful
coding I have done to interact with the Q931 packets.
Robert
Follow-Ups:
|
|
