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: http://svn.digium.com/svn/asterisk/team/murf/RFCs. 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 detstination. Regards, Greyman.
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.
> 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. > > DanielI 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
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
I agree with regs at kinetix.gr 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 >
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
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: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] 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 <andy at datavox.co.uk> wrote:> > In summary: Leave CDR exactly as it is and create a new CEL (CallEvent> 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
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 :).
"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 :).
"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).
Amen! -----Original Message----- From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] 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: regs at kinetix.gr ------------------------------------------- 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 throughevents> > 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 arepresented> as they happen (hold, ring, etc) - CDR's are usually presented AFTERthe> 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 seefit.> 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 allfor> 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
> 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
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 CallYYYYMMDD Call date at time of answer (YYYYMMDD 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.0000 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 .0000 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 voip at rockynet.com
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: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users- -->> bounces at lists.digium.com] On Behalf Of Anthony Francis -->> Sent: 10 December 2008 18:19 -->> To: murf at digium.com; asterisk-users at 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 -->> -->> -->> -->> CallYYYYMMDD -->> -->> -->> -->> Call date at time of answer (YYYYMMDD 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.0000 -->> -->> -->> 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 -->> -->> -->> -->> .0000 -->> -->> -->> -->> -->> -->> 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 -->> voip at rockynet.com -->> -->> -->> _______________________________________________ -->> -- 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
-->> -----Original Message----- -->> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users- -->> bounces at lists.digium.com] 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 +0000, 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