Summary:	ASTERISK-06518: Accountcode of second leg in cdrs on attended transfer
Reporter:	Christian Benke (christianbee)	Labels:
Date Opened:	2006-03-10 09:38:50.000-0600	Date Closed:	2007-06-22 12:20:33
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 2_cdr_table.csv ( 1) 2_dialplan.cfg ( 2) 2_verbose_and_sip_debug.txt ( 3) 2_verbose_debug.txt ( 4) 3_cdr_table.csv
Description:	When i do a attended transfer of a call, the accountcode that has been set for the second call leg is written to the first call leg-cdr as well(Instead of the accountcode that was set for the first call leg). I've extracted the problem to a simple dialplan, see the attached files. I've attached the dialplan, the custom-cdr-flat file, the verbose log and a csv-file from my postgres-cdr-table. The Error-500-message in the verbose-log comes from the OpenSER-Registrar on the same host where the phones are registered, asterisk is on port 5061, OpenSER on 5061.
Comments:	By: Christian Benke (christianbee) 2006-03-10 09:46:12.000-0600 admin please delete attached "verbose.log", "updated_verbose.log" is the correct version, thx! By: Christian Benke (christianbee) 2006-03-10 09:49:36.000-0600 i beg your pardon, openser is on port 5060 of course, appropriate SRV-records for siptest1.mydomain.com point to its ip and port. By: Christian Benke (christianbee) 2006-03-13 02:52:23.000-0600 btw: i don't use the asterisk-transfer-feature for the attended transfer but the button on my polycom 601... By: Olle Johansson (oej) 2006-03-13 03:11:36.000-0600 Ahh, so this is a SIP problem that should be in the SIP category? If you use SIP REFER, you have to file in the SIP category. I also believe there's an open bug on that already. By: Christian Benke (christianbee) 2006-03-13 03:54:30.000-0600 yes, i receive a "-- Got SIP response 302 "Moved Temporarily" back from "2XX.XXX.XXX.79" plz tell me if i can give you any more information - though you should be able to reproduce it with the dialplan i posted... By: Olle Johansson (oej) 2006-03-13 09:32:19.000-0600 For all SIP bugs, we need a complete trace with signalling. A 302 is not an attended transfer. Set verbose to 4, debug to 4 and enable "sip debug"  - save all that to a file so we can see how the transfer is processed and which call leg does what. i need to know whether the inbound or the outbound call leg sends the REFER. By: Christian Benke (christianbee) 2006-03-13 10:58:22.000-0600 sorry again, of course i don't get an 302 as this is an attended transfer, i confused this bug-report with another pending issue i have. i attach a full verbose debug as you requested, hope i didn't miss or strip anything important. thanks! By: Christian Benke (christianbee) 2006-04-05 03:45:39 Please provide feedback on this issue! Thanks!!! By: Serge Vecher (serge-v) 2006-05-04 09:39:52 christianbee: please try the patch in 6393 by russell and see if it fixes this issue for you... Thanks. By: Serge Vecher (serge-v) 2006-05-12 10:04:55 christianbee: if the issue is present in the latest trunk or 1.2 branch (rev > 26000), please reopen the bug with updated debugging information. thanks. By: Christian Benke (christianbee) 2006-05-30 14:20:25 sorry for the late reply, i was too busy to do the debugging. is there actually a better method to trace the sip-debug than by copying it out of the verbose log?(like cat verbose|grep 23174]) unfortunately, the problem still exists. i've again attached all the required files, named  as 2_*, including a very simple dialplan. By: Serge Vecher (serge-v) 2006-05-30 14:23:44 what version / revision is this from? By: Christian Benke (christianbee) 2006-05-30 14:26:03 that was quick ;-) just recognized that this is missing. i've version 1.2.1 installed By: Christian Benke (christianbee) 2006-05-30 14:27:57 sorry, 1.2.7.1 of course, guess therefore my reopening disqualifies anyways...? missed to check it earlier unfortunately :-( By: Serge Vecher (serge-v) 2006-05-30 14:45:08 ok, well the patch in 6393 went into the 1.2 branch. Please checkout the latest 1.2 branch and see if the issue is there. By: Serge Vecher (serge-v) 2006-05-30 19:34:56 note: 1.2.8 was just released, so you can test with that. By: Serge Vecher (serge-v) 2006-06-08 15:31:31 please only reopen if you can reproduce this problem with 1.2.9.1. Thanks By: Christian Benke (christianbee) 2006-06-09 09:54:10 updated to 1.2.9.1, but no changes, the accountcode of the second leg is still written to both records(see 3_cdr_table.csv) :-( By: Serge Vecher (serge-v) 2006-08-25 14:25:43 sorry to keep asking you, but since a developer hasn't picked it up yet, the only option is to test the latest stable to see if it was fixed already by something ... By: Christian Benke (christianbee) 2006-08-28 09:56:28 > sorry to keep asking you np, thanks for keeping this up! unfortunately no changes, still not working in 1.2.11 and svn trunk r41228 By: jmls (jmls) 2006-11-01 06:32:16.000-0600 oej, would you be able to take a quick look at this ? Thanks By: jmls (jmls) 2007-05-28 02:26:43 christianbee, the usual - would you be able to confirm that this is still broken in the release that you are using ? Thanks. By: Steve Murphy (murf) 2007-06-22 12:20:31 I am closing this bug for the exact same reasons as I closed 8830; the CDRs ARE telling the truth. The bridge was between the incoming caller and SIP/2. That's who talked on that bridge. It's the truth. There's no field, idea, or provision for recording who is "responsible" for the call, if not the incoming caller. And to add it... well, not in 1.4. See what I wrote in the closing comments for 8830.