Re: [asterisk-users] CDR Design
-->> -Original Message- -->> From: [EMAIL PROTECTED] [mailto:asterisk-users- -->> [EMAIL PROTECTED] On Behalf Of Steve Murphy -->> Sent: 11 December 2008 16:26 -->> To: Asterisk Users Mailing List - Non-Commercial Discussion -->> Subject: Re: [asterisk-users] CDR Design -->> -->> On Thu, 2008-12-11 at 11:37 +, Andrew Thomas wrote: -->> > I've just spotted another interesting CDR 'feature'. Data calls -->> don't -->> > get flagged as such. In other words - if I make an ISDN modem call -->> to -->> > another ISDN modem via. the PSTN, the source and destination -->> channels -->> > are set correctly (as is everything else in the current CDR) but -->> there -->> > is no record if it being a data call. -->> > -->> > Can the 'new style' (whatever it turns out to be) differentiate -->> between -->> > data and voice calls (eg. B and D channel ones on ISDN)? -->> > -->> -->> How do you picture this information appearing in a CDR? -->> Via another field, or some indication in an existing field? -->> -->> murf -->> Either/or is fine by me :). As long as there is some sort of indication I can parse - then I'm a happy bunny. Cheers Andy ___ -- 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 Design
On Thu, 2008-12-11 at 11:37 +, Andrew Thomas wrote: > I've just spotted another interesting CDR 'feature'. Data calls don't > get flagged as such. In other words - if I make an ISDN modem call to > another ISDN modem via. the PSTN, the source and destination channels > are set correctly (as is everything else in the current CDR) but there > is no record if it being a data call. > > Can the 'new style' (whatever it turns out to be) differentiate between > data and voice calls (eg. B and D channel ones on ISDN)? > How do you picture this information appearing in a CDR? Via another field, or some indication in an existing field? murf > Just one more thing to keep Papa Murf busy over the holidays :). > > Cheers > Andy > > -->> -Original Message- > -->> From: [EMAIL PROTECTED] > [mailto:asterisk-users- > -->> [EMAIL PROTECTED] On Behalf Of Anthony Francis > -->> Sent: 10 December 2008 18:19 > -->> To: [EMAIL PROTECTED]; asterisk-users@lists.digium.com > -->> Subject: Re: [asterisk-users] CDR Design > -->> > -->> > -->> > -->> Steve Murphy wrote: > -->> > Just to be pedantic, how would src_cid be different from the > clid > -->> field > -->> > that cdr's have now? > -->> > > -->> > and the same with src_exten vs. src; > -->> > > -->> > A simple example might help to let this sink into my brain. > -->> > > -->> > murf > -->> > > -->> > > -->> The main thing is that the originating number shouldn't be linked > to > -->> the > -->> callerid. This way you can do things like allow no callerid while > -->> maintaining billing integrity. > -->> Here is the CDR columns for one one of my providers that exhibits > -->> this: > -->> > -->> > -->> > -->> > -->> > -->> *Field Number* > -->> > -->> > -->> > -->> *Field Name* > -->> > -->> > -->> > -->> *Description* > -->> > -->> > -->> > -->> *Type* > -->> > -->> > -->> > -->> *Length* > -->> > -->> > -->> > -->> *Example* > -->> > -->> > -->> > -->> > -->> > -->> 1 > -->> > -->> > -->> > -->> SwitchBatchNbr > -->> > -->> > -->> > -->> Sequential, positive integer assigned to each CDR file imported > into > -->> the > -->> system > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->> > -->> > -->> 5594 > -->> > -->> > -->> > -->> > -->> > -->> 2 > -->> > -->> > -->> > -->> RecNbr > -->> > -->> > -->> > -->> Sequential, positive integer assigned to each CDR within a CDR > file. > -->> Together with the SwitchBatchNbr, a unique combination. > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->> > -->> > -->> 2354 > -->> > -->> > -->> > -->> > -->> > -->> 3 > -->> > -->> > -->> > -->> SwitchNbr > -->> > -->> > -->> > -->> Unique number identifying the switch from which the CDR was > processed > -->> or > -->> assigned > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Integer > -->> > -->> > -->> > -->> 13 > -->> > -->> > -->> > -->> > -->> > -->> 4 > -->> > -->> > -->> > -->> CustNbr > -->> > -->> > -->> > -->> The unique, numeric number assigned to a customer > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->>
Re: [asterisk-users] CDR Design
I've just spotted another interesting CDR 'feature'. Data calls don't get flagged as such. In other words - if I make an ISDN modem call to another ISDN modem via. the PSTN, the source and destination channels are set correctly (as is everything else in the current CDR) but there is no record if it being a data call. Can the 'new style' (whatever it turns out to be) differentiate between data and voice calls (eg. B and D channel ones on ISDN)? Just one more thing to keep Papa Murf busy over the holidays :). Cheers Andy -->> -Original Message- -->> From: [EMAIL PROTECTED] [mailto:asterisk-users- -->> [EMAIL PROTECTED] On Behalf Of Anthony Francis -->> Sent: 10 December 2008 18:19 -->> To: [EMAIL PROTECTED]; asterisk-users@lists.digium.com -->> Subject: Re: [asterisk-users] CDR Design -->> -->> -->> -->> Steve Murphy wrote: -->> > Just to be pedantic, how would src_cid be different from the clid -->> field -->> > that cdr's have now? -->> > -->> > and the same with src_exten vs. src; -->> > -->> > A simple example might help to let this sink into my brain. -->> > -->> > murf -->> > -->> > -->> The main thing is that the originating number shouldn't be linked to -->> the -->> callerid. This way you can do things like allow no callerid while -->> maintaining billing integrity. -->> Here is the CDR columns for one one of my providers that exhibits -->> this: -->> -->> -->> -->> -->> -->> *Field Number* -->> -->> -->> -->> *Field Name* -->> -->> -->> -->> *Description* -->> -->> -->> -->> *Type* -->> -->> -->> -->> *Length* -->> -->> -->> -->> *Example* -->> -->> -->> -->> -->> -->> 1 -->> -->> -->> -->> SwitchBatchNbr -->> -->> -->> -->> Sequential, positive integer assigned to each CDR file imported into -->> the -->> system -->> -->> -->> -->> Numeric -->> -->> -->> -->> Long Integer -->> -->> -->> -->> 5594 -->> -->> -->> -->> -->> -->> 2 -->> -->> -->> -->> RecNbr -->> -->> -->> -->> Sequential, positive integer assigned to each CDR within a CDR file. -->> Together with the SwitchBatchNbr, a unique combination. -->> -->> -->> -->> Numeric -->> -->> -->> -->> Long Integer -->> -->> -->> -->> 2354 -->> -->> -->> -->> -->> -->> 3 -->> -->> -->> -->> SwitchNbr -->> -->> -->> -->> Unique number identifying the switch from which the CDR was processed -->> or -->> assigned -->> -->> -->> -->> Numeric -->> -->> -->> -->> Integer -->> -->> -->> -->> 13 -->> -->> -->> -->> -->> -->> 4 -->> -->> -->> -->> CustNbr -->> -->> -->> -->> The unique, numeric number assigned to a customer -->> -->> -->> -->> Numeric -->> -->> -->> -->> Long Integer -->> -->> -->> -->> 1025 -->> -->> -->> -->> -->> -->> 5 -->> -->> -->> -->> AuthCode -->> -->> -->> -->> The authorization code used in the call. Can be the Switch/Trunk -->> combination (dedicated), ANI, Travel Card, 800 number, DID. -->> -->> -->> -->> Numeric -->> -->> -->> -->> Float -->> -->> -->> -->> 2145551212 -->> -->> -->> -->> -->> -->> 6 -->> -->> -->> -->> AcctCd -->> -->> -->> -->> The Account Code dialed with the CDR -->> -->> -->> -->> Numeric -->> -->> -->> -->> Long Integer -->> -->> -->> -->> 2331 -->> -->> -->> -->> -->> -->> 7 -->> -->> -->> -->>
Re: [asterisk-users] CDR Design
Steve Murphy wrote: > Just to be pedantic, how would src_cid be different from the clid field > that cdr's have now? > > and the same with src_exten vs. src; > > A simple example might help to let this sink into my brain. > > murf > > The main thing is that the originating number shouldn't be linked to the callerid. This way you can do things like allow no callerid while maintaining billing integrity. Here is the CDR columns for one one of my providers that exhibits this: *Field Number* *Field Name* *Description* *Type* *Length* *Example* 1 SwitchBatchNbr Sequential, positive integer assigned to each CDR file imported into the system Numeric Long Integer 5594 2 RecNbr Sequential, positive integer assigned to each CDR within a CDR file. Together with the SwitchBatchNbr, a unique combination. Numeric Long Integer 2354 3 SwitchNbr Unique number identifying the switch from which the CDR was processed or assigned Numeric Integer 13 4 CustNbr The unique, numeric number assigned to a customer Numeric Long Integer 1025 5 AuthCode The authorization code used in the call. Can be the Switch/Trunk combination (dedicated), ANI, Travel Card, 800 number, DID. Numeric Float 2145551212 6 AcctCd The Account Code dialed with the CDR Numeric Long Integer 2331 7 CallMMDD Call date at time of answer (MMDD format) Numeric Long Integer 20020131 8 CallHHMMSS Call time at time of answer (HHMMSS format) Numeric Long Integer 205618 9 DestNbr Destination Phone Number Char 18 2145551212 10 DialedNumber Dialed Number Char 18 12145551212 11 ThirdPartyNbr Third Party Number Char 18 2145551212 12 DestCity Destination city name Char 15 Dallas 13 DestState Destination state name Char 2 TX 14 DestOCN Destination OCN Char 4 9100 15 DestLata Destination LATA Numeric integer 552 16 IntraInter Flag indicating jurisdiction: 1=Intralata, 2=Intrastate, 3=Interstate, 4=Canada, 5=Intl, Mexico Numeric Integer 1 17 CallType Flag indicating type of call. See Appendix A: Call Type Codes. Char 3 OE 18 DurMinutes The rounded, billable duration of a rated call. Detailed to a tenth of a minute. Numeric Decimal 10,4 1.5000 19 CustRev The revenue computed for the CDR Numeric Decimal 10,4 0.0168 20 Surchrg The surcharge amount for the CDR Numeric Decimal 10,4 0. 21 OrigNbr Originating Phone Number Char 18 2145551212 22 OrigCity Originating City Char 15 DIR ASST 23 OrigState Originating State Char 2 TX 24 OrigOCN Originating OCN Char 4 9100 25 OrigLata Originating LATA Numeric Integer 552 26 SiteNbr Info digit assigned to CDR. Currently, Site Numbers: 7, 25, 27, 29, 70 are considered payphone Numeric Integer 0 27 SiteSurChrg Charge associated with payphone use as determined by the SiteNbr Numeric Decimal 10,4 . 28 ExtractSeqNbr Number used to designate a batch of CDR's that were extracted. If not used, value will be NULL. Numeric Integer 156 -- Thank you and have any kind of day you want, Anthony Francis Rockynet VOIP (303) 444-7052 opt 2 [EMAIL PROTECTED] ___
Re: [asterisk-users] CDR Design
Steve Murphy wrote: > > Well, read my draft RFC, and see if I'm on the right track. > > Tune into CDR Design in the subject line in this email > > list, and let's toss this around and see if consensus is > > possible. > > > > murf > > > > > First my apologies for this repost, my system date got messed up and this post looked like it was sent on Nov 5th :). One of the problems I generally have with cdr's in my multi-tenant hosted VOIP world, is that the src is inexorably tied to the callerid field, this makes it a pain when you have a billing system based on TDM billing systems that have not only a src field but an originating src field. This is what allows you to know what number placed the call but still allow things like no callerid. In a perfect world the fields would be src_cid src exten. When calls do not originate from within your dialplan (external to internal calls) most of these fields would be null or repetitive. I know many of you would say you know the originator of the call by the channel, but in a multitenant situation you can't have two sip devices named [100] so you use special ID's and have to do post-processing to determine that information. -- Thank you and have any kind of day you want, Anthony Francis Rockynet VOIP (303) 444-7052 opt 2 [EMAIL PROTECTED] ___ -- 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 Design
Steve Murphy wrote: > Well, read my draft RFC, and see if I'm on the right track. > Tune into CDR Design in the subject line in this email > list, and let's toss this around and see if consensus is > possible. > > murf > > One of the problems I generally have with cdr's in my multi-tenant hosted VOIP world, is that the src is inexorably tied to the callerid field, this makes it a pain when you have a billing system based on TDM billing systems that have not only a src field but an originating src field. This is what allows you to know what number placed the call but still allow things like no callerid. In a perfect world the fields would be src_cid src exten. When calls do not originate from within your dialplan (external to internal calls) most of these fields would be null or repetitive. I know many of you would say you know the originator of the call by the srcdevice, but in a multitenant situation you can't have two sip devices named [100] so you use special ID's and have to do post-processing to determine that information. -- Thank you and have any kind of day you want, Anthony Francis Rockynet VOIP (303) 444-7052 opt 2 [EMAIL PROTECTED] ___ -- 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 Design
> On Fri, Dec 5, 2008 at 8:11 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: > > Hmmm. See your point. I can suppress these HOLD events, and any > others I end up covering with a config file. Whether it's by default > on or off, we can arrange as the majority, whatever that is, > requests. > > In my current line of thinking, the HOLD period was output to > help describe what was done with the channel. Whether folks > on hold are charged the same as folks not on hold, that's a > business decision. > > I personally cannot predict with any certainty what folks > will be interested in billing or not billing. You seem pretty > certain that HOLD information is useless to billing, but can you > guarantee me that this info is useless in all possible billing > situations? No I can't but it would be the first I'd ever heard of anybody being differently when they were on hold compared to a normal call. Putting a call hold does not change the original call ends and the time on those calls keeps ticking so I can guarantee you there a people like me that want to bill the call besed on endpoints and whether the call is on hold, listening to streaming radio, being sent a festival tts message etc. is irrelevant. > Well, if I take a UUID type field and tack it onto the end of the > current LinkedID, will that do? I get something I can sort timewise > and make a quick decision on; you get something that but once every > billion-trillion-gazillion times, will be unique. And you can also > tack a system id onto the end, or the begin for that matter, on the > way to the database In my perfect World I'd change uniqueid to a UUID since that's what it claims to falsely be. But as you say there are other ways a unique id can be added and if needs be we could do it that way. I've being trying to avoid a bunch of comma separated data in the UserField but that's no big deal either way. > maybe. But, you can do one-touch stuff via dtmf to asterisk, and > do transfers that way. How this might reflect back into the sip > protocal, I'm not certain right now. A sip device might not be > able to tell what happened, but this is conjecture on my part. No it doesn't. A SIP transfer is a striaght forward operation and the only way to do one is with a REFER request. How you generate the REFER request can be different such as DTMF or transfer button but the effect is identical. When Asterisk processes the REFER request it is going to end up initiaiting a call and for a blind transfer hanging one up. That's it. > I'll have to think on this. Perhaps an option to reduce everything > to single per-chan cdrs. It'll be a ton easier to implement something > like this by NOT storing the CDR on a channel. In my life as a software engineer simple solutions tend to be the right ones. 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 Design
On Fri, 2008-12-05 at 16:32 +, Grey Man wrote: > Another thing to be aware of as the wish list for the Asterisk CDR > continues to grow is that right now Asterisk does not lend itself to > accurately creating the most fundamental requirement of a CDR which is > to accurately record at the very least the originator, destination, > time and duration for EVERY call Asterisk processes. We'll have to make sure the spec covers this info and where it goes, carefully. Then all I have to do is follow the spec. Simple. (murf rolls eyes) > It's already proven to be a very hard requirement to meet for Asterisk > given the original CDR design and implementation and to my mind there > is no point trying to add more sohisticated behaviour - call flows, > events, linked ids etc. - until it has been. The more convoluted any > new design gets the less chance it has of ever getting implemented in > the near future. Getting a basic accurate CDR system in place does not > preclude future enhancements but without it they'll just add another > few layers to the house of cards. > > Regards, > > Greyman. > -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 15:46 +0200, Apostolos Pantsiopoulos wrote: ... > In the first situation you need a real time system, but in the second > situation > you don't. > > Being a programmer that dealt with both situations I can say that we > need both approaches in asterisk :). In fact the LEGO paradigm > would be the ideal solution. I think that asterisk should cope > with both situations instead of just choosing one. > I think we all agree on that. I agree, too. Only trouble is, there's only so many hours in a day! murf -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 13:41 +, Andrew Thomas wrote: > "Pardon me," > > Granted ;). > > "I have created realtime stats package that's based on CDR, you see new > info immediately after call leg/event is over" > > I see what you are saying but can you show hold-times etc? For example, > call comes in to A, A puts call on hold, A dials B, B answers A, A > transfers call to B, B speaks to caller. Basic PBX functionality - but > how long did it take B to answer A? What if B is an external number > (trunk to trunk)? > > To illustrate - dial an external number and, while on that call, check > your CDR's - there isn't any. Now put that call on hold, still none, > now call another internal extension - still none. Now hang up and > transfer the call. Now there is one CDR for your call. That isn't > real-time - that's historic (ie. it happens AFTER the call is finished). > > The CDR that's produced here will show your call to the outside world - > and its duration etc. So far, so good (for historic reporting). Now get > the person you transferred the call to to hang up. Another CDR record > - but this show as you talking to the internal extension - not the > external extension talking to the outside world. > > Therefore, if the 2nd extension stays on that call for a long time - > who's picking up the bill? > > Current CDR's are lacking in this respect - and I think this is what > murf is trying to sort out (please jump in here murf). > > murf jumps: Read the emerging spec: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=log click on (view) in the first numbered Revision. Or, fetch it to your machine via svn checkout: http://svn.digium.com/svn/asterisk/team/murf/RFCs And publish your scathing comments, loathing, compliments, whatever, and we can hammer out the spec. murf -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 15:32 +0200, Apostolos Pantsiopoulos wrote: > But the new CDRs that we are discussing would have to deal > with transfers correctly. I think that's where the whole thing started. > > I am not happy with the current CDRs system either. I find it obsolete. > That is why I am not using it for billing purposes. But a NEW one that > meets certain criteria would be ideal for billing. > Well, read my draft RFC, and see if I'm on the right track. Tune into CDR Design in the subject line in this email list, and let's toss this around and see if consensus is possible. svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and an occasional "svn update" in the RFCs dir will keep you up to date. Or you can just read it via your browser at: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=log and choose the (view) of the first numbered revision in the list to see the latest version. murf -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 14:47 +0200, Atis Lezdins wrote: > On Fri, Dec 5, 2008 at 2:35 PM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > > "I'd disagree. In some cases a event based system would be the best > > solution, but in systems with high call volumes, scanning through events > > > > looking for the proper billing information and parsing them would be a > > hard job compared to CDRs." > > > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > > Events. Your 3rd party app could then do anything it wanted to with > > them. > > > > Events are real time - not historic (like CDR's). Events are presented > > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > > call has finished so you miss things like hold-times etc. > > > > Remember, I am not saying that everyone should stop using the CDR's if > > they feel comfortable with them - but I, for one, don't trust them for > > building a stable billing platform or a real time stats package (which > > more and more customers seem to want these days). > > Pardon me, > > I have created realtime stats package that's based on CDR, you see new > info immediately after call leg/event is over > > http://ftp.iq-labs.net/screenshots/cdr_view.jpg > > > If you start to change the CDR's to account for extra bits (using a > > unique ID) then your 'scanning' actually increases as you will need to > > tie up all the unique ID's to get one full call progress path. > > This is exactly how real-time billing works. If you somebody wants it, > they put in custom ResetCDR(w) in their dialplan and have all kinds of > events logged. Having Asterisk write all the timestamps/durations into > database is just much simpler. > > > Please note, I am not trying to cause flame wars here - just stating > > that I'd love an event based stream, that I can parse any way I see fit. > > I know there's the AMI - but that is a 2-way, give-you-everything > > solution. All I want is to know when a handset and/or trunk does > > something (I don't care about SIP registrations etc). > > > > I guess we'll just have to wait and see what santa murf gives us all for > > Christmas :). > > > > I really want to contribute this discussion (and RFC), i'm reading it > and i have lot of to say, but it's hard to find time for reading RFC > (i'm in middle yet). So, i hope this will go on and allow me to > respond with some objective comments. Atis-- I welcome your input. I don't want to write junk. And to make this useful to as many users as possible, I need to know what they need/want. I can't possibly make everyone happy, but I might get away with giving them something that makes getting to their desination possible. There's many ways to get a job done. I'm looking for the simplest and the most complete/general. murf > > Regards, > Atis > > -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 12:35 +, Andrew Thomas wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > > Remember, I am not saying that everyone should stop using the CDR's if > they feel comfortable with them - but I, for one, don't trust them for > building a stable billing platform or a real time stats package (which > more and more customers seem to want these days). > > If you start to change the CDR's to account for extra bits (using a > unique ID) then your 'scanning' actually increases as you will need to > tie up all the unique ID's to get one full call progress path. > > Please note, I am not trying to cause flame wars here - just stating > that I'd love an event based stream, that I can parse any way I see fit. > I know there's the AMI - but that is a 2-way, give-you-everything > solution. All I want is to know when a handset and/or trunk does > something (I don't care about SIP registrations etc). > > I guess we'll just have to wait and see what santa murf gives us all for > Christmas :). > LOL, santa murf here, just making note that a generic CDR generator, maybe with a few different flavors, generating CDR's 'realtime' or done on event logs once a month standalone, isn't going to be a walk in the park. Sure, there's going to be some simple bits to it, but as in every system with a fair number of event types, exceptions to rules, etc., it's going to involve some serious thinking, blood, sweat and tears. The code will encapsulate some hard-earned experience, minus some false assumptions that had to be corrected. Now, it might end up being a walk in the park, and maybe I'm just being pessimistic, but personally, as a programmer, a CDR spec is going to be easier to bill from than a sequence of interlaced events. 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 -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 10:52 +, Andrew Thomas wrote: > Thanks for this Greyman - it's all beginning to make sense now ;). > > I agree that the 'loss of CDR upon txfr' is a nasty bug which does need > to be addressed before anything else (assuming it hasn't been already). > > But, wouldn't it be better if you could ignore the CDR's completely and > use an event based system? This would give you ALL the information you > need. All that remains is to filter out the un-required bits. > > Like I said earlier - the CDR's aren't reliable enough for a billing > platform (as you've rightly pointed out) but are OK for very basic call > logging (something the customer can look at). > > Hopefully, the murf'ster will chirp in here :). > I'll Chirp here. I'm kinda impressed with the number of CDR Design messages in the Q since last I checked, but I'll try to plow my way thru them. I've been ruminating over Greyman's suggestion about simplified CDR's for the past few days, stepped outside my 'box', and I think realized what he actually was asking for, at last. As to the event system, say no more. CEL is it. It will spew out all possible CDR related events in any of several formats, in somewhat real-time (as they occur) order. The state of the channels are included with the time of each event. But, this alone isn't really useful in a database. Try coming up with SQL queries that tell you useful things about what's happened, or happening... CDR format is useful that way; and, like Brian, yes, you can mix the two to your heart's content, even add manager events to the mix. murf > Cheers > Andy > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man > Sent: 05 December 2008 09:37 > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] CDR Design > > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> > wrote: > > > > In summary: Leave CDR exactly as it is and create a new CEL (Call > Event > > Logging) module (optional in modules.conf) that puts out (and does not > > accept) call event information (ie. a one-way fire-and-forget output > > from Asterisk). > > > > Hi Andrew and Others, > > This thread is actually part of a discussion that has been going on > for over a year. The links below provide the background to the whole > thing. > > http://www.asterisk.org/node/48358 > http://bugs.digium.com/view.php?id=11849 > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm > l > > Up until recently the approach was to try and fix the specific bugs > with transfer CDRs as a typical bug. There is now a realisation that > that is a lot trickier than inially thought so it's been decided to > try and come up with a good design for the Asterisk CDR sub-system. > > 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 > > ___ > -- 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 -- Steve Murphy Software Developer 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 Design
On Fri, 2008-12-05 at 13:39 +0200, [EMAIL PROTECTED] wrote: > Quote : "Like I said earlier - the CDR's aren't > reliable enough for a billing platform (as you've > rightly pointed out) but are OK for very basic call > logging (something the customer can look at)." > > I couldn't disagree more. The CDRs is the MOST reliable > source for billing purposes (in postpaid mode that is - > for prepaid you have to use something else (although > even then the CDRs can be helpful for consistency checks)). > > Other alternatives (e.g. radius) could not give you > the same level of consistency as the CDRs (although better > than other implementations because the gateway retries > to send the packet many times before giving up). What would > happen if your radius server was overloaded and could > not process accounting packets for a few secs/mins/hours? > What would happen if the network is down (and the event > processing handler is in another box)? > All these calls would be lost. This can rarely be seen > with CDRs logging. Because, whatever might happen you can > always count on them to rectify the situation. > > I think the same can be said about other event based > billing setups. The gateway itself cannot (and shouldn't > really) be aware if the event was successfully processed by > the handling back-end so you end up with inconsistent data > and lost calls. > > Now, a combination of the two (e.g. radius+CDRs) can cover > all the possible gone-wrong scenarios. But in order for that > to work you need all the detailing you can get in the CDR. > > If ,however, you don't want to load your gateway with complex > CDRs you could entirely turn them off (or parts of it e.g. b-leg > logging, log only a few details etc). > > Well, if we spec some options, and it doesn't get *too* out of control, we can spell out a few different scenarios for the generated CDR's. Greyman's just wanting to know how long A was connected, how long B, etc, is an entirely different approach than spelling out each leg. Dropping stuff like HOLD and PARKING is possible, too. > > Andrew Thomas wrote: > > Thanks for this Greyman - it's all beginning to make sense now ;). > > > > I agree that the 'loss of CDR upon txfr' is a nasty bug which does need > > to be addressed before anything else (assuming it hasn't been already). > > > > But, wouldn't it be better if you could ignore the CDR's completely and > > use an event based system? This would give you ALL the information you > > need. All that remains is to filter out the un-required bits. > > > > Like I said earlier - the CDR's aren't reliable enough for a billing > > platform (as you've rightly pointed out) but are OK for very basic call > > logging (something the customer can look at). > > > > Hopefully, the murf'ster will chirp in here :). > > > > Cheers > > Andy > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man > > Sent: 05 December 2008 09:37 > > To: Asterisk Users Mailing List - Non-Commercial Discussion > > Subject: Re: [asterisk-users] CDR Design > > > > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> > > wrote: > > > > > In summary: Leave CDR exactly as it is and create a new CEL (Call > > > > > Event > > > > > Logging) module (optional in modules.conf) that puts out (and does not > > > accept) call event information (ie. a one-way fire-and-forget output > > > from Asterisk). > > > > > > > > > > Hi Andrew and Others, > > > > This thread is actually part of a discussion that has been going on > > for over a year. The links below provide the background to the whole > > thing. > > > > http://www.asterisk.org/node/48358 > > http://bugs.digium.com/view.php?id=11849 > > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm > > l > > > > Up until recently the approach was to try and fix the specific bugs > > with transfer CDRs as a typical bug. There is now a realisation that > > that is a lot trickier than inially thought so it's been decided to > > try and come up with a good design for the Asterisk CDR sub-system. > > > > Regards, > > > > Greyman. > > > > ___ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > asterisk-users mailing list
Re: [asterisk-users] CDR Design
On Wed, 2008-12-03 at 08:11 +, Andrew Thomas wrote: > It seems to me that we are confusing billing and logging here. Call > billing only really needs the start and finish (like we get now) - but > proper call logging requires all steps. > > Do we leave CDR's as they are (for billing purposes) and have a separate > 'event' driven log for call logging? Or do we change the CDR structure > to accommodate logging as well? > > Personally, a separate 'event' log seems preferable to me as this keeps > existing billing platforms useable. It just means the logging programs > will need to be re-written to look at a new database for events. > > I know we have the AMI - but that puts out a lot more information than > is needed for simple logging (and requires something to prune and store > the events in a database of some sort). > That's the classic tradeoff... too much vs. too little detail. If you want 3 tons of detail, use Manager. If you want just 1 ton of detail, use CEL If you want a half-ton of detail, with time diffs built in, use CDR. There are some other differentiating factors... like the fact that CDRs do provide some grouping of events natural to billing. At any rate, NONE of them can be directly used for a billing app (if any currently can, you may have a problem!) --and I've seen folks use hybrid mixtures of the above to put together "The Perfect Billing System". murf > Any thoughts? > > Andrew Thomas > Technical Services Manager > DataVox Ltd > Saddleworth Business Centre > Huddersfield Road > Delph, Oldham > OL3 5DF > -- Steve Murphy Software Developer 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 Design
> I agree with the fact that the base is broken and needs to be fixed > first. > > -- We wouldn't have this discussion if we had a close to perfect CDR design that just needed some 'fixing'. The processes of just adding another couple of patches has been ongoing for more than year now. I think that phase 1 should be creation of the new CDR's according to Steve's spec. A phase 2 could be an addon to CDR module or external script that would create a CDR record exactly as the old CDR record so we maintain backward compatibility with peoples existing billing systems that run on CDR's. Imagine that the existing CDR module collect the events as the are generated and then when it would create the CDR as it does now it runs the config controlled interpreter that convert the eventlist to the old CDR records. For simple Asterisk usage it would stil work 'out-of-the-box' with existing callingcard billing a.s.o. So for those that 'just' want simple CDR's this change wouldn't change anything as long as they don't lift the hood. The benefit would be that all event generation would be decoupled from the business logic thats in place for CDR generation and users may have control over that business logic. Using these events for 'realtime' stuff is anther spinoff but not the primary reason my 2 cent. Freddi ___ -- 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 Design
Grey Man wrote: > Another thing to be aware of as the wish list for the Asterisk CDR > continues to grow is that right now Asterisk does not lend itself to > accurately creating the most fundamental requirement of a CDR which is > to accurately record at the very least the originator, destination, > time and duration for EVERY call Asterisk processes. > > It's already proven to be a very hard requirement to meet for Asterisk > given the original CDR design and implementation and to my mind there > is no point trying to add more sohisticated behaviour - call flows, > events, linked ids etc. - until it has been. The more convoluted any > new design gets the less chance it has of ever getting implemented in > the near future. Getting a basic accurate CDR system in place does not > preclude future enhancements but without it they'll just add another > few layers to the house of cards. > > 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 > I agree with the fact that the base is broken and needs to be fixed first. -- Thank you and have any kind of day you want, Anthony Francis ___ -- 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 Design
Another thing to be aware of as the wish list for the Asterisk CDR continues to grow is that right now Asterisk does not lend itself to accurately creating the most fundamental requirement of a CDR which is to accurately record at the very least the originator, destination, time and duration for EVERY call Asterisk processes. It's already proven to be a very hard requirement to meet for Asterisk given the original CDR design and implementation and to my mind there is no point trying to add more sohisticated behaviour - call flows, events, linked ids etc. - until it has been. The more convoluted any new design gets the less chance it has of ever getting implemented in the near future. Getting a basic accurate CDR system in place does not preclude future enhancements but without it they'll just add another few layers to the house of cards. 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 Design
Anthony Francis wrote: Atis Lezdins wrote: When i started to write this implementation, luckily i didn't had much expertise in telephony, so i did it from programmers point of view. There's even funny story about this in our company - we had some "Project managers" and "Development managers" hired later who had lots of experience in telephony, and at some point when discussing some minor problems with my implementation, they told me that this is not the way how to do it. Telco's do all processing at end of month, so this system won't last for long. Currenty everybody in our company probably would be very disappointed if they wouldn't be able to see fresh data in reports immediately. Regards, Atis Just because that is the way Telco's do it doesn't mean that it is the way it SHOULD be done, there is always room for improvement and fresh ideas. I also believe near realtime CDR is not only possible but should be used, the only thing I do once a month is long distance consolidation for billing, I use multiple LD carriers and all of their monthly records need to be normalized and consolidated with our records. I don't think that all Telco's are using the same procedure for billing. Sometimes they use both. There are Telco's that provide pre-paid services (calling cards, pre-paid mobile services etc) and their calls have to be billed in real-time mode. The same Telco can use a CDR aggregation model to bill their post-paid customers. -- --- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [EMAIL PROTECTED] --- ___ -- 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 Design
Andrew Thomas wrote: > Quote : "I couldn't disagree more. The CDRs is the MOST reliable > source for billing purposes" > > ...at the moment. Have you read about Greyman's transfer problem? > > If you are billing customers purely on the CDR output from Asterisk - > then good luck to you :). This is exactly our point in this discussion. :):) We can't bill relying on Asterisk's CDRs at this moment, this is why we use a third party SBC to do real time billing & stats, as well as collect CDRs from the SBC off-line for cross-checking with the live data. And this is why we support the opinion that Asterisk's CDRs should be expanded. Best regards, Vlasis Hatzistavrou. ___ -- 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 Design
Atis Lezdins wrote: > When i started to > write this implementation, luckily i didn't had much expertise in > telephony, so i did it from programmers point of view. There's even > funny story about this in our company - we had some "Project managers" > and "Development managers" hired later who had lots of experience in > telephony, and at some point when discussing some minor problems with > my implementation, they told me that this is not the way how to do it. > Telco's do all processing at end of month, so this system won't last > for long. Currenty everybody in our company probably would be very > disappointed if they wouldn't be able to see fresh data in reports > immediately. > > > Regards, > Atis > > Just because that is the way Telco's do it doesn't mean that it is the way it SHOULD be done, there is always room for improvement and fresh ideas. I also believe near realtime CDR is not only possible but should be used, the only thing I do once a month is long distance consolidation for billing, I use multiple LD carriers and all of their monthly records need to be normalized and consolidated with our records. -- Thank you and have any kind of day you want, Anthony Francis Rockynet VOIP (303) 444-7052 opt 2 [EMAIL PROTECTED] ___ -- 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 Design
Hello, Andrew Thomas wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > Indeed, if you refer to real time events then this is the way to go. However, many people (including our company) use CDRs as a fall back in case we don't have real-time billing data available. We use real time information for prepaid customers and stats, but we also crosscheck this data with CDRs periodically. I agree that both approaches would be useful in many different scenarios for different users. It would be ideal if both approaches could be implemented. Best regards, Vlasis Hatzistavrou. ___ -- 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 Design
On Fri, Dec 5, 2008 at 3:41 PM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > "Pardon me," > > Granted ;). > > "I have created realtime stats package that's based on CDR, you see new > info immediately after call leg/event is over" > > I see what you are saying but can you show hold-times etc? For example, > call comes in to A, A puts call on hold, A dials B, B answers A, A > transfers call to B, B speaks to caller. Basic PBX functionality - but > how long did it take B to answer A? What if B is an external number > (trunk to trunk)? > > To illustrate - dial an external number and, while on that call, check > your CDR's - there isn't any. Now put that call on hold, still none, > now call another internal extension - still none. Now hang up and > transfer the call. Now there is one CDR for your call. That isn't > real-time - that's historic (ie. it happens AFTER the call is finished). Well, by "real-time" i meant that you don't have to run CDR processing at the end of month to see some reports/logs, etc. When i started to write this implementation, luckily i didn't had much expertise in telephony, so i did it from programmers point of view. There's even funny story about this in our company - we had some "Project managers" and "Development managers" hired later who had lots of experience in telephony, and at some point when discussing some minor problems with my implementation, they told me that this is not the way how to do it. Telco's do all processing at end of month, so this system won't last for long. Currenty everybody in our company probably would be very disappointed if they wouldn't be able to see fresh data in reports immediately. Regarding hold and transfers, yes - you can't achieve that in real-real-time, but i think it's not important. Calls don't last for several days, and even if they do - you have different view where you can see active calls. It's completely logical that CDR's get posted after finishing certain action - in order to account correct timing. Otherwise Asterisk would have to post a record, and later modify it (yet another minefield). > The CDR that's produced here will show your call to the outside world - > and its duration etc. So far, so good (for historic reporting). Now get > the person you transferred the call to to hang up. Another CDR record > - but this show as you talking to the internal extension - not the > external extension talking to the outside world. > > Therefore, if the 2nd extension stays on that call for a long time - > who's picking up the bill? > > Current CDR's are lacking in this respect - and I think this is what > murf is trying to sort out (please jump in here murf). > I would like to comment really much of this, but I'll refrain until i complete reading Murf's RFC. I just don't feel competent enough to speak about this without reading he's ideas first. Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, IQ Labs Inc, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 ___ -- 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 Design
Amen! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Apostolos Pantsiopoulos Sent: 05 December 2008 13:46 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] CDR Design Quote : "That's just it - you wouldn't be 'scanning' any CDR's - you'd be given Events. Your 3rd party app could then do anything it wanted to with them." A 3rd party "live" application introduces one more point of failure in the whole process. A 3rd party CDRs aggregator can run at its own pace (and multiple times if any issue arises). A 3rd party "live" application could get choked on heavy loads and introduce inconsistency. I think what Vlasis suggests is that there are times that you need an event-based system (PBX, predictive dialing etc). And there are times that you need bulk non-realtime processing of the CDRs (sometimes the billing can be done days or weeks after the actual call). In the first situation you need a real time system, but in the second situation you don't. Being a programmer that dealt with both situations I can say that we need both approaches in asterisk :). In fact the LEGO paradigm would be the ideal solution. I think that asterisk should cope with both situations instead of just choosing one. I think we all agree on that. -- --- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [EMAIL PROTECTED] --- Andrew Thomas wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > > Remember, I am not saying that everyone should stop using the CDR's if > they feel comfortable with them - but I, for one, don't trust them for > building a stable billing platform or a real time stats package (which > more and more customers seem to want these days). > > If you start to change the CDR's to account for extra bits (using a > unique ID) then your 'scanning' actually increases as you will need to > tie up all the unique ID's to get one full call progress path. > > Please note, I am not trying to cause flame wars here - just stating > that I'd love an event based stream, that I can parse any way I see fit. > I know there's the AMI - but that is a 2-way, give-you-everything > solution. All I want is to know when a handset and/or trunk does > something (I don't care about SIP registrations etc). > > I guess we'll just have to wait and see what santa murf gives us all for > Christmas :). > > > > ___ > -- 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 > ___ -- 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 ___ -- 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 Design
Quote : "That's just it - you wouldn't be 'scanning' any CDR's - you'd be given Events. Your 3rd party app could then do anything it wanted to with them." A 3rd party "live" application introduces one more point of failure in the whole process. A 3rd party CDRs aggregator can run at its own pace (and multiple times if any issue arises). A 3rd party "live" application could get choked on heavy loads and introduce inconsistency. I think what Vlasis suggests is that there are times that you need an event-based system (PBX, predictive dialing etc). And there are times that you need bulk non-realtime processing of the CDRs (sometimes the billing can be done days or weeks after the actual call). In the first situation you need a real time system, but in the second situation you don't. Being a programmer that dealt with both situations I can say that we need both approaches in asterisk :). In fact the LEGO paradigm would be the ideal solution. I think that asterisk should cope with both situations instead of just choosing one. I think we all agree on that. -- --- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [EMAIL PROTECTED] --- Andrew Thomas wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > > Remember, I am not saying that everyone should stop using the CDR's if > they feel comfortable with them - but I, for one, don't trust them for > building a stable billing platform or a real time stats package (which > more and more customers seem to want these days). > > If you start to change the CDR's to account for extra bits (using a > unique ID) then your 'scanning' actually increases as you will need to > tie up all the unique ID's to get one full call progress path. > > Please note, I am not trying to cause flame wars here - just stating > that I'd love an event based stream, that I can parse any way I see fit. > I know there's the AMI - but that is a 2-way, give-you-everything > solution. All I want is to know when a handset and/or trunk does > something (I don't care about SIP registrations etc). > > I guess we'll just have to wait and see what santa murf gives us all for > Christmas :). > > > > ___ > -- 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 > ___ -- 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 Design
"Pardon me," Granted ;). "I have created realtime stats package that's based on CDR, you see new info immediately after call leg/event is over" I see what you are saying but can you show hold-times etc? For example, call comes in to A, A puts call on hold, A dials B, B answers A, A transfers call to B, B speaks to caller. Basic PBX functionality - but how long did it take B to answer A? What if B is an external number (trunk to trunk)? To illustrate - dial an external number and, while on that call, check your CDR's - there isn't any. Now put that call on hold, still none, now call another internal extension - still none. Now hang up and transfer the call. Now there is one CDR for your call. That isn't real-time - that's historic (ie. it happens AFTER the call is finished). The CDR that's produced here will show your call to the outside world - and its duration etc. So far, so good (for historic reporting). Now get the person you transferred the call to to hang up. Another CDR record - but this show as you talking to the internal extension - not the external extension talking to the outside world. Therefore, if the 2nd extension stays on that call for a long time - who's picking up the bill? Current CDR's are lacking in this respect - and I think this is what murf is trying to sort out (please jump in here 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
Re: [asterisk-users] CDR Design
But the new CDRs that we are discussing would have to deal with transfers correctly. I think that's where the whole thing started. I am not happy with the current CDRs system either. I find it obsolete. That is why I am not using it for billing purposes. But a NEW one that meets certain criteria would be ideal for billing. -- --- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [EMAIL PROTECTED] --- Andrew Thomas wrote: > Quote : "I couldn't disagree more. The CDRs is the MOST reliable > source for billing purposes" > > ...at the moment. Have you read about Greyman's transfer problem? > > If you are billing customers purely on the CDR output from Asterisk - > then good luck to you :). > > > > ___ > -- 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 > ___ -- 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 Design
On Fri, Dec 5, 2008 at 2:35 PM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > > Remember, I am not saying that everyone should stop using the CDR's if > they feel comfortable with them - but I, for one, don't trust them for > building a stable billing platform or a real time stats package (which > more and more customers seem to want these days). Pardon me, I have created realtime stats package that's based on CDR, you see new info immediately after call leg/event is over http://ftp.iq-labs.net/screenshots/cdr_view.jpg > If you start to change the CDR's to account for extra bits (using a > unique ID) then your 'scanning' actually increases as you will need to > tie up all the unique ID's to get one full call progress path. This is exactly how real-time billing works. If you somebody wants it, they put in custom ResetCDR(w) in their dialplan and have all kinds of events logged. Having Asterisk write all the timestamps/durations into database is just much simpler. > Please note, I am not trying to cause flame wars here - just stating > that I'd love an event based stream, that I can parse any way I see fit. > I know there's the AMI - but that is a 2-way, give-you-everything > solution. All I want is to know when a handset and/or trunk does > something (I don't care about SIP registrations etc). > > I guess we'll just have to wait and see what santa murf gives us all for > Christmas :). > I really want to contribute this discussion (and RFC), i'm reading it and i have lot of to say, but it's hard to find time for reading RFC (i'm in middle yet). So, i hope this will go on and allow me to respond with some objective comments. Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, IQ Labs Inc, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 ___ -- 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 Design
"I'd disagree. In some cases a event based system would be the best solution, but in systems with high call volumes, scanning through events looking for the proper billing information and parsing them would be a hard job compared to CDRs." That's just it - you wouldn't be 'scanning' any CDR's - you'd be given Events. Your 3rd party app could then do anything it wanted to with them. Events are real time - not historic (like CDR's). Events are presented as they happen (hold, ring, etc) - CDR's are usually presented AFTER the call has finished so you miss things like hold-times etc. Remember, I am not saying that everyone should stop using the CDR's if they feel comfortable with them - but I, for one, don't trust them for building a stable billing platform or a real time stats package (which more and more customers seem to want these days). If you start to change the CDR's to account for extra bits (using a unique ID) then your 'scanning' actually increases as you will need to tie up all the unique ID's to get one full call progress path. Please note, I am not trying to cause flame wars here - just stating that I'd love an event based stream, that I can parse any way I see fit. I know there's the AMI - but that is a 2-way, give-you-everything solution. All I want is to know when a handset and/or trunk does something (I don't care about SIP registrations etc). I guess we'll just have to wait and see what santa murf gives us all for Christmas :). ___ -- 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 Design
Quote : "I couldn't disagree more. The CDRs is the MOST reliable source for billing purposes" ...at the moment. Have you read about Greyman's transfer problem? If you are billing customers purely on the CDR output from Asterisk - then good luck to you :). ___ -- 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 Design
Quote : "Like I said earlier - the CDR's aren't reliable enough for a billing platform (as you've rightly pointed out) but are OK for very basic call logging (something the customer can look at)." I couldn't disagree more. The CDRs is the MOST reliable source for billing purposes (in postpaid mode that is - for prepaid you have to use something else (although even then the CDRs can be helpful for consistency checks)). Other alternatives (e.g. radius) could not give you the same level of consistency as the CDRs (although better than other implementations because the gateway retries to send the packet many times before giving up). What would happen if your radius server was overloaded and could not process accounting packets for a few secs/mins/hours? What would happen if the network is down (and the event processing handler is in another box)? All these calls would be lost. This can rarely be seen with CDRs logging. Because, whatever might happen you can always count on them to rectify the situation. I think the same can be said about other event based billing setups. The gateway itself cannot (and shouldn't really) be aware if the event was successfully processed by the handling back-end so you end up with inconsistent data and lost calls. Now, a combination of the two (e.g. radius+CDRs) can cover all the possible gone-wrong scenarios. But in order for that to work you need all the detailing you can get in the CDR. If ,however, you don't want to load your gateway with complex CDRs you could entirely turn them off (or parts of it e.g. b-leg logging, log only a few details etc). Andrew Thomas wrote: Thanks for this Greyman - it's all beginning to make sense now ;). I agree that the 'loss of CDR upon txfr' is a nasty bug which does need to be addressed before anything else (assuming it hasn't been already). But, wouldn't it be better if you could ignore the CDR's completely and use an event based system? This would give you ALL the information you need. All that remains is to filter out the un-required bits. Like I said earlier - the CDR's aren't reliable enough for a billing platform (as you've rightly pointed out) but are OK for very basic call logging (something the customer can look at). Hopefully, the murf'ster will chirp in here :). Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man Sent: 05 December 2008 09:37 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] CDR Design On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> wrote: In summary: Leave CDR exactly as it is and create a new CEL (Call Event Logging) module (optional in modules.conf) that puts out (and does not accept) call event information (ie. a one-way fire-and-forget output from Asterisk). Hi Andrew and Others, This thread is actually part of a discussion that has been going on for over a year. The links below provide the background to the whole thing. http://www.asterisk.org/node/48358 http://bugs.digium.com/view.php?id=11849 http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm l Up until recently the approach was to try and fix the specific bugs with transfer CDRs as a typical bug. There is now a realisation that that is a lot trickier than inially thought so it's been decided to try and come up with a good design for the Asterisk CDR sub-system. 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 ___ -- 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 ___ -- 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 Design
Hello Andy, > But, wouldn't it be better if you could ignore the CDR's completely and > use an event based system? This would give you ALL the information you > need. All that remains is to filter out the un-required bits. I'd disagree. In some cases a event based system would be the best solution, but in systems with high call volumes, scanning through events looking for the proper billing information and parsing them would be a hard job compared to CDRs. In most cases where there are no transfers, calls on hold etc, but only basic dial-in & dial-out operations, using events instead of CDRs would probably be an overkill. > Like I said earlier - the CDR's aren't reliable enough for a billing > platform (as you've rightly pointed out) but are OK for very basic call > logging (something the customer can look at). I'm not sure I understand what you mean exactly. If you have in mind cases of transfers, calls on hold etc and you refer to Asterisk's CDRs at this point in time, then indeed, Asterisk's CDRs are not reliable in many cases. However, CDRs in general on other platforms tend to be very reliable and useful for billing. My opinion is to transform Asterisk's CDR capabilities to something more carrier-grade in mind, configurable by the user. Best regards, Vlasis Hatzistavrou. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man > Sent: 05 December 2008 09:37 > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] CDR Design > > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> > wrote: >> In summary: Leave CDR exactly as it is and create a new CEL (Call > Event >> Logging) module (optional in modules.conf) that puts out (and does not >> accept) call event information (ie. a one-way fire-and-forget output >> from Asterisk). >> > > Hi Andrew and Others, > > This thread is actually part of a discussion that has been going on > for over a year. The links below provide the background to the whole > thing. > > http://www.asterisk.org/node/48358 > http://bugs.digium.com/view.php?id=11849 > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm > l > > Up until recently the approach was to try and fix the specific bugs > with transfer CDRs as a typical bug. There is now a realisation that > that is a lot trickier than inially thought so it's been decided to > try and come up with a good design for the Asterisk CDR sub-system. > > 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 > > ___ > -- 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 > ___ -- 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 Design
Thanks for this Greyman - it's all beginning to make sense now ;). I agree that the 'loss of CDR upon txfr' is a nasty bug which does need to be addressed before anything else (assuming it hasn't been already). But, wouldn't it be better if you could ignore the CDR's completely and use an event based system? This would give you ALL the information you need. All that remains is to filter out the un-required bits. Like I said earlier - the CDR's aren't reliable enough for a billing platform (as you've rightly pointed out) but are OK for very basic call logging (something the customer can look at). Hopefully, the murf'ster will chirp in here :). Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man Sent: 05 December 2008 09:37 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] CDR Design On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > > In summary: Leave CDR exactly as it is and create a new CEL (Call Event > Logging) module (optional in modules.conf) that puts out (and does not > accept) call event information (ie. a one-way fire-and-forget output > from Asterisk). > Hi Andrew and Others, This thread is actually part of a discussion that has been going on for over a year. The links below provide the background to the whole thing. http://www.asterisk.org/node/48358 http://bugs.digium.com/view.php?id=11849 http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm l Up until recently the approach was to try and fix the specific bugs with transfer CDRs as a typical bug. There is now a realisation that that is a lot trickier than inially thought so it's been decided to try and come up with a good design for the Asterisk CDR sub-system. 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 ___ -- 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 Design
On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > > In summary: Leave CDR exactly as it is and create a new CEL (Call Event > Logging) module (optional in modules.conf) that puts out (and does not > accept) call event information (ie. a one-way fire-and-forget output > from Asterisk). > Hi Andrew and Others, This thread is actually part of a discussion that has been going on for over a year. The links below provide the background to the whole thing. http://www.asterisk.org/node/48358 http://bugs.digium.com/view.php?id=11849 http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html Up until recently the approach was to try and fix the specific bugs with transfer CDRs as a typical bug. There is now a realisation that that is a lot trickier than inially thought so it's been decided to try and come up with a good design for the Asterisk CDR sub-system. 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 Design
I think you may have misunderstood me. I didn't say "don't have the extra information", I said "Let's have the 'extra' information in a different way and leave the existing CDR's as they are". Take the example of a 'real' PBX - the SDX/Lucent/Avaya Index. The Index had 2 options for 'logging' - SMDR (what we know as CDR) and Events. The SMDR gives the call information - after the call has finished (what time, date, number, who answered etc). The Event log gave an Event 'code' every time a handset/trunk changed state (off-hook, dialling, ringing etc.). This Event log helped us provide real time (near as damn it) stats for the system (ring times, hold times etc.) whereas the SMDR just gave us the basic call information. This is what I am suggesting here. Leave the basic CDR's as they are - and focus more on the event driven side (maybe through a TCP/IP port or socket?). Having events put in to a database by Asterisk is putting yet more load on to the server - so why do it if it's not needed? As I joined this 'discussion' late in - I can only assume that murf is doing just this with the CEL bit (if someone can correct me if needed please). In summary: Leave CDR exactly as it is and create a new CEL (Call Event Logging) module (optional in modules.conf) that puts out (and does not accept) call event information (ie. a one-way fire-and-forget output from Asterisk). Hope that makes my positiion a little clearer. Cheers Andrew Thomas ___ -- 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 Design
On Wed, Dec 3, 2008 at 10:47 PM, JD <[EMAIL PROTECTED]> wrote: > > Grey man: you are right. The direction of a call leg is easy to > determine from the point of view of asterisk. I suspect other folks > however, think of it differently. Some would think of a call coming from > a customer CPE to asterisk as an outbound call. Inbound to asterisk, > yes. But outbound for billing purposes. But if you are using Asterisk > for xyz, then the pattern of logic may differ yet again. So, while AMA > CDRs may look at it in a specific way, Steve's flexible system should > probably leave it up to each programmer writing their unique billing > analysis software. I knew I shouldn't have mentioned inbound and outbound calls :-). I don't have any issues distinguishing between outbound and inbound calls in the current system all I was attempting to do was point out it's not very difficult to manage. However it's not that relevant an argument for the CDR design so should be disregarded. > To sum up, personally I still think the current AMA-style CDRs should > remain in place. Perhaps touched up a bit. Or not. Steve's system should > be in addition to the AMA-style CDRs and called something other than > CDRs. (CDRplus?) Well if you are in a situation where you have to bill users and those users are able to make transfers you'd be just as keen for the system to get the system changes as a lot of the rest of us. 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 Design
Ironically, much of the disagreement comes from everyone being *right*. Seriously. Philisophically, Asterisk is a tool chest, not a true product. As an analogy, if one wants to sit, one can either buy a chair or get a saw/hammer/nails/lumber and build one. Both will do the job. Asterisk is more like the saw/hammer/nails/lumber. Two wit: Andrew: you are right. For folks wanting a simple AMA-style billing CDR, it would be ideal if we leave that in the system as is. Even if it is broken for many other uses of Asterisk. I don't need it myself, but I see your point. regs: you are right. For folks wanting more advanced billing or intercarrier compensation, a standard CDR isn't going to cut it. We need to pull in N events, tied together by some kind of unique ID. Customized programming would then do the analysis and bill generation. Steve's system should help make that custom programming easier. Grey man: you are right. The direction of a call leg is easy to determine from the point of view of asterisk. I suspect other folks however, think of it differently. Some would think of a call coming from a customer CPE to asterisk as an outbound call. Inbound to asterisk, yes. But outbound for billing purposes. But if you are using Asterisk for xyz, then the pattern of logic may differ yet again. So, while AMA CDRs may look at it in a specific way, Steve's flexible system should probably leave it up to each programmer writing their unique billing analysis software. To sum up, personally I still think the current AMA-style CDRs should remain in place. Perhaps touched up a bit. Or not. Steve's system should be in addition to the AMA-style CDRs and called something other than CDRs. (CDRplus?) But, I'm not doing the coding, so take what I say with a grain of salt. John Freddi Hansen wrote: > I agree with [EMAIL PROTECTED] we need the events to create the final CDR. > I will not waste list space on a long but just show you 2 reallife > examples that can't be handled both within the same 'fixed' way of > generating CDR's as we do now.The new system that 's proposed would > handle both just with trimming of the config file. > A: > Asterisk used on a shared premium number where we pay the companies > that's chosen in the menu. > The Company chosen can make internal transfers, the point is that > A-line time for the whole session > is 'billable'. > B. > Voip service provider that allows transfers. > B-line time is billable - A pays for leg A to B, when a transfer occurs > then the leg from B to C must be paid by B > > It's difficult to impossible to maintain that kind of logic in the > Asterisk core. > Asking for 'one' CDR is essentially the same as asking for hardcoded > cdr-event logic in the core - > I would certainly prefer the way that Murf is proposing. > > If we use Dbus,socket or spawn external program (like with agi) that's > just an implementation detail but the architecture should be right. > > Freddi > > > >> Billing and logging should not be confused theoretically - I agree. >> But in practice, >> the logging of the calls (not other events of the system) IS used for >> billing purposes. >> The start and finish time is not enough for many (I not that it is not >> enough for me). >> >> The accountcode is not enough for me either. From my CDRs I have to >> extract all the >> information about which provider tried-and-failed or >> tried-and-succeeded to terminate >> the call. So I need the terminator's info in the CDRs. This is the >> only way that I can monitor >> what my providers charge me (and believe me, never take for granted >> that your provider charge >> you with pre-agreed rates, mistakes happen :)). Also, having the >> terminator's data in the CDR is >> the only way that I can calculate metrics such as ASR, ACD, mean PDD etc. >> And I can't imagine taking all this info from a logging module that >> mixes CDR log events with >> other ones (hardware events, user agent registrations, etc.) >> >> Since there is no agreement on WHAT to log and since we have the >> option to put a lot of info >> in the CDRs I think the right way to do it is provide the capability >> of every single detail that COULD >> be logged and let the end user choose WHAT to log through the >> configuration. I cannot understand >> tha benefit of a minimal/fixed/non-flexible CDR logging capability >> when can have the flexibility to >> go from minimal to complex depending on a configuration entry in a >> proper configuration file. >> >> P.S. Sometimes I wonder if I am the only one in the VoIP world that >> finds terminator information in the >> CDRs useful (including failed calls). >> >> P.S. Sometime we use the term "billing" only for customer billing >> processes which nowadays is incorrect >> or insufficient. "Billing" in today's demanding VoIP business means : >> >> 1. Customer Billing : we all know what that is >> >> 2. Provider CDRs cross-check : as I said above, you have
Re: [asterisk-users] CDR Design
I agree with [EMAIL PROTECTED] we need the events to create the final CDR. I will not waste list space on a long but just show you 2 reallife examples that can't be handled both within the same 'fixed' way of generating CDR's as we do now.The new system that 's proposed would handle both just with trimming of the config file. A: Asterisk used on a shared premium number where we pay the companies that's chosen in the menu. The Company chosen can make internal transfers, the point is that A-line time for the whole session is 'billable'. B. Voip service provider that allows transfers. B-line time is billable - A pays for leg A to B, when a transfer occurs then the leg from B to C must be paid by B It's difficult to impossible to maintain that kind of logic in the Asterisk core. Asking for 'one' CDR is essentially the same as asking for hardcoded cdr-event logic in the core - I would certainly prefer the way that Murf is proposing. If we use Dbus,socket or spawn external program (like with agi) that's just an implementation detail but the architecture should be right. Freddi > Billing and logging should not be confused theoretically - I agree. > But in practice, > the logging of the calls (not other events of the system) IS used for > billing purposes. > The start and finish time is not enough for many (I not that it is not > enough for me). > > The accountcode is not enough for me either. From my CDRs I have to > extract all the > information about which provider tried-and-failed or > tried-and-succeeded to terminate > the call. So I need the terminator's info in the CDRs. This is the > only way that I can monitor > what my providers charge me (and believe me, never take for granted > that your provider charge > you with pre-agreed rates, mistakes happen :)). Also, having the > terminator's data in the CDR is > the only way that I can calculate metrics such as ASR, ACD, mean PDD etc. > And I can't imagine taking all this info from a logging module that > mixes CDR log events with > other ones (hardware events, user agent registrations, etc.) > > Since there is no agreement on WHAT to log and since we have the > option to put a lot of info > in the CDRs I think the right way to do it is provide the capability > of every single detail that COULD > be logged and let the end user choose WHAT to log through the > configuration. I cannot understand > tha benefit of a minimal/fixed/non-flexible CDR logging capability > when can have the flexibility to > go from minimal to complex depending on a configuration entry in a > proper configuration file. > > P.S. Sometimes I wonder if I am the only one in the VoIP world that > finds terminator information in the > CDRs useful (including failed calls). > > P.S. Sometime we use the term "billing" only for customer billing > processes which nowadays is incorrect > or insufficient. "Billing" in today's demanding VoIP business means : > > 1. Customer Billing : we all know what that is > > 2. Provider CDRs cross-check : as I said above, you have to know what > your provider charges you in order > to catch mistakes and in order to able to produce profit/loss reports. > > 3. QoS metrics : ASR, ACD, PDD to name a few. These cannot be > calculated without proper termination info > from the CDRs. I see LCR modules being introduced now and then in the > asterisk community but they all seem > a little useless if the above metrics cannot be extracted from the > CDRs. What is the benefit of having a low cost provider > in your LCR if its ASR equals to 0.0001 %? and how can you measure its > ASR if the terminator's info (both failed and successful) > is not in the CDRs? > > > Andrew Thomas wrote: > It seems to me that we are confusing billing and logging here. Call > billing only really needs the start and finish (like we get now) - but > proper call logging requires all steps. > > Do we leave CDR's as they are (for billing purposes) and have a separate > 'event' driven log for call logging? Or do we change the CDR structure > to accommodate logging as well? > > Personally, a separate 'event' log seems preferable to me as this keeps > existing billing platforms useable. It just means the logging programs > will need to be re-written to look at a new database for events. > > I know we have the AMI - but that puts out a lot more information than > is needed for simple logging (and requires something to prune and store > the events in a database of some sort). > > Any thoughts? > > Andrew Thomas > Technical Services Manager > DataVox Ltd > Saddleworth Business Centre > Huddersfield Road > Delph, Oldham > OL3 5DF > ___ -- 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 Design
Billing and logging should not be confused theoretically - I agree. But in practice, the logging of the calls (not other events of the system) IS used for billing purposes. The start and finish time is not enough for many (I not that it is not enough for me). The accountcode is not enough for me either. From my CDRs I have to extract all the information about which provider tried-and-failed or tried-and-succeeded to terminate the call. So I need the terminator's info in the CDRs. This is the only way that I can monitor what my providers charge me (and believe me, never take for granted that your provider charge you with pre-agreed rates, mistakes happen :)). Also, having the terminator's data in the CDR is the only way that I can calculate metrics such as ASR, ACD, mean PDD etc. And I can't imagine taking all this info from a logging module that mixes CDR log events with other ones (hardware events, user agent registrations, etc.) Since there is no agreement on WHAT to log and since we have the option to put a lot of info in the CDRs I think the right way to do it is provide the capability of every single detail that COULD be logged and let the end user choose WHAT to log through the configuration. I cannot understand tha benefit of a minimal/fixed/non-flexible CDR logging capability when can have the flexibility to go from minimal to complex depending on a configuration entry in a proper configuration file. P.S. Sometimes I wonder if I am the only one in the VoIP world that finds terminator information in the CDRs useful (including failed calls). P.S. Sometime we use the term "billing" only for customer billing processes which nowadays is incorrect or insufficient. "Billing" in today's demanding VoIP business means : 1. Customer Billing : we all know what that is 2. Provider CDRs cross-check : as I said above, you have to know what your provider charges you in order to catch mistakes and in order to able to produce profit/loss reports. 3. QoS metrics : ASR, ACD, PDD to name a few. These cannot be calculated without proper termination info from the CDRs. I see LCR modules being introduced now and then in the asterisk community but they all seem a little useless if the above metrics cannot be extracted from the CDRs. What is the benefit of having a low cost provider in your LCR if its ASR equals to 0.0001 %? and how can you measure its ASR if the terminator's info (both failed and successful) is not in the CDRs? Andrew Thomas wrote: > It seems to me that we are confusing billing and logging here. Call > billing only really needs the start and finish (like we get now) - but > proper call logging requires all steps. > > Do we leave CDR's as they are (for billing purposes) and have a separate > 'event' driven log for call logging? Or do we change the CDR structure > to accommodate logging as well? > > Personally, a separate 'event' log seems preferable to me as this keeps > existing billing platforms useable. It just means the logging programs > will need to be re-written to look at a new database for events. > > I know we have the AMI - but that puts out a lot more information than > is needed for simple logging (and requires something to prune and store > the events in a database of some sort). > > Any thoughts? > > Andrew Thomas > Technical Services Manager > DataVox Ltd > Saddleworth Business Centre > Huddersfield Road > Delph, Oldham > OL3 5DF > > > ___ > -- 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 > ___ -- 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 Design
It seems to me that we are confusing billing and logging here. Call billing only really needs the start and finish (like we get now) - but proper call logging requires all steps. Do we leave CDR's as they are (for billing purposes) and have a separate 'event' driven log for call logging? Or do we change the CDR structure to accommodate logging as well? Personally, a separate 'event' log seems preferable to me as this keeps existing billing platforms useable. It just means the logging programs will need to be re-written to look at a new database for events. I know we have the AMI - but that puts out a lot more information than is needed for simple logging (and requires something to prune and store the events in a database of some sort). Any thoughts? Andrew Thomas Technical Services Manager DataVox Ltd Saddleworth Business Centre Huddersfield Road Delph, Oldham OL3 5DF ___ -- 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 Design
On Dec 2, 2008, at 7:01 AM, Grey Man wrote: >> On Mon, Dec 1, 2008 at 3:26 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: >> Everyone-- >> >> I've just made some major changes to the CDRfix2.rfc.txt >> file in http://svn.digium.com/svn/asterisk/team/murf/RFCs >> to accommodate the Leg approach instead of a >> channel-based approach. >> > > Hi murf, > > I've got a couple of points (as always) from the new design. > > First one would be the generation of CDRs when putting a call on hold. > I don't think that should occur. When a call is put on hold Asterisk > never changes the endpoints of a call all it does is possibly change > the media to one or both of the call ends. CDRs are about call > endpoints not about media transitions. In SIP terms putting a call on > hold is no different to changing codecs both operations are re-INVITES > and are irrelevant as far as CDRs and billing go. While I agree with your reasoning, I really like the idea of the CDR showing HOLD states. It allows me to generate a report on how often people are on hold. If I see that the incoming calls to my receptionist spend 15% of the time on hold, that means something to me. If someone doesn't care to know the hold states, they (or their script) can just ignore the HOLD CDR records. I don't see that it would impact any final numbers to just skip them, you still get the total call duration between point A and point B. Daniel > 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 Design
>On Mon, Dec 1, 2008 at 3:26 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: > Everyone-- > > I've just made some major changes to the CDRfix2.rfc.txt > file in http://svn.digium.com/svn/asterisk/team/murf/RFCs > to accommodate the Leg approach instead of a > channel-based approach. > Hi murf, I've got a couple of points (as always) from the new design. First one would be the generation of CDRs when putting a call on hold. I don't think that should occur. When a call is put on hold Asterisk never changes the endpoints of a call all it does is possibly change the media to one or both of the call ends. CDRs are about call endpoints not about media transitions. In SIP terms putting a call on hold is no different to changing codecs both operations are re-INVITES and are irrelevant as far as CDRs and billing go. As far as internal calls vs external calls go I would argue that Asterisk can distinguish between them. Any call initiated with the Dial (or equivalent) app is an outgoing call. Anything call request arriving at Asterisk from the outside World is an internal call. For a standard call from a SIP user there are two call legs; the incoming call leg to Asterisk and the outgoing call from the dialplan. For a DAHDI user there is only a single call leg being the outgoing call from the dialplan since providing dialtone when they pick up the phone is not a call leg. I guess it's not really relevant for the CDR design but it's actually not a difficult thing to cope with when writing a billing engine for Asterisk, I know as I've done it. I like the new CDR fields. My number one concern would be to get the CDRs accurate but additional useful information can only help as long as it used the right way, i.e. not treated as definitive for billing purposes. For the linkedid and ideally the uniqueid I reaally think it would be vastly more useful to use a GUID or UUID rather than a incrementing sort of unique id. A lot of use are dealing with CDRs by writing them to databases and it would greatly simplify and improve the robustness of billing if Asterisk CDRs could be categorically be indentified as unique. If we need to know which CDR came first we can use the calldate ther is no need for the linkedid or uniqueid to double up for that. I'm not to sure about: "In a leg-based sort of system, CDRs would follow bridging." Does that mean whenever the end of a bridge changes a CDR is generated? And does it mean there are two CDRs per bridge or one? >From your examples there only seems to be one CDR per bridge which straight away I can think of a scenario that would cause a problem. If I supply toll free numbers that need to be billed for incoming calls and that can be forwarded out to billable destinations then I want a CDR for both ends of the bridge. In your first blind transfer example what if the initial incoming call to A is billable? I can't see any easy way to get the duration of that call leg. 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 Design
> On Dec 1, 2008, at 9:07 AM, JD wrote: > >> Steve Murphy wrote: >>> >>> Freddi-- >>> >>> Very interesting. Brian Degenhardt had some code we just gave some >>> thought >>> to, wherein we determine if the last channel involved in a linkedID set >>> has been closed. If so, then the entire set is finished. We can use >>> this >>> facility to get you a closing attribute, that could be added to the >>> last >>> CDR emmitted for that set; OR, we could just emit another CDR with type >>> CLOSE or FINAL or something, that signals the end of the chain. >>> >>> murf >>> >> Just thinking out loud: how about a feature wherein, after the FINAL is >> sent, asterisk can >> 1. create a temp text file with just those entries, and >> 2. launch a user-made script. >> >> cdr_manager.conf >> [general] >> legparsecmd=/usr/local/bin/my_parser.pl >> >> wherein the linkedID is passed as the first parameter and the text file >> name&path as the second >> >> Ignore this suggestion if it horribly complicates things. > > Hmm.. While I normally like having this kind of "instant > notification", I could see this as a very big problem for larger > installations. Most OS's are not so great at launching new tasks, and > on a heavily loaded system that could easily be a number of tasks > launched every second, each doing a lot of database queries. Perhaps > a different approach would be to have a field that can be set to show > that the record(s) have been parsed into whatever standard CDR format > you want. This may or may not make more sense as a separate table > with just a list of linkedid's that have been parsed. > > Daniel I think that e.g. a socket would be preferable. You do not have the load of launching new a task for each cdr and the process listening on the socket would normally run at lower priority than Astrisk itself. If gives the freedom to send unprocessed 'leg-information' to a cdr backend process on another server if heavy loaded enviroment or just process it local if it's a small installation. To me it looks new cdr spec from murf would be a big step forward for Asterisk. Freddi ___ -- 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 Design
On Mon, 2008-12-01 at 10:55 -0600, JD wrote: > Steve Murphy wrote: > > [...] > > I love it! You will have it done later today, correct? (joke.) > > Just a non-technical/social suggestion: don't call this CDR. Call it > "Enhanced CEL" or something like that. > > Why?: because otherwise you will forever get arguments about it. > Traditionally, a CDR is one line per call; all inclusive. And as you > know, that is a horrible standard for todays complex systems; but it is > what it is. > > So, perhaps Asterisk should not build native CDR at all. It should build > your "Enhanced CEL". A separate perl/ruby/etc script could be included > in the Asterisk distribution that build the "CDRs" after the fact. Or > multiple CDR scripts based on the flavor-of-the-day of what CDR means. > > Just my thoughts. I very much look forward to your code. This will make > my life so much easier. > > John John-- Point well taken, but if I call it anything but CDR, people will go "Huh?". CEL is per-event, but CDR's are event-groups. I think we are safe to keep calling it CDR, because I perceive that at least some of the big-name pbx vendors are generating much more than simple line-per-call records and they still call them CDR's. Using a db to make sense of CEL events for billing purposes is extraordinarily difficult, as the strings of events are reported as they occur, and with multiple calls going on simultaneously, the events are interlaced. You can pull out single threads by sorting on the linkedid; but still you have strings of events among multiple channels that will not be obviously easy to decode, especially by concocting SQL queries. Thus, the need to provide some sense via CDR's. And, yes, I agree with you. I will try to make it so a CEL->CDR generator could be run either 'real time' inside asterisk (via make menuselect choice), (and using your selection of existing backends), AND, I can try to provide a stand-alone option that could be run on CEL events that were logged to one of the CEL backends; probably just one of the plain-text ones. murf -- Steve Murphy Software Developer 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 Design
Steve Murphy wrote: > [...] > > Everyone-- > > I've just made some major changes to the CDRfix2.rfc.txt > file in http://svn.digium.com/svn/asterisk/team/murf/RFCs > to accommodate the Leg approach instead of a > channel-based approach. > > Greyman is correct. By cutting the timeline into legs, > we avoid all the nasty channel state problems, or so it > appears thus far. I threw out all the text about > channel/peer state, fleshed in all the example > cases, etc. > > I added a section describing the linkedID field. > > I provide a list of CDR record types at the end, > that will eventually be expanded to describe each > field that set in that type, and what they mean. > > The types so far are: > > 3WAY > AXFER > AXFER1 > AXFER2 > BARGE > BXFER > CALL > CONF > HOLD > PARK > RECALL > RECONN > USER > WHISPER > > > murf > > I love it! You will have it done later today, correct? (joke.) Just a non-technical/social suggestion: don't call this CDR. Call it "Enhanced CEL" or something like that. Why?: because otherwise you will forever get arguments about it. Traditionally, a CDR is one line per call; all inclusive. And as you know, that is a horrible standard for todays complex systems; but it is what it is. So, perhaps Asterisk should not build native CDR at all. It should build your "Enhanced CEL". A separate perl/ruby/etc script could be included in the Asterisk distribution that build the "CDRs" after the fact. Or multiple CDR scripts based on the flavor-of-the-day of what CDR means. Just my thoughts. I very much look forward to your code. This will make my life so much easier. John ___ -- 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 Design
On Tue, 2008-11-25 at 08:06 +, Grey Man wrote: > >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: > > For the moment, let's not worry about the implementation. Let's > > get consensus on the spec first. In the scenario, where A calls B, > > B xfers A to C, C xfers A to D, or some such similar scenario, > > half the world wants a single CDR for A, from the time it started, > > to the time it hung up with D. The other half wants A->B's dial and > > bridge, > > a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some > > CDRs > > to describe the xfers, where B xfers A to C and C xfers A to D. > > > > My document is pointing in the former direction, and either we need to > > spec both, or pick one. > > To me the obvious answer is to provide a CDR for every call leg so for > A calling B via Asterisk there would be two CDRs produced. It's far > far easier to disregard the unwanted CDRs than it is to try and > generate the missing ones and in some cases it's virtually impossible. > If it's weighed up I think people would vote to have accurate CDRs > ahead of anything else and if single legs are the best way to do that > then it's the way it should be done. > > In addition with single leg CDRs it will solve the dilemna about > acommodating every possible call scenario that I know has caused you a > lot of consternation over the last 18 months. > > Sure it's a change from the current situation so maybe needs to use > the standard apporach of a configuration setting to opt in initially > before becoming the default in the subsequent major release. > > Regards, > > Greyman. > > P.S. Sorry about the duplicate post. I actually sent the email to the > list 4 times with around 8 hour spacings and I'm not sure why there > was a problem getting it through. Everyone-- I've just made some major changes to the CDRfix2.rfc.txt file in http://svn.digium.com/svn/asterisk/team/murf/RFCs to accommodate the Leg approach instead of a channel-based approach. Greyman is correct. By cutting the timeline into legs, we avoid all the nasty channel state problems, or so it appears thus far. I threw out all the text about channel/peer state, fleshed in all the example cases, etc. I added a section describing the linkedID field. I provide a list of CDR record types at the end, that will eventually be expanded to describe each field that set in that type, and what they mean. The types so far are: 3WAY AXFER AXFER1 AXFER2 BARGE BXFER CALL CONF HOLD PARK RECALL RECONN USER WHISPER murf -- Steve Murphy Software Developer 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 Design
Yes, I know we are suggesting the same thing... I just thought you are suggesting putting this multidimensional CDR in one row (which of course requires data structure other than a simple comma separated row - XML perhaps). I did not understand you were referring to a conceptual multi-dimensional and not an actual multidimensional storage method. Anthony Francis wrote: > We are suggesting the same thing, what you describe is multidimensional. > If you think of the cdr's as being in a database, and say you wanted to > have it show you all the calls today and all the calls that are > associated with that call. Your select grabs the first dimension, a list > of all calls. Then using the unique identifier of each call you build a > second dimension of the related calls. > > [EMAIL PROTECTED] wrote: > >> In order to avoid a multidimensional schema we could have 1 cdr per call >> leg. So , for instance, one >> call that had 3 different dial() commands as outgoing attempts would be >> described by 4 >> CDRs (1 for the incoming leg that has all the originating channel data >> and 3 for the outgoing >> legs that hold all the terminating channel's data). Those CDRs would be >> bound by a unique >> identifier field (the same for all 4). The terminating CDRs could be >> also identified by a increment field that indicates >> the order that the channels were called. Another issue is that failed >> attempts should also be logged because >> this is valuable info for many (or at least have the option to choose >> the desired behavior - which is available in asterisk as we speak). >> >> Anthony Francis wrote: >> >> >>> It is my belief that before redesigning the CDR engine some time should >>> be spent looking at current PSTN CDR formats and what information is >>> kept in them. >>> The main problem that I feel we face is that calls can be complicated, >>> but we want the record of it to not be. >>> In reality a CDR that incorporates all information about a call would >>> have at least two dimensions. >>> In the first you would have the base call record as we do now, in the >>> second we would have the event list. >>> The event list would be a time indexed list of event names and >>> attributes, just as you would currently store event information. >>> The event list would be your glue (with a bit of front end logic of >>> course.) that would relate a call that dialed X external numbers to the >>> X different new CDR's that generated. >>> That would allow you all the call path info you could ever want. The >>> most important thing would be a new config file that allows an >>> administrator granular control over what information is "important to >>> them. And of course a "keep it simple stupid" mode that just writes the >>> top level cdr as it does now. >>> >>> [EMAIL PROTECTED] wrote: >>> >>> >>> I think that the custom cdr back-end can be successfully used to maximize or minimize the CDRs detailing on a per-needs basis. Furthermore, the CDR() function gives plenty of room for even more detailing. In my opinion the detail level (fields) is not the issue with the CDRs generation nor is the lack of backends (asterisk gives a lot of different backends to store your CDRs). I find the issue with asterisk CDRs to be in the lack of proper CDRs generation for the B-leg of every call. If we want to really track what happens during a call through the CDRs one has to have all the details not only for the incoming channel but for the outgoing one as well. Furthermore, one needs to be able to tweak the B-leg CDRs like he does with the incoming legs. So what needs to be done in my opinion is record every B-leg CDR when such an event occurs and give the user access to the CDR info by extending the CDR() function (so that one can specify the channel of the CDR that is being tweaked) or creating a seperate one for the outgoing channels. Grey Man wrote: > I've taken the liberty of starting a new thread to discuss the design > of the Asterisk CDR mechanism. The discussion has been kindly > initiated by murf putting together a proposal (link ommitted to see if > email gets accepted). > > After reading the proposal I still don't think it's the right way to > go. To my mind adding more channel variables increases the complexity > in a situation that is already overly so. I think it's a mistake to > try and think about all the different call scenarios and come up with > little tricks for the more complicated ones. There will always be > something missed; app_shotgun initiates calls to 100 random numbers > and as soon as three or more calls are answered it will start randonly > transferring them amongst each other at 2 second intervals. > > I think it's important to clarify at the outset what
Re: [asterisk-users] CDR Design
On Mon, 2008-11-24 at 09:12 -0700, Anthony Francis wrote: > It is my belief that before redesigning the CDR engine some time should > be spent looking at current PSTN CDR formats and what information is > kept in them. > The main problem that I feel we face is that calls can be complicated, > but we want the record of it to not be. > In reality a CDR that incorporates all information about a call would > have at least two dimensions. > In the first you would have the base call record as we do now, in the > second we would have the event list. > The event list would be a time indexed list of event names and > attributes, just as you would currently store event information. > The event list would be your glue (with a bit of front end logic of > course.) that would relate a call that dialed X external numbers to the > X different new CDR's that generated. > That would allow you all the call path info you could ever want. The > most important thing would be a new config file that allows an > administrator granular control over what information is "important to > them. And of course a "keep it simple stupid" mode that just writes the > top level cdr as it does now. > Well, the CEL stuff definitely generates the event lists, and can do it to any of the normal database backends. But Brian Degenhardt pointed out that really, such event-list databases are practically useless. Queries for even simple things would involve incredibly complicated queries in terms of unique ID, event order, etc. etc. So, a CDR backend that lists all the call legs and the info 'behind' each leg, like what prompted this leg (an xfer vs a dial, etc), should be sufficient to answer most business-logic questions without ambiguity, and give you the info you seek, like how long a leg lasted. (which might be pretty interesting to calculate, if all you have are individual Start, answer, end, xfer, park, conf, etc. events in your db. Brian took all the raw events to a backend, but then post-processed them to form the records he needed. I plan the same for CEL, but am searching for consensus on what to generate. murf -- Steve Murphy Software Developer 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 Design
We are suggesting the same thing, what you describe is multidimensional. If you think of the cdr's as being in a database, and say you wanted to have it show you all the calls today and all the calls that are associated with that call. Your select grabs the first dimension, a list of all calls. Then using the unique identifier of each call you build a second dimension of the related calls. [EMAIL PROTECTED] wrote: > In order to avoid a multidimensional schema we could have 1 cdr per call > leg. So , for instance, one > call that had 3 different dial() commands as outgoing attempts would be > described by 4 > CDRs (1 for the incoming leg that has all the originating channel data > and 3 for the outgoing > legs that hold all the terminating channel's data). Those CDRs would be > bound by a unique > identifier field (the same for all 4). The terminating CDRs could be > also identified by a increment field that indicates > the order that the channels were called. Another issue is that failed > attempts should also be logged because > this is valuable info for many (or at least have the option to choose > the desired behavior - which is available in asterisk as we speak). > > Anthony Francis wrote: > >> It is my belief that before redesigning the CDR engine some time should >> be spent looking at current PSTN CDR formats and what information is >> kept in them. >> The main problem that I feel we face is that calls can be complicated, >> but we want the record of it to not be. >> In reality a CDR that incorporates all information about a call would >> have at least two dimensions. >> In the first you would have the base call record as we do now, in the >> second we would have the event list. >> The event list would be a time indexed list of event names and >> attributes, just as you would currently store event information. >> The event list would be your glue (with a bit of front end logic of >> course.) that would relate a call that dialed X external numbers to the >> X different new CDR's that generated. >> That would allow you all the call path info you could ever want. The >> most important thing would be a new config file that allows an >> administrator granular control over what information is "important to >> them. And of course a "keep it simple stupid" mode that just writes the >> top level cdr as it does now. >> >> [EMAIL PROTECTED] wrote: >> >> >>> I think that the custom cdr back-end can be successfully used to >>> maximize or minimize the CDRs detailing >>> on a per-needs basis. Furthermore, the CDR() function gives plenty of >>> room for even more detailing. >>> In my opinion the detail level (fields) is not the issue with the CDRs >>> generation nor is the lack of backends (asterisk gives a lot of different >>> backends to store your CDRs). I find the issue with asterisk CDRs to be >>> in the lack of proper CDRs generation for the B-leg of every call. >>> If we want to really track what happens during a call through the CDRs >>> one has to have all the details not only for the incoming channel >>> but for the outgoing one as well. Furthermore, one needs to be able to >>> tweak the B-leg CDRs like he does with the incoming legs. So what >>> needs to be done in my opinion is record every B-leg CDR when such an >>> event occurs and give the user access to the CDR info by >>> extending the CDR() function (so that one can specify the channel of the >>> CDR that is being tweaked) or creating a seperate one for >>> the outgoing channels. >>> >>> Grey Man wrote: >>> >>> >>> I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal (link ommitted to see if email gets accepted). After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; "channel" calls but not "peer" calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields b
Re: [asterisk-users] CDR Design
In order to avoid a multidimensional schema we could have 1 cdr per call leg. So , for instance, one call that had 3 different dial() commands as outgoing attempts would be described by 4 CDRs (1 for the incoming leg that has all the originating channel data and 3 for the outgoing legs that hold all the terminating channel's data). Those CDRs would be bound by a unique identifier field (the same for all 4). The terminating CDRs could be also identified by a increment field that indicates the order that the channels were called. Another issue is that failed attempts should also be logged because this is valuable info for many (or at least have the option to choose the desired behavior - which is available in asterisk as we speak). Anthony Francis wrote: > It is my belief that before redesigning the CDR engine some time should > be spent looking at current PSTN CDR formats and what information is > kept in them. > The main problem that I feel we face is that calls can be complicated, > but we want the record of it to not be. > In reality a CDR that incorporates all information about a call would > have at least two dimensions. > In the first you would have the base call record as we do now, in the > second we would have the event list. > The event list would be a time indexed list of event names and > attributes, just as you would currently store event information. > The event list would be your glue (with a bit of front end logic of > course.) that would relate a call that dialed X external numbers to the > X different new CDR's that generated. > That would allow you all the call path info you could ever want. The > most important thing would be a new config file that allows an > administrator granular control over what information is "important to > them. And of course a "keep it simple stupid" mode that just writes the > top level cdr as it does now. > > [EMAIL PROTECTED] wrote: > >> I think that the custom cdr back-end can be successfully used to >> maximize or minimize the CDRs detailing >> on a per-needs basis. Furthermore, the CDR() function gives plenty of >> room for even more detailing. >> In my opinion the detail level (fields) is not the issue with the CDRs >> generation nor is the lack of backends (asterisk gives a lot of different >> backends to store your CDRs). I find the issue with asterisk CDRs to be >> in the lack of proper CDRs generation for the B-leg of every call. >> If we want to really track what happens during a call through the CDRs >> one has to have all the details not only for the incoming channel >> but for the outgoing one as well. Furthermore, one needs to be able to >> tweak the B-leg CDRs like he does with the incoming legs. So what >> needs to be done in my opinion is record every B-leg CDR when such an >> event occurs and give the user access to the CDR info by >> extending the CDR() function (so that one can specify the channel of the >> CDR that is being tweaked) or creating a seperate one for >> the outgoing channels. >> >> Grey Man wrote: >> >> >>> I've taken the liberty of starting a new thread to discuss the design >>> of the Asterisk CDR mechanism. The discussion has been kindly >>> initiated by murf putting together a proposal (link ommitted to see if >>> email gets accepted). >>> >>> After reading the proposal I still don't think it's the right way to >>> go. To my mind adding more channel variables increases the complexity >>> in a situation that is already overly so. I think it's a mistake to >>> try and think about all the different call scenarios and come up with >>> little tricks for the more complicated ones. There will always be >>> something missed; app_shotgun initiates calls to 100 random numbers >>> and as soon as three or more calls are answered it will start randonly >>> transferring them amongst each other at 2 second intervals. >>> >>> I think it's important to clarify at the outset what a CDR should be. >>> The most fundamental requirement for CDRs is that they accurately >>> record the following pieces of information for EVERY call entering or >>> leaving the system (note every means every and not; "channel" calls >>> but not "peer" calls). >>> >>> 1. Destination (aka as A Number) >>> 2. AccountCode (aka as B Number) >>> 3. Call Start Time (answer time), >>> 4. Duration. >>> >>> Of course adding extra information can be very useful and I'm not >>> proposing any fields be removed from the current implementation >>> (although for pity's sake one change that should be made it to use a >>> GUID/UUID for the CDR's uniqueid and save endless confusion). >>> >>> People that really do need verbose or enhanced CDRs to do things like >>> tracking a call's flow as it travels in and out of queues, parking >>> lots etc. would be better off using AMI or the new CEL and not CDRs. >>> At the very least if problems arise with their call flow tracking they >>> will still be able to rely on the accuracy of the CDRs to piece it
Re: [asterisk-users] CDR Design
It is my belief that before redesigning the CDR engine some time should be spent looking at current PSTN CDR formats and what information is kept in them. The main problem that I feel we face is that calls can be complicated, but we want the record of it to not be. In reality a CDR that incorporates all information about a call would have at least two dimensions. In the first you would have the base call record as we do now, in the second we would have the event list. The event list would be a time indexed list of event names and attributes, just as you would currently store event information. The event list would be your glue (with a bit of front end logic of course.) that would relate a call that dialed X external numbers to the X different new CDR's that generated. That would allow you all the call path info you could ever want. The most important thing would be a new config file that allows an administrator granular control over what information is "important to them. And of course a "keep it simple stupid" mode that just writes the top level cdr as it does now. [EMAIL PROTECTED] wrote: > I think that the custom cdr back-end can be successfully used to > maximize or minimize the CDRs detailing > on a per-needs basis. Furthermore, the CDR() function gives plenty of > room for even more detailing. > In my opinion the detail level (fields) is not the issue with the CDRs > generation nor is the lack of backends (asterisk gives a lot of different > backends to store your CDRs). I find the issue with asterisk CDRs to be > in the lack of proper CDRs generation for the B-leg of every call. > If we want to really track what happens during a call through the CDRs > one has to have all the details not only for the incoming channel > but for the outgoing one as well. Furthermore, one needs to be able to > tweak the B-leg CDRs like he does with the incoming legs. So what > needs to be done in my opinion is record every B-leg CDR when such an > event occurs and give the user access to the CDR info by > extending the CDR() function (so that one can specify the channel of the > CDR that is being tweaked) or creating a seperate one for > the outgoing channels. > > Grey Man wrote: > >> I've taken the liberty of starting a new thread to discuss the design >> of the Asterisk CDR mechanism. The discussion has been kindly >> initiated by murf putting together a proposal (link ommitted to see if >> email gets accepted). >> >> After reading the proposal I still don't think it's the right way to >> go. To my mind adding more channel variables increases the complexity >> in a situation that is already overly so. I think it's a mistake to >> try and think about all the different call scenarios and come up with >> little tricks for the more complicated ones. There will always be >> something missed; app_shotgun initiates calls to 100 random numbers >> and as soon as three or more calls are answered it will start randonly >> transferring them amongst each other at 2 second intervals. >> >> I think it's important to clarify at the outset what a CDR should be. >> The most fundamental requirement for CDRs is that they accurately >> record the following pieces of information for EVERY call entering or >> leaving the system (note every means every and not; "channel" calls >> but not "peer" calls). >> >> 1. Destination (aka as A Number) >> 2. AccountCode (aka as B Number) >> 3. Call Start Time (answer time), >> 4. Duration. >> >> Of course adding extra information can be very useful and I'm not >> proposing any fields be removed from the current implementation >> (although for pity's sake one change that should be made it to use a >> GUID/UUID for the CDR's uniqueid and save endless confusion). >> >> People that really do need verbose or enhanced CDRs to do things like >> tracking a call's flow as it travels in and out of queues, parking >> lots etc. would be better off using AMI or the new CEL and not CDRs. >> At the very least if problems arise with their call flow tracking they >> will still be able to rely on the accuracy of the CDRs to piece it >> altogether to work out what's going wrong. >> >> My proposal of creating a 1-to-1 relationship between CDRs and >> Asterisk channels already exsits but somewhere along the line it's >> going awry. As an experiment, and to actually do something instead of >> continually moaning about it, I started commenting out the blocks of >> code in res_featrures.c and sip_channel.c that muck around with the >> channel CDRs when a transfer occurs. The results of that were that the >> CDRs for blind and attended transfers actually got better! They're >> still not quite right but are pretty close with only one CDR on each >> having a wrong destination. >> >> Regards, >> >> Greyman. >> >> ___ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit
Re: [asterisk-users] CDR Design
I think that the custom cdr back-end can be successfully used to maximize or minimize the CDRs detailing on a per-needs basis. Furthermore, the CDR() function gives plenty of room for even more detailing. In my opinion the detail level (fields) is not the issue with the CDRs generation nor is the lack of backends (asterisk gives a lot of different backends to store your CDRs). I find the issue with asterisk CDRs to be in the lack of proper CDRs generation for the B-leg of every call. If we want to really track what happens during a call through the CDRs one has to have all the details not only for the incoming channel but for the outgoing one as well. Furthermore, one needs to be able to tweak the B-leg CDRs like he does with the incoming legs. So what needs to be done in my opinion is record every B-leg CDR when such an event occurs and give the user access to the CDR info by extending the CDR() function (so that one can specify the channel of the CDR that is being tweaked) or creating a seperate one for the outgoing channels. Grey Man wrote: > I've taken the liberty of starting a new thread to discuss the design > of the Asterisk CDR mechanism. The discussion has been kindly > initiated by murf putting together a proposal (link ommitted to see if > email gets accepted). > > After reading the proposal I still don't think it's the right way to > go. To my mind adding more channel variables increases the complexity > in a situation that is already overly so. I think it's a mistake to > try and think about all the different call scenarios and come up with > little tricks for the more complicated ones. There will always be > something missed; app_shotgun initiates calls to 100 random numbers > and as soon as three or more calls are answered it will start randonly > transferring them amongst each other at 2 second intervals. > > I think it's important to clarify at the outset what a CDR should be. > The most fundamental requirement for CDRs is that they accurately > record the following pieces of information for EVERY call entering or > leaving the system (note every means every and not; "channel" calls > but not "peer" calls). > > 1. Destination (aka as A Number) > 2. AccountCode (aka as B Number) > 3. Call Start Time (answer time), > 4. Duration. > > Of course adding extra information can be very useful and I'm not > proposing any fields be removed from the current implementation > (although for pity's sake one change that should be made it to use a > GUID/UUID for the CDR's uniqueid and save endless confusion). > > People that really do need verbose or enhanced CDRs to do things like > tracking a call's flow as it travels in and out of queues, parking > lots etc. would be better off using AMI or the new CEL and not CDRs. > At the very least if problems arise with their call flow tracking they > will still be able to rely on the accuracy of the CDRs to piece it > altogether to work out what's going wrong. > > My proposal of creating a 1-to-1 relationship between CDRs and > Asterisk channels already exsits but somewhere along the line it's > going awry. As an experiment, and to actually do something instead of > continually moaning about it, I started commenting out the blocks of > code in res_featrures.c and sip_channel.c that muck around with the > channel CDRs when a transfer occurs. The results of that were that the > CDRs for blind and attended transfers actually got better! They're > still not quite right but are pretty close with only one CDR on each > having a wrong destination. > > 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 > ___ -- 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
