<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1">
</HEAD>
<BODY>
Ok, now for my long mail...<BR>
<BR>
tir, 13 01 2009 kl. 09:05 -0700, skrev Steve Murphy:<BR>
<BLOCKQUOTE TYPE=CITE>
CDR1: A -> B start: e1a ans: e2 end: e4 Party: B disp: ANSW linkedID: abc9<BR>
CDR2: A start: e1 ans: e1 end: e6 Party: A disp: ANSW linkedID: abc9<BR>
</BLOCKQUOTE>
<BR>
Are start time and answer time the same in CDR2?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
CDR3: B -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9<BR>
<BR>
CDR2 covers A (see the Party field), CDR1 covers B, CDR3 covers C.<BR>
<BR>
A's CDR could be used to bill A for his call in. It covers both the time A spent<BR>
talking to B, and C. If you charge a different rate for A talking to B vs C, then<BR>
you have some interesting SQL queries to make, I'll guess...<BR>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
I need to somehow generate these CDR's to pass to our billing system:<BR>
<BR>
A->B start: e1 ans: e2 end: e6 disp: ANSW<BR>
B->C start: e4 ans: e5 end: e6 disp: ANSW<BR>
<BR>
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.<BR>
<BLOCKQUOTE TYPE=CITE>
C's CDR records that B called C. It doesn't mention that A is doing all the talking.<BR>
</BLOCKQUOTE>
<BR>
Perfect.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
B's CDR records the call from A to B; this is the only one that seems a little useless...<BR>
</BLOCKQUOTE>
<BR>
It isn't useless, CDR2 is the one I need to get B as well as e2.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
Is this enough? If this is all you had, could you make it work? If you can't, <BR>
would adding a field or two help?<BR>
</BLOCKQUOTE>
<BR>
I am fairly certain it would be fine.<BR>
<BR>
Then the A does the transfer version...<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
In the SImple CDR world, here's what would be produced:<BR>
<BR>
CDR1: A start: e1 ans: e1 end: e4 Party: A disp: ANSW linkedID: abc9<BR>
CDR2: A -> B start: e1a ans: e2 end: e6 Party: B disp: ANSW linkedID: abc9<BR>
CDR3: A -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9<BR>
<BR>
Here, A's total connection time is in CDR1; B with CDR2; C with CDR3.<BR>
</BLOCKQUOTE>
<BR>
This is tricky... I need to create these CDR's for the billing system:<BR>
<BR>
src: A start: e1 ans: e2 end: e6 dst: B disp: ANSW<BR>
src: A start: e4 ans: e5 end: e6 dst: B disp: ANSW<BR>
<BR>
If I do the same substitution again, I get this:<BR>
<BR>
A->B start: e1 ans: e2 end: e4. Whoops, end time is wrong.<BR>
A->C start: e1 ans: e5 end: e4. Whoops, both start and end times are wrong.<BR>
<BR>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
Again, is there enough info here for you to do what you need to do? If not<BR>
what addition could be added to make it work?<BR>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
In the CDRfix2 doc, I outlined both the above blindxfer cases, and also permutations<BR>
of attended xfers. Look them over, and see if what you need is possible with this format.<BR>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
<BR>
/Benny<BR>
<BR>
<BR>
</BODY>
</HTML>