<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Thanks,Now I understand the problem,Now I am trying to change CDR to
    fix these issues.<br>
    <br>
    Thanks<br>
    Nikhil<br>
    <br>
    On 12/01/2010 08:31 PM, Steve Murphy wrote:
    <blockquote
      cite="mid:AANLkTikhu=Vv1yxkQ7MT1ZJAAnCvGAAXm+0jVKMbuwAK@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Wed, Dec 1, 2010 at 5:56 AM, Nikhil <span
          dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:d.nikhil@cem-solutions.net">d.nikhil@cem-solutions.net</a>&gt;</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>
          &gt; Hi everyone,<br>
          &gt; &nbsp; &nbsp; I am facing lots for problem with CDRs in 1.6 and
          above<br>
          &gt; versions,its shows wrong records when I do
          transfer(caller side and<br>
          &gt; calee side),callforward,call parking.Is the present CDRs
          in 1.6 is<br>
          &gt; enough for Complete billing.?What I need to do to make it<br>
          &gt; proper.Please help me on this.<br>
          &gt;<br>
          &gt; Thanks<br>
          &gt; 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.&nbsp; 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.&nbsp; 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-&gt;CDR generation, involving something I call "simple
          CDRs".This doc has<br>
          been evolving with time, and needs to be updated. I&nbsp;
          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 moz-do-not-send="true"
            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>
    </blockquote>
    <br>
  </body>
</html>