[Home]

Summary:ASTERISK-08356: [patch] dstchannel in cdr is empty when transfer call
Reporter:Afshin Mashayekhi (afshin)Labels:
Date Opened:2006-12-14 19:11:54.000-0600Date Closed:2007-01-23 14:43:10.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) res_features.patch
Description:When transfer call by asterisk the dstchannel in cdr is empty.

****** STEPS TO REPRODUCE ******

I fixed this issue for myself because it's so important for billing purposes and I test that.  It's work fine but I don't know how can I submit it. it's just 2 line in feature.c
Comments:By: Serge Vecher (serge-v) 2006-12-15 08:02:31.000-0600

1. Could you please get a disclaimer on file (see bottom of http://bugs.digium.com/main_page.php) and cofirm with a note here when done?
2. It would be great if you could upload your change as a patchfile. See  http://www.asterisk.org/developers/Patch_Howto

By: Steve Murphy (murf) 2006-12-15 09:33:39.000-0600

afshin-- yes, it would be nice to have that disclaimer; it's too late for the patch, I see you added these lines to park_exec after the bridge:

               memset(&config, 0, sizeof(struct ast_bridge_config));
               res = ast_bridge_call(chan, peer, &config);

+               pbx_builtin_setvar_helper(chan, "PARKEDCHANNEL", peer->name);
+               ast_cdr_setdestchan(chan->cdr, peer->name);
+
               /* Simulate the PBX hanging up */
               if (res != AST_PBX_NO_HANGUP_PEER)
                       ast_hangup(peer);

I'm mixing this in to the stuff I did for 8221, to see what/if there's any effects upon the whole...

By: Steve Murphy (murf) 2006-12-15 12:18:55.000-0600

One thing that bothers me here, is this is really only a partial fix.
If A calls B, B answers, parks the call, and C then picks up A's parked call,
then, without the fix, we got source and dest channels blank, and now,
we have the dest channel filled in, so we know that C picked up a parked call, but there may be several parked calls, and there's no real way to tell which caller we are linked. Right at the only moment, we can't tell he picked up A's call, except maybe that the end times in the CDR's match (which will change, by the way, when I finish with 8221! Those two calls do NOT end at the same time!)

We need to fill in the src channel as well, don't we?



By: Afshin Mashayekhi (afshin) 2006-12-19 01:25:48.000-0600

I faxed the disclaimer to Digium. And I tried to compile the svn revision 48572 to check if it was fixed or not but it wasn't compiling.
I will check later.

By: Afshin Mashayekhi (afshin) 2006-12-27 18:38:00.000-0600

I checked this new code with asterisk 1.4 final and it's fine...

By: Serge Vecher (serge-v) 2006-12-28 08:33:52.000-0600

are you saying this problem no longer exists in 1.4.0 release? If yes, do you know which revision this got fixed in?

By: Afshin Mashayekhi (afshin) 2006-12-28 15:56:41.000-0600

I didn't say this problem is not exist in 1.4.
It is exist in 1.4 but I used my code and I patched 1.4 and the problem was fixed.

By: Serge Vecher (serge-v) 2006-12-31 11:32:28.000-0600

ok, thanks for clarification. Can you please upload the changes as a patch file? http://www.asterisk.org/developers/Patch_Howto

By: Steve Murphy (murf) 2007-01-04 12:07:31.000-0600

serge-v, afshin--

It's OK. I've been playing with this code change; I've been playing with several cdr-related problems; I've got other places where I make sure dst and src channel names are filled in the cdr's, and it's not entirely certain to me yet that this particular mod will need to be added. When and if it is, I'll add commit to the sources.

murf

By: Afshin Mashayekhi (afshin) 2007-01-04 15:59:26.000-0600

I check this problem in SVN 49356 and it's still the same.
Please when you changed the code and applied your changes, let me know to check it...

By: Steve Murphy (murf) 2007-01-23 14:43:09.000-0600

afshin-- Many thanks for this patch; Sorry it took so long to merge; the problem is that CDR's have several overlapping problems (see 8221), and it's been a fairly huge project trying to sort it all out.
This patch does not hurt the other fixes I've been developing, so I decided that since they are small and fix immediate problems, I'll go ahead now and get them merged in. I may end up making changes again later when the more complete, hopefully "final" changes are committed, tho!

For 1.4, see r.51716, for trunk, see r.51717.