[asterisk-bugs] [Asterisk 0017899]: [patch] Fake answer start in app_dial

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17899 
====================================================================== 
Reported By:                under
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17899
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-22 16:57 CDT
Last Modified:              2010-08-23 09:23 CDT
====================================================================== 
Summary:                    [patch] Fake answer start in app_dial
Description: 
When using H (hangup by "*") or d (exit on DTMF) while invoking Dial(),
this makes app_dial answering incoming channel immediately, not waiting
until outbount channel answers.

I guess this was done to be able to cancel call by hitting "*" not waiting
until it's answered.

But this stuff completely breaks logic for those who perform billing of
the subscribers with Asterisk, because in this case subscribers get CDR
with call duration that is longer that actual (and actually they are
charged money for the calls that were not connected)
====================================================================== 

---------------------------------------------------------------------- 
 (0126228) davidw (reporter) - 2010-08-23 09:23
 https://issues.asterisk.org/view.php?id=17899#c126228 
---------------------------------------------------------------------- 
Unless you are trying to undermine your own case, you need to be a little
clearer as to what you mean.  In your scenario, the answer has to happen
between steps 1 and 2, so there is no question of doing an answer at step
6, as it has already been done.

There may be an issue with the generation of CDRs with an ANSWERED
disposition (after clearing the answered status from the previous stage
with ResetCDR or ForkCDR), but, if so, that is the real problem and needs
addressing as such.

If you cannot decouple answering party A from setting the CDR to answered,
then you have a feature change, and as I suggested, you need to issue a
warning if someone tries to use those options without the call being
answered.

If this is the real problem, could one not check to see if the incoming
side is up, and suppress the answer and associated CDR event.

On the other hand, this might come under the category of difficult CDR
cases, for which the right answer is to use Channel Event Logging. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-23 09:23 davidw         Note Added: 0126228                          
======================================================================