[asterisk-users] [asterisk-dev] 1.4 and CDRs -- The Breaking Point

[Steve Murphy]

On Sat, 2009-02-07 at 15:51 -0500, Alexander Lopez wrote:
> 
> > -----Original Message-----
> > From: Steve Murphy [mailto:murf at digium.com]
> > Sent: Saturday, February 07, 2009 1:59 PM
> > To: Alexander Lopez
> > Subject: RE: [asterisk-dev] 1.4 and CDRs -- The Breaking Point
> > 
> > On Fri, 2009-02-06 at 12:28 -0500, Alexander Lopez wrote:
> > >
> > > Looks good so far but let me make a few points some are redundant as you
> > > have already covered them in your document, others may present an
> > alternate
> > > view (SNAFU)
> > >
> > >
> > > I my opinion a call is a call, doesn't matter where it went or how many
> > > times it changes legs.
> > >
> > > A call should have a single unique call ID.
> > >
> > > For example
> > >
> > > Call begins 0:00
> > >
> > > Sales (A) calls customer (B)
> > > customer states they have a problem, Sales (A) tranfers Customer (B) to
> > > Support (C).
> > > Support look up Customer determines they are not in system transfers to
> > > Accounting Queue for Help (D) call leaves accounting and goes to support
> > > queue (E) call gets handled by support engineer (F) then transfered back
> > to
> > > different salesman  (G)
> > >
> > > In this case I would have ONE call lasting 25 minutes, with events in
> > > between.
> > >
> > > I should have two records one with a summery of the call.
> > >
> > > CallID lasted 25minutes on such and such a date and time, originated by
> > (A)
> > > and answered by (B).
> > >
> > > And second set of records showing the detail or the calls. (Your chart
> > in
> > > the document would be fine)
> > >
> > 
> > Alexander--
> > 
> > From the above, I'd guess that the Simple CDR spec might be appealing to
> > you.
> > In that scenario, you'd get one CDR for each channel involved in the
> > total
> > call, but the interesting one would be the one with Party=B in this
> > case.
> > 
> > CDR:  Party: B; channel: A, dstchannel: B, start: When B was dialed;
> >       ans: when B answered; end: when B hung up; disposition: ANSWERED.
> > 
> > There would also be CDRs for A, C, D, E, F, and G; Each would reflect
> > who
> > called them, when they answered, when they hung up (ended).
> > 
> > CDR: Party: A; channel: A, dstchannel: <null>; start: when A went
> > offhook or submitted call, dep on tech; ans = start time, if applicable;
> > end: when A
> > xferred to C and got dialtone.
> > 
> > CDR: Party: C; channel: A, dstchannel: C; start: when C was dialed;
> > ans: when C answered; end: when C xferred or hungup. Disp: ANSWERED;
> > 
> > CDR: Party: D; channel: C; dstchannel: D; start: when D was dialed;
> > ans: when D answered; end: when D xferred to E...
> > 
> > and so on.
> > 
> > All the above would have the same LinkedID (as discussed in the doc),
> > but this may not make much difference to you... you seem to be
> > concerned about only the one situation, and the rest could be ignored.
> > 
> > I'd imagine you could tell that all but B were "internal" locations,
> > and B's CDR is probably the only one you'd be interested in billing
> > for in this case, since B is the destination of the call. A would or
> > should foot the bill for the call, no matter how many others talked
> > to B (at least in my opinion). Deciding who's interesting for billing
> > is not Asterisk's job. It's up to your CDR processing s/w to toss out
> > the uninteresting CDRs.
> > 
> > Do you agree, or is something fundamental missing here that you need?
> > 
> > murf
> > 
> > --
> > Steve Murphy <murf at digium.com>
> > Digium
> 
> 
> 
> If I get to call you Murf, You get to call me Alex...
> 
> The scenario I portrayed was for a corporate PBX, not a switch used to
> sell/process minutes on Pre-paid. On all of the PBXs I have worked on,
> management is looking for a few things.
> 
> 1	Who called who
> 2	Are my sales reps / customer service reps placing the calls they
> need to. 
> 3	How long was the caller / callee on hold (could be told by Events in
> the detail CDR)
> 
> 
> 	I like your idea of a detail written to the every time an Event
> happens, (IE Hold, Park, Transfer, Queue, Agent, Application, etc.) One of
> the issue I have is that I have no idea what the call went through from the
> CDR as it stands. 
> 
> I vote to give as much detail in the CDR as possible, that would require ALL
> Asterisk applications to be CDR AWARE!!!!  They would have to inherit a few
> details during the copy.
> 
> The Current (OLD) channel will be in charge of writing the CDR as it stands
> at that moment in time to the CDR logger.
> 
> For example.
> 
> A calls B, B then transfers (blind) to C, and then C puts me one hold, picks
> up and transfers me to D.
> 
> 
> A calls B using Dial()
> 		CDR Starts with origin and dest.
> B Answers
> 	B blind transfers to C
> 		Dial() started by A dies and is copied to new one started by
> B.
> 			Exiting Dial() should write a CDR record reflecting
> that call was transferred, and copy needed variables to New Dial()
> C Answers
> 	New Dial() writes to CDR starting CDR for new leg
> C Places A on Hold. 
> 	MusicOnHold() will need to log an entry into CDR with UniqueID.
> C picks up Held call.
> 	MusicOnHold() Again writes to the CDR as it exits...
> C transfers to D
> 	Dial application from C writes to CDR as it dies.
> D Answers
> 	New Dial() for D logs entry
> D hangsup
> 	Dial() write entry in CDR as it dies. Since there is no MASQ to new
> channel. Dial() writes summery of call that has been inherited from all
> other apps to CDR.
> 
> I know that the application should not be doing to on their own and I agree
> with the monolithic approach. However for CDR to really work well, ALL
> applications in Asterisk need to be CDR Aware....
> 
> I feel that you should give as much detail as possible any well written
> billing program can take that information and run with it.
>   
> Alex


Alex-- 

Oh, you'll love the Leg-Based CDR's when I've written it, then. As it
stands,
the CEL interface will allow you to specify the apps you want to track.
I'll
probably only hard-code the few apps that initiate dials with a
directive
to cut a CDR leg when they start.

And, with one simple dialplan command, you can skip tracking apps
entirely,
and just split the CDRs where you want to mark time, and give them their
own types so you know what's going on.

Really, that's the best. I can't imagine anyone wanting to track how
long
a channel spent executing a "goto" instruction, a "NoOp" app, etc...

I may end up finding it practical to cut the CDR when ANY tracked
application
is run... we'll see...

murf

-- 
Steve Murphy <murf at digium.com>
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-users/attachments/20090209/284f3a78/attachment.bin