Is existing CDR in Asterisk is enough for complete billing

Home » Asterisk Users » Is existing CDR in Asterisk is enough for complete billing
Asterisk Users 8 Comments

Hi everyone,
I am facing lots for problem with CDRs in 1.6 and above
versions,its shows wrong records when I do transfer(caller side and
calee side),callforward,call parking.Is the present CDRs in 1.6 is
enough for Complete billing.?What I need to do to make it proper.Please
help me on this.

Thanks
Nikhil

8 thoughts on - Is existing CDR in Asterisk is enough for complete billing

  • I can tell you that back in 2005 I set up a complete
    residential/business VOIP ITSP that was using just the Asterisk CDRs
    to track billing. As long as you setup your billing, I see now reason
    wh

  • Nikhil–

    Yes, there is a problem with CDR’s in asterisk. There is a bug filed
    against the problem, but no practical solution for it.

    The cure: use the CEL interface instead, and generate your own
    CDR’s (or whatever else you could bill from [it doesn’t *have* to be
    CDRs])

    The cause of the problem: An interesting combination of 3 operations
    being performed on channels, namely masquerading, and
    forming local channels; add to that the hardwired ‘roles’ that channels
    are given (channel, and peer), and the final knockout: CDRs are stored
    on channels.

    The above 3 operations affect CDR’s because parking and transfers
    can change the role that a channel plays (chan to peer or vice-versa);
    Transfers and parking involve the masquerading, and sometimes local
    channels–
    both these operations involve duplicating a channel. CDR’s are meant for
    the
    channel playing the “channel” role, and CDRs on channels playing the “peer”
    role are tossed out.

    Transfers turn the above into a complex mush in which the results vary
    depending
    on who transfers who, who is calling, and who is called, etc. Because the
    CDR’s
    are stored on the channels themselves, they pass thru many filters and
    operations
    that vary based on the roles they play and the operations performed, which
    can change
    in subtle ways from release to release, from one bugfix to another, even.

    So, the best way to get around all this is to get the CDRs out of the
    channels,
    And to do that, you either use CEL, or you build your own event tracking
    mechanism, using
    whatever means available (I’ve seen folks use the manager event reports with
    their
    own logic in perl, or php, or whatever to do the parsing and storage). Then,
    you either
    turn the events into your own billing mechanism, or you generate CDR’s to
    fit into your
    currently existing billing mechanism. Doing this right
    and making it dependable is not an overnight sort of thing.

    I proposed a CDR generating backend for CEL (which I haven’t completed yet).
    I even started it, but got layed off before I could finish it. I’ve
    generated a spec
    for CEL->CDR generation, involving something I call “simple CDRs”.This doc
    has
    been evolving with time, and needs to be updated. I previously described
    “complex”
    CDR’s in the spec that provided more fine-grained event logging in CDR
    format, but I’ve convinced
    myself that the complex stuff can also be done via the “simple” method, and
    so I’m
    about half way thru the spec, expunging the “complex” stuff. All my examples
    have to be
    changed — If you are interested in looking at my spec, you can:

    svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs

    and look at the pdf there in that directory.

    murf

    Steve Murphy

    ParseTree Corp.

  • On Wed, Dec 1, 2010 at 7:41 AM, Sherwood McGowan
    previously, IF you
    don’t do call transfers, and you don’t park calls.

    And even if you do a small amount of that, as long as no one forwards an
    incoming call to some international destination, you’ll probably be OK with
    CDR’s. If you don’t mind losing a little chunk of the conversation here or
    there,
    the current CDR’s should be sufficient for you, and you don’t have to go
    thru
    any bother.

    Just keep in mind that clever people can/will take advantage of the fact
    that everything after an incoming call is transferred is lost to billing (as
    an example).

    murf

    Steve Murphy

    ParseTree Corp.

  • href=”mailto:sherwood.mcgowan@gmail.com”>sherwood.mcgowan@gmail.com> wrote:

    Good call Steve! Your comment is spot on, as you said, transfers screw it
    all up. My prior client did not allow transfers, since it was just a simple
    VOIP provider service, without transfer capabilities for customers 🙂

    Good to see you around!

  • Hi
    I have small query that if my phone set callerid and anonymous(both
    name and number in from header),and make a call to asterisk,then the CDR
    shows
    src: anonymous
    dst:9999
    clid:”Anonymous””
    and etc

    .Here the actual name of the src is missing,so how I bill for this
    call?.I planning to change the function that set src by parsing contact
    header instead of from,Is it fine?

    Thanks
    nikhil

  • Well, the first thing that pops into my head is, try setting
    accountcode for your sip endpoints, so that you have something that
    will identify the “customer” for billing purposes. You can also use
    setvar to set a different variable (such as the phone number) which
    can then be used in some way to update the CDR with an identifier
    specific to the customer.

    Proost,
    Sherwood