1994-11-22 - C.I.D.

Header Data

From: m5@vail.tivoli.com (Mike McNally)
To: cypherpunks@toad.com
Message Hash: 3e7f96a85c2807cbc32262e5c8740442d830fc3c8fe61c3b2827c9b98db80909
Message ID: <9411222321.AA10063@vail.tivoli.com>
Reply To: <199411222103.NAA22263@jobe.shell.portal.com>
UTC Datetime: 1994-11-22 23:22:08 UTC
Raw Date: Tue, 22 Nov 94 15:22:08 PST

Raw message

From: m5@vail.tivoli.com (Mike McNally)
Date: Tue, 22 Nov 94 15:22:08 PST
To: cypherpunks@toad.com
Subject: C.I.D.
In-Reply-To: <199411222103.NAA22263@jobe.shell.portal.com>
Message-ID: <9411222321.AA10063@vail.tivoli.com>
MIME-Version: 1.0
Content-Type: text/plain



[ I tried direct mail, but I haven't the energy to investigate why it
didn't work.  This is as relevant to the list as the drug war, at
least :-) ]


How exactly are you going to transmit the synthesized caller ID
information from the subscriber equipment up the line to the local CO
when that local CO has no expectation whatsoever of seeing the
information in the first place?  In other words, what existing
signalling facility are you going to spoof?

The caller ID information originates at the local CO, not at the
subscriber drop.  Between the time you complete dialing and the time
at which a connection is established, the local CO is not listening to
the subscriber line.  Caller ID information is delivered from the
remote CO to the called subscriber between the first and second ring
pulses.  How are you going to get your data there?

Note that I could be wrong; if you know how or why my above assertions
are wrong, I'd love to be corrected :-)

| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5@tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |






Thread