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.nik...@cem-solutions.net
<mailto:d.nik...@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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
