Summary:	ASTERISK-16604: [patch] Fake answer start in app_dial
Reporter:	under (under)	Labels:
Date Opened:	2010-08-22 16:57:45	Date Closed:	2011-06-07 14:05:28
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 0017899.diff
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)
Comments:	By: under (under) 2010-08-22 16:58:29 this stuff was absent in 1.4 and appeared in 1.6.0 By: under (under) 2010-08-22 17:01:38 patch attached. It doesn't make sense to have such behavior. Those who want it, can invoke Answer() before Dial() By: David Woolley (davidw) 2010-08-23 08:59:56 As long as the call is only answered when Asterisk needs to see inbound digits, I see no problem with what you describe to be the current behaviour.  If you don't want the billing to start, don't use features that only work after the call has been answered. At best, this is a feature request. I think the real problem here is the Asterisk code is, in general, rather short of comments explaining why things are being done. By: David Woolley (davidw) 2010-08-23 09:05:09 If people were to agree with your rationale, then rather than the patch completely deleting code, it should issue a warning that the features were ineffective because the call was not answered. By: under (under) 2010-08-23 09:11:31 most of the Calling Cards applications (like a2billing) propose the service of this kind: 1) subscriber calls to pre-defined DID number 2) IVR (based on asterisk) prompts to enter PIN 3) subscriber enters PIN 4) IVR authenticates subscriber and prompts to enter destination number 5) subscriber enters destination number 6) Asterisk places outgoing call and bridges channels together. 7) subscriber hits * to hangup call when he finished a conversation and returns to IVR prompt i4 (without redialing DID number, entering PIN and paying for connection!) and can dial new destination number. With the subj. issue i.7 will be broken, because application cannot use H option anymore to preserve correct billing! By: David Woolley (davidw) 2010-08-23 09:23:03 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. By: under (under) 2010-08-23 09:30:01 davidw, I guess you understood the main point. In my case, when subscriber is authenticated, a new CDR is allocated and attached to the current, answered, one. Then, when outbound channel answers, ast_answer is called and this new CDR gets correct answer time (and this "answer time" goes to billing for the subscriber). But when Dial() is called with "H", answer time is set immediately for this new forked CDR and this breaks billing. By: Russell Bryant (russell) 2010-08-24 13:18:56 Answering the channel when those options are used is the expected and intended behavior.