[asterisk-bugs] [Asterisk 0013665]: Wrong CDR is posted if call files or Manager API Originate is used

Asterisk Bug Tracker noreply at bugs.digium.com
Sun Nov 16 11:18:53 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13665 
====================================================================== 
Reported By:                corruptor
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13665
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-10 09:07 CDT
Last Modified:              2008-11-16 11:18 CST
====================================================================== 
Summary:                    Wrong CDR is posted if call files or Manager API
Originate is used
Description: 
This has changed between 1.4.21 and 1.4.22.
If we use call files and call has been answered asterisk sets DIALSTATUS
variable to ANSWER but disposition field of the CDR is NO ANSWER.
====================================================================== 

---------------------------------------------------------------------- 
 (0094934) riksta (reporter) - 2008-11-16 11:18
 http://bugs.digium.com/view.php?id=13665#c94934 
---------------------------------------------------------------------- 
Below is a log of what happens when you ForkCDR() with no arguments, to try
to get separate CDRs for both legs of a call.

The first CDR listed below, was the second leg and has has the duration
(13) correct but no billsec (0) and disposition of NO_ANSWER (it was
answered)

The second CDR listed below was the first leg, which has all details
correct as far as I can see. Duration (12) Billsec (6)

2008-11-16 17:11:44,012
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv: Event:
Cdr
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Privilege: cdr,all
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AccountCode: 
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Source: 
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Destination: s
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
DestinationContext: ricks_room
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
CallerID: 
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Channel: SIP/1000-009ec748
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
DestinationChannel: 
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
LastApplication: ForkCDR
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
LastData: 
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
StartTime: 2008-11-16 17:14:03
2008-11-16 17:11:44,013
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AnswerTime: 
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
EndTime: 2008-11-16 17:14:16
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Duration: 13
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
BillableSeconds: 0
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Disposition: NO ANSWER
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AMAFlags: DOCUMENTATION
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
UniqueID: 1226855643.1950
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
UserField: 
2008-11-16 17:11:44,014
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv: 
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerConnectionImpl DEBUG - Dispatching
event:
org.asteriskjava.manager.event.CdrEvent[dateReceived=Sun Nov 16 17:11:44
GMT 2008,privilege='cdr,all',starttime='2008-11-16
17:14:03',destinationchannel='null',amaflags='DOCUMENTATION',lastapplication='ForkCDR',userfield='null',callerid='null',starttimeasdate='Sun
Nov 16 17:14:03 GMT 2008',disposition='NO
ANSWER',billableseconds='0',timestamp='null',server='null',channel='SIP/1000-009ec748',accountcode='null',destination='s',endtimeasdate='Sun
Nov 16 17:14:16 GMT
2008',answertime='null',answertimeasdate='null',src='null',endtime='2008-11-16
17:14:16',lastdata='null',uniqueid='1226855643.1950',duration='13',destinationcontext='ricks_room',systemHashcode=4872882]
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv: Event:
Cdr
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Privilege: cdr,all
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AccountCode: 
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Source: SIP/1000
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Destination: 41002
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
DestinationContext: clickToCall
2008-11-16 17:11:44,016
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
CallerID: "Encompass" <SIP/1000>
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Channel: SIP/1000-009ec748
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
DestinationChannel: SIP/1002-00a27b58
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
LastApplication: Dial
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
LastData: SIP/1002
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
StartTime: 2008-11-16 17:14:16
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AnswerTime: 
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
EndTime: 2008-11-16 17:14:16
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Duration: 0
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
BillableSeconds: 0
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
Disposition: NO ANSWER
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
AMAFlags: DOCUMENTATION
2008-11-16 17:11:44,017
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
UniqueID: 1226855643.1950
2008-11-16 17:11:44,018
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv:
UserField: 
2008-11-16 17:11:44,018
org.asteriskjava.manager.internal.ManagerReaderImpl DEBUG - <--Recv: 


So it is certainly correct that the second leg of the call is being set as
NO_ANSWER and no billsec.

I am running Asterisk 1.6-svn checked out yesterday. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-16 11:18 riksta         Note Added: 0094934                          
======================================================================




More information about the asterisk-bugs mailing list