Summary:	ASTERISK-08200: [patch] forkcdr does not work as expected
Reporter:	Loic Didelot (voipgate)	Labels:
Date Opened:	2006-11-28 07:26:43.000-0600	Date Closed:	2007-06-22 22:36:36
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_forkcdr
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) cdrfix4
Description:	When using forkcdr in asterisk 1.4 it does not work as expected. SRC and CLID are empty in the cdr line generated before the forkcdr. ****** ADDITIONAL INFORMATION ****** Tested on 1.2 and the problem does not exist there.
Comments:	By: Joshua C. Colp (jcolp) 2006-11-28 23:01:59.000-0600 I labbed this up and was unable to reproduce it. Can you give some more information on what scenario triggers it, configs that do it? By: Loic Didelot (voipgate) 2006-12-04 07:21:15.000-0600 Here is an example dialplan. Maybe it is important to note that we are using cdr_addon_mysql. exten => 123,1,NOOP(this is a forkcdre test) exten => 123,2,Set(CALLERID(number)=1234567890) exten => 123,3,Set(CALLERID(name)=before fork) exten => 123,4,Forkcdr exten => 123,5,Set(CALLERID(number)=0987654321) exten => 123,6,Set(CALLERID(name)=after fork) exten => 123,7,Answer exten => 123,8,Echo exten => 123,9,Hangup By: Joshua C. Colp (jcolp) 2006-12-06 10:04:09.000-0600 Just out of curiosity - what does /var/log/asterisk/cdr-custom/Master.csv show? Same as what is going into your database? By: Loic Didelot (voipgate) 2006-12-08 03:14:49.000-0600 It is not correct in the csv files either. By: Joshua C. Colp (jcolp) 2006-12-18 20:52:44.000-0600 Here murf, since you have become intimate with CDRs. By: Steve Murphy (murf) 2007-01-03 10:15:42.000-0600 Hmmm. Testing on the latest 1.4.0 svn gives me different results. In my case, I provide an extension in the context for an FXS phone. I pick up the phone, dial 873 or whatever, and execute the code you provided, the ForkCDR and Echo calls. This results in two CDR's, both identical, except for the app and data, one is ForkCDR, the other Echo. Both CDRs record the "after fork" CID info. This has me puzzled. How do you invoke your ForkCDR? Incoming call? Does it make a difference? I'm going to go build and install a 1.2 version, and see what I get. By: Steve Murphy (murf) 2007-01-03 11:05:17.000-0600 Even stranger. I brought up 1.2, and reran; I pick the phone, dial 873, or whatever, and execute the sequence. I get two almost identical CDR's: both "after fork" cid info, both "Echo", both have the same start, answer, end times. The second cdr has the duration and billsec set to correct values, the first has zeroes in these two fields... very interesting! By: Steve Murphy (murf) 2007-01-03 12:43:12.000-0600 OK, I understand. The setcid funcs set all the cdrs on a channel to the new cid. So, according to that, and that forkcdr dups the one to the other, explains most of what I see. By: Steve Murphy (murf) 2007-01-04 11:58:34.000-0600 voipgate-- Can you give me some more details on the sequence/environment under which this is occurring? I'm not reproducing the problem. By: Loic Didelot (voipgate) 2007-01-04 13:22:06.000-0600 I will recheck with the newest 1.4 version and give you feedback. All the tests I have done have been an outgoing call from a SIP device. By: Loic Didelot (voipgate) 2007-01-05 02:47:29.000-0600 I just tested under asterisk 1.4 revision 49000. I have my IAX "friend" setup in a way that it is in a context called CUSTOMER and in this context I have the extensions as stated above. 2 cdr's are inserted into the database but the data is not really correct.  In this case the callerid data. Now the data is no longer empty but it inserts the data which is set after the forkcdr. name="after fork". Something which seems to be strange now is that exten => 123,2,Set(CALLERID(number)=1234567890) or exten => 123,2,Set(CALLERID(num)=1234567890) do not seem to work. By: Steve Murphy (murf) 2007-01-08 17:23:25.000-0600 The ForkCDR() calls dups the current cdr, and chains it to the existing cdr, which hangs on the current channel. The CALLERID() funcs operate on the entire chain, and does the same thing to all of them. This explains what you see in the logs. I also tried this on 1.2, and get the same results... So, I guess, my question is, what were expecting this to do? What do you need it to do? By: Loic Didelot (voipgate) 2007-01-09 01:03:25.000-0600 Well I do a forkcdr because I want to have 2 cdr lines but as soon as I have done a forkcdr I am aware that I can no longer control/modify the first line. But I should be able to control/modify the second one through the use of the CDR function. Typical scenario: I get an incoming call, I dial my SIP friend but that one is unavailable but I know that he has setup a redirection in my database. So after I have dialed the SIP friend I do a forkcdr and do an outgoing call to the user's mobile. Like this I have 2 cdr lines one for an incoming call and one for an outgoing call which I need to rate and bill. By: Steve Murphy (murf) 2007-05-15 17:20:10 OK, I've think I've found and fixed the problem. I was a bit more naive about what to do with locked CDR's than I thought, during the merge operation. I've tested out the fix, and it seems to work in the scenario you've presented. It's general, and covers the cases where multiple ForkCDR's are stacked up. Please use patch to apply the uploaded cdrfix4 file (patch -p0 < cdrfix4) to your 1.4 release. Don't mind the reported offsets. They should be OK. Tell me if this fixes your problem. By: Steve Murphy (murf) 2007-06-22 22:36:35 voipgate-- I waited for some input, but this seems to need to be in the code. I applied this to 1.4 via 71230; to trunk via 71231. I am closing this bug; if this doesn't solve your problem, reopen and we'll dig deeper. My own testing verified that it works, but you know how it sometimes goes. The clid/source lossage was also reported late in 10016; but in that case, no forkCDR was involved, so it may not have anything to do with it.