[Asterisk-bugs] [Asterisk 0010067]: CDR dst and dcontext field wrong information depending if caller or callee hangs up first

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10067 
====================================================================== 
Reported By:                samdell3
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   10067
Category:                   Core/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             06-26-2007 17:49 CDT
Last Modified:              07-05-2007 17:35 CDT
====================================================================== 
Summary:                    CDR dst and dcontext field wrong information
depending if caller or callee hangs up first
Description: 
We are in the process of bench testing 1.4.5 (gotta love that T.38!)
This bug can be replicated 100% of the time.
I classify this as major as many calls cannot be billed.

All test calls are SIP to SIP. Caller = 6500011,  Callee = 6500012

If the CALLER hangs up first: 
CDR record logs dst and dcontext field from within the macro. Weird. EG
dst field results in 's' and dcontext results in 'macro-call-sip-nap'

If the CALLEE hangs up first:
CDR is recorded OK
dst field results in '66500012' and dcontext results in 'default'

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

---------------------------------------------------------------------- 
 murf - 07-05-07 17:35  
---------------------------------------------------------------------- 
OK, I have just revised my opinion.

After some discussions with tilghman (corydon76), I have changed my
attitude about this situation.

First of all, in both situations, the CDRs are indeed telling the truth.
If you call a macro in the dial, it gets executed on the peer side (IIRC).
"s" and macro name for dst and dcontext are truthful. 

While you may not be particurly interested in what I'm about to say,
because it looks like you've found a work-around, I'm going to say it for
the sake of all who bump into this sort of problem...

First of all, the CDR system as it stands has some pretty big
deficiencies. I've patched and tweeked, but it has to really be changed
fundamentally to get it to handle transfers and other situations correctly.
I'm working on that now. Some big shifts in strategy will occur in 1.6 (I
hope to get in before we release). And perhaps in 1.8, I'll be able to
intro CEL.

My determination is to settle on having CDR's tell the unwanted, maybe
different truth than it did in previous releases. Working around it using
the accountcode or userfields is the suggested thing to do right now.
Corydon76 has introduced the adaptive_odbc stuff, and I think in trunk,
that will be the advised way to handle situations like this. Shove ${EXTEN}
(or whatever you want) into a CDR variable or userfield, or accountcode, or
whatever, and then using mapping capabilities on the backend, map it into
the field you are interested in seeing.

The main drawback to just allowing folks to tweak CDR field, is that it
still will not solve all the problems. Any of the "non-editable' fields you
might set, might mysteriously get changed by the underlying CDR mechanisms
in Asterisk. You might waste a lot of time twiddling and tweaking and
experimenting, only to find that you can't solve the problem that way! So,
doing mappings at the backend is the real, true answer. We've had some
discussion on this on asterisk-dev; look for postings from murf (me)
there.

If you are using mysql, then you might consider, if things need tweaking,
moving over to an ODBC interface, and moving up to cdr_adaptive_odbc.

So, I will close this bug, for the time being. Any who have violent
objections to this strategy, please reopen and feel free to share your most
poignant feelings on the subject. If nothing else, we can always serve as a
shoulder to cry on! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-05-07 17:35  murf           Note Added: 0066561                          
======================================================================