[asterisk-users] Simple CDRs

[Steve Murphy]

Greyman--

I'm taking this discussion to the list. 

Folks, 

what we are talking about here, is me trying to get a grasp around
Greyman's (Aaron's) request for a bare-bones CDR generation
that describes just total connect time for channels, stripping
out all the details. Who cares about xfer, park, hold, etc.?
So in the following is our discussion about what *should* be
there, and in what form...

So, what I'm thinking, is to spec out two CDR generation modes,
one detailed one according to the spec I'm working on, and the
other mode will follow these lines...


On Tue, 2009-01-06 at 10:37 +0000, Grey Man wrote:
> On Mon, Jan 5, 2009 at 6:42 PM, Steve Murphy <murf at digium.com> wrote:
> > I **think** I have a handle on it... Basically, for each channel
> > that did anything, no matter what, you'd like a single CDR
> > for that channel that would record the time from when it first
> > activated to the time it hung up. I'd have to assume the
> > first "answer" time would be recorded in the CDR, in case
> > multiple "answer" times might apply (for incoming calls, it
> > would be the time the pbx 'answered' the incoming call;
> > for outgoing calls it would be the time the other end "answered"
> > the call... right?
> 
> Hi murf,
> 
> To my mind only hangups should generate CDRs and nothing else should.
> When you say "for each channel that did anything" I'd like a CDR I'm
> not to sure about that, if you mean to generate a CDR for every type
> of channel that is ever hungup then the answer is yes. If you mean to
> generate a CDR on non-hangup channel events then the answer is no.

OK 

> 
> > so, if A calls B, B parks A, A's park expires, B is rung,
> > B answers, B xfers A to C, they hang up, we should have
> > a CDR for A's time, with the start time being the time
> > the PBX created the channel for A; the answer time would
> > be (if A is an incoming call) when the PBX answered the
> > incoming call and maybe started giving A the IVR experience,
> > and (if A is an extension), when B answered the call. The
> > end time would be when A was hung up.
> >
> > A CDR for B would be generated? with his answer time when
> > he picked up the phone to answer the incoming call from A?
> > and an end time when he parked A?
> >
> > Another CDR for B would be produced he answered the callback
> > from the PBX for the expired session with A, and end when
> > he got hung up xferring the call to C?
> >
> > Another CDR for C would be produced to record C's conversation
> > with A, start when his phone started ringing, answer when he
> > answered, and end when he hung up?
> >
> > Am I on the right track?
> 
> I don't use Parking myself so my understanding may be slightly off but
> from what I do understand of Parking the CDRs would not be generated
> quite how you describe. The main point is that Parking a call should
> not generate a CDR as the Park operation has not necessarily ended a
> call.

Parking a call will hang you up, in most normal cases. This includes
calling the Park() app, bxfer to the parking exten, and using the
one-touch parking features. But, if some strange combo of events
allows someone to park without a hangup, then I'd agree, no CDR 
should be generated.

> 
> In your description I think the CDRs should be:
> 
> 1 The call from A to the PBX, start time when B answers, end time when
> the A-C call is hungup,

Can't do this; it would be inaccurate; start time is when A either
picks up the phone (if dahdi exten), or when A submits an invite 
(if sip exten), or when an incoming call (via sip invite, or dahdi
fxo i/f) arrives at the pbx.

As to Answers, we have to start getting pedantic; if A is an exten,
then the first answer will be when B answers. But if A is an incoming
call via, say a dahdi fxo interface, or an incoming sip invite, then
an s exten is going to get run, and usually the PBX runs the answer()
app, and this will usually be the first answer. Now, I can use heuristics
to override this first answer if a dial occurs, but... if multiple dials
occur, this heuristic would tend to record the last answer; if we
override only Answer() in the 's' exten, then we would only record
the first answer... is this more like it?

Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override 
an ANSWER on exten s, BTW...

And, would it be proper to include all dial attempts? My guess is
that you would *NOT* want to see any dial attempts in this mode. Well,
at least, in this particular case, if A *tries* to dial B, but B
doesn't answer, then since A is a live channel, we would record
it's life in the system. When A hangs up, we would see the NO ANSWER
disposition, and the destination of B, right? If A tried to dial a
group, and nobody answered, the destination would be a random member
of that group, the args to the Dial command would record the other
members, usually.

> 
> 2. The call from the PBX to B, start time when B answers, end time
> when the call to B is hungup once the blind transfer of A to C is
> initiated,

The start time will be when B is first dialed; The answer time when
he answers.

I notice that you group the two B CDRs I described into a single
entity, but in doing so, you violate your own rule; when B parked
A, B was hung up. (He could easily dialed party D, eg, and had a
conversation and hung up while A was parked!) According to the
rules, there should be two CDR's for B, right?

> 3. The call from the PBX to C, start time when C answers Am end time
> when the A-C call is hungup.
> 
> I think the main difference in our approaches is that to me the PBX,
> in this case Asterisk, should be considered a black box as far as the
> CDRs are concerned. Things like parking, holding, re-inviting to
> change codecs, etc. etc. are all irrelevant events as far as a CDR is
> concerned. The only events of relevance are when the calls to and from
> end points external to the PBX are answered and hungup.

OK, gotcha. Now, let's talk about the fields in current/future CDRs, 
and see which you consider relevant?


accountcode (user modifiable)
amaflags    (user modifiable)
clid        (user modifiable)
userfield   (user modifiable)
    --- These 4 fields are set on the channel,
        and CEL events will record snapshots of these with
        each channel event. The accountcode can be set to 
        some default value in most channel config files, so
        it has some value the moment the channel is created.
        The user can modify these channel values with the
        CHANNEL() func from the dialplan, as in (eg):
           Set(CHANNEL(accountcode)=someval)
        I propose that the last non-null value be used,
        from the time-sorted list of channel events. It
        *is* possible (or could be possible), that these
        fields could be lost... or be reset to the default...

answer      (timeval)
    --- see previous discussion... This will probably
        be the most complicated field to track. And
        it's not *that* complicated...

axfer2hungup  (new)
    --- useless

billsec
    --- the usual (end-time minus answer-time)

channel
    --- the channel name. Pretty basic. Will most
        likely look like:  Dahdi/1-1
        Don't be shocked if you see Dahdi/1-2 --it
        happens with local channels.
        Don't be shocked if you see Dahdi/1-1<ZOMBIE>
        -- it happens with masquerading.

confid
    --- useless

dcontext
    --- Since a channel could be connected to several other
        channels during its lifetime, these fields might
        be useless. I could set them to the successful
        first target of a dial attempt... and leave them
        blank otherwise? If you really need/care about
        these fields, then maybe this mode is not proper
        for you. You can use linkedid to find all the
        other channels that may have conversed with this
        one.

disposition
    --- See above discussion.

dst
dstchannel
    --- Since a channel could be connected to several other
        channels during its lifetime, these fields might
        be useless. I could set them to the successful
        first target of a dial attempt... and leave them
        blank otherwise? If you really need/care about
        these fields, then maybe this mode is not proper
        for you. You can use linkedid to find all the
        other channels that may have conversed with this
        one.

duration
    --- the usual (end-time minus start-time)

end         (timeval)
   -- the time of the final hangup.

lastapp
lastdata
     --- since several dial attempts may be run during the life 
         a channel, in this mode, these fields may not be useful.

linkedid      (new, sort of)
     --- very easily could tie different channels together
         involved in xfers, direct dials, etc. Virally spread
         from channel to channel as they interact, oldest 
         linkedid wins.

         There have been fairly extensive discussion on this
         field. We can append a long uuid system-wide-unique
         string on a per-linkedID basis, or on a per-asterisk
         run, or on a per-CDR module load basis, or we simply
         have an option to add the system name (or whatever
         string you wish) to the end to allow guaranteed-
         unique linkedid's across systems.

parkingstall  (new)
    --- useless

peeraccount
    --- useless

party         (new)
    --- useless

src
     --- what do you *want* this to specify?

start       (timeval)
     --- the time the channel was created (activated, whatever).

type          (new)   
     --- in this mode, this field could be blank
         or something like "SIMPLE".
      
uniqueid
    --- useless

vars        (a list of attached vars)
        --- right now, CEL doesn't carry these channel vars forward;
            you'll have to cram them in the userfield string.


What I really need to do is describe each field in a/the spec,
and when in this simplified mode, what each field records, where
and when it gets its data, and what that data means.

This might seem a bit tedious, but it's a critical part of the
spec, and gets really critical when users don't get what they
expect.

murf

PS, I've updated the CDRfix2 document over the past few weeks...
mostly small tweaks, but I did add stuff where a dial operation
will split out a new CDR field (in the other mode), forming
the PREDIAL type CDR.



> Regards,
> 
> Aaron
-- 
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/20090106/e9a0a1dc/attachment.bin