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

Fri Feb 6 09:38:11 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-02-06 09:38 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0099603) murf (administrator) - 2009-02-06 09:38
 http://bugs.digium.com/view.php?id=13892#c99603 
---------------------------------------------------------------------- 
OK, I've been running my own tests... and I think I've tackled all the
probs I noticed. I've uploaded d7.dig1, and it replaces all other patches.

I tried these scenarios:

On the calling system, I have a dahdi fxs analog phone at dahdi/51,
and a t1 dual-span card fills dahdi/1 thru dahdi/48. dahdi/1 thru
dahdi/24 crossover cable connected to a single span t1 card in the
other system.
on the calling system I can dial these numbers:

301: will perform Dial(Dahdi/10/125|30|TtWwHhKkXx)  which will
     ring an extension at dahdi/25 on the called system. I looked
     at the results of both answering the call, and not answering
     the call.

302: will perform Dial(Dahdi/10/180|30|TtWwHhKkXx). This will
     attempt to call dahdi/80 on the called system, which doesn't exist,
     although the extension is in the dialplan.

303: Will perform Dial(Dahdi/13/1800|30|TtWwHhKkXx). The 1800
     extension is not in the called systems dialplan.

304: Will perform Dial(Dahdi/13/13|20|TtWwHhKkXx). the 13 exten
     in the called system's dialplan exists, and calls Answer(), and
ResetCDR()
     twice, and hits the end of the priorities.

305: Will perform Dial(Dahdi/14/14|20|TtWwHhKkXx). the 14 exten
     in the called system's dialplan exists, and calls ResetCDR()
     twice, and hits the end of the priorities. (no Answer() call).

306: Will perform Dial(Dahdi/14|20|TtWwHhKkXx) Since  no target exten
     is specified at all, the "s" exten is used on the called system.
     At least, this week it does. Previously, 14 would have been called.
     This was a bug that was fixed at the beginning of the week.

In all cases, the results look OK now. Chan_dahdi wasn't paying attention
to the results of some of the most common hangup causes, which would tend
to show "NO ANSWER" instead of "FAILED". I removed the disposition as a 
criteria for publishing a CDR. I made the dahdi channel driver set the 
dstchannel field to <none> for incoming calls, so all incoming are logged
now (even taking an analog phone offhook and setting it back on hook will
generate a CDR (Let me know if this is irritating, I might be able to 
make another config option to get rid of it (or something)).

By forcing chan_dahdi to set "needcongestion", I can push the FAILED
disposition back to the calling system, so its CDR will report a FAILED
disposition also.

Try this patch out on your test system, and I'm hoping you should find it
very satisfactory! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-06 09:38 murf           Note Added: 0099603                          
======================================================================