PSTN line: how to detect answer

How can I detect when the recipient (voice call PSTN) answers?

I think the only method is to detect the ringback tone (changing country by country) and, if absent for some time, the call could be considered connected.

And with the same method I could detect when the recipient is busy when the busy tone(s) (changing country by country) is detected instead of ringback tone.

Is there an IC that makes this work for me? Maybe with DTMF decoder/encoder integrated? Is there a simple method to implement a call progress detection and DTMF decoder/encoder in a microcontroller?

The application is simple: the device open the phone line, compose the number, waits for the *real* answer of the recipient, play a voice message and waits for DTMF keys.

Reply to
pozz
Loading thread data ...

Go here:

Select your language, then search for the ICs you need.

Reply to
John S

sorry... bad link. Hope I can do better soon.

Reply to
John S

I really screwed up those last two messages. I'll try again...

They have all sorts of ICs involving telephones and other weird stuff. Good luck.

Reply to
John S

The way dalek based nuisance calls do it seems to rely on detecting a voice at the other end. I have taken to answering unrecognised numbers with dead air if I happen to pick up before the answerphone kicks in.

Most times I just let the answerphone filter them for me.

"Please type in your banking PIN now?"

--
Regards, 
Martin Brown
Reply to
Martin Brown

What you are looking for is "Call Progress Tones". In the old days, you could detect things like this by watching line polarity, battery drop, etc.

How reliable do you want this to be?

I.e., do you need to know the *instant* the line is answered (what if that happens to occur BETWEEN ring-back cadences?)? Can you count on the user to assist in the process (e.g., knowing to "press 1" as soon as he answers)?

Here (US) *most* exchanges will produce somewhat standardized ring-back tones. The frequencies of the tones (usually a mix of two tones that are not harmonically related) as well as the envelope defining their *cadence* is the primary means of differentiating them. [You can also look at signal *levels* but this is a bit less reliable -- e.g., compare the signal level of DIAL tone to that which you see as RINGBACK tone]

I do this with digital filters (in software). But, have found that it can get hosed by some of the exchanges here which use oddball signalling conventions (I suspect they are ancient throwbacks).

If you, instead, watch for signal that is clearly *not* a simple (pair of) tones -- e.g., speech -- and can further refine your confidence in this estimate by noting signal that *appears* to be ringback (freqs and cadence) then you can usually catch the actual "start of conversation" which usually immediately follows the recipient going off-hook.

[NB: a recipient can answer before you get *any* ringback signal! Make sure you handle this case as well!]
Reply to
Don Y

A more interesting approach (with NON-robot callers) is to remove the answering machine's outgoing message -- so the caller is met with a "beep". While damn near everyone knows what such a beep means, most are so conditioned to having the "grace period" of an outgoing message (to compose their thoughts, etc.) that the immediate encounter with that tone causes them to freeze.

Of course, the people that are familiar with you (i.e., call you often enough to know this behavior) aren't bothered by it (well, friends say it still "bothers" them but they have grown to expect it).

Telemarketers (human) invariably hang up and dial again. A small "win" to know that you've inconvenienced one of the bastards who is trying to inconvenience *you*! :>

(No longer effective as almost all such calls are automated, now. But, can annoy the volunteer staffers during political seasons!)

We now let the answering machine answer with it's "factory default" voice/message (thus providing no indication as to the identiti(es) of the folks here) and turn off the ringer. "Eventually", we'll see the blinking light telling us when someone has called. Then, some time later (e.g., after we've finished what we are doing) we'll listen to one or more of the messages and decide if we want to reply.

[We *really* don't like being "disturbed"]

Of course, we also tend to forget to reset the indicator. So, a day or more later, if the light is still blinking, we are likely to just "erase all messages" on the *assumption* that we've already reviewed them. Often, some NEW message has come in that we didn't yet review -- which gets lost in this process. "If it's important, they'll call back!"

I've been trying to fashion a "good" set of algorithms for screening incoming calls (a truly "automated attendant") but haven't come up with a set of criteria that I'm happy with -- yet. I.e., I don't want to have to review messages that an "attendant" should be able to discard FOR me!

Reply to
Don Y

How about requiring the caller to enter a code/"extension number" before allowing it to complete? ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    | 
| San Tan Valley, AZ 85142     Skype: skypeanalog  |             | 
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  | 
| E-mail Icon at http://www.analog-innovations.com |    1962     | 
              
I love to cook with wine.     Sometimes I even put it in the food.
Reply to
Jim Thompson

This was the first approach I considered. "Voice" allows you to get around callers who may not have DTMF capability.

But, "codes" (secrets) can be freely given to others. If calls *your* secretary, they can't just *claim* to be "your wife", "your accountant", etc. -- even if they know something (secret) that you assume is only known by that person (i.e., I suspect having the

*name* of your accountant would be enough to fool most naive secretaries; but not one that has any "history" with you -- as he/she will undoubtedly have some familiarity with that individual)

There are several different classes of callers you have to address. Folks you never want to hear from (robodialers), folks you always want to hear from (friends/family), folks you want to hear from but who don't have a vested interest in "cooperating" with (accommodating) you (e.g., your MD calling with lab results), "authorities", etc.

Even among those, you *may* want to accept a call from your public library's robocaller *if* it is informing you of an overdue item. Or, the robocaller from your MD informing you of a change to your scheduled appointment.

OTOH, you might *not* want to hear from/speak to a friend or family member from time to time. If they *know* (learn) that they have a "hotline" to you, then their encountering any "resistance" signals (to them) that your attitude towards them has changed, etc.

A "good secretary" knows who to let through, when, and for which reasons.

So, ideally, you want such an "automated attendant" to know, to varying degrees of certainty, the identity of the caller based on what that individual is likely to want from you. E.g., a neighbor calling at

3AM is probably a call you *want* to let through (as they would "know better" than to bother you at that hour unless it was REALLY important).

You need a set of policies and a set of authentication mechanisms that can be used in concert to achieve a particular level of assurance. E.g., CID can be spoofed. But, CID + secret PIN number is a bit more reassuring. CID + user-specific PIN even moreso. "Voice print" can be spoofed but an interactive voice *dialog* raises the bar considerably. "Hi, Tom. How is your wife? What was her name, again?" (i.e., the sort of banter a secretary could engage in without the caller feeling like he was being QUIZZED).

Then, depending on how sure you were of the caller's identity, you could provide services commensurate with that. "Sorry, Tom. Don's not in. But he said I should tell you to meet him at Joe's tonight around 7P".

Or, "Hi Jane. Don's asleep presently. Do you really want me to wake him?"

Reply to
Don Y

Hello,

We did this a long tme ago, it was early in 90''s i remember we've used HiQ bandpass filters, a PLL (LM567) a DTMF decoder and a CVSD Codec, all this managed with software (ringback and busy tones detection), remember also this was not 100% reliable ... but it fulfilled the customers needs ... Nowadays all these things are integrated in a SLIC IC (Silabs and CML Micro have nice chips for that). A more powerfull solution is Asterisk the FreePBX, don't know if Asterisk has been ported on a small ARM based board ...

Habib.

Reply to
Habib Bouaziz-Viallet

I see.

No, the user (recipient) wants to answer and hear a voice message. Nothing more.

It seems, in Europe the ringback is a single tone at 425Hz. The duration of the tones and pauses says the "call progress state" (ringing, recipient busy, no answer, ...)

Do you think Goertzel algorithm is enough for this kind of tone detection? Do you think it could be implemented in a small-ish microcontroller (such as Cortex-M0+ running at 10-20MHz) with an internal 10-bit ADC? Maybe with DTMF tones detection?

The user could answer and not start to speech, because he knows the caller id is an automatic caller. So he answers and waits for the vocal message.

Reply to
pozz

I don't see how you can ever expect to distinguish between a real answer and an answering machine.

Sylvia.

Reply to
Sylvia Else

Never known it make any difference, almost all clear down moments after the answerphone kicks in (I pick up if it is someone I do want to talk to). Most people groan somewhat when faced with an answerphone.

I used to hate ringing people in the US on those early automated switchboards when the UK was still largely pulse dialing - I had to carry a gizmo that made the right tones and it was a PITA to use.

You actually still get human cold callers in the States?

All ours now are random multiple dialer farms that route the call to some hapless droid at a desk when the dalek dialer hears a real human voice. Not sure how it manages to recognise an answerphone but it does.

We don't have any of that over here.

Telespam du jour is "you may have been sold dodgy bank payment protection insurance - claim now", "have you been in an accident that wasn't your fault" and "free solar panels". All have an element of truth to them but the first is being pushed by the same bunch of spivs that sold the dodgy insurance in the first place, the second is because the insurance companies have been selling on accident info to ambulance chasing lawyers and the last is misguided government policy!

--
Regards, 
Martin Brown
Reply to
Martin Brown
[attrs elided]

From looking at the "logs" of our answering machine, there are two classes of robot dialers:

- one just starts jabbering away as soon as the machine goes off-hook (perhaps allows 1.8 seconds for a HUMAN recipient to say "Hello?") they start jabbering *while* the outgoing message is playing and continue until they are finished -- or you hang up

- the second hangs up as soon as they realize its a machine

Of course, there's no way of knowing if the second group doesn't also (or even EXCLUSIVELY!) consist of human callers who know better than to interact with a machine!

Yeah, I had a little device that looked like half a 103 modem with a keypad and display on the back side. Hold it up to the mouthpiece and press buttons (for DTMF codes) *or* call up pre-stored phone numbers and use it as an automated dialer (for DTMF enabled lines). Clumsy, heavy and ate batteries.

Yes. This is particularly true during "election season". Some campaigns will use robot dialers. They can contact more people with less effort. But, probably have come to realize that this also has the effectiveness of "junk mail" -- folks just hang up when they know its a machine that is trying to make a *pitch* on behalf of a candidate.

So, it seems the more effective way is to have scores of suckers^H^H^H^H volunteers manning phones and making these cold calls. At least they can take notes as to how well their message(s) are received by callees, etc.

Yes. I think this delay is a viable cue to a machine to *drop* the call (that it has "mistakenly" answered) under suspicion that the caller is NOT a real person.

Even the laws that are SUPPOSEDLY designed to keep telemarketers from pestering you have exemptions for "political campaigns", etc. No idea how the lawmakers thought that we'd WANT to receive cold calls from

*them* but NOT from someone trying to SELL US SOMETHING! (I guess its all part of the disbelief they have that they are actually trying to sell themselves!)

I think there are "campaigns" here to convince you that you are delinquent on your taxes and *need* to contact the "IRS representative" at some phone number that clearly isn't registered to the IRS.

Or, sell you "maintenance insurance" for your automobile ("extend your factory warranty").

Or, convince you that your grandchild desperately needs money (despite the fact that you've never had *children*, let alone GRANDchildren!)

When I first started thinking about automating the screening of calls, I used to worry about how "authorities" would be able to get through my screen. I.e., a human secretary could sort out that "Sargent Jones" actually *was* with the local Police Department and make a note of his attempted contact; any box I designed couldn't know that for sure! I would have to record all "filtered calls" and then review them at some later time -- hardly an effective screen!

Then, I realized that any such contact I would probably NOT want to be via telephone anyways! (hey, if its really important, send an officer over to the house to talk with me! If you *did* telephone, I'd have to do something to reassure myself that you were, in fact, who you claimed to be. Like, "Great! What extension should I ask the Police Department Operator to connect me to when I call you back in 3 minutes? No, I don't need the phone number FROM you... I can look it up in the phone book!")

"You say I owe back taxes? Can you put that in writing so I can bring it to my accountant for *his* take on that issue??"

Reply to
Don Y

"Humans" tend to utter a simple greeting: "Hello?" whereas answering machines begin a lengthier monologue: "I'm sorry, we're unable to come to the phone...". Answering machines also tend to follow the message with a tone. (some will even continue to produce periodic tones as a legal requirement to alert the caller that the call is being recorded)

A friend used to precede his outgoing message with the special information tone (SIT) to confuse folks into thinking their call had not been completed. A bit of patience (wait for the tone and accompanying message to play out... then leave *your* message) was all it took for "folks in the know" to wrok around it.

Of course, none of these are cast in stone -- witness my "no message" answering machine approach. You could, likewise, play "random" noise and confound whatever is trying to make sense of it!

A lot also depends on whether you are looking for a "one off" solution or something that is more widely produced. The former will have a smaller user base that can (eventually) learn all there is to know about the device and their interaction with it. The latter is a much larger population with more divers expectations/reactions/etc.

Anyone can make *one* of work -- in some tightly constrained environment. Figuring out how to address a wider variety of experiences takes a bit more design work! :-/

Reply to
Don Y

OK, I'm not in Europe so can't speak to their practices... But, if it's just

*a* tone, then a simple filter tuned to that frequency with something else monitoring the modulation envelope (to determine cadence) would suffice (?)

You might be able to get by with an even simpler filter and just look for a certain amount of in-band energy (unless you also want to leverage the same code to do the DTMF detection?)

The resolution of your ADC will depend largely on how well the signal fits the dynamic range of the converter. E.g., do you have any sort of auto level control to compensate for variations in signal levels from connection to connection? Or, are you hopping to address that with some of the range inherent in the ADC itself?

Yes. My point was that you can't assume a particular set of events will happen when the call is placed and (possibly) answered. Nor can you count on their absence to be significant, either. Have you never placed a call and had it "answered" -- yet not been able to hear the other party? (yet they could hear *you* -- as you discovered when you abandoned the call and retried the call, successfully, later)

Perhaps the callee sees that it is an automatic caller and opts *not* to answer??

Reply to
Don Y

I'm not interested in distinguish the above situation. What I really need is to distinguish the time when the user answers (off-hook or press the button on a mobile phone). If the answer comes from an automatic responder, my device should start playing the message as usual.

Reply to
pozz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.