[asterisk-dev] CDR Problem Proposals

[Kaloyan Kovachev]

On Fri, 21 Nov 2008 08:46:21 -0700, Steve Murphy wrote
> 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.

 I like the idea of CDRs being controlled from the dialplan and I think it is
not necessary to run through the dialplan (an application) in order to do this
- if one can just set some variables that will control the decision made at
the right time (on hangup/xfer/park).
 I was thinking about the possibility of having multiple CDRs attached to the
channel and (similar to the roles, but as) a bitmask for each one to post_CDR,
run_h_exten, need_status update  and need_endtime_update (more can be added
later), then in some conf file (instead of compile time option) to list the
default rules, but to able to override them form the dialplan (per call) or in
the conf itself (as company policy) for each of the cases listed at
http://svn.digium.com/svn/asterisk/team/murf/RFCs

How I would expect it to work ... in short each bridge between different
parties (+1 for CDR filed Party, but type may well be just the party name as
Park or Transfer) has its own CDR and its own rules so:
	A calls B - CDR[A1_to_B1] is attached on pbx_start to A with all options
enabled (or the ones defined as entering_dialplan) and B has no CDR at all (or
to make it more complicated :) set from called_from_dial options group)

	A parks B - CDR[A1_to_B1] is copied to B (but turn off post_CDR on A ... one
may decide to also turn off run_h_exten on A or B ... or not to turn off
post_CDR) and a new one CDR[B2_to_Park1] is created with the default options
for entering_park

	1) B hangs up - simple - CDR posted and h exten is run  if marked
	2) C dials in to the parking lot - CDR[B2_to_Park1] updated to not be posted
(as usual one may override it) and not need status/endtime updates any longer,
CDR[A1_to_B1] is not touched (except if override - needs new option
move_on_new_peer), CDR[C1_to_Park1] attached to C
	3) timeout - B gets new CDR[B3_to_A2] added with options from park_timeout

... similar rules defined for the transfers/queues and others ... I hope you
get the idea and how it can be extended with new features or triggers being
added (like turn off 'bill_me' field for CDR[B3_to_A2] ? ) ... so we have
defaults and we have the triggers to change them for each group from the dialplan.

 I would prefer to have just a simple 'transfer' as case and treat the blind
one as specific case of attended no matter if direct feature/button was used
or just the transferee hangs up in order not to duplicate the option groups,
but one may wish to set different rules (?!?)

 The ForkCDR, NoCDR and ResetCDR applications may work then on either all,
selected or on the last_only, but may well became deprecated with such model
(comment form someone using them?)

P.S.
 I don't like separating channels on FXO and FXS (based on hardware), because
it may well be that the FXO port is a local extension and FXS is an outgoing
line - it should be configurable per device if at all


> 
> murf
> 
> -- 
> Steve Murphy
> Software Developer
> Digium