[asterisk-bugs] [Asterisk 0013892]: After upgrading from 1.4.21.2 to 1.4.22 unaswered calls aren't correctly saved as CDR

Asterisk Bug Tracker noreply at bugs.digium.com
Sat Jan 31 02:32:21 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13892 
====================================================================== 
Reported By:                dzajro
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13892
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-11-12 17:11 CST
Last Modified:              2009-01-31 02:32 CST
====================================================================== 
Summary:                    After upgrading from 1.4.21.2 to 1.4.22 unaswered
calls aren't correctly saved as CDR
Description: 
Call from SIP extension into PSTN via Zap to non-existing number. PSTN is
correctly returning unassigne/unallocated number.

    -- Executing [s at macro-to-pstn-4:3] Dial("SIP/421232660232-0a2d22d8",
"Zap/g4/421230123123") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g4/421230123123
    -- Zap/1-1 is proceeding passing it to SIP/421232660232-0a2d22d8
    -- Channel 0/1, span 1 got hangup request, cause 1
    -- Hungup 'Zap/1-1'
  == Everyone is busy/congested at this time (1:0/0/1)

With 1.4.21.2 and "unanswered = no" in cdr.conf * produces following CDR:

src=421232660232
dst=421230123123
channel=SIP/421232660232-xxx
dstchannel=Zap/1-1
duration=0
billsec=0
disposition=NO ANSWER

1.4.21.2 with "unanswered = yes" produces the same PLUS (the are 2 CDR for
the same call, with the same call_date):

src=421232660232
dst=s
channel=Zap/1-1
dstchannel=
duration=0
billsec=0
disposition=NO ANSWER

With 1.4.22 and "unanswered = no" system produces NO CDR

With 1.4.22 and "unanswered = yes" system produces only ONE CDR:
src=
dst=s
channel=Zap/1-1
dstchannel=
duration=0
billsec=0
disposition=NO ANSWER

This CDR is unusable for billing/documentary purpose, there's NO SRC, no
real channel.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0011849 Missing CDR's for Transfers
related to          0013691 [patch] Unanswered Queue() calls don't ...
====================================================================== 

---------------------------------------------------------------------- 
 (0099177) dzajro (reporter) - 2009-01-31 02:32
 http://bugs.digium.com/view.php?id=13892#c99177 
---------------------------------------------------------------------- 
Okej, forgetting 13892.patch :)

Regarding callattempts=yes / unanswered = yes 

In 20090130-rel_cause_1_unanswered_yes.txt is call attempt to the same
number (again released by PSTN with rel. cause 0x01) with 'unanswered=yes'.
There is one CDR generated, but this CDR has no destination (instead
destination there is just 's').

Is there a chance this will be fixed?

Another question, do You think it's a good idea to run latest svn of 1.4
in production environment ? We have thousands of SIP and hundreds of iax2
peers. Stability is critical for us. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-31 02:32 dzajro         Note Added: 0099177                          
======================================================================




More information about the asterisk-bugs mailing list