[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]

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:                     feedback
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-30 00:14 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0099110) murf (administrator) - 2009-01-30 00:14
 http://bugs.digium.com/view.php?id=13892#c99110 
---------------------------------------------------------------------- 
OK, I reproduced the "missing CDR effect" when you try to call a device
that doesn't exist: you get no CDR at all. And I think I have it. 

Please download and apply the "d1.dig1" patch.

It mods chan_dahdi to return a more accurate cause when a channel can't be
matched. It forces a CDR to be output when such a failure occurs, whether
you say "unanswered=yes" or not.

Now, when you do a dial(dahdi/1/888888) and dahdi/1 is a PRI, the guy at
the other end will most likely choke on the 888888, but all you'll be able
to say about it is probably "NO ANSWER", because the remote systems hangup
cause doesn't seem to be returned-- which may be a bug; at least I've
covered the problems with CDRs and dial.

Please test ASAP. I'd like to get this into the next release. I'd love to
get your feedback on this, but really, I need to get this in today... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-30 00:14 murf           Note Added: 0099110                          
======================================================================