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

[Nikhil]

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"" <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

On 12/02/2010 09:31 AM, Nikhil wrote:
> 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/ea5dad2f/attachment.htm