PSTN Authentication

On 9/14/2014 3:14 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 14:03:57 -0700, Don Y<this@isnotme.com> wrote:

One could envision other technologies used to detect occupancy,
activity, *identity*.

I worked on a proposal for a nuclear power plant that wanted to know
the location of literally everyone at all times. We didn't get the
contract, but did participate in the inevitable compromises until the
bitter end. The problem was that they wanted to know if anyone was
trapped inside a room or building in the even of a nuclear incident.

Makes sense. Note, however, that they probably are happy to just
know that there is *A* person in *A* particular room. The identity
and EXACT location would be icing on the cake (the identity could
be inferred as "one of the guys that are currently unaccounted" -- and
probably refined beyond that: Which of these guys are likely to be
*in* that room?")

[You also have to consider the mindset/motivation of the users -- in
your scenario, one would assume they WANT to be found -- unlike
Finney! :> ]

There were various systems proposed for identification (mine was an IR
transponder on an ID badge) but all were rejected as being unusable
during an emergency, especially when everyone tries to squeeze through
the doorway bottlenecks. After the usual acrimonious yelling and
screaming, it was decided to keep it simple and just track people
going in and out of the doorways. There were only 20 doorways that
needed monitoring. They gave up on individual identification and just
settled on counting people going in and out which was done with two
PIR detectors per doorway. They couldn't do activity and identity,
but occupancy was possible.

You can track presence a variety of different ways. Much depends on
how many bodies you are trying to track and how many locations.

E.g., you can track RFID tags passing by fixed RFID readers (at
"choke" points in the traffic flow). You have no idea where the
people are n the times between 'reads'. But, geography can allow
you to make good deductions (there's only one way into that room!)

OTOH, if you have relatively few bodies and many locations, you
can affix the RFID reader (effectively) to the *body* and have it
report tags that it "passes by"!

Expanding on this, you could issue everyone an RF ID badge, and track
their location. The technology for this already exists. There are
some technical problems, but the real problem is human. People forget
their ID badges. The local hospital has such a system. I can get
real numbers if you want, but my guess is that on any given day, at
least 5% of the staff has forgotten their electronic door keys, ID
badges, or both. They pickup temporary cards at the security office
and then forget to return them.

"Policy" has not incentivized them, suitably! :> "Your badge is
your timecard. Without it, The System has no way of knowing that
you worked, today!" (Draconian but you get my point)

This is the approach that I am currently pursuing. It serves two
purposes: provides location tracking for the user(s) (by noting
which device is "assigned" to each user) AND provides a means by
which The User can interact with The System -- and vice versa.

It's the equivalent of carrying your cell phone with you "everywhere
you go" (except IN the shower) but without the bulk/inconvenience/cost.

The "incentive" for doing so is you can interact with The System
without having to wander over to some "control terminal". And,
The System can better anticipate your needs (because it knows
WHO you are, your preferences, current location and its impact
on those preferences, etc.). E.g., if *I* call for "music",
it will not likely be the same sort of material that SWMBO would
want to hear!

Just knowing that an individual is in a particular room allows a lot
to be inferred (with some degree of accuracy) about his/her activities.

True, if you're consistent. I'm not. For example, I arrive anywhere
between 8AM and 1PM. lunch is anywhere between 10AM and 3PM. I leave
anywhere between 5PM and midnight.

I lead a very unstructured life. (SWMBO wonders how we ever *see* each
other! :> ) Yet, I never shower in the kitchen. Nor eat in the
bathroom. If I am in the bedroom for more than a few minutes (time it
takes to restock the printer in there), I am asleep (or trying to be).

If I am in the Living Room, I am probably watching a movie. If I am
in the back yard, I'm picking fruit or doing yard work.

Activities tend to stick to locations.

[One screw up is I cant resolve altitude. So, if I am working on the
roof -- patching, painting, servicing antennae, etc. -- The System
thinks I am inside the house (and wonders how I was able to move
from the master bath DIRECTLY into the kitchen... through several
walls!!! :< Unanticipated condition required some rework of my
coding logic.]

In a residential setting,

I'm sure the family will be thrilled with your requirement that they
carry RF ID cards and have their activities monitored.

How are you incentivizing them? Most folks that I know carry their
cell phones on their person even inside their homes (Sheesh! Can't
you WALK OVER to the counter to pick it up when it rings??)
Would you complain if you wore a wristband that gave you access
to The System (and, in return, tracked your location "for free")?

*My* preference is for a BT earpiece. It gives me voice access
to The System so I can interact with it "hands/eyes free". And,
I don't have to *build* the damn things (at least for protos).

Of course, you can make a *wrong* deduction (maybe the user is repairing
some of the plumbing and has the fan on to vent the solder/flux fumes
from the propane torch)?

I've worked on several "smart home" systems. Something like this, but
more customized:
http://www.elanhomesystems.com
One of them has a voice control feature. You say the magic words and
the computah, err... computer, responds with the desired action. The
system has some intelligence. For example, telling it to turn on the
lights when the lights are already turned on, will produce a
computerized question asking for clarification. There are sensors
scattered around the house to deal with the HVAC system which includes
an occupancy sensor system. It's not to track users so that phone
calls can be directed to the correct room. It's simply to turn off
the heat or cooling in rooms that are not being used. Batting average
for getting right is about 95%, which means that the HVAC system is
wasting expensive gas and electricity for 18 days per year. Swell.

If you have "data", then why limit it to one particular "application"?
Why shouldn't the phone be able to benefit from knowledge of the
user's location? Or, likely activities?

Knowing that the occupant(s) is(are) asleep allows you to adjust the
HVAC. But, it also lets you inhibit incoming phone calls that could
*disturb* that sleep (i.e., if you can identify the caller and
make a judgement call as to how important that interruption would
likely be regarded by the sleeping occupant). Or inhibit the doorbell
for similar reason.

Ensure the lights in the house have been turned off (one of my
most common errors: "You left the lights on in the kitchen last
night").

Etc.

Leverage *everything* that you have -- an "integrated" solution
instead of a bunch of "islands of automation" (e.g., storebought
solutions!)

Automation is fine. Predictive automation is a problem (see DARPA
autonomous vehicle trials for an example).

You have to consider the consequences of a "bad prediction"!
If someone's call goes to voicemail instead of to the callee,
there may be some "opportunity cost". Or not.

If a car assumes you will ZIG and you, instead, ZAG... :<

> Have you considered that this project might be a bit too ambitious?

Nope. I don't aim for a perfect solution. Rather, to put together
a framework that others can improve upon (or, dissect and extract
"useful bits").

My real goals lie elsewhere -- this is just a good vehicle to
explore a "significant (understatement!) application" that touches
on lots of different areas (not easily dismissed).

If not, have you considered that instrumenting the house and office in
the manner you suggest might be overkill for simply answering a
telephone? Rube Goldberg comes to mind, where the complexity of the
system is far in excess of what is required to accomplish a simple
task.

Phone is just one of many subsystems. But, rather than *simply*
tying the phone in to The System, take the opportunity to improve
upon how we interact with The Phone (and callers).

Relacing a secretary with a (tape) answering machine is a tiny
improvement. Replacing a tape answering machine with a digital
store is another tiny improvement. Ditto voice-mail (remote
access, call forwarding, etc.) None of these things fundamentally
change the way we interact with people trying to "access us"
via the PSTN!
 
On 9/14/2014 3:42 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 15:14:24 -0700, Jeff Liebermann<jeffl@cruzio.com
wrote:

I've worked on several "smart home" systems. Something like this, but
more customized:
http://www.elanhomesystems.com
One of them has a voice control feature. You say the magic words and
the computah, err... computer, responds with the desired action.

Incidentally (an intro to topic drift), you can get the same effect
using Google Voice Search. It should work if your computah, errr...
computer, has an attached microphone.
https://support.google.com/websearch/answer/3542118?hl=en
Run Google Chrome. Go to:
Settings -> Advanced Settings -> Privacy
and check the box labeled
[x] Enable "OK Google" to start Voice Search
Then, bring up Google search. You'll see a small microphone on the
right side of the search box. Just say "OK Google" followed by
whatever you want to lookup. If you have your speakers enabled,
sometimes the answer will spew from the speakers.

I like to leave open a window with Chrome running so that I can ask
stupid questions. Favorite questions are "what time is it" and
"current weather". A favorite demo is "how far to Dominican
hospital". It's also good for unit conversions. Try "convert 10 feet
to meters" or "convert 22 miles per gallon to liters per kilometer"
and the usual math problems. Also physical constants. Try
"Boltzman's constant" or "Planck's constant". More:
https://support.google.com/chrome/answer/1331723?hl=en

It's not quite ready to run your life for you, but that will probably
be a feature in the next release.

Google wants to peek inside your house. They don't want to rely on
what you *tell* them (by the content of your emails, searches you
conduct or sites you visit).

Rather, they want to see how you live your life so they can "help"
you (by pitching other products and services to you! :> )

IMO, any tie-in to an "outside service" is just an offer to sell
yourself -- often "for free"!

Notice TVs that "watch" the viewer(s) -- allegedly to allow them to
control the TV without the need for a "real remote".

[Dear advertiser: the folks in this houshold were glued to the
screen during that last commercial of yours! Perhaps you should
send them some "unsolicited" coupons for your product... you
stand a far better chance of them exercising those coupons than
the household down the street -- where everyone left the room
during your commercial!]

The same sort of things are being done with other staple appliances
(refrigerators that watch what you consume -- to *help* you prepare
a shopping list for this upcoming week... and, of course, tattle on
your consumption patterns to boost sales for particular products, etc.).

I don't think it overly paranoid to want to exercise some control
over "who sees what".
 
On 9/14/2014 2:40 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 13:28:36 -0700, Don Y<this@isnotme.com> wrote:

No. What I really want is an "electronic secretary".

It's been tried before:
http://www.rexophone.com/?p=1138

The "secretary" analogy/model is a good one, I feel. A "good"
secretary knows your habits, preferences, priorities, etc. and
can make decisions based on those.

It's much easier to have the electronic secretary run your life for
you than for it to guess what you're going to do next. For example,
the electronic secretary could prepare your schedule for you and
enforce compliance with the schedule through various unpleasant ways.
I vaguely recall a 1950's sci-fi story that revolved around that
theme.

It doesn't have to guess what you are going to do next. Rather,
know what the chances of your handling a particular situation
in a particular way are likely to be.

E.g., if your "routine" is to listen to the news in the morning
while rushing your teeth, then, chances are, if you command
the "RADIO" on in the morning while you are in the bathroom,
(i.e., no, you don't want the radio to be on in the living
room or kitchen -- because you aren't LOCATED in those places!)
it is LIKELY that you will want it tuned to the news station
(and not the Jazz station that you were listening to in bed the
night before).

If it errs, then the user is inconvenienced but not harmed.
(i.e., you now have to call for NEWS instead of just the
radio/TV)

E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")

The problem is that you're building a state machine with an unknown
number of states. You can do that successfully, but only to the point
where you go insane trying to define all possible states for all
possible input conditions. There are AI (artificial intelligence)
programs that will do that. I've scribbled one program each in Prolog
and LISP to see what they were like. More successfully, I worked on a
telephone answering contrivance, that used a state machine to
determine the outcome of all possible input conditions. The state
table was wall size. (The flow chart fit on letter size page). It's
not like you have only two possible states for your machine (i.e.
answer phone, don't answer phone). You also have a wide collection of
possible actions that can be performed for either state. What makes
this work is that with a state machine, everything happens at the same
time with storage for prior states. It can be done with a big lookup
table if necessary.

No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.

E.g., (radio,news) is more likely -- by looking at the users
historical behavior -- than (radio,music). Every further command
issued by the user tweaks those probabilities. How you weight
these changes is dictated by how quickly you want the system
to "learn" them.

[You can walk in the bathroom tomorrow and command the RADIO and
be met with NEWS or MUSIC... depending on how quickly you've
configured the system to adapt to the change in your preferences
the day before]

There are various schemes to help simplify the programming. One is to
assign a "value" to each input and a "cost" to each output. For
example, on a scale of 0-9, a call from the family would be a 9, while
an obvious telemarketer detection would be a zero. Various
acquaintances would have assigned "values" as would your location,
time of day, and what else you might be doing. Any state that exceeds
some threshold, answers the call. Below that threshold, the call is
dealt with according to a "cost". For example, dumping to voice mail
is cheap. SMS message alert to your cell phone is expensive.

The down side to such a state machine is that you can easily create
undefined states. That's where a combination of inputs has not been
defined and the state machine has no clue what to do with it. An
early ATM machine did that when someone forgot to program in the input
state of the cash drawer. The machine thought the transaction hadn't
been completed and failed to deduct the amount from the users account.
Repeating the cash withdrawal over and over until the drawer was
finally opened, was recorded as a single withdrawal.

Your electronic secretary has far too many input states to be
manageable. Off the top of my thinning head:
1. CID (caller ID)
2. Time of day
3. Local activity (meeting, lunch, busy, working, etc)
4. Your location
5. Remote activity (driving, meeting, travel, airport, bus, etc)
6. Urgency level
7. Human telemarketer detection
8. Machine telemarketer detection
9. Value of caller
10. Cost of call disposition (Voicemail, SMS, ring through, forward)
11. Occupancy detector (did you step out?)
12. Alarms and alerts (computer failure, heartbeat, autoreboot,
connectivity loss, power fail).
13. Priority bypass and over-ride.
14. Remote message playback request.
15. Local intercom.
16. Whatever else I forgot.
Now, all you need to do it put together a chart for every possible
condition and state of these inputs, to decide what to do with the
incoming phone call. Got the picture?

You don't deal with all inputs. You create simple rules ("invariants")
and let it adjust the probabilities based on observation.

E.g., I *know* SWMBO should beable to get in touch with me REGARDLESS
of everything else (in the shower, asleep, in the back yard, working
on the car, out buying groceries, etc.). Rather than letting a system
learn these things over a *lifetime* (how often will she call while
you are inthe shower?? how long will it take to learn that you want
to receive her call in that UNLIKELY situation?), "prime" the system
with known facts.

The trick, thereafter, is to be able to map your future encounters
with this (as yet unidentified) individual with the database of
previously encountered callers.

Actually, the trick is to have more than one recording of each
individual with which to compare. Unfortunately, that's not always
possible. Time for some math. Ideally, it would be someone saying
the same word or phrase through various devices (POTS, VoIP, cell
phone, Bluetooth). Each sounds sufficiently different to make
identification possible. I had the advantage of a phase that was
present in most transmissions (the FCC call sign) which also provided
a form of identification. Very roughly, my address book has about 500
names. If I store 5 seconds of a phrase, with 6 different devices,
I'll have 30 seconds of recordings to compare per caller. With 500
possible callers, that's searching 250 minutes of recordings per call.

You dont store recordings. Instead, you exract parameters from speech
samples that you have *casually* observed (by listening in to the
caller's side of the conversation EVERY TIME THE USER SPEAKS WITH HIM.

You make estimates of the various vowel frequencies, etc. Then,
tabulate these.

You notice how particular words are spoken (you have lots of time
between phone calls to analyze all this recorded speech!). E.g.,
my regional accent causes some embedded 't's to bespoken as a
glottal stop -- effectively cutting the word in half at that point.
I pronounce 'g's very hard. Others effectively *omit* that
sound in many words (esp "ing" -- as "in'")

Now, the "real time" (interactive) problem becomes one of steering
thecaller into saying words from which you can easily extract these
parameters -- and, doing so in a casual/natural manner.

I gave up trying to compare compressed audio, so that's about 2
Mbytes/minute or 500 MBytes of data that has to be searched and
compared continuously for each call. If I'm looking at a 5 second
window, then I'll be searching at:
500 MBytes * 8 bits/byte / 5 sec = 800 MHz
I other words, my brute force method is not going to happen with a
commodity PC.
 
On Sun, 14 Sep 2014 18:22:08 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 3:51 PM, Jeff Liebermann wrote:
On Sat, 13 Sep 2014 21:59:04 -0400, rickman <gnuarm@gmail.com> wrote:

I'm not sure how the unit will know you are asleep...

I had an IR motion detector wired to my computer and media player.
When I woke up in the morning, it would turn on these devices.

You keep making jumps in logic.

Just follow the bouncing ball.

An IR detector can't tell if you are
asleep or not. It can't tell if you are at the office.

I do sleep in my office, so that might be a problem. For excursions
outside, to get some air, I had a long time delay before it would turn
off the computer and medial players. I think it was about 10 minutes.
Note that I was more interested in whether I was active and in the
house than whether I was in which room. I had 3 motion sensors
upstairs and 2 downstairs. The logic was that if ANY of these showed
activity, I would be considered NOT asleep.

The basic assumption is that if NONE of the motion sensors detected
any motion, I would be considered either out of the house, asleep, or
dead. A simple pressure switch on my bed, couch, and overstuffed
chair would be sufficient to determine if I was asleep. Maybe a
microphone to detect snoring would be helpful. The lack of any senor
input would show that I was gone.

It's not pretty, 100% accurate, or perfect, but methinks good enough.

It also can't tell if you have gone to the kitchen or bathroom or
whatever. It is very hard for a computer system to tell what you are
actually doing and why you are in a given room. I know in my lifestyle
this sort of thing would be pointless.

A motion sensor in the kitchen and bathroom would take care of that.
If there's no motion in the computer room, but motion is detected in
the kitchen or bathroom, I would have added a few minutes before the
power dropped off on the computers and media players. Again, it's not
perfect logic, but I think it's good enough.

If this ultimate telemarketing call filter just happens to be a
computah, the answering machine function could be built in. A common
8GB SDHC card should be sufficient for recording messages and storing
a call record. The rest is software.

Yep if that is what you want. But that doesn't get you a cordless
phone. Mine already has the answering machine built in complete with
remote access.

Creeping featuritis? The electronic secretary has to interface with
the telephone system in some manner. Might as well have it do
everything involving the phone including the cordless phone aspect.
Even the ancient Merlin phone system that I had the pleasure of
ripping out of the adjoining office had a built in 900 MHz analog
cordless phone as an option.

>Why reinvent the wheel?

Because options tend to be more profitable. Reinvented features such
as the cordless phone option tend to be high profit margin items. The
idea is to give away the basic functions and soak the customer for the
accessories and options.

However, the soaking is not always because of greed. It's often
because handling options are expensive. It's sometimes cheaper to
just build them into the basic product and include them with every
device, than to deal with the separate handling, packaging,
documentation, inventory, etc. Worst case nightmare is with mutually
exclusive options, where you can pick this option, or that option, but
not both at the same time. I had that experience in the past and
never want to repeat it. Integrating the answering machine, call
logger, cordless phone, VoIP, Asterisk switch, T1 PRI expansion, baby
monitor, and kitchen sink, might be desirable if handling these as
separate options or as interconnect problems are deemed overly complex
or expensive. Instead of reinventing, think of it as repackaging.

In this case, building in the answering machine makes sense because
the box already has audio processing, disk storage, and CPU horsepower
sufficient to easily add an answering machine. The IVR functions of
the box closely resemble and answering machine. Most of the cost is
software, which only needs to be bought once. On the other foot, the
cordless phone is quite separate from the answering machine. Just
because most cordless phone vendors decided to conglomerate both
devices in a single box doesn't mean that such a combination is
mandatory. Because the location of the box and the cordless phone
base radio might not be the same, it makes sense to add the cordless
phone bases outside the box and connected with phone cable.

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
On 9/14/2014 3:46 PM, rickman wrote:
On 9/14/2014 6:14 PM, Don Y wrote:
On 9/14/2014 11:42 AM, rickman wrote:

You also have to allow for it to be spoken in case the caller can't
emit DTMF during the call.

I don't. I can't remember the last time I couldn't send a DTMF tone.

My parents have a *dial* telephone.

Why can't your system count dial pulses? Got to be easier than voice
recognition.

If you "dial" while a call is in progress, you stand a good chance of
dropping the call. (At least this is how things *used* to be. I can
dig out a dial phone and try it on our current service. Of course,
no guarantee that that will speak for the nation as a whole...)

You must have been in some other country. I've never been able to drop a
call by pulse dialing. In fact it used to be common for systems to
accept pulses as well as DTMF.

Well, it was obviously from *their* home! (No, they don't live in
another country!)

"Easier" implies "easier for the DEVELOPER". I prefer to makelife
easier for the *user*!

Go for it! I won't wait for your solution. I may not live that long.

I wasn't *offering* it to you! :>
 
On 9/14/2014 4:48 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 18:22:08 -0400, rickman<gnuarm@gmail.com> wrote:

On 9/14/2014 3:51 PM, Jeff Liebermann wrote:
On Sat, 13 Sep 2014 21:59:04 -0400, rickman<gnuarm@gmail.com> wrote:

I'm not sure how the unit will know you are asleep...

I had an IR motion detector wired to my computer and media player.
When I woke up in the morning, it would turn on these devices.

You keep making jumps in logic.

Just follow the bouncing ball.

An IR detector can't tell if you are
asleep or not. It can't tell if you are at the office.

I do sleep in my office, so that might be a problem. For excursions
outside, to get some air, I had a long time delay before it would turn
off the computer and medial players. I think it was about 10 minutes.
Note that I was more interested in whether I was active and in the
house than whether I was in which room. I had 3 motion sensors
upstairs and 2 downstairs. The logic was that if ANY of these showed
activity, I would be considered NOT asleep.

You can also track state instead of just relying on "current inputs".
E.g., if you are perfectly still and all the sensors are "momentarily
reset", the system has no idea where you are.

OTOH, if motion was most recently detected in the kitchen and hasn't
been noticed anywhere else, then it is probably a good bet that you
are still in the kitchen!

It also can't tell if you have gone to the kitchen or bathroom or
whatever. It is very hard for a computer system to tell what you are
actually doing and why you are in a given room. I know in my lifestyle
this sort of thing would be pointless.

A motion sensor in the kitchen and bathroom would take care of that.
If there's no motion in the computer room, but motion is detected in
the kitchen or bathroom, I would have added a few minutes before the
power dropped off on the computers and media players. Again, it's not
perfect logic, but I think it's good enough.

As I said, a neighbor has PIr's in essentially every room. You can
watch the little "activity LED" blink on each unit as you move into
different rooms.

Of course, he cant tell *who* is in each room...

If this ultimate telemarketing call filter just happens to be a
computah, the answering machine function could be built in. A common
8GB SDHC card should be sufficient for recording messages and storing
a call record. The rest is software.

Yep if that is what you want. But that doesn't get you a cordless
phone. Mine already has the answering machine built in complete with
remote access.

Creeping featuritis? The electronic secretary has to interface with
the telephone system in some manner. Might as well have it do
everything involving the phone including the cordless phone aspect.
Even the ancient Merlin phone system that I had the pleasure of
ripping out of the adjoining office had a built in 900 MHz analog
cordless phone as an option.

I'm already carrying a device that lets the system know where I am
AND gives it a way to talk/respond to me as well as for me to issue
commands to it. Why not also use that same channel to pass audio
between me and a caller? Or, "announce" callers to me ("Bob is
calling. Would you like to speak with him?") instead of trying to
get dogs to salivate...

Gee, why not let the system announce callers at the front door,
similarly? Why ring yet another bell? (especially if one of
us is sleeping)
 
On Sun, 14 Sep 2014 15:14:36 -0700, Don Y <this@isnotme.com> wrote:

>"Place" is a pretty good predictor of "activity".

True, but not when the purpose is how to deal with the telephone. A
more accurate indicator is the distance between you and the nearest
phone. Instead of trying to guess by activity whether you can take a
call or if it should go to voice mail, use the distances involved to
make the determination. For example, when you're under the car
changing the oil, and doing want your oily hands all over your phone
handset, it would a safe bet that going to voice mail would be best.
On the other foot, if you're in the adjacent room, and the phone
rings, you can just walk over and pick it up.

The trick is how to measure the distance. An RFID style transponder
in the telephone base or handset, combined with a transponder pendant
that you carry around might work, but is likely to get lost or
forgotten. Using IR motion detectors in each room might be good
enough. A security camera with face tracking might be even better.

You could also divide the house into zones, where accepting calls in
some zones are acceptable, while others are not.

In any case, none of the previously mentioned methods are going to
make a clear determination if the call should go to a handset, to
voicemail, SMS, or into a black hole. The best you can do is probably
a tolerable guess, which will need to suffice. To me, the real
decision is one of priority. Is it more important not to miss a call,
or more important not to be bothered by obnoxious telemarketers? So
far, the ideas have largely been to prevent obnoxious callers from
ringing through. That's a lofty goal, but after you miss a few
important calls, I suspect it's priority level will rapidly sink into
unimportance. If you do conjure some form of artificial intelligence
based decision processor, I suggest you err on the side of accepting
the call.

Anyone can design a system that works. Very few can design one that
will not fail because there are many more ways for things to fail than
to work properly. (Me, about 1980)



--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
On 9/14/2014 7:53 PM, Don Y wrote:
On 9/14/2014 3:46 PM, rickman wrote:
On 9/14/2014 6:14 PM, Don Y wrote:
On 9/14/2014 11:42 AM, rickman wrote:

You also have to allow for it to be spoken in case the caller can't
emit DTMF during the call.

I don't. I can't remember the last time I couldn't send a DTMF tone.

My parents have a *dial* telephone.

Why can't your system count dial pulses? Got to be easier than voice
recognition.

If you "dial" while a call is in progress, you stand a good chance of
dropping the call. (At least this is how things *used* to be. I can
dig out a dial phone and try it on our current service. Of course,
no guarantee that that will speak for the nation as a whole...)

You must have been in some other country. I've never been able to drop a
call by pulse dialing. In fact it used to be common for systems to
accept pulses as well as DTMF.

Well, it was obviously from *their* home! (No, they don't live in
another country!)

"Easier" implies "easier for the DEVELOPER". I prefer to makelife
easier for the *user*!

Go for it! I won't wait for your solution. I may not live that long.

I wasn't *offering* it to you! :

Exactly!!!

--

Rick
 
On 9/14/2014 7:48 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 18:22:08 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 3:51 PM, Jeff Liebermann wrote:
On Sat, 13 Sep 2014 21:59:04 -0400, rickman <gnuarm@gmail.com> wrote:

I'm not sure how the unit will know you are asleep...

I had an IR motion detector wired to my computer and media player.
When I woke up in the morning, it would turn on these devices.

You keep making jumps in logic.

Just follow the bouncing ball.

An IR detector can't tell if you are
asleep or not. It can't tell if you are at the office.

I do sleep in my office, so that might be a problem. For excursions
outside, to get some air, I had a long time delay before it would turn
off the computer and medial players. I think it was about 10 minutes.
Note that I was more interested in whether I was active and in the
house than whether I was in which room. I had 3 motion sensors
upstairs and 2 downstairs. The logic was that if ANY of these showed
activity, I would be considered NOT asleep.

The basic assumption is that if NONE of the motion sensors detected
any motion, I would be considered either out of the house, asleep, or
dead. A simple pressure switch on my bed, couch, and overstuffed
chair would be sufficient to determine if I was asleep. Maybe a
microphone to detect snoring would be helpful. The lack of any senor
input would show that I was gone.

It's not pretty, 100% accurate, or perfect, but methinks good enough.

Good enough for what? To let you miss calls because the ringer didn't
sound since you were obviously asleep (or reading a book or watching a
TV show... ad infinitum).

Even the motion detectors to turn off lights in offices don't work well.
They often turn off in the middle of a meeting because no one had
stood up or moved enough to not appear dead.


It also can't tell if you have gone to the kitchen or bathroom or
whatever. It is very hard for a computer system to tell what you are
actually doing and why you are in a given room. I know in my lifestyle
this sort of thing would be pointless.

A motion sensor in the kitchen and bathroom would take care of that.
If there's no motion in the computer room, but motion is detected in
the kitchen or bathroom, I would have added a few minutes before the
power dropped off on the computers and media players. Again, it's not
perfect logic, but I think it's good enough.

So it will know if I'm in the shower or did I just teleport out of the
house?

That's the problem. A system like this needs to be HIGHLY reliable or
it gets turned off. But since you aren't really building one it doesn't
matter.


If this ultimate telemarketing call filter just happens to be a
computah, the answering machine function could be built in. A common
8GB SDHC card should be sufficient for recording messages and storing
a call record. The rest is software.

Yep if that is what you want. But that doesn't get you a cordless
phone. Mine already has the answering machine built in complete with
remote access.

Creeping featuritis? The electronic secretary has to interface with
the telephone system in some manner. Might as well have it do
everything involving the phone including the cordless phone aspect.
Even the ancient Merlin phone system that I had the pleasure of
ripping out of the adjoining office had a built in 900 MHz analog
cordless phone as an option.

Ok, go ahead. I'm waiting. Let me know when you are done.


Why reinvent the wheel?

Because options tend to be more profitable. Reinvented features such
as the cordless phone option tend to be high profit margin items. The
idea is to give away the basic functions and soak the customer for the
accessories and options.

However, the soaking is not always because of greed. It's often
because handling options are expensive. It's sometimes cheaper to
just build them into the basic product and include them with every
device, than to deal with the separate handling, packaging,
documentation, inventory, etc. Worst case nightmare is with mutually
exclusive options, where you can pick this option, or that option, but
not both at the same time. I had that experience in the past and
never want to repeat it. Integrating the answering machine, call
logger, cordless phone, VoIP, Asterisk switch, T1 PRI expansion, baby
monitor, and kitchen sink, might be desirable if handling these as
separate options or as interconnect problems are deemed overly complex
or expensive. Instead of reinventing, think of it as repackaging.

In this case, building in the answering machine makes sense because
the box already has audio processing, disk storage, and CPU horsepower
sufficient to easily add an answering machine. The IVR functions of
the box closely resemble and answering machine. Most of the cost is
software, which only needs to be bought once. On the other foot, the
cordless phone is quite separate from the answering machine. Just
because most cordless phone vendors decided to conglomerate both
devices in a single box doesn't mean that such a combination is
mandatory. Because the location of the box and the cordless phone
base radio might not be the same, it makes sense to add the cordless
phone bases outside the box and connected with phone cable.

The real problem is that any system like this for the masses has to suit
a large variety of life styles. Just as I don't use the programmability
features on my thermostat most people won't use the fancy features of an
electronic secretary because they won't work very well for them.

--

Rick
 
On 9/14/2014 8:03 PM, Don Y wrote:
On 9/14/2014 4:48 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 18:22:08 -0400, rickman<gnuarm@gmail.com> wrote:

On 9/14/2014 3:51 PM, Jeff Liebermann wrote:
On Sat, 13 Sep 2014 21:59:04 -0400, rickman<gnuarm@gmail.com> wrote:

I'm not sure how the unit will know you are asleep...

I had an IR motion detector wired to my computer and media player.
When I woke up in the morning, it would turn on these devices.

You keep making jumps in logic.

Just follow the bouncing ball.

An IR detector can't tell if you are
asleep or not. It can't tell if you are at the office.

I do sleep in my office, so that might be a problem. For excursions
outside, to get some air, I had a long time delay before it would turn
off the computer and medial players. I think it was about 10 minutes.
Note that I was more interested in whether I was active and in the
house than whether I was in which room. I had 3 motion sensors
upstairs and 2 downstairs. The logic was that if ANY of these showed
activity, I would be considered NOT asleep.

You can also track state instead of just relying on "current inputs".
E.g., if you are perfectly still and all the sensors are "momentarily
reset", the system has no idea where you are.

OTOH, if motion was most recently detected in the kitchen and hasn't
been noticed anywhere else, then it is probably a good bet that you
are still in the kitchen!

Unless it is because you have left! Are you going to put sensors
outside too? Maybe it will be easier to just tell us where you *won't*
have sensors?


It also can't tell if you have gone to the kitchen or bathroom or
whatever. It is very hard for a computer system to tell what you are
actually doing and why you are in a given room. I know in my lifestyle
this sort of thing would be pointless.

A motion sensor in the kitchen and bathroom would take care of that.
If there's no motion in the computer room, but motion is detected in
the kitchen or bathroom, I would have added a few minutes before the
power dropped off on the computers and media players. Again, it's not
perfect logic, but I think it's good enough.

As I said, a neighbor has PIr's in essentially every room. You can
watch the little "activity LED" blink on each unit as you move into
different rooms.

Of course, he cant tell *who* is in each room...

Or tell where you are when you haven't tripped any detectors. A
friend's office got a motion detector for a wall switch. It couldn't
see him while sitting at his desk. lol


If this ultimate telemarketing call filter just happens to be a
computah, the answering machine function could be built in. A common
8GB SDHC card should be sufficient for recording messages and storing
a call record. The rest is software.

Yep if that is what you want. But that doesn't get you a cordless
phone. Mine already has the answering machine built in complete with
remote access.

Creeping featuritis? The electronic secretary has to interface with
the telephone system in some manner. Might as well have it do
everything involving the phone including the cordless phone aspect.
Even the ancient Merlin phone system that I had the pleasure of
ripping out of the adjoining office had a built in 900 MHz analog
cordless phone as an option.

I'm already carrying a device that lets the system know where I am
AND gives it a way to talk/respond to me as well as for me to issue
commands to it. Why not also use that same channel to pass audio
between me and a caller? Or, "announce" callers to me ("Bob is
calling. Would you like to speak with him?") instead of trying to
get dogs to salivate...

Gee, why not let the system announce callers at the front door,
similarly? Why ring yet another bell? (especially if one of
us is sleeping)

Yes, why not rip out a perfectly good door bell and wire it into a
complex electronic system so you won't be woken up on the off chance
someone comes to the door while you are napping? Or do you get lots of
people coming to your door at night as well? Of course you will need to
register this with the police so they know that they need to pound on
your door when they want to wake you up.

--

Rick
 
On 9/14/2014 5:18 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 15:14:36 -0700, Don Y<this@isnotme.com> wrote:

"Place" is a pretty good predictor of "activity".

True, but not when the purpose is how to deal with the telephone. A
more accurate indicator is the distance between you and the nearest
phone.

In my case, that distance is a constant: *0* (to a potential phone).
*If* the call should be taken, it "comes to me" instead of me going
to "pick it up".

So, the question becomes one of whether or not I should be "bothered"
with some indication of an incoming call, and how much additional
information can be provided to me to help me decide (if I *should*
decide!) whether or not to answer.

Instead of trying to guess by activity whether you can take a
call or if it should go to voice mail, use the distances involved to
make the determination. For example, when you're under the car
changing the oil, and doing want your oily hands all over your phone
handset, it would a safe bet that going to voice mail would be best.
On the other foot, if you're in the adjacent room, and the phone
rings, you can just walk over and pick it up.

If I'm under the car and my earpiece tells me there is an incoming call
(from <whomever>), I can just choose to accept the call or indicate
how I would like it handled (or, pretend I didn't get the notification
and let the system handle it n its default manner).

Likewise for a notification that "Jane" is at the front door.

Or, that I just received an email from FedEx, etc.

The trick is how to measure the distance. An RFID style transponder
in the telephone base or handset, combined with a transponder pendant
that you carry around might work, but is likely to get lost or
forgotten. Using IR motion detectors in each room might be good
enough. A security camera with face tracking might be even better.

I think people have an inherent dislike for cameras *inside* a home.
Feels somewhat creepy. That's why I opted for the BT scheme.

OTOH, a commercial establishment might *prefer* cameras as it
also gives them surveillance capabilities.

You could also divide the house into zones, where accepting calls in
some zones are acceptable, while others are not.

In any case, none of the previously mentioned methods are going to
make a clear determination if the call should go to a handset, to
voicemail, SMS, or into a black hole. The best you can do is probably
a tolerable guess, which will need to suffice.

I claim that knowledge of the caller's identity goes a LONG way to
biasing that decision.

To me, the real
decision is one of priority. Is it more important not to miss a call,
or more important not to be bothered by obnoxious telemarketers? So

Its not just telemarketers, politicians, etc. Your secretary doesn't
operate under a single, crude "drop all calls from telemarketers and
take a message from everyone else" rule.

In years past, when I had the ringer connected, a phone call in the
wee hours of the morning inevitably sent my BP soring: what the
hell has happened, *now*? Even if it was a wrong number!

I've had phone numbers in the past whose previous "owner" was delinquent
on some payment. I finally had to have TPC change my number to get
rid of the harrassment (the caller apparently refused to believe I
was not the party in arrears on their payments!).

If I can (reasonably reliably) identify a caller, I can use that
information to give access to services/capabilities to others
"cheaply". E.g., if I leave the garage door open, let a neighbor
call up and *command* it closed (though probably ever *open*!).

I.e., you deal with "PSTN Authentication as a capability and
then figure out what other things you an do with it, once you have it.

far, the ideas have largely been to prevent obnoxious callers from
ringing through. That's a lofty goal, but after you miss a few
important calls, I suspect it's priority level will rapidly sink into
unimportance. If you do conjure some form of artificial intelligence
based decision processor, I suggest you err on the side of accepting
the call.

Anyone can design a system that works. Very few can design one that
will not fail because there are many more ways for things to fail than
to work properly. (Me, about 1980)

We've found ignoring the phone works pretty well. I.e., treat it as
a call MAKING device instead of a call RECEIVING device.

Certain times the phone activity goes wacky -- e.g., political
seasons when every bozo is trying to "target" you with ads or
polling. In our case, it just looks like a bunch of "abandoned
calls".

OTOH, if you were accustomed to making and taking lots of calls,
this extra traffic would be very noticeable (and annoying)
 
On Sat, 13 Sep 2014 11:57:59 -0700 in sci.electronics.design, Don Y
<this@isnotme.com> wrote,
I'm looking for ideas on how to provide (reasonable) authentication
over the PSTN. CID is too readily spoofed (usually by the very folks
that you want to "avoid"!).

Use ANI.
 
On Sun, 14 Sep 2014 14:47:35 -0400, rickman <gnuarm@gmail.com> wrote:

Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

$1 is far too much, but a penny would do the job well I think. It would
end the robocalls I think.

Ha. It should be at least $10 initially so that LEA can get a cut. Then
it will be enforced.

?-)
 
On 9/14/2014 10:51 PM, josephkk wrote:
On Sun, 14 Sep 2014 14:47:35 -0400, rickman <gnuarm@gmail.com> wrote:


Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

$1 is far too much, but a penny would do the job well I think. It would
end the robocalls I think.


Ha. It should be at least $10 initially so that LEA can get a cut. Then
it will be enforced.

LEA?

--

Rick
 
On 9/14/2014 7:51 PM, josephkk wrote:
On Sun, 14 Sep 2014 14:47:35 -0400, rickman <gnuarm@gmail.com> wrote:


Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

$1 is far too much, but a penny would do the job well I think. It would
end the robocalls I think.

Ha. It should be at least $10 initially so that LEA can get a cut. Then
it will be enforced.

"Users" aren't going to bother dealing with a penny at a time
(what's their cut? HALF a penny?? How often do folks bend down
to pick up a penny -- CASH! -- on the sidewalk?)

At a dollar? You can bet folks will be DELIGHTED to press the
"bill-that-unsolicited-caller" button! *And* pray the caller
calls BACK!

And, as the companies are doing the collecting, they'll have an
incentive to chase down those dollars (that *they* now owe the
"recipient's service")
 
On 2014-09-14, Don Y <this@isnotme.com> wrote:
On 9/14/2014 9:25 AM, Jim Thompson wrote:
On Sun, 14 Sep 2014 09:13:15 -0700, DecadentLinuxUserNumeroUno

Here's a trick I use with my cellphone...

Verizon only allows for 5 blocked numbers, and must be "renewed" every
90 days.

TPC has no interest in "serving" their customers -- especially if
that "service" reduces their income!

An approach they would *welcome* (if they could get over the shame
of doing so) would be to allow a callee to elect to "punish" a
caller (press *23 or whatever in the first few seconds -- so YOU
can positively ID the caller regardless of CID!) and the caller is
automatically billed some small amount (e.g., $1).

Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

There was a guy in australia who got a 0900 number for his home phone.

--
umop apisdn


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
On Sun, 14 Sep 2014 21:10:41 -0700, Don Y <this@is.not.me.com> wrote:

On 9/14/2014 7:51 PM, josephkk wrote:
On Sun, 14 Sep 2014 14:47:35 -0400, rickman <gnuarm@gmail.com> wrote:


Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

$1 is far too much, but a penny would do the job well I think. It would
end the robocalls I think.

Ha. It should be at least $10 initially so that LEA can get a cut. Then
it will be enforced.

"Users" aren't going to bother dealing with a penny at a time
(what's their cut? HALF a penny?? How often do folks bend down
to pick up a penny -- CASH! -- on the sidewalk?)

At a dollar? You can bet folks will be DELIGHTED to press the
"bill-that-unsolicited-caller" button! *And* pray the caller
calls BACK!

And, as the companies are doing the collecting, they'll have an
incentive to chase down those dollars (that *they* now owe the
"recipient's service")

Until the collection starts to involve police and courts etc. Then it
gets messy again. Plan for paying for them in the first place.

?-)
 
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:

On 9/14/2014 2:40 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 13:28:36 -0700, Don Y<this@isnotme.com> wrote:

No. What I really want is an "electronic secretary".

It's been tried before:
http://www.rexophone.com/?p=1138

The "secretary" analogy/model is a good one, I feel. A "good"
secretary knows your habits, preferences, priorities, etc. and
can make decisions based on those.

It's much easier to have the electronic secretary run your life for
you than for it to guess what you're going to do next. For example,
the electronic secretary could prepare your schedule for you and
enforce compliance with the schedule through various unpleasant ways.
I vaguely recall a 1950's sci-fi story that revolved around that
theme.

It doesn't have to guess what you are going to do next. Rather,
know what the chances of your handling a particular situation
in a particular way are likely to be.

E.g., if your "routine" is to listen to the news in the morning
while rushing your teeth, then, chances are, if you command
the "RADIO" on in the morning while you are in the bathroom,
(i.e., no, you don't want the radio to be on in the living
room or kitchen -- because you aren't LOCATED in those places!)
it is LIKELY that you will want it tuned to the news station
(and not the Jazz station that you were listening to in bed the
night before).

If it errs, then the user is inconvenienced but not harmed.
(i.e., you now have to call for NEWS instead of just the
radio/TV)

E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")

The problem is that you're building a state machine with an unknown
number of states. You can do that successfully, but only to the point
where you go insane trying to define all possible states for all
possible input conditions. There are AI (artificial intelligence)
programs that will do that. I've scribbled one program each in Prolog
and LISP to see what they were like. More successfully, I worked on a
telephone answering contrivance, that used a state machine to
determine the outcome of all possible input conditions. The state
table was wall size. (The flow chart fit on letter size page). It's
not like you have only two possible states for your machine (i.e.
answer phone, don't answer phone). You also have a wide collection of
possible actions that can be performed for either state. What makes
this work is that with a state machine, everything happens at the same
time with storage for prior states. It can be done with a big lookup
table if necessary.

No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.

Ooch, such a silly thing to say that is.

More complex systems are not implemented as a single mega-state machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.

?-)

E.g., (radio,news) is more likely -- by looking at the users
historical behavior -- than (radio,music). Every further command
issued by the user tweaks those probabilities. How you weight
these changes is dictated by how quickly you want the system
to "learn" them.

[You can walk in the bathroom tomorrow and command the RADIO and
be met with NEWS or MUSIC... depending on how quickly you've
configured the system to adapt to the change in your preferences
the day before]

There are various schemes to help simplify the programming. One is to
assign a "value" to each input and a "cost" to each output. For
example, on a scale of 0-9, a call from the family would be a 9, while
an obvious telemarketer detection would be a zero. Various
acquaintances would have assigned "values" as would your location,
time of day, and what else you might be doing. Any state that exceeds
some threshold, answers the call. Below that threshold, the call is
dealt with according to a "cost". For example, dumping to voice mail
is cheap. SMS message alert to your cell phone is expensive.

The down side to such a state machine is that you can easily create
undefined states. That's where a combination of inputs has not been
defined and the state machine has no clue what to do with it. An
early ATM machine did that when someone forgot to program in the input
state of the cash drawer. The machine thought the transaction hadn't
been completed and failed to deduct the amount from the users account.
Repeating the cash withdrawal over and over until the drawer was
finally opened, was recorded as a single withdrawal.

Your electronic secretary has far too many input states to be
manageable. Off the top of my thinning head:
1. CID (caller ID)
2. Time of day
3. Local activity (meeting, lunch, busy, working, etc)
4. Your location
5. Remote activity (driving, meeting, travel, airport, bus, etc)
6. Urgency level
7. Human telemarketer detection
8. Machine telemarketer detection
9. Value of caller
10. Cost of call disposition (Voicemail, SMS, ring through, forward)
11. Occupancy detector (did you step out?)
12. Alarms and alerts (computer failure, heartbeat, autoreboot,
connectivity loss, power fail).
13. Priority bypass and over-ride.
14. Remote message playback request.
15. Local intercom.
16. Whatever else I forgot.
Now, all you need to do it put together a chart for every possible
condition and state of these inputs, to decide what to do with the
incoming phone call. Got the picture?

You don't deal with all inputs. You create simple rules ("invariants")
and let it adjust the probabilities based on observation.

E.g., I *know* SWMBO should beable to get in touch with me REGARDLESS
of everything else (in the shower, asleep, in the back yard, working
on the car, out buying groceries, etc.). Rather than letting a system
learn these things over a *lifetime* (how often will she call while
you are inthe shower?? how long will it take to learn that you want
to receive her call in that UNLIKELY situation?), "prime" the system
with known facts.

The trick, thereafter, is to be able to map your future encounters
with this (as yet unidentified) individual with the database of
previously encountered callers.

Actually, the trick is to have more than one recording of each
individual with which to compare. Unfortunately, that's not always
possible. Time for some math. Ideally, it would be someone saying
the same word or phrase through various devices (POTS, VoIP, cell
phone, Bluetooth). Each sounds sufficiently different to make
identification possible. I had the advantage of a phase that was
present in most transmissions (the FCC call sign) which also provided
a form of identification. Very roughly, my address book has about 500
names. If I store 5 seconds of a phrase, with 6 different devices,
I'll have 30 seconds of recordings to compare per caller. With 500
possible callers, that's searching 250 minutes of recordings per call.

You dont store recordings. Instead, you exract parameters from speech
samples that you have *casually* observed (by listening in to the
caller's side of the conversation EVERY TIME THE USER SPEAKS WITH HIM.

You make estimates of the various vowel frequencies, etc. Then,
tabulate these.

You notice how particular words are spoken (you have lots of time
between phone calls to analyze all this recorded speech!). E.g.,
my regional accent causes some embedded 't's to bespoken as a
glottal stop -- effectively cutting the word in half at that point.
I pronounce 'g's very hard. Others effectively *omit* that
sound in many words (esp "ing" -- as "in'")

Now, the "real time" (interactive) problem becomes one of steering
thecaller into saying words from which you can easily extract these
parameters -- and, doing so in a casual/natural manner.

I gave up trying to compare compressed audio, so that's about 2
Mbytes/minute or 500 MBytes of data that has to be searched and
compared continuously for each call. If I'm looking at a 5 second
window, then I'll be searching at:
500 MBytes * 8 bits/byte / 5 sec = 800 MHz
I other words, my brute force method is not going to happen with a
commodity PC.
 
On 9/15/2014 10:59 PM, josephkk wrote:
On Sun, 14 Sep 2014 21:10:41 -0700, Don Y <this@is.not.me.com> wrote:

On 9/14/2014 7:51 PM, josephkk wrote:
On Sun, 14 Sep 2014 14:47:35 -0400, rickman <gnuarm@gmail.com> wrote:


Craft the legislation so the caller need not pay it -- but, the
originating "service" is billed, instead (e.g., if the call comes
from a Sprint subscriber, Sprint is responsible for the payment).
Then, the service provider has an incentive to KNOW onto whom to
pass the charges; the "incoming" service provider has an incentive
(it gets a "cut" of that $1) and the "harmed" callee gets
reimbursed.

$1 is far too much, but a penny would do the job well I think. It would
end the robocalls I think.

Ha. It should be at least $10 initially so that LEA can get a cut. Then
it will be enforced.

"Users" aren't going to bother dealing with a penny at a time
(what's their cut? HALF a penny?? How often do folks bend down
to pick up a penny -- CASH! -- on the sidewalk?)

At a dollar? You can bet folks will be DELIGHTED to press the
"bill-that-unsolicited-caller" button! *And* pray the caller
calls BACK!

And, as the companies are doing the collecting, they'll have an
incentive to chase down those dollars (that *they* now owe the
"recipient's service")

Until the collection starts to involve police and courts etc. Then it
gets messy again. Plan for paying for them in the first place.

That's why you make the "provider" legally responsible.
In the (unlikely) event that a provider contests charges
*claimed* by another ("provider"), they already have
mechanisms in place to deal with this (i.e., legal
departments... "cost of doing business").

And, if some *user*/subscriber tries to avoid "paying his
bill", they've already got mechanisms for THAT as well!
(disconnect service, credit reporting, etc.)

Any "user" that is engaged in the sort of activities that
would cause him to incur large "fines" (of this sort) would
surely *not* want word to get out that he fails to pay his
bills! No other provider would offer him access to the
network --> find another line of work!
 
On 2014-09-15, David Harmon <source@netcom.com> wrote:
On Sat, 13 Sep 2014 11:57:59 -0700 in sci.electronics.design, Don Y
this@isnotme.com> wrote,
I'm looking for ideas on how to provide (reasonable) authentication
over the PSTN. CID is too readily spoofed (usually by the very folks
that you want to "avoid"!).

Use ANI.

hmm, you can get ANI by being a telco, or having a toll or toll-free
number.

--
umop apisdn


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 

Welcome to EDABoard.com

Sponsor

Back
Top