[asterisk-bugs] [Asterisk 0017569]: [patch] cdr->src variable is not set anymore in destination channels

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Jun 30 17:51:55 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17569 
====================================================================== 
Reported By:                tbelder
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17569
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.33 
JIRA:                       SWP-1798 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-06-30 08:07 CDT
Last Modified:              2010-06-30 17:51 CDT
====================================================================== 
Summary:                    [patch] cdr->src variable is not set anymore in
destination channels
Description: 
This bug is introduced by a part in revision 127663 (version 1.4.22).

You can see it by using the cli command: 'show channel SIP/bla-bla' or by
requesting the value of ${CDR(src)} after connect using the 'G' option in
Dial ().


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010927 Zap assisted xfer via hookflash yield C...
====================================================================== 

---------------------------------------------------------------------- 
 (0124119) murf (manager) - 2010-06-30 17:51
 https://issues.asterisk.org/view.php?id=17569#c124119 
---------------------------------------------------------------------- 
Hmmm. It's been a quite a while, and I just read the log entry for that
version, and it's not one of my ultra-verbose-explain-every-change entries.
It was made almost exactly two years ago.

I have some hazy memory of situations where, if I set the CDR src val
where it used to be set, it would get reset over and over in other
situations, and by then it would be quite wrong. I thought I had it covered
by setting the val at a different point in the code, but alas, perhaps
later fixes got rid of *that*.. but hey, if the user has a fix, I'd advise
the standard set of tests:

1. A calls B, they tallk, one/both hang(s) up. If it makes any difference
to a CDR, then both ways.

2. A calls B, A transfers B to C. (blind transfer via feature)

3. A calls B, B transfers A to C.(blind transfer via feature)

and variants of 2 and 3 where dahdi hookflash is used to do a transfer
and then sip phone buttons to do xfers (the xfer is done in the channel
driver); make sure to throw in as many chanel drivers as allow xfers.

4. Call file connects A to B.

5. All the variants of Assisted transfers.

6. All the variants of 3-ways during Assisted transfers, with various
parties hanging up first. (this results in different CDRs!)

7 Caller dials in, gets connected to Application.

8. Caller dials in, gets connected to AGI

9. All the parking scenarios. (A calls B, A parks B, picks back up; B
parks A, picks back up; Same sets, but C picks up instead; No-one picks up,
etc)

10. SIP phone forwarding.

And who knows what other common, everyday scenarios are involved....

Check each CDR carefully, and determine whether the mod makes things
better, or worse.

If everything says the change is for the better, then commit it!

If not, maybe you have to settle in favor of the "most common cases",
whatever that might mean.

And now, here's my real advise: CDR's are fundamentally, seriously flawed,
complicated, and undocumented. (OK, seriously under-documented, but due to
the complexity, it might be doing people a favor). Every moment you
re-arrange the deck furniture is a waste of time. Instead, pull out the CEL
stuff, and determine how you will extract what you need from the CEL event
streams. Do not store the CDR related data on channels. The only successful
billing systems that can handle transfers,  keep track of events outside
the channels, if not outside asterisk entirely. I've even heard of AMI
being used from another process. Whatever. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-30 17:51 murf           Note Added: 0124119                          
======================================================================




More information about the asterisk-bugs mailing list