Summary:	ASTERISK-08442: billsec is 0 even when the call is answered
Reporter:	Afshin Mashayekhi (afshin)	Labels:
Date Opened:	2006-12-27 18:27:00.000-0600	Date Closed:	2007-03-30 10:22:31
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I tried to call from manager api but I'm getting the billsec=0 when I use it. I test the system with direct call by using phones and there is no problem. When a phone makes a call to another phone it just use Dial sip. I'm guessing the manager api uses dial Local (because I had this problem when I used Local for dialing another extension). It could be related to issue no. 0008221
Comments:	By: Tilghman Lesher (tilghman) 2006-12-27 18:39:48.000-0600 Billsec is not actually set until after the call is concluded.  Are you perhaps attempting to access the value while the call is still ongoing? By: Afshin Mashayekhi (afshin) 2006-12-27 18:46:33.000-0600 We are looking at the final cdr which has been produced and written in the database... By: Serge Vecher (serge-v) 2006-12-28 08:35:20.000-0600 afshin: have you tested the branch in 8221? By: Afshin Mashayekhi (afshin) 2006-12-28 15:55:11.000-0600 No. I've downloaded the final release from the website... I didn't get anything from SVN... By: Serge Vecher (serge-v) 2006-12-31 11:30:18.000-0600 ok, that was a question with a suggestion; let me rephrase: can you please download the code in branch for 8221 and test? Happy New Year! By: Afshin Mashayekhi (afshin) 2007-01-08 16:37:46.000-0600 I tried to dial Local/number1@context1 from context1 and context2 and I cheched cdrs... From context2 the billsec is 0 but from context1 the billsec is not 0 and surprisingly it is correct. I've tested this in svn 49356 and 1.4 final release. Both the same. By: Joshua C. Colp (jcolp) 2007-01-26 19:55:17.000-0600 Perhaps the optimization is kicking in causing the two parties to directly connect and dropping the Local channel out with no billsecs. If you use the /n option at the end of your tests does everything then work as you expect? By: Peng Yong (ppyy) 2007-01-27 07:02:25.000-0600 it should not be a bug. your manager api will Dail Local and then connect to a context. you can add a ResetCDR() to the context of your dial plan, all will be OK. By: Afshin Mashayekhi (afshin) 2007-01-28 01:43:56.000-0600 thnak you file.. I will test it with switch n tomorrow and I will report the result.. By: Jan Serve (jserve) 2007-02-11 15:00:14.000-0600 I can reproduce the problem on my both systems (1st 1.4.0 Release; 2nd is everytime the lastest subversion). I have test the ResetCDR(), the /n and also tested the patch file from Bug 8221. I get still the problems, anything else what could be tried or where the problem can be? By: Serge Vecher (serge-v) 2007-02-12 11:15:07.000-0600 jserver: please post the verbose/debug log of the console with /n option used. Thanks. By: Jan Serve (jserve) 2007-02-16 09:26:14.000-0600 Sorry for the answering delay. Today I have setup a clean box with the 8221branch, and it works now. So, still need the logs? By: Joshua C. Colp (jcolp) 2007-02-16 12:12:01.000-0600 Since the 8221 branch has solved the issue I'm assigning this over to murf. By: pj (pj) 2007-02-21 09:11:55.000-0600 I have following set in 'h' extension to display call stats after hangup on console, but CDR variables are still '0' in master.csv file values are stored correcty, ie. with non zero values  h => {    NoOP(callerid: ${CDR(clid)} - call dur: ${CDR(duration)} - connected: ${CDR(billsec)});  } also when looking to variables during connected call, I see, that CDR dur/billsec are always zero... output from "core show channel" ....  CDR Variables: level 1: clid="Vaclav Ovsik" <511> level 1: src=511 level 1: dst=726 level 1: dcontext=from-bill level 1: channel=IAX2/bill-gw-34 level 1: dstchannel=IAX2/wilder-gw-36 level 1: lastapp=Dial level 1: lastdata=IAX2/wilder-gw/726 level 1: start=2007-02-21 15:55:49 level 1: answer=2007-02-21 15:55:54 level 1: end=2007-02-21 15:55:54 level 1: duration=0 level 1: billsec=0 level 1: disposition=ANSWERED level 1: amaflags=DOCUMENTATION level 1: uniqueid=1172069749.152 By: Serge Vecher (serge-v) 2007-03-30 10:22:30 since jserve has reported that the branch from 8221 has fixed the issue earlier and that branch is now merged into 1.4 / trunk, I'm closing the issue. If there are additional issues here, it is probably best to open a new bug-report; unless a report for 1.4 rev over 59486 is already open, in which case just add additional info to it.