[asterisk-bugs] [Asterisk 0010444]: billsec value changes depending on dialing method

[noreply at bugs.digium.com]

The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=10444 
====================================================================== 
Reported By:                krtorio
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   10444
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:            1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             08-13-2007 20:06 CDT
Last Modified:              08-22-2007 16:15 CDT
====================================================================== 
Summary:                    billsec value changes depending on dialing method
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


====================================================================== 

---------------------------------------------------------------------- 
 murf - 08-22-07 16: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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-22-07 16:15  murf           Status                   assigned => closed  
08-22-07 16:15  murf           Note Added: 0069282                          
======================================================================