[Home]

Summary:ASTERISK-12866: Wrong CDR is posted if call files or Manager API Originate is used
Reporter:Andrey Solovyev (corruptor)Labels:
Date Opened:2008-10-10 09:07:21Date Closed:2011-06-07 14:08:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

****** ADDITIONAL INFORMATION ******

This can be reproduced easily.
Just create a call file where asterisk calls you phone and then dials another phone. W'll see in Master.csv something like this:
"","55555","7757575","originate-test","55555","SIP/4028-08e28cf0","SIP/trunk-08a529a8","Dial","SIP/trunk/7757575","2008-10-10 17:51:46","2008-10-10 17:52:02","2008-10-10 17:52:07",21,5,"NO ANSWER","DOCUMENTATION","1223646706.125624",""

Billsec is 5, call has been answered but disposition is NO ANSWERED.
Comments:By: Leif Madsen (lmadsen) 2008-10-14 11:26:37

Howdy murf!

I've assigned this issue to you as you're the CDR god. Would you mind doing a quick check to determine if there is something you can do to move this issue forward?

Thanks!
By: Steve Murphy (murf) 2008-10-24 18:29:51

OK, I think I can repro this pretty quick, and soon I'll be looking into it.
By: David Woolley (davidw) 2008-10-30 13:48:53

This may or may not be the same underlying problem, but on 1.6.0, if you AMI Redirect an answered call and CDRReset(av) in the new extension, you get a proper CDR for the original Dial, output during the reset, but the CDR for an answered Dial, in the new extension, shows a good start, end and answer time, for the new segment, but shows a NO ANSWER status.

(Incidentally, I resorted to just using ResetCDR because ForkCDR didn't seem helpful and ResetCDR effectively forks the CDR, anyway.)
By: laura (laurav) 2008-11-14 08:02:06.000-0600

Hi! I am dealing with the same problem, but don't even get an answer time or billsec... I'm using 1.4.22. Have been testing with .call and manager api, getting the same behaviour.

Any idea why can that be?
By: Richard Hamnett (riksta) 2008-11-16 11:18:52.000-0600

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 incorrect as far as I can see. Duration (0) Billsec (0)

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:


The raw data from my MYSQL CDR logs are as follows:

Leg 1 (2nd CDR posted above)  Duration (12) Billsec (6)

1226855643.1950       SIP/1000   41002   clickToCall     SIP/1000-009ec748   SIP/1002-00a27b58   Dial   SIP/1002   2008-11-16 17:14:04   12   6   ANSWERED   3  

Leg 2 (1st CDR posted above)  Duration (13) Billsec (0)

1226855643.1950         s   ricks_room     SIP/1000-009ec748     ForkCDR     2008-11-16 17:14:03   13   0   NO ANSWER   3


I am running Asterisk 1.6-svn checked out yesterday.


By: Jan Gatzke (jan80) 2008-11-19 09:32:53.000-0600

Using Asterisk 1.4.21.2 and Asterisk addons 1.4.7 the field disposition is always set to "ANSWERED" if the call was initiated by the manager api via "ORIGINATE". The value billsec is equal to the time you wait for the other party to accept the call, I think.
By: Steve Murphy (murf) 2008-11-19 18:29:08.000-0600

Very interesting. Using the head version of 1.4 from SVN, I see no problems,
so I downloaded and ran with 1.4.22; and got no CDR at all. So, please,
see if this problem still exists in the latest svn version of 1.4. If it does,
I need more details to duplicate. I was using call files:

Channel: Dahdi/1
Callerid: d1
WaitTime: 15
Account: something
Context: extension
Extension: 102
Priority: 1

first, dahdi/1 rings, then as soon as I pick it up,
dahdi/2 rings. I pick up the second, wait a few sec. and
hang them both up.

I will try the Mangager interface before quitting for the night.
By: Jan Gatzke (jan80) 2008-11-20 00:42:16.000-0600

Which Version of Asterisk addons did you use? Perhaps it is a problem with the cdr module?
ich will try callfiles and upgrade to the latest svn version this weekend.
Let me know the rsults of your try with the manager interface.
By: laura (laurav) 2008-11-20 00:59:16.000-0600

I am using asterisk 1.4.21, with this version using the manager interface i get:
- billsec, answertime, endtime, ok
- answer disposition ok
- failed disposition for failed calls and no answered calls

The tests are done originating a call to a cellphone with the manager, using a voip provider.
By: Damian Adamski (sh0t) 2008-11-20 01:44:09.000-0600

murf: you say that on 1.4.22 you don't see CDR at all, could it have some relationship to:
0013797: forkcdr() doesn't fork when call disposition is ANSWERED
?
By: Andrey Solovyev (corruptor) 2008-11-20 04:21:31.000-0600

murf: I've tried the latest svn version of 1.4. CDRs seem ok there using my simple scenario. I haven't tested it with Manager API yet, but I hope it'll be ok.


By: Jan Gatzke (jan80) 2008-11-20 06:26:24.000-0600

I have compiled and installed the svn version this morning. I need to recompile the addons because I'm logging to mysql only. I think I can report this evening. Good to hear, that it "should" work. ;)
By: Steve Murphy (murf) 2008-11-20 10:09:17.000-0600

laurav => I posted a fix for not getting NOANSWER in the cdr, on bug 12694 yesterday, try it and I'll it solves that problem. I'll commit it when folks say it works.

sh0t: I'll be looking at *that* bug real soon (13797).

corruptor: good. I'll be checking that in the next few minutes myself...

Jan80: many thanks.
By: Richard Hamnett (riksta) 2008-11-20 10:39:46.000-0600

Will this be reflected within 1.6?

@murf Does the information I posted make sense... the billsec etc are also not populated correctly.
By: Steve Murphy (murf) 2008-11-20 11:17:24.000-0600

I **tried** the manager interface, but while the call files work fine,
something is amiss with my manager config, I guess. I don't want to waste
more time on it. I'll clear up the manager stuff later.
When I say:

Action: Originate
Channel: Dahdi/1
Exten: 102
Context: extension
Priority: 1
Timeout: 10
CallerID: d1a
Account: ManPlacedCall

Dahdi/1 gets called and then is immediately hung up. No explanation,
even if I turn up verbose to 40 and Debug to 20. I'll figure it out
later.

riksta: This bug is posted against 1.4; 1.6.0 is feature frozen, and not
all bug fixes get posted against it. Try 1.6.1, and see if it's having the same problem.
By: Jan Gatzke (jan80) 2008-11-20 11:26:25.000-0600

As promised I completet my tests - with success! Everything works like expected using Asterisk 1.4 SVN and Asterisk-addons 1.4.7. I hope the SVN snapshot is stable enough for my installation...
By: Steve Murphy (murf) 2008-11-21 13:22:16.000-0600

OK, then, I'm closing this, as some previous change for another bug, perhaps,
fixed this problem and it will be available in the next 1.4 release, and is fixed in the current 1.4 branch (svn).

If any of you feel that the problem still remains, feel free to re-open this bug, or file a new one.