Steve Murphy wrote: > On Wed, 2007-10-17 at 02:41 +0200, Philipp Kempgen wrote: >> Steve Murphy wrote:
(Sorry for quoting so much but I need to keep the context.) >>> For instance, if Zap/52 dials Zap/51, >> 52 --- dials & talks ---> 51 >> >>> who hookflashes and dials Zap/50, >> 51 ------- dials -------> 50 >> >>> and 51 hangs up, leaving 52 and 50 to talk away, >> 52 ------- talks -------> 50 >> >>> we should get 1 cdr >>> that records the call from 52 to 51, which would last until the >>> hookflash; >> No doubt about it. >> >>> and a second CDR that would be from 51 to 50, which would >>> start at either chan 50/51 channel creation time, or even at hookflash >>> time, have an answer time when 50 picked up, and last until either 50 or >>> 52 hang up. >> Right. But why should it start at 50->51 channel creation time? >> That way you would think (by looking at the CDRs) that 51 talked to >> 50 for longer than they did. I'd prefer hookflash time. >> > > Well, the "start" time isn't as important as the "answer" time; because > your billing times from "answer" to "end". True if billing was the only thing CDRs are good for. > The time from "start" to > "answer" is how much time it took to dial, wait, and have the call > answered... which people usually don't pay as much attention to. Right. But nonetheless the value that gets stored should be as accurate as possible. Or else you could just store a random value because nobody cares about it anyway. ;) > 50's channel creation time will be when 50 picked up the phone to answer > the call from 51. > > 51's channel creation time will be when 51 picked up the phone to answer > the call from 52. > > If we use 51's channel creation time as the start time, it would be > possible to see that 52's conversation with 51 and 51's with 50, > overlap. It may not help much, but it's a hint that 52 was there. Need to think about it for a while. >> How about splitting the "src" into "rsp" (who's responsible for the >> call, i.e. who should pay the bill) and "src" (who was involved in >> the audio bridge)? >> >> Example: >> rsp src dst duration billsec >> 52 52 51 130 120 >> 51 51 50 10 5 >> 51 52 50 3610 3600 > > Actually, I've been thinking about this; adding a CDR field to record > the responsible party for a call is a good way to handle these > situations. > > But, in 1.4, I really can't add a new CDR field and call it a 'bug fix'. > It really is a 'new', 'enhanced' sort of thing. So, this kind of change > will have to go into trunk at the moment. Sad but true. I guess it couldn't go in even if there was a config option defaulting to off (i.e. old-style behavior)? > Since I can't add the new field into 1.4, I'm restricted to having to > record something true and useful, and I have to surrender what could be > a valuable > piece of information: how much time 52 spent talking to 50. But, as far > as billing is concerned, I would save the most valuable thing: that 51 > made the call to 50, and ****that**** call lasted xxx seconds, no matter > who else may or not have spent time in the circuit. Right. > And another complication not brought up by this scenario, concerns > 3-ways. (really, using assisted xfer, you can form n-way conferences > this way)-- CDR's like the 3rd one you listed above, would add up to way > more seconds than were > actually spent on the call. I guess we could set such CDR's to > DOCUMENTATION instead of BILLING (or whatever), to mark them. Haven't yet decided on how I would naturally expect such things to appear in the CDRs. > And another issue you brought up earlier-- collect calls. Actually I wrote that later. Maybe the first messages was delayed before showing up on the list. Whatever. > I see in the > libpri code, that there's a q931 Information element that signals a > collect call; perhaps we can insinuate this into the CDR's and dialplan > somehow, to either > record or even block incoming collect calls. (I guess it'd be a good > selling point for moving to PRI.) I had guessed that this is signaled on PRI but wasn't sure. Could be made available to the dialplan as a channel variable. And possibly as a flag or something in the CDRs but that would certainly not pass as a bugfix. > Transfers, parking, masquerading, local channels! Bah!!! Humbug!! > :) Humbug - I wasn't aware that this word existed in English. Same thing for German. :) Regards, Philipp Kempgen -- amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Let's use IT to solve problems and not to create new ones. Asterisk? -> http://www.das-asterisk-buch.de Geschäftsführer: Stefan Wintermeyer Handelsregister: Neuwied B 14998 _______________________________________________ --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
