[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:                     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 14:16 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0099190) murf (administrator) - 2009-01-31 14:16
 http://bugs.digium.com/view.php?id=13892#c99190 
---------------------------------------------------------------------- 
To answer my own question about the "s" exten, I took note that the dst
field in the CDR is usually set in this manner: S_OR(c->macroexten,
c->exten), which means, that when you are calling a macro, the s exten
won't show up in the dst field. 

So, I found that in app_dial, I was setting the dst field for peers from
just the c->exten field. So I fixed that to do it like it's done everywhere
else.

I have high hopes that it will solve the problem. Try the d3.dig1 patch I
attached. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-31 14:16 murf           Note Added: 0099190                          
======================================================================