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

Sat Jan 31 12:55:22 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 12:55 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0099189) murf (administrator) - 2009-01-31 12:55
 http://bugs.digium.com/view.php?id=13892#c99189 
---------------------------------------------------------------------- 
The "s" is because of the macro call; hmmmm. What should it be?
421232000000?

As to the question about 1.4 svn in a production environment...

That's a question only YOU can answer! If you are not doing it already,
you should be doing this:

1. You should have a at least one other machine identical to the one you
are using for production. It is your "test", or "staging" machine.

2. On the test machine, you should have some way to test candidates for
upgrades-- either via simulating normal traffic, or a way to shunt a small
percentage of your normal traffic thru it. Simulation is best, because it
won't disturb any customers if you encounter total disaster. Tools like
sipp could help here. To simulate T1 traffic, you may need to grab a third
machine, put a t1 card in it, and use it simulate the pstn, making and
getting calls to/from your test machine.

3. You need to keep tight track of your config files. CVS, SVN, or even
git would be sufficient for this. You commit every change you make, and
record in the logs what you were doing and why.

4. You ONLY change what you have on the production machine after it has
been tested to your satisfaction. You would probably copy all config files,
etc, as a unit, and log that.

5. "If it isn't broken, don't fix it", is what the engineers always say;
it's advice to the wise. Don't upgrade your production boxes unless there
is a compelling reason to do so. Never do it just "because". Never do it
because "newer versions are available". For instance, you could do it for
security fixes, which is a pretty good reason, but if, and only if, your
system is actually subject to the security flaw being patched. You might
try staging the fix applied to the production systems-- not upgrading to
the version that the fix was applied to, but taking the raw security patch,
and applying it to the version of the source your production system is
running. "Change only one variable at a time", is a scientific way of
determining where a problem occurs.

At some point, the "cost" of backporting such fixes will be greater than
the cost of upgrading to the latest SVN release; then you've got a good
reason to go with the latest version. (after testing, of course!)

So, I ask you: is 1.4 SVN  OK for production? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-31 12:55 murf           Note Added: 0099189                          
======================================================================