Summary:	ASTERISK-14884: [patch] Not recording the duration of transfers.
Reporter:	Fernando Lujan (flujan)	Labels:
Date Opened:	2009-09-24 16:53:36	Date Closed:	2010-07-06 16:43:01
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_cdr
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 15960-1.txt ( 1) app_dial.c.patch
Description:	CDR is not recording the proper duration of calls. A calls B (PSTN). A Attended transfer to C. CDR will not record the duration of the call of B with C. So if the duration: A calls B = 15 A transferes to C = ???? It is not possible to bill theses calls
Comments:	By: David Woolley (davidw) 2009-09-28 06:40:02 flujan: Could you check that this is not a duplicate of ASTERISK-11309.  Either way, I suspect the resolution will be the same. By: Leif Madsen (lmadsen) 2009-09-28 09:00:00 I'm assigning this to mnicholson to make a comment on, although I suspect davidw is correct in that this is expected behaviour with the current CDR implementations. You may wish to look into using CEL (Channel Event Logging) which may give you more fine grained control of scenarios such as this one. This has been assigned to mnicholson to close, or at least confirm that closing this issue is correct. He may contact me on IRC to close this if this is the case. Thanks! By: Matthew Nicholson (mnicholson) 2009-10-01 08:37:48 What is the duration of the CDR record for the call between B and C? By: Fernando Lujan (flujan) 2009-10-01 14:02:56 Hello, can I enable CEL on version 1.6.2 or 1.4 branch? mnicholson The duration is A -> B pstn. Asterisk do not sum the transfer duration into the CDR record. Thanks in advance for the help guys. By: Matthew Nicholson (mnicholson) 2009-10-01 14:08:45 CEL will be in version 1.6.3.  It is not in any previous branches. What do your CDR records look like? I would like to know what you are seeing in your CDR records during transfers.  How many CDR records are generated and what are the values for billsec and duration? By: Fernando Lujan (flujan) 2009-10-01 14:38:53 Here goes what asterisk is recording on the CDR. It is recording twice the same call, not the transfer. This call, have a duration of 360 seconds. It just record 145,134. The second record is increased by 1 second. By: Matthew Nicholson (mnicholson) 2009-10-01 14:49:35 I will try and reproduce this here to see if this is a duplicate of ASTERISK-11309. By: Martin Vit (festr) 2009-10-06 10:06:52 Hi. We have similiar problem with asterisk 1.4 rev 222026. The problem is when doing attendand transfer or if SIP phone is redirecting with 30X "moved temporarily". The problem is that the second CDR has billsec = 0. Two CDR are generated. In case of 30X SIP redirect (A calls B which redirects to C), first CDR generates ASAP transfered call is answered and src = A, dst = C, duration = 11, billsec = 0. Second CDR is generated with src = A, dst = B, duration = 94, billsec = 83 By: Martin Vit (festr) 2009-10-07 06:59:08 I've workaround it in app_dial.c. I've added "/n" parametr for Local/x@y/n so the channel will not hangup and two cdr are generated. By: Steve Poirier (mousepad99) 2010-03-29 14:59:12 What is happening with this bug? We lost approximately 10,000 USD last week-end with this exploit :( Ready to pay a few hundred bucks to get a fix to the 1.4 branch Exploit: Call Expensive destination, Blind Xfer to Cheap Destinaton On top of the timer stopping on first leg, the second leg has the time of the first leg added to its duration. By: Leif Madsen (lmadsen) 2010-03-31 10:39:10 Unassigning from mnicholson as he has been pulled away to work on other projects. Setting this to Acknowledge for now. By: Tomas Urbanek (turby) 2010-06-18 07:25:19 I added patch (asterisk 1.4) added "/n" to Local channel. By: David Woolley (davidw) 2010-06-18 07:40:21 If the result is that it is no longer possible to re-invite out the RTP, I would say that adding /n is not an acceptable solution. By: Leif Madsen (lmadsen) 2010-07-06 16:43:00 I'm closing this issue for the same reason ASTERISK-11309 was closed -- the answer here is to use CEL (which will be available in Asterisk 1.8). CDRs are not really designed to be doing what you're trying to do with them, and in the past when these types of issues get resolved, it just creates havoc with other areas in CDRs. In order to avoid regressions, and because the real solution is to use CEL, I'm closing this issue as "Won't Fix".