[asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Nikhil]

Thanks,Now I understand the problem,Now I am trying to change CDR to fix 
these issues.

Thanks
Nikhil

On 12/01/2010 08:31 PM, Steve Murphy wrote:
>
>
> On Wed, Dec 1, 2010 at 5:56 AM, Nikhil <d.nikhil at cem-solutions.net 
> <mailto:d.nikhil at cem-solutions.net>> wrote:
>
>     anyone have a idea on this..
>
>     On 11/22/2010 10:50 AM, Nikhil wrote:
>     > 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
>
>
> 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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20101202/4f5dcca3/attachment.htm