Hello! Most are probably bored seeing another letter about this, but I've put in a fair amount work on a spec for rewriting the CDR system in Asterisk, and I have some questions: First, please look at what I've written so far: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and look at the file "CDRfix2.rfc.txt" in the RFCs dir. The spec SIGNIFICANTLY alters the way CDRs are generated, how they are structured, and what they express. If you have ANYTHING to do with CDRs, then it is critical you become involved in the design process for the new system! Or suffer with the results! What's going on? I wrote up two modes of CDR generation: Leg-Based, and Simple. A new field, "linkedID", that can be used to link CDRs as part of the same total call. Leg-Based is (or can be) very detailed. Every CDR has a type, like CALL, AXFER, BXFER, PARK, etc. Depending on what actions occur during a call, a call can be split up into several "legs". A dialplan func to insert an event that will create a new "leg" will be available, with its own user-specified type. Simple is just that. One CDR is generated per activated channel. The start time is when it was created. The end time when it died/hungup. The answer time is... you know! No fine-grained details. No dialplan fanciness. linkedID can help you group channels involved in a single 'logical call'. QUESTIONS: Which of the two would you see being useful to you? Is there Yet Another CDR system you would like to see instead? How would/should it work? Will both fulfil the requirements of CALEA? It's been proposed that we implement just the Simple CDR now, and it be introduced in some 1.6.x (or higher) release. In that release, the existing CDR system would be deprecated, and in some "futurer" release the "old" (now current) CDR system would be dropped entirely. What do you think? Are we high on drugs, or what? murf -- 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/20090112/3eac2fd1/attachment.bin
Apostolos Pantsiopoulos
2009-Jan-12 17:26 UTC
[asterisk-users] CDR Rewrite -- Questions to the users
Steve Murphy wrote:> Hello! > > Most are probably bored seeing another letter about this, > but I've put in a fair amount work on a spec for rewriting > the CDR system in Asterisk, and I have some questions: > > First, please look at what I've written so far: > > svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs > > and look at the file "CDRfix2.rfc.txt" in the RFCs dir. > > The spec SIGNIFICANTLY alters the way CDRs are generated, > how they are structured, and what they express. > > If you have ANYTHING to do with CDRs, then it is critical > you become involved in the design process for the new system! > Or suffer with the results! > > What's going on? > > I wrote up two modes of CDR generation: Leg-Based, and Simple. > > A new field, "linkedID", that can be used to link CDRs as part > of the same total call. > > Leg-Based is (or can be) very detailed. Every CDR has a type, > like CALL, AXFER, BXFER, PARK, etc. Depending on what actions > occur during a call, a call can be split up into several > "legs". A dialplan func to insert an event that will create > a new "leg" will be available, with its own user-specified > type. > > Simple is just that. One CDR is generated per activated channel. > The start time is when it was created. The end time when it died/hungup. > The answer time is... you know! No fine-grained details. No dialplan > fanciness. linkedID can help you group channels involved in a single > 'logical call'. > > QUESTIONS: > > Which of the two would you see being useful to you? > > Is there Yet Another CDR system you would like to see instead? > How would/should it work? > > Will both fulfil the requirements of CALEA? > > It's been proposed that we implement just the Simple > CDR now, and it be introduced in some 1.6.x (or higher) > release. In that release, the existing CDR system would be > deprecated, and in some "futurer" release the "old" (now current) > CDR system would be dropped entirely. What do you > think? Are we high on drugs, or what? > > murf > > > ------------------------------------------------------------------------ > > _______________________________________________ > -- 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-usersHi, The specs look very promising. I think everyone here should be grateful for your efforts. In answer to your question I personally find both approaches very useful, although I would prefer to see the "simple" approach implemented first chronologically since I believe it is simpler to implement and we could get immediate results. One small question. I tried finding the "peeraccount" variable that was brought up many times in past emails in your CDRs fields descriptions but I couldn't. This field was supposed to hold the accountcode for the terminating side (and could be set for each channel using CHANNEL()) according to this : http://www.venturevoip.com/print.php?rssid=2011 Is this field going to be implemented? -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs at kinetix.gr ------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090112/9a6aa470/attachment.htm
Benny Amorsen
2009-Jan-13 13:16 UTC
[asterisk-users] CDR Rewrite -- Questions to the users
Steve Murphy <murf at digium.com> writes:> Which of the two would you see being useful to you?"Leg based", as far as I can see, because that looks like the only way to bill transfers differently depending on which end did the transfer. Possibly "Simple" on the Asterisk systems where we forbid transfers.> Is there Yet Another CDR system you would like to see instead? > How would/should it work?"Leg based" looks good.> Will both fulfil the requirements of CALEA?We're not yet operating in a jurisdiction where CALEA applies. It looks good enough for the jurisdictions we operate in, possibly apart from the transfer issues further down, but I am certainly not a lawyer.> It's been proposed that we implement just the Simple > CDR now, and it be introduced in some 1.6.x (or higher) > release. In that release, the existing CDR system would be > deprecated, and in some "futurer" release the "old" (now current) > CDR system would be dropped entirely. What do you > think? Are we high on drugs, or what?I need this functionality for transfers, and I don't think "Simple" provides it: A calls B: A pays for the whole duration for A => B B transfers to C: B pays for B => C, A is still paying A => B If it was A who transferred the call instead: A calls B: A pays for the whole duration for A => B A transfers to C: A pays for A => C, and A is still paying A => B B and C get to talk for free, while A pays twice. This should apply whether transfers are attended (soft), unattended (hard) or caused by SIP redirections before answering. Ideally it should also be possible to simulate SIP-like redirections in the dialplan with the same CDR behaviour. /Benny
Benny Amorsen
2009-Jan-13 20:09 UTC
[asterisk-users] CDR Rewrite -- Questions to the users
I wrote a really long email, but it hinged on one thing I need clarified... 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: abc9We are talking about the "Simple" CDR's, not the leg-based ones, right? If so, why do all the CDR's only call one "Party"? Shouldn't there be a src and a destination? /Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090113/8b6f5070/attachment.htm
Benny Amorsen
2009-Jan-14 09:12 UTC
[asterisk-users] CDR Rewrite -- Questions to the users
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: abc9Are 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
On Sat, Jan 17, 2009 at 3:08 AM, Steve Murphy <murf at digium.com> wrote:> Greyman-- > > I've been thinking of Benny Amorsen's comments on Simple CDRs... > > >> 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. > > Do you have any ideas that might make this work for him? > I guess simple CDR's won't work for everyone, but... if they > could work in this case.... >
On Sat, Jan 17, 2009 at 10:39 AM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:> > Only if the dial plan actually gets enough information to set the > accountcode, which at least historically wasn't the case for Asterisk. > In 1.2.x, you couldn't in the dialplan tell if a call went A->B or > A->C(SIP redirect)->B. BLINDXFER didn't get set correctly in all > cases. > > The alternative is to use the built-in accountcode from sip.conf; I > haven't verified how well that actually works. It won't work if you > need to distinguish two different phones behind a SIP trunk, but I > don't think anything can, so we can forget about that case. >I've always set the accountcode directly in the dialplan using SetAccountCode and now the newer CDR function. I to encountered occassional problems relying on Asterisk picking up the accountcode from configuration files or a realtime database. We changed our approach to doing a FastAGI call to get the accountcode, the FastAGI call provides the channel name from which the authenticated username and then accountcode can be looked up. As for blind transfers I've always seen the accountcode on the transferred call leg set to that of the call that initiated it. If you wanted it the other way around you do have the option of breaking back into the dialplan when a blind transfer occurs by using the TRANSFER_CONTEXT. At the moment depending on which Asterisk version you are using that won't completely solve the problem since the CDRs produced when transfers occur are all wrong and differently wrong in the different Asterisk versions. Regards, Greyman.