[Home]

Summary:ASTERISK-05804: [patch] Answering machine detection
Reporter:klictel (klictel)Labels:
Date Opened:2005-12-08 14:26:12.000-0600Date Closed:2006-02-14 16:31:43.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) amd.conf
( 1) app_amd.c
( 2) app_amd2.c
( 3) applications.conf.sample
Description:An application that detects answering machines.

****** ADDITIONAL INFORMATION ******

app_amd.c reads the frames and detects if it is an answering machine or a human. It is based on some configurable parameters to adjust its algorithm and analyses the greeting. Upon completion is sets the channel variable AMDSTATUS.
It ships with a config file amd.conf which i couldn't attach so I include its contents here:

# initial_silence: Maximum silence duration before the greeting. If exceeded then MACHINE.
# greeting: Maximum length of a greeting. If exceeded then MACHINE.
# after_greeting_silence: Silence after detecting a greeting. If exceeded then HUMAN
# total_analysis_time: Maximum time allowed for the algorithm to decide on a HUMAN or PERSON
# min_word_length: Minimum duration of Voice to considered as a word
# between_words_silence: Minimum duration of silence after a word to considere the audio what follows as a new word
# maximum_number_of_words: Maximum number of words in the greeting. If exceeded then MACHINE

[AnsweringMachineDetector]
initial_silence            = 2500
greeting                   = 1500
after_greeting_silence     = 300
total_analysis_time        = 5000
min_word_length            = 120
between_words_silence      = 50
maximum_number_of_words    = 2
silence_threshold          = 256

Comments:By: Cameron Grant (wonton) 2005-12-12 20:25:04.000-0600

I have been testing it today - behaves nicely.
cameron
By: Clod Patry (junky) 2006-01-03 21:07:20.000-0600

Like I already discussed of this concept with drumkilla, about the possibility of putting all the configuration configs (with unique class) in applications.conf, this is maybe the start.
By: Robert La Ferla (rlaferla) 2006-01-11 19:36:23.000-0600

This looks like a useful application.  When will it be released?
By: Matt O'Gorman (mogorman) 2006-01-11 23:19:42.000-0600

i will try to get a chance to play with it at work tommorrow.
By: Clod Patry (junky) 2006-01-12 00:19:43.000-0600

rlaferla : at this time, we're more looking to see if that works fine, did you test it? Does it works fine for you?

mogorman: whatcha think about the applications.conf concept?
I can do some tests on my side too.

Klictel, does it works fine with BELL tele-reponse too?
The notice "Jan 12 02:22:29 NOTICE[10765]: app_amd.c:256 reload_conf: No Atelka config file." should be changed btw.


By: klictel (klictel) 2006-01-12 08:04:50.000-0600

I changed the error message when the config file is not found. Sorry for that. Regarding having on config file for multiple client applications, I think it is a good idea like I already told junky. It willa void having 75 diffrent ones which can make it pretty messy. I did the modification as well as expanded the verbose that show the parameters loaded.
Junky: Regarding Bell's, I never tested it aginst their voicemail specifically. We did some tests with Fidos. It would be interesting doing that and seeing how it behaves, but in all honesty, we do not have the extra time right now.
Thanks for the feedback.
By: Matthew Fredrickson (mattf) 2006-01-12 10:42:24.000-0600

Generally, this is a pretty nice app.  However, there are just a few little nit picks.  For inclusion with the code base, the coding style should basically follow the existing style (see doc/CODING-GUIDELINES for details).  Also, C++ comments are a no-no.  If you want this to be included right now, probably doing it's own config file is the right way, with the possibility of opening a discussion either on here or the asterisk-dev mailing list about adding a new applications.conf file for doing application specific configuration if this is something actually worth pursuing.
By: klictel (klictel) 2006-01-12 11:52:04.000-0600

Sounds good. I will take a look at the guidelines and make it conform. Also I will switch back to amd.conf config file.
By: Eldad Ran (eldadran) 2006-01-12 14:50:19.000-0600

I've tested it for about 1K calls, it works very nice, but I think it would be more useable if the parameters are handed on call, and not in a static conf file, diffrent countries behaves diffrently, and as I use it for diffrent countries, I can't change the conf file every time I switch the country target.
Other then that great job.
BTW: if you need more testing, i can provide daily testings for this app.


By: klictel (klictel) 2006-01-13 08:39:53.000-0600

Makes sense passing the parameters. Should we still have a config file however but when you invoke the app with parameters they overwrite the values in the config file (will be like default values)?
By: klictel (klictel) 2006-01-13 09:37:26.000-0600

I did some reformatting work on it after reading the coding duidelines. Also rolledback to amd.conf instead of applications.conf while waiting for the applications.conf approach to be adopted.
By: Matt O'Gorman (mogorman) 2006-01-13 18:21:05.000-0600

have you thought about allowing these variables to be passed to the application from the dial plan as well as the config file?
By: klictel (klictel) 2006-01-13 18:50:17.000-0600

I think passing parameters from the dialplan makes a lot of sense. It allows to have different settings for different types of answering machines you know you might be dialing. If we do such a change, is it a good idea to still have a config file, lets say for default values? I will work on the parameters as soon as I have the chance, hopefully beginning of next week.
By: Matt O'Gorman (mogorman) 2006-01-18 09:50:13.000-0600

yes i think having the config file for defaults is a great idea.
By: Matthew Fredrickson (mattf) 2006-01-24 14:38:00.000-0600

Do you have the updated version of this available so we can get this moving again?
By: klictel (klictel) 2006-01-24 15:07:00.000-0600

Hi Mattf, I don't have the update version ready yet. I'm going to be at the Internet Telephony show for the rest of the week, so you guys have to be patient with me. I won't be able to submit anything before mid-next week at least. Sorry for the delay...
By: dwildes (dwildes) 2006-02-02 17:09:09.000-0600

Not sure if this is the way the app suppose to work, but it will not work on analog lines without callprogress.  It will detect ringing as words.
The only way I've got it to work is to enable callprogress, so AMD isn't ran until  after the call is confirmed answered.
After it is answered, it works as expected.
By: Dan Hollis (bani) 2006-02-10 22:58:14.000-0600

"Also, C++ comments are a no-no."

// is C.

see ISO/IEC 9899:1999 page 66, section 6.4.9 paragraph 2.
By: boprey (boprey) 2006-02-11 13:20:47.000-0600

dwildes,

For analog trucks and robbit T1/E1s, detection of the ring back tone, busy tone, tri-tones has to be added. Different countries has their own definition of all these. It is going to complicate the code alot; especially if you have to detect tri-tones. However, this app is good enough if you are using ISDN or VoIP. I am going to test this app extensively as I was going to write one myself anyway. Two thumbs up to the author.

BTW. Kind of think of it. It is very easy to add ring-back and busy detection to the app. Tri-tone detection requires a bit of DSP code. Maybe Asterisk has DFFT implemented in one of its routines.
By: Matt Florell (mflorell) 2006-02-11 14:15:03.000-0600

I tested this code with VICIDIAL last week and it works great. Looking forward to integration into the SVN tree.

Good work klicTel and thanks for putting this out.

As for SIT tone detection(tri tone), that's a pre-Answer (before carrier sends Answer[off-hook] signal) and IMHO should not be part of the app_amd code.
By: dwildes (dwildes) 2006-02-11 15:13:36.000-0600

To add some input - I used the NVLineDetect application to help with the detection of ring, busy, answer, etc.. before calling the AMD application - working great!

So, to me - it sounds like keeping AMD separate from ring/busy/answer analog detection would be better, and keep it focused on what it does best - detecting human vs. answer machine.
By: boprey (boprey) 2006-02-11 15:16:24.000-0600

Not quite mflorell, through my experience of dealing with TelCos in the past 15 years. With robbit T1s, AT&T is the only company that guarantees TRUE Answer-Supervision. I have seen lines from Quest, Spirint, and MCI sending back the Answer-Supervision as soon as the calling equipement seizes the line. There is also the case that when the call has to go through different switch technologies before it could reach its destination. Relying on Answer-Supervision from the CO is not enough.
By: Matt Florell (mflorell) 2006-02-11 16:26:56.000-0600

I currently have 18 RBS(Robbed-bit) voice T1s and have never had a problem with any carrier sending Answer signals upon far-end call pickup. We have used AT&T, Sprint, MCI, Global Crossing, Qwest, Broadwing, GTE/Verizon and several sub-carriers over the last 8 year and have never had an issue with the Answer signal being sent properly. We are in the process of switching over to PRIs right now(for quicker dialing and custom CallerID sending per call), but we never had any issues with signalling problems on the old RBS trunks whether they were D4/AMI or B8ZS/ESF.

I used app_amd on a system with RBS T1s last week and had no problems, it worked as expected.
By: boprey (boprey) 2006-02-11 19:45:10.000-0600

You are lucky. I have seen carriers gave my customer a reverse T1 for the sake of just getting a contract signed eventhough their prefered facility doesn't have T1.

Going back to topic, what percentage of answer machines this code can sucessfullly pick up?
By: klictel (klictel) 2006-02-13 12:11:18.000-0600

I did the last(?) modifications to amd.conf. Now it should be compliant and you have the possibility of passing parameters to it. If there are no parameters, or if you pass only a subset of the parameters, then the default values for the missing one will be retreived from amd.conf.
BTW in the config file the commented out lines must start with ';' and not '#'.
Is it possible for the persons who tested it to share how they setup the test in the dialplan?
Cheers.
By: Matt Florell (mflorell) 2006-02-13 12:30:34.000-0600

For the testing I did last week with VICIDIAL I wrote a little AGI script that parsed the amd results and sent the call on to where it's supposed to go depending on the campaign settings.

VICIDIAL is a little different than other dialing-out apps in Asterisk because it uses meetme rooms. Because of that, only the calls that receive an Answer signal back will be run through the app_amd code.

It's very hard to measure the true Answering Machine detection percentage, but I think it did better than 70% with the default values in place through live calling. It could be much higher than that in actuality, but I didn't have a formal test setup when doing these tests.

Here's what we put in the extensions.conf:
; VICIDIAL_auto_dialer transfer script AMD with Load Balanced:
exten => 8369,1,AGI(call_log.agi,${EXTEN})
exten => 8369,2,AMD
exten => 8369,3,AGI(VD_amd.agi,${EXTEN})
exten => 8369,4,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,5,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,6,AGI(agi-VDAD_LB_transfer.agi,${EXTEN})
exten => 8369,7,Hangup

Where VD_amd.agi parses the AMD output and can forward it on to another extension/priority, Hangup or just exit and let the call progress through the current exten.
By: Matt O'Gorman (mogorman) 2006-02-13 16:22:01.000-0600

klicTel can you please update your source and config file.  I think it is very close to being ready to commit, just need the new version with runtim options, and some asterisk coding guideline fixes.
By: klictel (klictel) 2006-02-14 07:43:08.000-0600

I just uploaded the latest verison with runtime possibility and supposedly compliant.
Thanks to Junk-Y who made me realise that I have to click on "upload" to actually upload!!!
By: klictel (klictel) 2006-02-14 07:44:57.000-0600

And here is the config file.
By: Matt O'Gorman (mogorman) 2006-02-14 09:43:06.000-0600

Committed revision 9918. ^_^ thanks to everyone involved
By: Matt O'Gorman (mogorman) 2006-02-14 16:31:43.000-0600

slightly changed the way it works please see the show application amd so it doesnt break anything