[Home]

Summary:ASTERISK-10076: billsec value changes depending on dialing method
Reporter:KR Torio (krtorio)Labels:
Date Opened:2007-08-13 20:06:07Date Closed:2007-08-22 16:15:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Billsec value when dialing manually is accurate.

However, if we use the manager action Originate, it gives a different billsec value.

I think this can be easily reproducible.

Here's the sample dialplan:

[sample]
exten => _6XX,1,Dial(SIP/${EXTEN},60,t)

And here's the sample manager input:

Action: Originate
Channel: SIP/601
Exten: 602
Context: sample
Priority: 1

Comments:By: James Golovich (jamesgolovich) 2007-08-14 00:46:11

I tried to duplicate this in my setup but couldn't.  A manual call to a remote extension that played a soundfile resulted with billsec 19.  Using manager originate to generate a call to the same extension also resulted with a billsec of 19.  I did this using 1.4.10 and I don't believe anything has changed relating to manager originate since 1.4.9.
By: KR Torio (krtorio) 2007-08-14 02:48:35

I used 1.4.10.1 this time. There is a difference when I tested it.

I allowed it to ring approx. 10 seconds before answering the destination channel, and let the call run for approx. 20 seconds.

Manual dialing produced a billsec of 21s
Dialing via manager action Originate produced 32s billsec, a 10s difference.

It seems when the source answers an Originate action it automatically sets the call status to 'ANSWERED', even if the destination channel hasn't connected.


By: Steve Murphy (murf) 2007-08-22 16:15:15

Sorry this has taken me so long to spend some attention time with.

I would not be surprised at all if your diagnosis, krtorio, is completely correct.
That the answer time might be set when you answer the Originate, as opposed to when the party at the other end answers the originate...

One source of the problem is the code in cdr_answer():

               if (cdr->disposition < AST_CDR_ANSWERED)
                       cdr->disposition = AST_CDR_ANSWERED;
               if (ast_tvzero(cdr->answer))
                       cdr->answer = ast_tvnow();

In other words, if the time and/or the disposition is already set, it will not change them.

If I were to remove the conditions, and just let the code set it, neither you, nor I can predict the profound changes in behavior that would result, and the countless headaches that this would bring to folks with existing implementations! But I can easily imagine the complaints that would stream in, and the bug reports that would result!

So, for 1.4, I am following a simple rule of thumb with respect to CDR bugs: If the information is FALSE, I'll fix it.

But because there are two answer times involved here, and one is right and represented, and nobody ever documented which one is correct, and which is false, and folks have built implementations on CDR's depending on its behavior, I dare not change the code. Sorry.


I took some time and checked this scenario in my CDRfix5 branch, to see if it would do a better job, and it looks like it. So, hopefully, 1.6 will be a step forward in this respect.