[asterisk-dev] CDR Problem Proposals

[Steve Murphy]

On Fri, 2008-11-21 at 09:20 -0600, John Lange wrote:
> On Thu, 2008-11-20 at 16:49 -0500, Leif Madsen wrote:
> > 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 doesn't seem like this would be workable. For example, how in the
> dialplan do you track an attended transfer capturing all 3 legs of the
> call?
> 
> Or what about putting a caller on hold? How do you keep track of how
> long the first leg of the call was, how long they were on hold, and then
> how long the third portion of the call was? None of those things are
> normally part of the dialplan.
> 
> On the other hand, ALL of those actions touch the bridging code (1.
> Bridge two callers, 2. Bridge to music, 3. bridge 2 callers) so again, I
> feel strongly all of the raw CDR code should go in bridging.
> 
> As a parallel effort their could be new "custom" CDR-style functions
> added to the dialplan that log to a completely different place but the
> "raw" CDR stuff still needs to be there.
> 
> I can't think of a single things that needs to be logged that doesn't
> involve a bridge between two (or more) channels being taken down.
> 
> In simple terms, every time a bridge is taken down, create a log entry
> that records the two end points, the reason the bridge was taken down,
> the date & time of the event, and duration the bridge was up. That would
> pretty much cover everything.
> 
> Of course, since I'm not a major contributor this is all very easy for
> me to say ;)
> 

No, that's pretty much why I thought the bridging approach would be
ideal.
But, the problem ends up being that masquerading (and other things,
perhaps)
gums this up horribly. The channels involved in the bridge are swapped
and change unmercifully. Why, in some cases (parking particularly), the
channels themselves might even have been terminated and freed.

Ideas that are running around in my head include tracking the
channel/peer
on the channel itself, and having the masquerade/park/xfer stuff
preserve 
the role of the channels as you manipulate them. This kind of thing
is 'architectural', and shows up in non-CDR related situations, like
when parked parties hang up, do you run the 'h' extension for them, or
not?

It's all still a little hazy, I'm trying to put it all on paper and see
if some sort of sense of order emerges from it.

See http://svn.digium.com/svn/asterisk/team/murf/RFCs
At the least, this doc should serve as a spec for CDR's
emitted by Asterisk. Input welcome.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20081121/41751719/attachment.bin