[asterisk-dev] CDR Problem Proposals

[Julian Lyndon-Smith]

Steve,

Although it's not a CDR problem we had, it is / was a similar thing. I 
needed to track a call from the moment it came in, to the moment it 
ended, regardless of parking / transfers etc etc.

I managed to achieve this by allocating a GUID to the call, and saving 
that GUID as an inherited variable. Thus, all other channels that came 
into contact with the original channel inherited the call GUID.

Couldn't you do something similar internally ? When a call first comes 
in, create a CDR object, and allocate a GUID to it. Set an inherited 
internal channel variable to the value of the CDR GUID and pass that 
around. This should bypass all the issues with transfers / masquerades 
etc. Perhaps have a parent CDR GUID as well, so a channel has it's own, 
and the one of the channel it connected to.

I know, I know, it's an extremely simplistic scenario and it most likely 
will not work but perhaps it is enough to give food for thought.

Julian.

Steve Murphy wrote:
> On Thu, 2008-11-20 at 19:34 -0800, John Todd wrote:
>   
>> On Nov 20, 2008, at 1:49 PM, Leif Madsen wrote:
>>
>>     
>>> Steve Murphy wrote:
>>>       
>>>> Hello--
>>>>
>>>> When I did it, catching CDR xfers, etc, in the
>>>> bridge routine seemed such a good idea. After all,
>>>> if we cut a CDR there, we were guaranteed to never
>>>> miss a call leg! But the further I go down that road,
>>>> the worse the decision appears.
>>>>         
>>> Perhaps building CDRs into Asterisk is the wrong approach, and maybe  
>>> we
>>> need to take the course of allowing people to build their own CDRs via
>>> the dialplan; and that just means providing them the tools to do it,  
>>> and
>>> some examples of the most common scenarios (this is what CEL is  
>>> supposed
>>> to be right?)
>>>
>>> It seems everyone has a different idea about what CDRs are supposed to
>>> be, and how they are supposed to be represented, and perhaps no route
>>> you take is ever going to succeed at solving the underlying issue.
>>>
>>> Just a thought, but I'd hate to see spend another round of trying,  
>>> just
>>> to realize that perhaps there is no route to success using the current
>>> methodology?
>>>       
>>
>> Well, the most obvious problem with that solution is that the Dial()  
>> command doesn't allow for much visibility into what's going on with  
>> the call.
>>
>> So it may be that CEL or something like it is the answer, but call  
>> events probably need to be recorded in a way that is outside the  
>> dialplan since there are many "invisible" parts of calls that the  
>> dialplan is typically executed during those events.  One could argue  
>> that the dialplan maybe SHOULD be called during those events - but  
>> that's a different architectural issue.   Plus, other API-ish things  
>> would then have to push CDR entries of their own instead of relying on  
>> Asterisk to do it "without thinking."   Despite being complex today, I  
>> would suggest that removing CDR functionality from the core would make  
>> programming Asterisk _more_ difficult.  I won't argue that perhaps  
>> there are better ways it could be done in the "core", but I'm not well  
>> positioned right now to make a case one way or the other as to what is  
>> the best method.
>>     
>
> I don't think it's the Dial() app's transparency that's the cause
> of the current complexity. Dial is just doing what it was designed
> to do. It sets up a call (rings possibly several extens, grabs the
> first pickup, and bridges the caller to the callee with several
> options, 
> sets some vars when the bridge closes, and returns.
>
> It's the asynchronous activities of the bridged channels that's
> the juicy part. Dahdi hookflashes, Features (one touch park,
> blind xfer, attended xfers, etc), and the masquerades that are
> performed to make the actions possible within the confines of Asterisk
> that make it all so.... interesting!
>
> I think we've reached a point where we actually have to sit down
> and truly think and agree on what to do to get to where we want to
> be, which includes defining exactly where we want to 'be'.
>
> We can take this anywhere we want. I've seen/heard of folks
> that have used nothing but the dialplan to accomplish working
> billing systems; others use manager events; others use a mix;
> others use the existing CDR system, with really inventive
> use of ForkCDR, etc.
>
> But I think most folks don't want to spend a couple man-months
> of labor/expense to get a minimally working CDR system running.
>
> murf
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________