Grey Man wrote: > ----- Original Message ---- > >> From: Steve Murphy <[EMAIL PROTECTED]> >> To: Asterisk Users Mailing List - Non-Commercial Discussion >> <asterisk-users@lists.digium.com> >> Sent: Thursday, 27 December, 2007 5:44:01 PM >> Subject: Re: [asterisk-users] CDR >> >> Greyman-- >> >> No real new functionality in 1.4, except a cdr.conf option that >> lets >> >> > you > >> control whether you see one-channel cdrs. >> >> I haven't been working on CDR's the last few months in favor of other >> projects that seem a little more urgent. Plus, I have some folks urging >> me NOT to proceed until some architectural issues are discussed, which >> might be wise. I have been working on one bug where I did make some >> substantive changes to how the CDR's are generated, but it is almost >> certain that these changes will only show up in trunk. >> >> I've reached the limit of what I can do in 1.4; it is simply impossible >> to do anything with CDR's in 1.4 without tearing the very fabric >> of >> >> > time > >> and space, and just plain getting everybody upset... at least, >> those >> >> > who > >> were not erased from existence by the tear... on a more serious note, >> the changes are intrusive enough, the behavior changes big enough, that >> they really don't qualify to be applied to a current release. >> >> It's a huge job! My past work was just in the ZAP channel driver code, >> and because it's so asynch, and all split up into different code, it's >> really tough to get the right pieces in the right places at the right >> time in the right way. >> >> What this all says is that I'm most likely NOT doing it the right way. >> And what worries me most is that there might not be any "right" >> way. >> >> > But > >> I'm still new to this, and will get back around to it hopefully fairly >> soon. >> >> murf >> > > Hi Steve, > > Thanks for the update. > > I agree it's complicated and looks like it does require a look at the design > of Asterisk and where CDR's are generated. As you've already documented and > lots of us have discovered generating a single CDR for each bridged call is > not suitable when CDR's are used for billing and blind and attended transfers > are taking place. > > For any SIP (can't speak for other channels but most likely the same) service > providers running Asterisk that are not aware of this problem you will not be > getting correct CDR's on blind and attended transfers. Also depending on your > dial plan users may be able to send a 302 Redirect response (301 or 302) to > an incoming call and get a free outgoing call. This has the potential to cost > you money which is very dangerous if any of your users cotton on to it. The > easiest way to check your susceptibility is to do call an expensive > destination, blind transfer to a free destination and then check the CDRs and > pay close attention to the call durations of each CDR. > > I'll go back to trying to find a way to detect and block dangerous REFER > requests at the SIP Proxy before they get to Asterisk. > > Regards, > > Aaron > Wondering out loud if as the whole CDR defect is looked at, that the issue of blind vs attended transfers should be examined as well. In the rest of the telephony world, there is no difference. It is simply a transfer. An attended ( or announced ) transfer can become a blind transfer simply by the transferrer hanging up. How the original design became what it is is a puzzle, unless the original architect was not too familiar with the time proven practice in PBX systems for many years. Having to differentiate between types of transfer before initiating the transfer is not very user friendly. Once that is corrected will it make fixing the CDR defect easier? In other systems with SMDR/SMDI/CDR the report contains information and timing for the total call, as mostly no one cares who answered the call and then transferred, it is total time that is important for billing.
John Novack -- Dog is my co-pilot _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
