[asterisk-bugs] [Asterisk 0014660]: [patch] Lost info in CDR when transfering call via AMI's Redirect

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Aug 13 14:36:30 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14660 
====================================================================== 
Reported By:                caspy
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14660
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0.6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-13 09:11 CDT
Last Modified:              2009-08-13 14:36 CDT
====================================================================== 
Summary:                    [patch] Lost info in CDR when transfering call via
AMI's Redirect
Description: 
- SIP/1344 call SIP/1340
- SIP/1340 answers, and they are speaking
- man-in-a-middle do a Redirect of SIP/1344 leg of this call to SIP/1341
- SIP/1341 answers, and 1344 speaks with 1341 successfuly.

The probles is in CDR.
For the first call (1344 to 1340) asterisk lost just all important
fields:


"","","s","fromoffice","","SIP/1340-08c6dce8","","","","2009-03-13
16:37:44","2009-03-13 16:37:47","2009-03-13
16:37:54",10,7,"ANSWERED","DOCUMENTATION","1236951464.550476",""

"","1344","1341","fromoffice","""Akzhan Test""
<1344>","SIP/1344-b4b3e758","SIP/1341-b51deec0","Dial","SIP/1341,60,twTWL(5400000)","2009-03-13
16:37:44","2009-03-13 16:38:00","2009-03-13
16:38:05",21,5,"ANSWERED","DOCUMENTATION","1236951464.550474",""


Also, mention that uniqueid is very strange: first part (time) is the
same, but second is decreesed for two. Why?
====================================================================== 

---------------------------------------------------------------------- 
 (0109014) mnicholson (administrator) - 2009-08-13 14:36
 https://issues.asterisk.org/view.php?id=14660#c109014 
---------------------------------------------------------------------- 
That is a tricky problem to solve.  The answer time value is reset during
the redirect.  I actually think the behavior is correct the way it is
currently implemented in the patch.  If there is a 'Dial' after the
redirect, that will populate answer time and generate a proper value for
billsec.  If there is no dial, answer time will not be filled in unless the
'Answer' application is called in the dialplan.  If answer time was
populated during the redirect and then 'dial' was called, billsec would be
incorrect because answer time would record when the redirect occurred, not
when the new call was actually answered.

Both of these situations cannot be fixed within the current CDR framework.
 CEL should not have this issue. It should also be possible to work around
some of these limitations within your billing software.  We need to
determine which one of these two behaviors is the optimal one and then
document it and leave it at that.  Personally, I think the proper behavior
is to not set answer time in the redirect to allow for 'Dial' to set the
answer time later on. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-13 14:36 mnicholson     Note Added: 0109014                          
======================================================================




More information about the asterisk-bugs mailing list