Summary:ASTERISK-15149: Missing CDR
Reporter:Daniel A. Veiga (dveiga)Labels:
Date Opened:2009-11-16 20:53:19.000-0600Date Closed:2011-07-27 13:28:08
Versions:Frequency of
Description:- T0: Party A calls party B, B picks up.
- T1: Party B hook-flashes and calls C, party C picks up.
- T2: Party B hangs up, leaving A connected to C.
- T3: Party A or C hangup, terminating the last call.

Only 2 CDRs are created: A->B(T0-T2) and B->C(T0-T3). It is not possible to know (looking at CDRs) that A talked to C nor the time they talked (as the actual time T2-T3 does not appear in any CDR).

I would expect 3 records:

NOTE: Notation [OrigChannel]->[DestChannel]([StartTime]-[EndTime]). All other fields in the CDR are ommited for clarity.


I looked into the problem and found it could be solved quite easily in main/channel.c, posting opened CDRs and creating a new one during the masquerade process that performs the transfer when party B hangs up in ast_do_masquerade().
The problem is function ast_bridge_call(), in main/features.c, ignores the CDRs in the channels and relies only in the one it created whose pointer (bridge_cdr) keeps as a local variable. In other words, posting a CDR in ast_do_masquerade() can add the record B->C, but it's impossible to modify the remaining CDR and change the source channel to A.
Before attempting a solution, and particualarly because of the implicances of a change in those functions, I'd like to contact someone with experience in Asterisk's CDRs for an advise. After that, I can code what has been suggested.

Thread here:  http://lists.digium.com/pipermail/asterisk-dev/2009-November/040694.html
Comments:By: Leif Madsen (lmadsen) 2009-11-17 07:50:41.000-0600

Acknowledging this issue.

The best person to discuss this with is going to be mnicholson as he has extensive experience with the CDRs. There may be a reason this is not possible in the current system, mostly due to backwards compatibility.

However, I'll encourage you to discuss this on the asterisk-dev mailing list prior to submitting any patches (as you alluded to) in order to come up with the best approach to solving this issue.

It may come down to waiting for CEL (Channel Event Logging) which was created to solve this type of issue, but there may or may not be something that can be done in the existing branches. Thanks!

By: Daniel A. Veiga (dveiga) 2009-11-18 06:28:47.000-0600

Thanks lmadsen, I've already joint asterisk-dev list and posted a message. I'm looking forward to mnicholson's reply. I'll post soon in this bug to let you know if something can be done or not, and according to it keep it open and submit a patch or close it.

By: Leif Madsen (lmadsen) 2009-11-18 08:15:53.000-0600

Thank you for the feedback. I will leave this issue open for a couple of weeks pending any additional feedback. Thanks!

By: Leif Madsen (lmadsen) 2009-11-30 14:49:43.000-0600

Any update here?

By: Leif Madsen (lmadsen) 2009-12-01 11:17:21.000-0600

Thread here:  http://lists.digium.com/pipermail/asterisk-dev/2009-November/040694.html

By: Russell Bryant (russell) 2011-07-27 13:28:02.599-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!