[Home]

Summary:ASTERISK-12273: SIP Channel Reports Wrong CDR
Reporter:Visu Kaka (visu)Labels:
Date Opened:2008-06-28 08:42:52Date Closed:2011-06-07 14:02:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:SIP Channel always reports wrong CDR in following case

We have following setup where Internal Clients connects to external world using Asterisk

[Internal Clients] -------- [Asterisk] --------- [External World]

When internal clients dial external number, Asterisk dials outside number and everything works great. However, Asterisk always reports CDR 8 even if caller party drops the call before called party picks up. The call time reported is duration of calling party

If called party does not pickup the phone, CDR is also 8 but this time duration is 0





Comments:By: Visu Kaka (visu) 2008-06-28 08:47:06

If call completes, it also report CDR 8 with duration. So now, there is no way to know if call was completed or caller dropped it before called party picked up
By: Visu Kaka (visu) 2008-06-28 09:23:03

cdr->disposition is AST_CDR_ANSWERED in all cases
By: Steve Murphy (murf) 2008-08-06 09:49:13

I am going to need more information to reproduce and fix this bug, whatever
it is. I don't understand what "CDR 8" is, where it occurs, or why.

So, show me example output; perhaps the output if cdr-custom is used, of a CDR that is bad, and the Dial command that you used which generated the bad CDR,
and the devices (all SIP?) that were involved in making the call with the bad CDR.

By: Steve Murphy (murf) 2008-09-10 20:24:00

Pardon me. I should have realized that CDR 8 meant the disposition of ANSWERED.

This bug has been in feedback for a long time, and I think that it's been fixed
in the meantime. I just ran a quick test, between two sip phones via asterisk, and NO-ANSWER and ANSWER and BUSY were all recorded in CDR's.

I'm going to close this bug, but if you still see a problem, re-open this issue and we'll get to the bottom of things.