PSTN Authentication

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!

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...

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)

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

Exactly!!!

--

Rick

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.

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.

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

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

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?

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

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

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.

If I'm under the car and my earpiece tells me there is an incoming call (from ), 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.

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.

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

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.

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 wrote,

Use ANI.

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

?-)

LEA?

--

Rick

"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")

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 ---

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!

would

Then

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

?-)

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.

?-)

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 ---

It is also available from some "services" -- with caveats. But, it's yet-another-service that a user would have to acquire.

There's no *need* for a "giant state machine". You're dealing with a bunch of different "interactions" with a bunch of different aspects (subsystems, applications, etc.) of The System.

Your "Windows Media Player" has no idea of the nature or details of the last action you took in "Adobe Reader". It, in turn, has no idea of the last file you opened via the File Manager ("Windows Explorer").

Granted, they may indirectly interact -- through OS structures that they can each *elect* to inspect (e.g., if you changed the system time via one app and another could observe this as having changed). But, for the most part, they are all freestanding apps/aspects of your environment.

E.g., the fact that you were in the conference room listening to music *before* you moved into your office to do a video chat has no direct impact on either "app".

OTOH, if you are listening to music in the conference room and want the music to *follow* you into your office, then the app that pushes the music assumes the responsibility for interacting with any conflicting "audio" apps that might, by chance, happen to be active in your office currently.

As to the original question, I hashed this out with a few colleagues last night via PM. The overwhelming concensus was to truly mimic the secretary model. Your secretary doesn't require callers to identify themselves with ID numbers, DTMF tones, etc. The phone was intended for voice so rely on voice.

But, focus on speaker identification, not verification. E.g., your secretary doesn't rely on recognizing the characteristics of every caller's voice. Rather, this gives her a clue as to identity -- which she then reinforces with subsequent "exchanges" of information (worst case, "Who ARE you?"). She *doesn't* say, "Using your touchtone keypad, please type in the age of your oldest child..."! With the voice channel, the types of questions she can ask (data that can be exchanged) are far less constrained than a DTMF keypad -- and far more natural (less annoying).

This also allows other features/services to be offered and/or enhanced! I.e., can be leveraged to improve other capabilities as well!

I figure if *banks* and CC agencies are using these sorts of capabilities (I see records of some going back 20 years!), it's a technology that people (vendors and users) are comfortable with!

We'll see... having a framework in place can only

*win* from future technological advancements. OTOH, taking "the poor man's option" pretty much leaves you with that option indefinitely!

He can call it what he wants, it is still a FSM.

--

Rick

No, it isn't. If you approach it in that manner, you will fail, miserably.

If it *is*, then identify the *states*.

Rather, use a production system:

if LOCATION==CONFERENCE_ROOM and CALLER=={FRIEND|ACQUAINTANCE|REP} then DON'T_TAKE_CALL

if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3 and CALLER==SO then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED

similarly,

if LOCATION==BATHROOM then TAKE_A_MESSAGE

etc.

How much you choose to condition each rule is a matter of choice. E.g., you could just as easily have:

if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3 and CALLER==SO then if WORKING_HOURS then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED if AFTER_5 then TAKE_CALL

You have a sh*tload of rules (productions) but very little *state*! What you might *consider* as "state" is really just an input to a big combinatorial circuit.

Writing such systems "from scratch" is tedious and error prone. OTOH, having an *agent* write them based on observataions of your behavior hides much of the tedium *and* allows the rules to change without requiring the user to sit down for a rewrite!

For example: if USER==CEO and if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3 and CALLER==SO then TAKE_CALL

Agents aren't inherently "safe" from creating conflicting rule sets! OTOH, they can be coded to enforce invariants that protect against this.

For example, if, based on observations, the system sees that your response to a given set of INPUT CONDITIONS varies (perhaps because of some other condition that it can not observe, directly), it can offer you a *choice* as to how the situation is resolved (i.e., it can *require* further clarification FROM YOU).

There are spots in the house where resolving my location can be ambiguous -- "is he in the kitchen or the adjoining dining room?".

If the rules regarding how to interpret my current actions/commands in those two locations *differ*, I have to resolve the ambiguity "manually". This could be done by clarifying my position to the system ("I am in the Dining Room"); *moving* so my position is

*less* ambiguous (though it can STILL be ambiguous -- as long as the ambiguity doesn't cause my action to be interpreted in two or more different ways); or more explicitly refine the command.

But, there's still no "state" involved -- just "current inputs" examined, rules scanned, production(s) scheduled, conflict(s) resolved and, eventually, action(s) taken.

I use state *in* subsystems -- primarily to cache results and overcome inadequacies in the technologies. E.g., the location resolution system doesn't make a decision based on "inputs" tied to your current "location" but, rather, knows what it's most recent decision was and, assuming it hasn't been told otherwise, assumes that will be "near" your current location.

If your previous location was "kitchen" and your new location APPEARS to be "master bedroom", it's simply not possible for you to have made that change in location that quickly (given this floorplan). So, it holds off claiming you are in the master bedroom in the hope that new sensor data will explain this "error" -- perhaps something has interfered with the signal path, etc.

A "better" implementation that yielded correct data *solely* from current inputs wouldn't need the "filtering" that my state variable presents.