Re: the police was dispatched to ... the wrong house

[Nomen Nescio <nobody@xxxxxxxxx>]

Bass said:

>Uh, no.  It is not.  They could try actually capturing
>and ptocessing Caller ID.  They could offer daily
>tests and o/c reports like we have been discussing.
>T^hey could take the trouble to check when a test
>signal has the wrong Caller ID so that people like
>the OP don't have to pay fines due to alarm company
>stupidity.

That works, maybe, if you are monitoring a handful of alarm systems from
your garage.  But matching up account numbers and Caller ID info is a
complete non-starter for a large central station.  There are just too many
things that can go wrong.  It would be irresponsible not to dispatch
because of a Caller ID - account number mismatch.

I'd also point out that in many cases, you would be talking about ANI
rather than Caller ID, if the central station is using 800 numbers for its
receivers.  ANI data is not transmitted in the same way as Caller ID data,
further complicating the matching process.

Consider the following scenarios which could affect ANI/Caller ID info
after a system is installed:

1.  Customer decides he doesn't like Caller ID, and orders per-line
blocking, where available.

2.  Customer changes his phone number and doesn't tell the central station.
This can easily happen when businesses change phone companies:  the main
number stay the same, but the other lines get new numbers.

3.  Customer gets a PBX system that generates a preprogrammed ANI
regardless of which line actually placed the call.  Bill collectors use
this feature so they don't get called back.  Programmable ANI/Caller ID is
also a feature of some VOIP systems.

4.  The Caller ID data gets garbled during transmission.  Unlike alarm
data, it isn't sent again and again until it's acknowledged.

You want to generate service calls when you have a data mismatch or no data
on a timer test?  Who pays for that?

You can think up more scenarios for yourself.  The key question is this:

What does a central station do if it receives a signal with no ANI/Caller
ID info, or a mismatch between the account number and the info that is on
file?

Answer:  treat it as an alarm, and  dispatch on it.  They may call the
premises first, but they were going to do that anyway, even if the info had
matched.  They would be negligent if they ignored the signal due to an ANI
mismatch, because so many other things besides a phantom transmitter could
cause that.

At best, it's a maintenance issue, but the signal is going to be handled as
an alarm anyway, ANI doesn't really do any good in terms of false alarm
reduction.

Incidentally, there is one other possible explanation for this phantom
signal that I don't believe anyone has mentioned.   Many receiver line
cards transmit multiple handshakes, and receive signals in several
different formats, including old pulse formats.  Old pulse format dialers
used to transmit bogus signals on occasion, or perhaps I should say the
receivers would misinterpret that string of beeps.  So, even if account 246
is programmed as a Contact ID account, a different transmitter sending
pulse format could send in a signal on that same account number by mistake.
A close analysis of the signals received near the time of the one in
question might shed some light on this, but it's too late now.

- badenov