<br><br><div class="gmail_quote">On Wed, Dec 1, 2010 at 5:56 AM, Nikhil <span dir="ltr"><<a href="mailto:d.nikhil@cem-solutions.net">d.nikhil@cem-solutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
anyone have a idea on this..<br>
<br>
On 11/22/2010 10:50 AM, Nikhil wrote:<br>
> Hi everyone,<br>
> I am facing lots for problem with CDRs in 1.6 and above<br>
> versions,its shows wrong records when I do transfer(caller side and<br>
> calee side),callforward,call parking.Is the present CDRs in 1.6 is<br>
> enough for Complete billing.?What I need to do to make it<br>
> proper.Please help me on this.<br>
><br>
> Thanks<br>
> Nikhil<br></blockquote><div><br>Nikhil--<br><br>Yes, there is a problem with CDR's in asterisk. There is a bug filed <br>against the problem, but no practical solution for it.<br><br>The cure: use the CEL interface instead, and generate your own <br>
CDR's (or whatever else you could bill from [it doesn't *have* to be<br>CDRs])<br><br>The cause of the problem: An interesting combination of 3 operations <br>being performed on channels, namely masquerading, and <br>
forming local channels; add to that the hardwired 'roles' that channels<br>are given (channel, and peer), and the final knockout: CDRs are stored<br>on channels.<br><br>The above 3 operations affect CDR's because parking and transfers<br>
can change the role that a channel plays (chan to peer or vice-versa); <br>Transfers and parking involve the masquerading, and sometimes local channels--<br>both these operations involve duplicating a channel. CDR's are meant for the<br>
channel playing the "channel" role, and CDRs on channels playing the "peer"<br>role are tossed out.<br><br>Transfers turn the above into a complex mush in which the results vary depending<br>on who transfers who, who is calling, and who is called, etc. Because the CDR's<br>
are stored on the channels themselves, they pass thru many filters and operations<br>that vary based on the roles they play and the operations performed, which can change<br>in subtle ways from release to release, from one bugfix to another, even.<br>
<br>So, the best way to get around all this is to get the CDRs out of the channels, <br>And to do that, you either use CEL, or you build your own event tracking mechanism, using<br>whatever means available (I've seen folks use the manager event reports with their<br>
own logic in perl, or php, or whatever to do the parsing and storage). Then, you either<br>turn the events into your own billing mechanism, or you generate CDR's to fit into your<br>currently existing billing mechanism. Doing this right<br>
and making it dependable is not an overnight sort of thing.<br><br>I proposed a CDR generating backend for CEL (which I haven't completed yet).<br>I even started it, but got layed off before I could finish it. I've generated a spec<br>
for CEL->CDR generation, involving something I call "simple CDRs".This doc has<br>been evolving with time, and needs to be updated. I previously described "complex"<br>CDR's in the spec that provided more fine-grained event logging in CDR format, but I've convinced<br>
myself that the complex stuff can also be done via the "simple" method, and so I'm<br>about half way thru the spec, expunging the "complex" stuff. All my examples have to be <br>changed -- If you are interested in looking at my spec, you can:<br>
<br>svn co <a href="http://svn.digium.com/svn/asterisk/team/murf/RFCs">http://svn.digium.com/svn/asterisk/team/murf/RFCs</a><br><br>and look at the pdf there in that directory.<br><br>murf<br><br><br><br></div></div><div id="WISESTAMP_SIG_2251">
<span style="font-size: 13.3px; font-family: Verdana,Arial,Helvetica,sans-serif;"><div style="margin: 0pt 0pt 8px;"><p style="margin: 0pt;"><span style="font-family: comic sans ms,sans-serif; font-size: medium;">Steve Murphy</span></p>
<p style="margin: 0pt;"><span style="font-family: comic sans ms,sans-serif; font-size: medium;">ParseTree Corp.<br></span></p><br></div></span></div>