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

[noreply at bugs.diguim.com]

email_notification_title_for_action_bugnote_submitted 
====================================================================== 
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 
====================================================================== 
Date Submitted:             06-26-2007 17:49 CDT
Last Modified:              06-29-2007 08:04 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'

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

---------------------------------------------------------------------- 
 cstadlmann - 06-29-07 08:04  
---------------------------------------------------------------------- 
samdell, I'm also no c guru at all, so I don't even try to dig into the
source. Anyway, extracting the values from the lastdata field could cause
extra trouble, so in my case the workaround with storing the inital
${EXTEN} seems to be the most riskless way.

BTW, I'm sure you found out that some zombie entries are stored into cdr
table, at least in svn-branch version. These zombie entries have nearly the
same data but no 'dstchannel', 'lastapp', 'lastdata' or 'duration'. So in
my hangup-script (which is PHP AGI) I call the following sql query:


// Now check if a zombie entry is in the table
$tuniqueid = explode(".", $agi->request["agi_uniqueid"]);
$query = "DELETE FROM cdr WHERE uniqueid LIKE '".$tuniqueid[0].".%' AND
lastapp='';";
$result = mysql_query($query) or die_with_message("Update for Zombie
failed: ".mysql_error());


Maybe this is useful for you in housekeeping the database, because you
really don't need these zombies... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-29-07 08:04  cstadlmann     Note Added: 0065902                          
======================================================================