Summary:	ASTERISK-01576: CDR Error log on call transfer
Reporter:	powerkill (powerkill)	Labels:
Date Opened:	2004-05-09 16:47:57	Date Closed:	2008-01-15 15:09:03.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) cdr.diff.txt
Description:	Person A is calling person B, and then he makes (person A) a call transfer to person C. That means that person B is talking to person C, and A is not in the picture anymore. But here is the problem: When person A is calling person B, a log is being made from A to person B, which is ok. Then person A is making a transfer to person C, a log is being made from person A to person C, which is ok. But here come the problem, the log between person A and person B is terminated, but the conversation between B and C still continues, and the only log now is between person A and person C. Here is a demonstration about how this log can be fatal for us. Person A is calling person B (for example Cellular Phone), then person A is making a call transfer to person C (for example Proper Phone.), the log between person A -> B is terminated but between person A -> C still continues. And the people who are actually talking are person B -> C. Person A is the one who made the calls for both destinations, and we are those who will pay the bill, but we will only be able to bill for a partial time from person A -> B and the rest of the time between A -> C, where in reality the billing should be the whole time between A -> B  + and A -> C.
Comments:	By: Olle Johansson (oej) 2004-06-14 14:57:14 Is this in any way related to a specific channel or a general problem? By: Mark Spencer (markster) 2004-06-20 23:00:25 Which channel driver are you interested in here? By: Mark Spencer (markster) 2004-06-24 01:00:16 If you still have an interest in seeing this fixed, please let me know what channel driver you're using that has the trouble so I can be sure it's fixed for it now that we have the structure to be able to support something like this. By: powerkill (powerkill) 2004-06-27 10:24:41 I'm using SIP channel but i think the bug can be reproduce in all channel By: Brian West (bkw918) 2004-06-27 14:00:40 This is solved by stacking CDR Records so you have records running side by side for A -> B and B -> C (and its possible)   Anyway its not a bug really its how its done.  We need an option to have a CDR per call leg(stacked). bkw By: powerkill (powerkill) 2004-07-03 20:32:30 ok so may be the transfert can be patch to tell to the cdr logging engine to stack it ? if it possible to do it in this level ? By: twisted (twisted) 2004-07-23 20:36:14 Request for update - any intrest still here? -HouseKeeping By: powerkill (powerkill) 2004-07-25 19:09:44 still interested but how to solve the problem ? By: Mark Spencer (markster) 2004-07-25 19:16:27 You can link the two CDR's potentially.  Tha functionality is now in cdr.c so they can be linked, but the transfer code would need to save and link the original CDR, basically. By: mustdie (mustdie) 2004-07-25 19:18:25 I just found out that one customer of mine is activly exploiting this "functionality". Oops. By: Mark Spencer (markster) 2004-07-27 17:34:12 Can't wait to see the surprise on his face when we work around it right? :) By: powerkill (powerkill) 2004-07-27 19:10:45 LOL ;) I'm learning the CDR Logic to try to make a patch, currently I found a way to do it with a crontab that correct the problem after the call but is very dirty :) By: Mark Spencer (markster) 2004-07-27 22:33:30 In principle, attaching the CDR of one call to the other (it's a linked list) should be sufficient.  We could do it as a development job... By: powerkill (powerkill) 2004-08-02 09:01:22 perfect, so I think we can pass it to be a future feature, but the bugs main remain open if others users encounter the same problem or worst don't see the problem and loose money :) By: chrisorme (chrisorme) 2004-08-20 06:25:02 just a quick note to say the way I dealt with this was not as a cron job but to write a perl agi, called from the dial plan, before allowing the customers dial, that scanned the cdr and corrected the blank transfered call entries and correctly allocated them to an account and deducted them from the users balance.  I identified the owner of the 'transfered' calls as they have certain properties like a field in common with the original call/cdr record and are after them in date. This is probably how most people handle this but I thought I might as well post this so long as noone minds as it might help someone with this problem in the meantime. edited on: 08-20-04 06:25 By: adomjan (adomjan) 2004-09-09 17:24:33 And temporarily could be disable 302 sip redirect to workaround the problem? By: Mark Spencer (markster) 2004-09-09 22:02:44 It's not a 302 moved that does it, it's a REDIRECT presumably with a call reference (replaces=) but if you can tell me for sure which environment you care about this in (Zap vs. SIP) then I can probably try to do one or the other pretty straight forwardly. By: adomjan (adomjan) 2004-09-10 01:44:25 With SIP channel. By: adomjan (adomjan) 2004-09-10 02:37:15 96(IAX) calling 57(SIP) 57 transfer to 76(SIP) and where is 57? "","96","76","local","""Domjan Attila"" <96>","IAX2/guede-iax@guede-iax/16384","SIP/76-493d","Dial","SIP/76|120|r","2004-09-10 09:14:30","2004-09-10 09:14:31","2004-09-10 09:14:52",22,21,"ANSWERED","DOCUMENTATION" ------------------------------------------------------------------------------ scenario b: 57(SIP) call top outside over Zap and 57 make transfer to 96(IAX): "12886357","12886357","0630xxx9188","local","""Domjan Attila"" <12886357>","SIP/57-c9f3","Zap/12-1","Dial","Zap/r1/0630xxx9188||f","2004-09-10 09:28:03","2004-09-10 09:28:08","2004-09-10 09:28:12",9,4,"ANSWERED","DOCUMENTATION" the 1st cdr was written when 57 make transfer "","12886357","96","local","""Domjan Attila"" <12886357>","Zap/12-1","IAX2/guede-iax/16384","Dial","IAX2/guede-iax/96|120|r","2004-09-10 09:28:12","2004-09-10 09:28:14","2004-09-10 09:28:32",20,18,"ANSWERED","DOCUMENTATION" here, I can see only 57 call 96, when 0630xxx9188 talk to 96, and 0630xxx9188 is an expensive mobile call. So, the first cdr not should be ended, when 57 press transfer! By: Russell Bryant (russell) 2004-10-03 16:00:05 Fixed in CVS head for SIP and Zap supervised transfers. By: Russell Bryant (russell) 2004-10-03 16:21:52 Fixed in the 1.0 branch. By: Digium Subversion (svnbot) 2008-01-15 15:09:02.000-0600 Repository: asterisk Revision: 3902 U   trunk/cdr.c U   trunk/channels/chan_sip.c U   trunk/channels/chan_zap.c U   trunk/include/asterisk/cdr.h ------------------------------------------------------------------------ r3902 | markster | 2008-01-15 15:09:02 -0600 (Tue, 15 Jan 2008) | 2 lines Correct CDR's for supervised transfer (bug ASTERISK-1576) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3902 By: Digium Subversion (svnbot) 2008-01-15 15:09:03.000-0600 Repository: asterisk Revision: 3903 U   branches/v1-0/cdr.c U   branches/v1-0/channels/chan_sip.c U   branches/v1-0/channels/chan_zap.c U   branches/v1-0/include/asterisk/cdr.h ------------------------------------------------------------------------ r3903 | russell | 2008-01-15 15:09:03 -0600 (Tue, 15 Jan 2008) | 2 lines Fix CDR for supervised transfer in chan_zap and chan_sip (bug ASTERISK-1576) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3903