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
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
