Summary:	ASTERISK-10248: CDRs are not merged for not answered calls
Reporter:	Andrey S Pankov (casper)	Labels:
Date Opened:	2007-09-06 10:02:18	Date Closed:	2007-11-28 14:44:48.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	CDR/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	After upgrade from 1.2 to 1.4 I noticed that bogus CDRs were generated for timed out or cancelled calls with context "default" and extention "s". ****** ADDITIONAL INFORMATION ****** Here is an example: "","transatlant2","s","default","transatlant2","SIP/protech-09bd3938","","","","2007-09-06 17:47:07",,"2007-09-06 17:47:37",30,0,"NO ANSWER","DOCUMENTATION" "","transatlant2","101","transatlant","""transatlant2""<transatlant2>","SIP/transatlant2-09bc58f8","SIP/protech-09bd3938","Dial","SIP/protech/101|30","2007-09-06 17:47:07",,"2007-09-06 17:47:37",30,0,"NO ANSWER","DOCUMENTATION" I do not see any reason why there should be TWO CDRs for such calls since if a call is answered, from and to CDRs get merged in ast_bridge_call().
Comments:	By: Steve Murphy (murf) 2007-09-11 15:40:21 r82261 | murf | 2007-09-11 14:36:15 -0600 (Tue, 11 Sep 2007) | 1 line this change should fix issue # 10659 -- what I worry about is how many other bug reports it may generate. Hopefully, we can please the/a majority. Hopefully. We shall see. Calls not marked ANSWERED and with only one channel name will not be posted. This should eliminate the double CDR's. and fixed in trunk via 82262... By: Tilghman Lesher (tilghman) 2007-11-15 12:46:03.000-0600 I think this fix has caused enough issues that we should revert this change and discuss a more appropriate fix. By: zoa (zoa) 2007-11-16 01:26:35.000-0600 Just to add something to the history (and explain why some people need it), we also saw a problem: This is the email my collegue sent to asterisk-dev on 15 nov 2007: --- Hi, Looking at this and the commit for it, and having disabled it to fix an issue with a system that we have, I want to ask - are you sure people don't want single-channel unanswered events? What if the call started but got hung-up before the dialplan was able go find the destination and do Dial() - in that case the CDR is lost, and it's in fact very important in some setups  :) By: Andrey S Pankov (casper) 2007-11-23 08:45:58.000-0600 Maybe we should revert the fix applied to cdr.c and fix _only_ app_dial for now. Let me expalain one more time: if you read carefully the code of ast_bridge_call() in res_features.c you'll notice, that we "arrange" CDRs there. But we call ast_bridge_call() only for answered calls. CDRs for other calls (timed out or cancelled) are not arranged anywhere. By: Steve Murphy (murf) 2007-11-27 00:57:36.000-0600 I set up an option for 11379, that lets you choose whether you want to see the extra CDR's. (by default, you won't see the extra unanswered cdrs.). Either way, no more pesky "cdr not posted" messages. I basically put code into app_dial to disable posting the rung channels if the option isn't set. That's a better place, as we know the intention of the channel there. I'll leave this open for a little while.  Did my fix to 11379 solve this problem? By: Steve Murphy (murf) 2007-11-28 14:44:47.000-0600 I'm going to close this, as there was no immediate outcry of rage. I invite you to reopen this bug, if you are not satisfied, and we'll see what can be done.