[asterisk-users] wrong billsec, when using dial-flag M (was:Answering machine detection after Dial())

[Johannes Zweng]

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 at 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 at lists.digium.com [mailto:asterisk-
> users-bounces at lists.digium.com] On Behalf Of Johannes Zweng
> Sent: Tuesday, June 12, 2007 8:50 PM
> To: asterisk-users at 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 at voiceserver01
> 
> Note: "callerid" is what the voice-server sees, not the real-life
> person.