Summary:	ASTERISK-12500: [patch] Incorrect ANSWERTIME when using M option
Reporter:	Ruddy G (ruddy)	Labels:
Date Opened:	2008-07-31 19:10:52	Date Closed:	2008-10-28 11:54:08
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20081014__bug13216.diff.txt
Description:	Here is the situation we have. When somebody call extension 1000, we start AGI 'agicaller.php' that will try to call 10 people one after another. For each person, if the other party answer the channel, with option M(agicallee.php), we check if the other person accept the call and if yes, we connect both parties. If not, we try the next person and so on. Now, after looking at app_dial.c, I realize that, ANSWEREDTIME is not set to 0 when we enter dial application and is setup only when after the BRIDGE. So, if somebody reject the call and the agicallee.php macro setup MACRO_RESULT to CONGESTION, the DIALSTATUS is set to ANSWERED but ANSWEREDTIME is not reset and have the same value as the last Dial that was made by that call. I think : 1. Everytime, we enter dial_exec_full, we should reset ANSWEREDTIME to 0 2. Setup ANSWEREDTIME for every situation where the call was answered, not only when it was bridge.   Because the agicallee.php can take 5 minutes to execute and set MACRO_RESULT to CONGESTION after all. I hope I was enough clear in my explanations. Thanks.
Comments:	By: Leif Madsen (lmadsen) 2008-10-14 12:11:26 Hrmmm... I'm not entirely sure Asterisk is doing something wrong here. It does seem to make sense that ANSWEREDTIME is the value past the channels being bridged, because that is technically when they are answered. However following through your explaination I'm slightly confused as to whether you're saying the value isn't started until the call is actually bridged, or whether you're getting a value that is the total time from the initial call being loaded? I've assigned this issue to Corydon76 as maybe he has a better idea as to what is going on here, and to determine whether Asterisk is doing the right thing. By: Tilghman Lesher (tilghman) 2008-10-14 14:50:29 I am also confused and require blitzrage's questions to be answered before I can proceed. By: Ruddy G (ruddy) 2008-10-14 15:24:57 Here is the issue. On the app_dial.c source code, to setup the channel variable ANSWEREDTIME, we do the difference between endtime and answer_time. Also ANSWEREDTIME is setup only and only after the call were actually bridge (ie after ast_bridge_call). I will give you two situations so you can understand what the issues are. Situation 1 : If I have an agi script where the user is asked to enter the number he wish to dial, then we dial that number, bridge the call A and after the conversation we record the ANSWEREDTIME in the database. Then the user is asked to enter another number. If this second call fails, the ANSWEREDTIME on the user channel is still stuck to the call A answered time. So, we have BUSY as DIALRESULT and ANSWEREDTIME != 0. So, what I suggest is to reset ANSWEREDTIME to 0 or empty string everytime we enter the Dial cmd. So, ANSWEREDTIME is really the last call ANSWEREDTIME. Situation 2 : For situation 1, we can have a walk around by checking the DIALSTATUS. So, if the DIALSTATUS != ANSWER, then we just ignore the ANSWEREDTIME. But this workaround becomes ineffective if we use the M option in the dial. This M option will be use to execute an AGI script to the callee so he can accept or reject the call. That can take up to 2 minutes to the callee to do so. First, in this case, we don't have any variable to get the CONVERSATIONTIME which is the ANSWEREDTIME minus the time the callee takes to accept the call. Second, if the user dial CALL A who was accepted, we have DIALRESULT=ANSWER and ANSWEREDTIME=40minutes, then if the user dial CALL B who is rejected, we have the exact same variables at the output ie DIALRESULT=ANSWER (because the call was answered but rejected by the callee) and ANSWEREDTIME=40minutes (because it was not reset between dials). Suggestion : What I suggest is - add a variable CONVERSATIONTIME or BILLABLETIME that will be different from ANSWEREDTIME, specially when we use the M option - everytime we enter the Dial command, reset ANSWEREDTIME to 0 or empty string. I hope this is much clear. By: Tilghman Lesher (tilghman) 2008-10-20 11:44:51 ruddy:  some testing is needed, here, please.  Does this patch solve your issue? By: Ruddy G (ruddy) 2008-10-27 09:54:44 yes it does. Thank you. However, I think we should add a channel variable that gives the conversation time which can be different from the answeredtime, specially if we use the M option and the callee macro takes some time to process. By: Digium Subversion (svnbot) 2008-10-28 11:54:05 Repository: asterisk Revision: 152368 U   branches/1.4/apps/app_dial.c ------------------------------------------------------------------------ r152368 | tilghman | 2008-10-28 11:54:04 -0500 (Tue, 28 Oct 2008) | 8 lines Reset all DIAL variables back to blank, in case Dial is called multiple times per call (which could otherwise lead to inconsistent status reports). (closes issue ASTERISK-12500) Reported by: ruddy Patches:       20081014__bug13216.diff.txt uploaded by Corydon76 (license 14) Tested by: ruddy ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=152368