[asterisk-bugs] [Asterisk 0013251]: [branch] endbeforehexten=yes is useless now

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13251 
====================================================================== 
Reported By:                sergee
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13251
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 135435 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-08-06 15:10 CDT
Last Modified:              2008-09-11 23:57 CDT
====================================================================== 
Summary:                    [branch] endbeforehexten=yes is useless now
Description: 
1. Part of code:

  if (c->cdr && ast_opt_end_cdr_before_h_exten)
	                         ast_cdr_end(c->cdr);

- missing (this is how it was
http://svn.digium.com/view/asterisk/trunk/pbx.c?r1=12896&r2=12895&pathrev=12896)

2. I have very simple scenario SIP/A calls SIP/B they talk 30 seconds,
then call is finished. Even after i call ast_cdr_end(chan->cdr) - manually
from my app,  these fields aren't initialized:

chan->cdr->billsec == 0,
chan->cdr->duration == 0,
chan->cdr->answer.tv_sec == 0,
chan->cdr->end.tv_sec == 0

3. as far as i understand, CDRs are posted now as soon as channels are
unbridged. This behavior breaks billings which make calculations inside 'h'
extensions. It would be nice to post CDRs after no more apps are left in
the 'h' extension or to have an application in the DialPlan, something like
CDRPost().

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013289 Changes to NoCDR() prevent access to ce...
====================================================================== 

---------------------------------------------------------------------- 
 (0092397) murf (administrator) - 2008-09-11 23:57
 http://bugs.digium.com/view.php?id=13251#c92397 
---------------------------------------------------------------------- 
Hmmm. I did something wrong in the commit msg, I guess, so I'll close this
bug 'by hand'.

I've applied the changes from the branches advertised to 1.4 and trunk and
1.6.x
via svn revisions 142675 thru 142678.

Here is the verbage that went with the commit:

(closes issue http://bugs.digium.com/view.php?id=13289)
Reported by: TechnoPirate

(closes issue http://bugs.digium.com/view.php?id=13251)
Reported by: sergee
Tested by: sergee, murf, chris-mac, andrew, KNK


This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from 
the ground up!

This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.

Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.

While I dearly hope that this patch overcomes all problems, and 
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-11 23:57 murf           Note Added: 0092397                          
======================================================================