Summary:	ASTERISK-08676: Call Forward closing the second cdr
Reporter:	Afshin Mashayekhi (afshin)	Labels:
Date Opened:	2007-01-28 19:36:52.000-0600	Date Closed:	2007-06-21 18:50:30
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I tried to use call forward button in Cisco phones (It uses SIP forward - SIP response 302). I forward phone B to C and I dialed from A to B: -- Called SIP-B -- Got SIP response 302 "Moved Temporarily" back from 172.31.101.16 -- Now forwarding SIP/B-09726808 to 'Local/C@context' (thanks to SIP/B-09730930)                               as soon as C picks up the phone asterisk will write a cdr record from B to C with billsec 0 (witch is NOT correct)  (it used to be from A to C and I tried dial with option f and it fixed the first part which was the source callerid) When C hangs up his phone asterisk will write another CDR from A to B with the correct billsec. (witch is correct)
Comments:	By: Steve Murphy (murf) 2007-03-29 22:27:00 I apologize for the long delay here, been pretty snowed under by all the cdr issues (and all the other issues I've been handling)! Is it possible to try an experiment? Pick up the 8221 branch, and test to see if this issue is fixed using that code? It's at team/murf/bug8221-1.4 Let me know if it helps at all. By: Steve Murphy (murf) 2007-03-30 08:14:34 So, it seems that, from your description, there are multiple errrors here. First of all, the first, empty CDR should have been from A to B, not B to C. That this record has billsec == 0 is problematic. It's not a transfer, is it? Seems like you programmed the phone to forward incoming calls to another extension...? So no conversation took place, no answer at B, right? And, the second CDR says its from A to B, but because of the forward, it should be from A to C, right? By: Serge Vecher (serge-v) 2007-03-30 10:27:11 are we all set with 1.4 checked out from svn? By: Steve Murphy (murf) 2007-03-30 14:32:06 No, this is still a problem. By: Afshin Mashayekhi (afshin) 2007-04-01 18:34:04 Hi, I tried again with the trunk version and it's getting worse... I forward B to my mobile and called B from A. Now it is generating 3 records rather than 2 and the first record is totally empty... it just has cdr_channel, calldate and disposition = "No Answer" the second record is the same as before (A-->Mobile) with billsec = 0 and the third has the correct bill sec but it is from A to B I reckon the forward process has to generate 2 record first from A to B with bill sec 0 and then from B to mobile... because it is not logical to charge user A for that mobile call. imagine this is a call from outside of your office to your office and you've forwarded your phone to your mobile. We have to charge the office phone for that mobile call not the phone who made a call (in many cases we even don't know who made a call because it is from outside or it is an incoming call from one of our PSTN lines...) By: Steve Murphy (murf) 2007-06-14 13:08:23 OK, I've been studying this sequence. I've set my polycom phone to forward to extension 150 (which could have been any interface/number, and I see, 1.4, these 3 CDRs generated: "152","152","s","extension","SIP/polycom430-08240690","","","","2007-06-14 10:33:09","","2007-06-14 10:33:09","0","0","NO ANSWER","DOCUMENTATION","","1181838789.12","" ""fxs.52" <152>","152","150","extension","Local/150@extension-c22a,2","Zap/50-1","Dial","Zap/50|30|TtWw","2007-06-14 10:33:09","2007-06-14 10:33:15","2007-06-14 10:33:15","6","0","ANSWERED","DOCUMENTATION","","1181838789.14","" ""fxs.52" <152>","152","h","extension","Zap/52-1","Local/150@extension-c22a,1","NoOp","More Hangup message after hopping around"","2007-06-14 10:33:05","2007-06-14 10:33:15","2007-06-14 10:33:47","42","32","ANSWERED","DOCUMENTATION","","1181838785.11","" Apparently, the SIP channel driver performs the transfer using a Local Channel to Dial to the forwarded number. So, to piece together the sequence, you do need all 3 CDR's unfortunately. The first CDR records 152's attempt to dial the SIP/poly phone. It was not answered there, and the call was abruptly started and ended at 10:33:09 The two following CDRs document the Local/ channel pair. One end of the Local channel pair records just the dial time of the pair. (6 sec), and the last CDR records the action on 152 from start (10:33:05), to answer by 150 (10:33:15), to hangup at 10:33:47. 10:33:05 is the time that 152 went off-hook. Knowing that Local/150@extension-c22a,1  and Local/150@extension-c22a,2 are the two halves of a transfer, you can use the start time of the c22a,2 record and the originating channel extension (152) to locate the ref to Sip/polycom at 10:33:09. (BTW, Local channels always occur in pairs, and are used to splice channels to apps.) Sorry, I can't think of an easier way to handle this right now. In 1.2, and 1.4, the handling of transfers in CDRs is fairly non-implemented. It's almost an accident,  that you have enough information to figure out what happened. In the trunk version, I intend at some point, to merge the stuff I have in team/murf/CDRfix5. And this branch, in the same situation, pumps out these CDRs: "","","150","extension","Local/150@extension-5288,2","Zap/50-1","Dial","Zap/50|30|TtWw","2007-06-14 10:52:27","2007-06-14 10:52:34","2007-06-14 10:52:35","8","1","ANSWERED","DOCUMENTATION","","1181839947.8","" ""fxs.52" <152>","152","s","extension","Zap/52-1","Local/150@extension-5288,1","Dial","SIP/polycom430|30|TtWw","2007-06-14 10:52:24","2007-06-14 10:52:34","2007-06-14 10:52:46","22","12","ANSWERED","DOCUMENTATION","","1181839944.5","" Again, the two Local/ channel references. the second CDR has all the info you need: the Local/150@extension-5288,1 in the destination, the SIP/poly in the dial command, the ref to extension 150 is in the Local/150@ specifier. This should be enough info to bill SIP/poly instead of 152. Unfortunately, to handle transfer situations correctly in CDRs, you will have to be familiar with Local and masqueraded channels, and recognize the patterns in the CDRs. Handling transfers 'correctly' requires that some underlying assumptions/philosophies have to change to make it even possible to generate CDRs that could describe the situation. And I can't just go and totally, fundamentally change things in 1.2 and 1.4. So, beginning with trunk, we hope to get CDRs right with transfers. I'm going to close this bug, because, like I said, I can't really "fix" this in 1.2/1.4; and the changes are big enough in trunk, that I'm treating this like an enhancement/new feature. By: Steve Murphy (murf) 2007-06-21 18:50:29 NOTE: THIS IS A KEY BUG REPORT. I'm closing it as "not fixable" in 1.4 or 1.2. But there is hope for 1.6 (trunk). The current system uses hangups to post CDR's, and simply does not have the mechanisms to handle all the xfer issues properly. Just the changes I have made to get answer times from peers, etc., have been relatively disruptive to those in the community who have billing apps already written around the current system. Already, I am seeing that a small change to fix one problem, will upset the cart, so to speak, of those who have apps written that now depend on this bug/feature. So, in the team/murf/CDRfix5 branch, which will sometime be applied to trunk, I introduce a new philosophy behind CDRs: bridge based. It's philosophy is a bit simpler: If a bridge is formed, a CDR is generated. When are bridges formed? When one channel is connected to another. In other words, when a conversation between two parties happens. While this isn't totally ideal, it more or less covers most situations involved in blind, and attended tranfers, whether via hookflash, xfer buttons on sip phones, etc. SO, REALLY, all work on CDRfix5 could be attributed to this bug! I have another solution, that may appear in some future version of Asterisk, based on Events. I think its in team/murf/newcdr. While it's maybe half done, it's demonstratable. Some general, useful, tool to parse the event sequences into CDR records is needed to make it practical. It's on hold until I get some time to finish it.