[asterisk-users] CDR Rewrite -- Questions to the users

[Benny Amorsen]

Ok, now for my long mail...

tir, 13 01 2009 kl. 09:05 -0700, skrev Steve Murphy:

>      CDR1:  A -> B  start: e1a  ans: e2  end: e4   Party: B  disp:
> ANSW       linkedID: abc9
>      CDR2:  A       start: e1   ans: e1  end: e6   Party: A  disp:
> ANSW       linkedID: abc9


Are start time and answer time the same in CDR2?


>      CDR3:  B -> C  start: e4   ans: e5  end: e6   Party: C  disp:
> ANSW       linkedid: abc9
> 
> CDR2 covers A (see the Party field),  CDR1 covers B, CDR3 covers C.
> 
> A's CDR could be used to bill A for his call in. It covers both the
> time A spent
> talking to B, and C. If you charge a different rate for A talking to B
> vs C, then
> you have some interesting SQL queries to make, I'll guess...


As far as I'm concerned, A called B and that's what they pay for. The
fact that B transferred them to a cell phone in Antarctica isn't A's
problem, it's B's problem, so I'm happy with that.

I need to somehow generate these CDR's to pass to our billing system:

A->B start: e1  ans: e2  end: e6 disp: ANSW
B->C start: e4 ans: e5 end: e6 disp: ANSW

I can get that by looking at all foo->bar CDR's (CDR1) and look for a
CDR's with the same linkedID and only foo (CDR2). Then I replace start
and end times in CDR1 with the start and end times from CDR2, and I'm
done. Nothing happens for CDR3 with this process, so I'm done.

> C's CDR records that B called C. It doesn't mention that A is doing
> all the talking.


Perfect.


> B's CDR records the call from A to B; this is the only one that seems
> a little useless...


It isn't useless, CDR2 is the one I need to get B as well as e2.


> Is this enough? If this is all you had, could you make it work? If you
> can't, 
> would adding a field or two help?


I am fairly certain it would be fine.

Then the A does the transfer version...


> In the SImple CDR world, here's what would be produced:
> 
>      CDR1:  A       start: e1   ans: e1  end: e4   Party: A  disp:
> ANSW       linkedID: abc9
>      CDR2:  A -> B  start: e1a  ans: e2  end: e6   Party: B  disp:
> ANSW       linkedID: abc9
>      CDR3:  A -> C  start: e4   ans: e5  end: e6   Party: C  disp:
> ANSW       linkedid: abc9
> 
> Here, A's total connection time is in CDR1; B with CDR2;  C with CDR3.


This is tricky... I need to create these CDR's for the billing system:

src: A  start: e1  ans: e2  end: e6   dst: B  disp: ANSW
src: A  start: e4  ans: e5  end: e6   dst: B  disp: ANSW

If I do the same substitution again, I get this:

A->B start: e1 ans: e2 end: e4. Whoops, end time is wrong.
A->C start: e1 ans: e5 end: e4. Whoops, both start and end times are
wrong.

CDR2 needs to find e1 so it can replace start, while CDR3 shouldn't have
anything replaced. I can't think of a query which will do this
correctly.


> Again, is there enough info here for you to do what you need to do? If
> not
> what addition could be added to make it work?


As far as I can tell, I won't be able to bill correctly for transfers
with these CDR's. That isn't a regression by the way, so it shouldn't
necessarily stop the switch to Simple CDR's.


> In the CDRfix2 doc, I outlined both the above blindxfer cases, and
> also permutations
> of attended xfers. Look them over, and see if what you need is
> possible with this format.


The CDRfix2 doc is concerned with Leg-based CDR's. I haven't looked at
those in-depth yet, because your proposal is to implement the Simple
system first.


/Benny


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090114/f4ee0794/attachment.htm