On 12/23/2015 1:32 PM, Mark Lloyd wrote:
[snip]

It's relatively easy to detect "no message" as most folks drop the
connection
before the OGM has completed.

Most drop the connection. That's been true until recently. I've been getting a
lot (I think those CID shows as "TOLL FREE CALL") where there's just a grunt or
vague mumble.

When we sort through our messages, we sometimes encounter "dumb"
robodialers that just recite their "payload" without regard to
whether or not there is anything listening. The local public
library is like this. And, must know how stupid their approach
is as the repeat the message several times -- in English
and Spanish -- in the hope that ONE of them is caught by
whatever is "listening"

The problem with this solution was that it was too much of a "toy";
having to set aside an entire PC (tower, keyboard, display) -- big,
power hungry, noisey (fan), etc. -- for the functionality of an
"answering machine".

It doesn't take an "entire PC" if the software runs in the background, or in a
virtual machine. It could be the same PC you're using anyway.

It means a PC needs to be on 24/7. And, to not be a "superfluous
PC", needs to be the one you *want* to use for whatever else.

Nowadays, you can find small, low power machines (I have some that
run on less than 10W that I have "up" 24/7/365). That wasn't the
case decades ago.

I just rescued a pair of SFF PC's (Optiplex 745's) one of which will
replace the tower that's been our HTPC/DVD player. They were chosen
for their small size and (relatively) low power consumption. Plus
the fact that I can swap out the DVD player easily if it fails,
over time (this was a concern with the original tower -- I could
replace the half-height optical drive with another far easier than
buying a new "DVD player").

But, any PC based solution ties my hands with the approach I can
take to the problem. What happens when that PC dies? Will the
PC available 5 years hence support the same peripherals that
I'm using for that feature? The same physical busses, etc.?
And, what about the OS? If I have to code on bare iron, then
the PC is the LEAST desirable hardware platform!

So, instead, I'm pursuing a VoIP gateway sort of approach:
an appliance that has an FXO port on one side and an RJ45 on
the other. Bury all the telco interface (hardware) in the
device and just deliver network packets to my software.

This allows my software to run on anything that I choose -- as
long as there is a way to "get to a network connection".

But, it adds other complexities that a PC-as-answering_machine
doesn't have to address -- mainly latency. The gateway has
to buffer audio content before delivering it to the network.
It has to then compete with other network traffic and travel
to my "machine" (whatever it may be), percolating up through
the network stack before my software can "see" it. This
all takes time. And, can vary from one instant to the next!

In an exaggerated example, imagine your phone buffered up
entire sentences from the calling party before delivering them
to your ear. You'd *hear* everything the caller said. But,
while you are hearing them, the caller is wondering why you're
not SAYING anything -- he/she stopped speaking moments ago
and you've not yet replied (because you are only, just now!,
hearing those statements).

"No free lunch." To gain some measure of independence/isolation,
I have to assume some additional design complexities.

*UNLESS* I can get my code to run *in* the VoIP gateway!
There, it could access the incoming analog audio as it
arrives -- without having to buffer it and transfer it
over the network...