[Home]

Summary:ASTERISK-10625: CDR Created incorrectly on Transfer of outgoing call
Reporter:Ross Beer (rossbeer)Labels:
Date Opened:2007-10-26 10:02:41Date Closed:2008-07-02 19:09:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_cdr
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When making an outgoing call and then transferring a call to another extension the CDR details are incorrect.

I would expect to see two CDR's created, one for the outgoing call and another for the transfer as Asterisk does, however it stops (ends) the outgoing CDR at the point of transfer, instead of continuing to increment the 'seconds'.

This problem occurs on both blind transfers and attended (using a Snom and not using '#' or '*1' features). However attended transfers are more accurate than blind transfers, they do continue to count however the time is not 100% accurate.

I have tried to fix this myself in the dial plan by using '/n' and a local channel however it still occurs. This problem did not occur in previous versions of Asterisk.
Comments:By: Juan Pablo Abuyeres (jpabuyer) 2007-11-21 15:00:05.000-0600

I upgraded from 1.2 to 1.4 yesterday, and hit this bug miserably. So I had to go back, and after researching and testing a lot, this is what I found:

First, the main scenario are this Steps:
1.- A Calls B and B answers, let's say instantly (for the sake of math simplicity)
2.- X seconds later, B transfers the Call to C, C answers, and B gets out of the way.
3.- Y seconds later A or C hang up.

After step 3, two CDRs should be created:
1.- one for A calling B, lasting X+Y seconds.
2.- one for B calling C, for Y seconds.

And that's the behavior we had until 1.4-r59485 inclusive.
Since r59486 (http://bugs.digium.com/view.php?id=8221) the behavior starts changing to this: Two CDRs are created:
After Step 2:
1.- one for A calling B, lasting only X seconds.
After Step 3:
2.- one for B calling C, for Y seconds.

This is totally wrong, and totally breaks our billing system. But it doesn't end here.

Since 1.4-r60989, CDRs for transfered calls are totally useless. For any transfered call, 6 CDR entries are created. Describing them might be as useless as the records themselves, but anyway:
After Step 2:
1.- accountcode present, src is empty, dst is C, answered.
2.- accountcode is empty, src is empty, dst is 's', answered.
3.- accountcode is present, src is empty, dst is B, answered.
4.- accountcode is present, src is B, dst is B, failed. (Channel says <ZOMBIE>)
After Step 3:
5.- accountcode is empty, src is empty, dst is 's', answered.
6.- accountcode is present, src is B, dst is empty, failed.

Latest svn release 1.4-r89505 is not much better. It creates 4 entries:
After Step 2:
1.- accountcode present, src is B, dst is B, answered.
2.- accountcode is empty, src is empty, dst is empty, answered.
3.- accountcode present, src is A, dst is B, answered.
After Step 3:
4.- accountcode present, src is B, dst is 's', answered.


rossbeer, if you need correct CDR records, like I do, you will need to stick to release 1.4.2 or svn release 59485.

murf, your hands have been in all the patches that have broken CDRs for transfered calls hahahaha :-D so it's perfect that you've been assigned for this bug. If I can help in any way, don't hesitate to ask me. I already have 4 polycoms in my desktop to make tests, and I am very interested in this problem to be solved.

By: Juan Pablo Abuyeres (jpabuyer) 2007-11-26 14:29:08.000-0600

hello??

By: Juan Pablo Abuyeres (jpabuyer) 2007-12-12 15:33:35.000-0600

This bug is still present in latest SVN-branch-1.4-r92617
Please I need to upgrade but I can't because of this bug.

By: Grey VoIP (greyvoip) 2008-01-26 10:31:17.000-0600

CDR's for transfers are definitely a big problem and always have been. In the case of OP's first scenario I have never seen any version of Asterisk generate the CDR's correctly for a blind transfer so the bug here is not new to 1.4.

"First, the main scenario are this Steps:
1.- A Calls B and B answers, let's say instantly (for the sake of math simplicity)
2.- X seconds later, B transfers the Call to C, C answers, and B gets out of the way.
3.- Y seconds later A or C hang up.

After step 3, two CDRs should be created:
1.- one for A calling B, lasting X+Y seconds.
2.- one for B calling C, for Y seconds."

I have just re-tested with Asterisk 1.2 and there are two CDR's generated but they are:

1.- one for A calling B, lasting X seconds (NOT X+Y seconds).
2.- one for B calling C, for Y seconds.

By: Doug (doug) 2008-02-21 08:08:24.000-0600

This has been a constant problem that will only probably be fixed in 1.6. You will notice that the same problems happen when using call forward.

By: Grey VoIP (greyvoip) 2008-02-22 20:15:56.000-0600

I'm pretty sure it hasn't been fixed in 1.6 at this point. It needs a design decision more than a patch.

http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html

Same discussion going on with bug 0011849.

By: Steve Murphy (murf) 2008-02-25 12:23:07.000-0600

OK, I'll be taking a look at this. I took a CDR vacation when I tried to look into 10927 and spent a good week on it, and still wasn't finished. It's been a few months, maybe it's time to get going again. That was work on the chan_zap, but yours appears to be chan_sip related.

My main difficulties with working on 1.4 CDR issues, is I can't possibly win. Any fix I make (or have made so far) might fix one issue, but usually have created other issues. But it won't hurt to look at this closely and see what exactly might be entailed, and maybe this is something where I can win-- a fix to a specific issue where no other affects are created. You never know.

So, tell me these things:

1. You say you are using a snom. Lucky day. I have a snom 360. I might be able to reproduce this sequence pretty closely. What about A and C? Are all phones involved SIP phones? are there any zap interfaces involved?

2. Exactly what buttons are pressed on the snom to do the transfer, and in what order. Hate to get picky here, but sometimes, if I choose an alternate path, I might fix a problem and not help your situation. It may not make any difference, but just to be safe.... You hit the conference button, I suppose, and B all three were talking until B hung suppose... correct?

By: Ross Beer (rossbeer) 2008-02-25 13:28:25.000-0600

This occurs when making any outgoing call, I use IAX and SIP to route calls.

To reproduce this, dial an external extension then place the call on hold. On the snom I normally press the illuminated key, or the 'r' hold key.

Dial an internal number and hangup to connect the two together. After the call ends there should be two CDR's. One for the outgoing call and another for the transfer, however at present the first(outgoing call) CDR stops counting.

This problem appears to be present on all devices. I have tried this with a Linksys ATA & another phone too.

By: Grey VoIP (greyvoip) 2008-02-26 06:57:59.000-0600

Isn't the best starting point here to realise that both ends of an Asterisk Call Bridge can change and there are always going to be instances where both ends could be billable?

Adding in support for a few specific scenarios while more welcome than nothing has the potential to create more problems than it solves as we have seen from attended transfer CDRs from 1.2 to 1.4.

It's not so much the development work here but getting the design agreed on. I still believe generating a CDR for each end of a call bridge is the way to go. It means there can never be a situation where a call leg is not recorded.

Thanks to you murf for looking into this.

By: Steve Murphy (murf) 2008-04-22 13:51:54

OK, for the moment, I'm taking this out of feedback; I'll be getting back into CDR's here again (again, again) soon.


By: Grey VoIP (greyvoip) 2008-04-28 08:53:13

murf if you need any input on the design I'd be happy to contribute. I have messed around with SIP CDRs on www.mysipswitch.com and the mechanism there is exactly what's required. Each call leg on a bridged generates a CDR and whenever a REFER is received and a call leg is terminated a CDR is generated rather then waiting until the end of the call.

By: Private Name (falves11) 2008-05-09 17:16:28

I support the resolution of this BUG, and Barak Obama. We need change.

By: Sherwood McGowan (rushowr) 2008-05-12 07:34:21

I look forward to the progress on this :)

By: Steve Murphy (murf) 2008-06-12 12:37:06

OK, guys, something concrete for you guys to test out!

Try checking out http://svn.digium.com/svn/asterisk/team/murf/CDRfix4

(for those of you that are interested in 1.4)

there is also a team/murf/CDRfix6 for trunk/1.6, btw. with the same set of changes.

I've cleaned up several xfer related snafus, regressions since 1.2, etc.
See if this cleans up the mess. Please report back on remaining problems. I've
got some complaints about not enough CDR's being generated, but most of the time related issues have also been solved (a small step up from 1.2).

The sequence looks a lot like 10927. I'll add that to the dependency list,
as these bugs seem a bit similar, and hopefully the fixes will be also!


By: Sherwood McGowan (rushowr) 2008-06-12 13:03:26

Murf, thanks, I'll compile and test as soon as I get back into town and can closely watch over the results at the office :)

By: Steve Murphy (murf) 2008-06-13 10:23:11

looking over the history of this bug, I've noticed that folks are pretty
loose about their event descriptions, and because of that, they get different
results. Maybe this shouldn't be; but at the moment, it is.

As an example, jpabuyer describes the xfer:
...
2.- X seconds later, B transfers the Call to C, C answers, and B gets out of the way.
...
and reports that:

After step 3, two CDRs should be created:
1.- one for A calling B, lasting X+Y seconds.
2.- one for B calling C, for Y seconds.

Greyvoip, otoh, reports on 1.2:

1.- one for A calling B, lasting X seconds (NOT X+Y seconds).
2.- one for B calling C, for Y seconds.

Now, I just did a test a day or two ago on 1.2, and saw two CDR's ending
at the same time, which would be jpabuyer's results.
Is Greyvoip wrong? Not necessarily! It all depends on which method you
use to perform:

2.- X seconds later, B transfers the Call to C, C answers, and B gets out of the way.

Let's see: there's the 'features' approach of using '#' to xfer a call.
And, (2.) could be accomplished by using either 'attended' or 'blind' xfer methods native to the phone itself. Between 'blind' and 'attended' xfers, you can get different CDR results. Using '#' vs phone xfer buttons could also, theoretically, give different CDR results.

Also, on 3-ways, different CDR's can result based on who hangs up first.

So, if we are going to discuss what CDR's **should** look like, we need to get really specific about the sequence of events. You shouldn't be saying "A tranfers B to C"... you should be saying "A hits the 'hold' button, puts
B on hold, dials C, talks, and then hits the Xfer button." or somesuch, so we can reproduce the exact sequence in question.

By: Juan Pablo Abuyeres (jpabuyer) 2008-06-13 12:17:11

Murf,

All of my descriptions were made pressing the transfer button (holding the call automatically) and performing an attended transfer. Blind transfers are prohibited in my dialplan for historical "CDR" reasons.

Now, seven months after I reported the wrong behavior, I don't have the polycoms or the server set up to make the tests :( .... I'll try to get them.

By: Steve Murphy (murf) 2008-06-13 13:34:23

Sorry about the long wait; fixing these bugs took a lot of time,
and I never really totally finished. Now, I'm trying to at least
save my previous efforts from being wasted.

NOTICE to ALL:

I've just svnmerged CDRfix/4/5/6; so now it's all DAHDI based.

Don't forget to check out:

http://svn.digium.com/svn/dahdi/linux/trunk
http://svn.digium.com/svn/dahdi/tools/trunk

build and install first the linux half
then build and install the tools half;

then run ./configure in the CDRfix* dir make menuselect; make; make install
there. Make sure the channel driver "chan_dahdi" is selected (if you use
any zap stuff), and built.

By: Grey VoIP (greyvoip) 2008-06-27 09:58:14

I have tested against CDRfix4 and attended transfer CDRs are now correct. Blind transfer CDRs still have the wrong duration on the first call leg.

By: Steve Murphy (murf) 2008-07-02 19:04:26

Greyvoip reported via email this past week, that indeed, the
blind xfer times are correct. yay!

By: Digium Subversion (svnbot) 2008-07-02 19:09:24

Repository: asterisk
Revision: 127663

U   branches/1.4/channels/chan_dahdi.c
U   branches/1.4/channels/chan_sip.c
U   branches/1.4/include/asterisk/cdr.h
U   branches/1.4/main/cdr.c
U   branches/1.4/main/channel.c
U   branches/1.4/main/pbx.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r127663 | murf | 2008-07-02 19:08:58 -0500 (Wed, 02 Jul 2008) | 30 lines

The CDRfix4/5/6 omnibus cdr fixes.

(closes issue ASTERISK-10481)
Reported by: murf
Tested by: murf, deeperror

(closes issue ASTERISK-12240)
Reported by: falves11
Tested by: murf, falves11


(closes issue ASTERISK-11309)
Reported by: greyvoip

As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.

Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.

(closes issue ASTERISK-10625)
Reported by: rossbeer
Tested by: greyvoip, murf



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=127663