asterisk users - Jun 2007 - Answering machine detection after Dial()

Hi people! 

Sorry for bringing up some annoying issue.. yes, it's AMD again...

But I was searching the last days for a solution for my problem and
didn't really find anything. Now I'm hoping that someone of you has
maybe an idea for me. :)


My setup:
---------
I use the Asterik Manager API to generate outgoing calls (by using
"Originate" messages).

These outgoing calls are placed to a SIP IVR-Server (dialog system
with speech recognition) and are then connected out to real-world
users via the dialplan using "Dial()" (see context below).

(The reason why the first call-leg goes to the voice-server and not to
the user is for reliability reasons. I don't want to annoy users with
calls which cannot be established, when the voice-server is down for
example.)


My problem:
-----------
Somehow I should be able to detect, if an answering machine answers on
the second outgoing call leg (caused by the Dial(), going out to the
real-life person) and I should somehow be able to inform the
voice-server about this fact.


My naive first idea:
--------------------
I thought I could use the dialplan application AMD() and if it detects
an answering machine, I could play a pre-defined text, or
DTMF-sequence, which in fact will be recognized by the voice-server
which should interrupt its "human" dialog and restart with the
"machine" dialog.

BUT: I found out that my AMD() command in the dialplan after the
Dial() never gets executed. :( As far as I understood, it's not
possible to execute further commands after the Dial(). (Maybe I'm
wrong. Please correct me, if so..).



Hmm.. And here I'm stuck. Has anybody some idea for me where I can
start looking for further solutions? Any help would be appreciated!!
:)


Thanks in advance!!!

Best regards and greetings from Austria!
johnny



P.S.:

Some detail infos:

I'm using Asterisk 1.2.9.1.

I installed app_amd from http://www.freedomphones.net/files/app_amd2.c

My dialplan context for generating the outgoing calls looks like this
(I use AEL):


context 1000_amd_tests {

  _0043[1-9]. => {
	// be verbose.. :)
	Verbose(0,InfoInfo ${CONTEXT} - ${EXTEN} called on
${CHANNEL}.);

	// set our callerId to the correct id
	Set(CALLERID(number)=xxxxxxxxxx);

	// absolute call timeout
	Set(TIMEOUT(absolute)=3600;

	// debug
	Verbose(0,DebugDebug Will execute Dial on ${CHANNEL}.);

	// now dial to reallife user, timeout 300 because, we will
abort
	// via manager API if we decide it takes too long
	Dial(Zap/r1/${EXTEN:4,0},300);

	// debug
	Verbose(0,DebugDebug we are now after Dial on ${CHANNEL}.);

	// try AMD (configured through amd.conf)
	AMD(); 

	// debug
	Verbose(0,DebugDebug AMD ${AMDSTATUS} - ${AMDCAUSE}.);

	Hangup();
  };

  T => {
	Verbose(0,WARN timeout - ${CONTEXT} ${EXTEN} on ${CHANNEL}.);
	Hangup();
  };

};



An exmplaric Originate message for generating a call looks like this:

action: Originate
actionid: 25326212_156#20070531_193654_987_0043650xxxxxxx
timeout: 15000
exten: 0043650xxxxxxx
account: 8594
async: true
callerid: 6437
context: 1000_amd_tests
priority: 1
channel: SIP/voice-application@voiceserver01

Note: "callerid" is what the voice-server sees, not the real-life
person.

Summarizing my previous problem:
I had troubles to execute dialplan commands (for example: AMD) on the
called party call-leg after issuing a Dial().

Today I played around with the Dial-flag M(), which allows to execute
macros on the called party call-leg, before the link (bridging) takes
place and I am facing a new problem:

I am executing AMD() in a macro on the called party, after the called
party answers and before the link takes place. As you may know, AMD()
needs some time (can be a few seconds) before it's finished.
Asterisk waits until the macro is finished and then links (bridges)
the two call legs together. Everything ok until here.


But when analyzing my logs and the CDR, I found out that "billsec"
contained only the time from the "Link" Event until the
"Unlink" event
(hangup) and not the time while the dial-Macro was running, altough
the outgoing call is already answered and therefore costing money
while the macro (AMD) is running!


Here my Dial command:

Dial(SIP/01xxxxxxx@my_sip_provider,300,m(silence)M(testAmdMacro));


And here the macro:

macro testAmdMacro () {
	Verbose(0,Starting macro testAmdMacro.);
	AMD();
	Verbose(0,AMD finished. result: ${AMDSTATUS});
};


Has anybody an idea if I make something wrong, or is this the intended
behaviour?


Best regards,
 john



> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-
> users-bounces@lists.digium.com] On Behalf Of Johannes Zweng
> Sent: Tuesday, June 12, 2007 8:50 PM
> To: asterisk-users@lists.digium.com
> Subject: [asterisk-users] Answering machine detection after Dial()
> 
> Hi people!
> 
> Sorry for bringing up some annoying issue.. yes, it's AMD again...
> 
> But I was searching the last days for a solution for my problem and
> didn't really find anything. Now I'm hoping that someone of you has
> maybe an idea for me. :)
> 
> 
> My setup:
> ---------
> I use the Asterik Manager API to generate outgoing calls (by using
> "Originate" messages).
> 
> These outgoing calls are placed to a SIP IVR-Server (dialog system
> with speech recognition) and are then connected out to real-world
> users via the dialplan using "Dial()" (see context below).
> 
> (The reason why the first call-leg goes to the voice-server and not
> to
> the user is for reliability reasons. I don't want to annoy users
> with
> calls which cannot be established, when the voice-server is down for
> example.)
> 
> 
> My problem:
> -----------
> Somehow I should be able to detect, if an answering machine answers
> on
> the second outgoing call leg (caused by the Dial(), going out to the
> real-life person) and I should somehow be able to inform the
> voice-server about this fact.
> 
> 
> My naive first idea:
> --------------------
> I thought I could use the dialplan application AMD() and if it
> detects
> an answering machine, I could play a pre-defined text, or
> DTMF-sequence, which in fact will be recognized by the voice-server
> which should interrupt its "human" dialog and restart with the
> "machine" dialog.
> 
> BUT: I found out that my AMD() command in the dialplan after the
> Dial() never gets executed. :( As far as I understood, it's not
> possible to execute further commands after the Dial(). (Maybe I'm
> wrong. Please correct me, if so..).
> 
> 
> 
> Hmm.. And here I'm stuck. Has anybody some idea for me where I can
> start looking for further solutions? Any help would be appreciated!!
> :)
> 
> 
> Thanks in advance!!!
> 
> Best regards and greetings from Austria!
> johnny
> 
> 
> 
> P.S.:
> 
> Some detail infos:
> 
> I'm using Asterisk 1.2.9.1.
> 
> I installed app_amd from
> http://www.freedomphones.net/files/app_amd2.c
> 
> My dialplan context for generating the outgoing calls looks like
> this
> (I use AEL):
> 
> 
> context 1000_amd_tests {
> 
>   _0043[1-9]. => {
> 	// be verbose.. :)
> 	Verbose(0,InfoInfo ${CONTEXT} - ${EXTEN} called on
> ${CHANNEL}.);
> 
> 	// set our callerId to the correct id
> 	Set(CALLERID(number)=xxxxxxxxxx);
> 
> 	// absolute call timeout
> 	Set(TIMEOUT(absolute)=3600;
> 
> 	// debug
> 	Verbose(0,DebugDebug Will execute Dial on ${CHANNEL}.);
> 
> 	// now dial to reallife user, timeout 300 because, we will
> abort
> 	// via manager API if we decide it takes too long
> 	Dial(Zap/r1/${EXTEN:4,0},300);
> 
> 	// debug
> 	Verbose(0,DebugDebug we are now after Dial on ${CHANNEL}.);
> 
> 	// try AMD (configured through amd.conf)
> 	AMD();
> 
> 	// debug
> 	Verbose(0,DebugDebug AMD ${AMDSTATUS} - ${AMDCAUSE}.);
> 
> 	Hangup();
>   };
> 
>   T => {
> 	Verbose(0,WARN timeout - ${CONTEXT} ${EXTEN} on ${CHANNEL}.);
> 	Hangup();
>   };
> 
> };
> 
> 
> 
> An exmplaric Originate message for generating a call looks like
> this:
> 
> action: Originate
> actionid: 25326212_156#20070531_193654_987_0043650xxxxxxx
> timeout: 15000
> exten: 0043650xxxxxxx
> account: 8594
> async: true
> callerid: 6437
> context: 1000_amd_tests
> priority: 1
> channel: SIP/voice-application@voiceserver01
> 
> Note: "callerid" is what the voice-server sees, not the real-life
> person.