Re: [asterisk-users] CDR Rewrite -- Questions to the users
Grey Man greymanv...@gmail.com writes: The trick with transfers is to forget about the src field for billing purposes and make sure the accountcode for the call is set in accordance with the business rules. For example if two customers A and B are talking to each other and A blind transfers B to a billable destination Z then who pays for the call from B to Z? There is no right answer but as far as the CDRs are concerned it's irrelvant as long as each call is recorded and the accountcode can be set within the dialplan both choices can be accomodated. 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. /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
[asterisk-users] CDR Rewrite -- Questions to the users
On Sat, Jan 17, 2009 at 10:39 AM, Benny Amorsen benny+use...@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. ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Sat, Jan 17, 2009 at 3:08 AM, Steve Murphy m...@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 From what I can gather the problem Benny has is getting the src field correct for a transfer. In the traditional Telco World the src (or A Number) field tends to be both the callerid of the customer and an identifier that ties the CDR to the customer for billing purposes. With Asterisk and a lot of other modern day softswitches there's usually a field called accountcode or similar which can be used to tie a CDR to a customer. The src field is then only fulfilling one role which is to hold the callerid that was set or recieved for the call. The trick with transfers is to forget about the src field for billing purposes and make sure the accountcode for the call is set in accordance with the business rules. For example if two customers A and B are talking to each other and A blind transfers B to a billable destination Z then who pays for the call from B to Z? There is no right answer but as far as the CDRs are concerned it's irrelvant as long as each call is recorded and the accountcode can be set within the dialplan both choices can be accomodated. With the simple CDR approach it could end up that there are multiple CDRs for a customer for the one call since they could be charged for both ends of a transfer. I don't see that as an issue. Regards, Greyman. ___ -- 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
Re: [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: 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users
Steve Murphy m...@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 ___ -- 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
Re: [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: abc9 We 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 ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Tue, 2009-01-13 at 21:09 +0100, Benny Amorsen wrote: 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: abc9 We 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 Benny-- First, yes, all the examples I gave were for Simple CDR mode. Next, the notation is simplified. A - B means channel: A dstchannel: B (A and B are also contractions for stuff like Dahdi/1-1 or Sip/bob-1) start, ans, end are the 3 times (e2, e3, etc are event times (symbolic); disp is the disposition field. linkedID is described in the doc. I don't specify src/dest, in the examples, as they really don't convey much without all the background description, (if I said src = '101' and dest = '202' you'd have to know the associated contexts, etc. -- a can of worms)--- but every CDR will specify those fields for the Dial (or whatever else was responsible for activating the channel). I also didn't spell out stuff like userfield, amaflags, callerid fields, etc; it isn't that they aren't important, it just clouds the examples to get too explicit and verbose. The main thing about these fields is that they are in the list of CDR fields and described in the CDR field section. The Party field says which channel this CDR applies to. I use it because the channel/dstchannel aren't always going to involve the channel in question. Usually, tho, Party will either be the channel or the destchannel. Knowing which one is the trick. And, as a side note, the A CDR in my examples usually lacks a dstchannel field, because it's not being activated by a dial-- it's being activated via an incoming call on an FXO interface. (or an incoming SIP invite, maybe...) And, if I'm missing info that would really, really, necessary to have, or hard to inject from the dialplan, now is the time to fight to make sure that it is in the spec. murf -- Steve Murphy m...@digium.com Digium smime.p7s Description: S/MIME cryptographic signature ___ -- 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
[asterisk-users] CDR Rewrite -- Questions to the users
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 m...@digium.com Digium smime.p7s Description: S/MIME cryptographic signature ___ -- 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
Re: [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-users Hi, 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: r...@kinetix.gr --- ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Mon, 2009-01-12 at 19:26 +0200, Apostolos Pantsiopoulos wrote: Steve Murphy wrote: Hello! ... Hi, 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? Yes, it will. I apologize for that omission. I will correct the CDRfix2.rfc.txt file, so it properly mentions this var. (small wait, while I go do it). There, now, rev 168504 of that doc contains peeraccount in both the Simple and Leg-Based sections. User modifiable, with a little verbage as to how. Thanks for catching that, btw!! murf -- Steve Murphy m...@digium.com Digium smime.p7s Description: S/MIME cryptographic signature ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)
Quoth Steve Murphy... Date: Mon, 12 Jan 2009 08:51:03 -0700 QUESTIONS: Which of the two would you see being useful to you? Obvious comment really but given LEG based CDR, one can determine the 'Simple' data but you can't work it the other way. I'd therefore find LEG based CDR more useful as the granularity (time on Hold, in Queue, Waiting on pre-xfer ring etc etc) would be good. -- Regards, Russell | Russell Brown | MAIL: russ...@lls.com PHONE: 01780 471800 | | Lady Lodge Systems | WWW Work: http://www.lls.com | | Peterborough, England | WWW Play: http://www.ruffle.me.uk | ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)
2009/1/12 Russell Brown russ...@lls.lls.com Quoth Steve Murphy... Date: Mon, 12 Jan 2009 08:51:03 -0700 QUESTIONS: Which of the two would you see being useful to you? Obvious comment really but given LEG based CDR, one can determine the 'Simple' data but you can't work it the other way. I'd therefore find LEG based CDR more useful as the granularity (time on Hold, in Queue, Waiting on pre-xfer ring etc etc) would be good. -- Regards, Russell | Russell Brown | MAIL: russ...@lls.com PHONE: 01780 471800 | | Lady Lodge Systems | WWW Work: http://www.lls.com | | Peterborough, England | WWW Play: http://www.ruffle.me.uk | ___ -- 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 hi one question, i will need to rewrite all my apps that use the cdr? and the queue_log will be rewrited? thanks -- (\__/) (='.'=)This is Bunny. Copy and paste bunny into your ()_()signature to help him gain world domination. ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)
David fire wrote: 2009/1/12 Russell Brown russ...@lls.lls.com mailto:russ...@lls.lls.com Quoth Steve Murphy... Date: Mon, 12 Jan 2009 08:51:03 -0700 QUESTIONS: Which of the two would you see being useful to you? Obvious comment really but given LEG based CDR, one can determine the 'Simple' data but you can't work it the other way. I'd therefore find LEG based CDR more useful as the granularity (time on Hold, in Queue, Waiting on pre-xfer ring etc etc) would be good. -- Regards, Russell hi one question, i will need to rewrite all my apps that use the cdr? and the queue_log will be rewrited? thanks I have found that it is easier to use queue events rather than the queue log, I have my own custom build of asterisk in which I send everything that would be written to the queue log to the AMI, and then I use a perl script that watches for those events and writes them to a DB. I would recommend doing something similar as it makes adapting to changes in the structure easier. Anthony ___ -- 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
Re: [asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)
On Mon, 2009-01-12 at 17:08 -0200, David fire wrote: 2009/1/12 Russell Brown russ...@lls.lls.com Quoth Steve Murphy... Date: Mon, 12 Jan 2009 08:51:03 -0700 QUESTIONS: Which of the two would you see being useful to you? Obvious comment really but given LEG based CDR, one can determine the 'Simple' data but you can't work it the other way. I'd therefore find LEG based CDR more useful as the granularity (time on Hold, in Queue, Waiting on pre-xfer ring etc etc) would be good. -- Regards, Russell hi one question, i will need to rewrite all my apps that use the cdr? and the queue_log will be rewrited? thanks Well, the wish/plan/whatever, if followed thru, would require people who have software that works with the existing CDR's, to tweak their code to work with the new regime. I don't think the queue_log stuff will need to be modified, at least with respect to CDR's, as all they do is reference the uniqueID... there may be other reasons pertaining to enhancements, etc. that might demand some code update there, but that's not in the realm of CDRs. By tweak their code, is might involve a few lines of update, or a total rewrite, I don't know. But the idea is make the specs for the new system as public and known as possible in advance of a new implementation. The period of time during which the old code would still exist would be an entire release, so that gives you probably about 2 years... in the meantime, we'll probably want to cease maintaining the old code. That should mean that the old code should actually become more stable, because so far, it's very difficult to change ANY aspect of the current CDR system without introducing new regressions. Given the fact that the current implementation has serious problems, holes and gaps wrt to parking, xfers, etc, and is so hard to maintain in its current format, the long-term goals of reducing the cost of maintenance, and getting higher reliability, hopefully will make the effort of recoding worth that effort. murf -- Steve Murphy m...@digium.com Digium smime.p7s Description: S/MIME cryptographic signature ___ -- 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
