| 01:43.40 | *** join/#asterisk-doc jsmith-away (n=njsmith@72.21.36.138) |
| 01:45.43 | *** mode/#asterisk-doc [+o jsmith] by ChanServ |
| 09:21.00 | *** join/#asterisk-doc ToTo (n=ToTo@82.205.216.83) |
| 09:21.41 | *** join/#asterisk-doc [ToTo] (n=ToTo@82.205.216.83) |
| 09:27.19 | *** join/#asterisk-doc ^ToTo^ (n=ToTo@82.205.216.83) |
| 13:16.13 | *** join/#asterisk-doc ziro_axis (n=ziro_axi@62.240.61.150) |
| 13:16.37 | *** part/#asterisk-doc ziro_axis (n=ziro_axi@62.240.61.150) |
| 13:55.23 | *** join/#asterisk-doc RobH (n=RobH@rob.tech.wikimedia.org) |
| 14:14.11 | lmadsen | jsmith: ping>? |
| 15:35.01 | *** join/#asterisk-doc russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 15:56.25 | *** join/#asterisk-doc RobH2 (n=RobH@customer-wireless.as30217.net) |
| 15:57.10 | *** join/#asterisk-doc snuff-ho1e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:03.42 | *** join/#asterisk-doc snuff-ho2e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:11.10 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:17.42 | *** join/#asterisk-doc snuff-ho3e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:23.05 | *** join/#asterisk-doc RobH2 (n=RobH@rob.tech.wikimedia.org) |
| 16:23.11 | *** join/#asterisk-doc snuff-ho1e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:34.44 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:41.10 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 16:53.05 | *** join/#asterisk-doc snuff-ho2e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 17:04.39 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 17:20.20 | *** join/#asterisk-doc snuff-ho1e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 17:34.59 | *** join/#asterisk-doc snuff-ho2e (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 19:06.43 | *** join/#asterisk-doc RobH (n=RobH@130-227.127-70.tampabay.res.rr.com) |
| 19:32.23 | lmadsen | codefreeze-lap: I'm liking this idea of just using Simple CDRs for the CDR backend, then CEL for anything that needs to be more complicated |
| 19:32.59 | lmadsen | it should make documenting the CDRs... possible :) |
| 19:34.06 | codefreeze-lap | laughs... |
| 19:35.17 | codefreeze-lap | Well, you might document just the one; but I'm thinking that if I just implemented simple cdrs, I'd get mobbed.... |
| 19:36.59 | lmadsen | no way... the current way of doing CDRs is going to cause you to never be able to stop development on it. To my viewpoint, it seems like a whack-a-mole game |
| 19:37.30 | lmadsen | either that... or you can keep the CDRs as they are now, but put them into an unsupported mode, and encourage people to transition to Simple CDRs+CEL |
| 19:37.46 | lmadsen | since the new policy is that we can't remove the CDRs as they are now entirely (backward compat) |
| 19:39.05 | codefreeze-lap | lmadsen: you may have a point. Yes, CDRs as they now are will exist for a couple years, depricated at some point, disappearing at another, I hope... |
| 19:40.11 | lmadsen | agreed |
| 19:40.35 | codefreeze-lap | But I *do* think the simple CDRs will be pretty easy to implement... and maintain.... but I don't have a feel for how many billing creators will find it sufficient.... |
| 19:40.44 | lmadsen | but I am totally in favour of Simple CDRs taking over the primary (recommended) roll for CDRs, and deprecating current CDR functionality, and freezing development on it |
| 19:41.01 | codefreeze-lap | Amen... |
| 19:41.17 | lmadsen | I may not know enough about CEL to say that Simple CDRs + CEL could replace current CDRs, but I suspect they should... |
| 19:41.52 | lmadsen | but having a CDR system that as a simple, clearly defined set of rules with few (if any!) special cases sure would be nice |
| 19:42.15 | lmadsen | because with those 2 tools, then we can just leave the current CDR mess 'as-is', deprecate, and say, "use at own risk" |
| 19:51.20 | codefreeze-lap | Yes, I'm beginning to see that there would definite to make the SimpleCDR spec the base; it's going to be pretty.... well.... Simple! |
| 19:52.44 | codefreeze-lap | But gee, the Leg-based will be so descriptive.... hmmmm.... murf pulls out scales to weigh the situation.... simple, leg..... easy, more complex.... easy to maintain, more detailed..... I'd be an idiot to sign up for anything but the simple case! |
| 19:53.55 | codefreeze-lap | Greyman would be proud to hear me say this, btw. at least, I'd think so.... |
| 19:54.48 | file | on a separate note do CDRs have to be directly tied to channels? |
| 19:55.03 | codefreeze-lap | file: in which way? |
| 19:55.18 | file | directly on the channel structure, manipulated in the channel thread |
| 19:56.39 | codefreeze-lap | file: no.... pardon my saying it, but... HELL no! (Will Smith tradition)... it was imho, a mistake to do this in the first place, but who could imagine the future? |
| 19:56.48 | file | nods |
| 19:58.11 | lmadsen | codefreeze-lap: I say go the *most* simple route, which has the most clearly defined rules. If something needs to be made more complicated in the future, it can be done, but starting with a very simple, very clear base will give you a good foundation on which to build anything more complex. |
| 19:58.48 | lmadsen | I have realized I need to shower... brb :) |
| 20:02.25 | codefreeze-lap | lmadsen: I'm with you on that, but I still plan to spec the leg-based stuff (even if I don't plan to immediately implement it), mainly to get it out and discussed. If most of the guys who do billing systems are perfectly happy with that, then I may be done. But I doubt that it will suffice, personally... we'll find out, I guess. |
| 20:02.59 | codefreeze-lap | By "that", I mean the SimpleCDR spec. |
| 20:07.17 | lmadsen | codefreeze-lap: gotcha. Well it makes sense to have the spec discussion out there and going. Perhaps you end up with a couple of CDR backends that you can implement/enable at build time that would allow you to pick the one most appropriate to your situation. This way, you don't have to build a system that tries to do 3 different methods at the same time. |
| 20:19.01 | codefreeze-lap | Oh, definitely-- you'd config which mode you want. You'd have to configure your databases accordingly, as they most likely will not set the same list of fields. |
| 20:19.35 | codefreeze-lap | lmadsen: Are you familiar with journalling file systems (like ext3, or reiserfs)? |
| 20:20.30 | lmadsen | codefreeze-lap: umm... I am familiar of their existence.. yes :) (and I use ext3) |
| 20:23.20 | codefreeze-lap | Well, I am *not*, but the cel-events situation kinda reminds of this. I have no idea of what is journalled, or to how much detail. But CEL events will be pretty detailed and fine-grained. they are not easily turned into sensible information about what's going on. CDR's will always have much more value as an interface you can sql query to get info you need. |
| 20:24.10 | Juggie | i'm just suprised like 4 years have past |
| 20:24.13 | Juggie | and cdrs are still an issue |
| 20:24.30 | lmadsen | Juggie: you might get smacked :) |
| 20:24.40 | file | thinks storing these directly into is a bad thing and that it should be up to the implementor to write an intermediary layer to interpret them as they see fit, but *shrug* |
| 20:25.04 | codefreeze-lap | I think the leg-based stuff will be valuable for stuff that the simple-cdrs can't supply: How much time and how often are people put on hold, and traded around? etc. |
| 20:25.44 | codefreeze-lap | file: yes, but you'll find very few that will feel up to writing the code to do the job. |
| 20:26.44 | file | aye, so then it becomes your responsibility to write something that does it? |
| 20:27.16 | Juggie | lmadsen, its sad but true unfortunatally. |
| 20:28.01 | codefreeze-lap | eh, responsibility? well, I don't think of it that way... we provide a package that adds value to Asterisk. If it's insufficient, someone will do the rest, maybe for pay. |
| 20:28.07 | file | this is... policy! |
| 20:28.40 | codefreeze-lap | file, shhhhh! don't use the p-word in a public place!!!! ;) |
| 20:29.35 | codefreeze-lap | Actually, you'd be surprised. The goal is to be policy-free; we just state the facts; external stuff deals with those policies... |
| 20:30.05 | file | ideally yeah |
| 20:30.08 | codefreeze-lap | The trick is what facts to state, and how, to allow the most policies to operate. |
| 20:30.22 | Juggie | head runs in circles |
| 20:30.33 | lmadsen | Juggie: it just goes to show you how impossible it was to foresee where asterisk would go, and to write a CDR system that could have grown with it. I think we're just getting to the point that we've finally outgrown whatever model it may have tried to be, and we're now to the point we know enough that we could actually build one to move us forward |
| 20:30.37 | file | but you're going to have to put your foot down if people start bringing stuff up that is policy as a bug |
| 20:31.15 | Juggie | i'm just glad we completly ignore billing :) |
| 20:31.21 | Juggie | so its a non issue for us |
| 20:31.42 | codefreeze-lap | file: yes; but if tossing in a little of this or that gets folks happy, then maybe do it; maybe not. |
| 20:32.04 | file | but where do you draw the line? |
| 20:32.07 | file | :) |
| 20:32.19 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 20:32.39 | lmadsen | I say you don't do anything that goes outside of policy. Adding things here and there is going to open you back up to the 'whack-a-mole' problem |
| 20:32.42 | codefreeze-lap | Juggie: if there is one thing I've noted, and that is, if we implemented a billing system, probably exactly one person/org would find it useful. |
| 20:32.45 | file | lmadsen: right |
| 20:33.03 | file | you have to draw the line and say no |
| 20:33.08 | lmadsen | "this is how we do CDRs in Asterisk. If you need something OTHER than that, you are responsible for creating the tool" |
| 20:33.08 | Juggie | codefreeze-lap, no one reads the bills around here so it doesnt really matter much :) |
| 20:33.14 | codefreeze-lap | lol |
| 20:33.21 | lmadsen | codefreeze-lap: don't worry... I will make sure I'm the bad guy that closes the bug. |
| 20:33.36 | lmadsen | you can say, "oh sorry.. I would totally have done that, but Leif said NO!" |
| 20:33.41 | Juggie | idealy we just need to stick with something |
| 20:33.43 | *** join/#asterisk-doc snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 20:33.47 | Juggie | pick a system that works and thats it |
| 20:33.53 | Juggie | if the data is incorrect its a problem |
| 20:34.08 | Juggie | but if there just isnt enough well then, thats not a problem necessairly |
| 20:34.14 | file | as much as I'm all for helping users, you have to draw the line and say no... or else you will be swamped with requests from users which utilizes your time better spent elsewhere |
| 20:34.15 | lmadsen | well the problem is that there is no 'system' yet... that's what murf and greyman (and my minor interjections) have been discussing |
| 20:34.38 | lmadsen | especially if it is for something that is really just a method that is only useful in THEIR situation |
| 20:34.43 | codefreeze-lap | As to policy, I have no idea what policies might be applied to what is about to be done. All I know, we'll most likely get requests to pass more and more data to the CEL backend, so we can include it in the CDR's. |
| 20:34.44 | lmadsen | it would have to be something generally, and widely useable |
| 20:35.24 | file | lmadsen: we seem to be on the same page! |
| 20:35.46 | lmadsen | file: hells ya! :) |
| 20:35.47 | Juggie | in its simplest form, we just need all the calls/transfers that occured on a given call tied together with a unique id that we can use after the fact to tie it all together. |
| 20:35.50 | lmadsen | we are the same person afterall |
| 20:36.37 | lmadsen | really... if we come up with a decent system that is flexible enough, it shouldn't require us to be constantly maintaining and changing the CDR backend. The amount of work you have spent on the CDRs should totally be unnecessary if we have a good backend |
| 20:37.01 | Juggie | yes, if the raw data is there a good sql statement should be able to tie it all together |
| 20:37.06 | Juggie | asterisk should not need to be responsible |
| 20:37.12 | codefreeze-lap | We'd have to try to please a "majority". If we were selling Asterisk, we'd have hard numbers to back up what "majority" means, so we just have to wing it in the meantime. |
| 20:37.23 | lmadsen | we also need to get something that isn't going to change as much as has been happening between every point release. I realize that is not your fault as you are trying to make everyone happy, while at the same time trying to fix fundamental issues... but it seems as if we've gotten into a spaghetti code problem |
| 20:38.11 | file | we can't please a majority because the majority want a solution where the CDRs generated fit exactly what they want |
| 20:38.28 | lmadsen | well we can provide what we feel is a decent approximation of the logging of calls and their duration; anyone who needs anything beyond that is welcome to write their own CDR driver and tie it into asterisk. It's all open source! |
| 20:38.33 | Juggie | has anyone studied what other products, cisco, mitel, meridian, offer |
| 20:38.35 | lmadsen | file: amen |
| 20:38.52 | codefreeze-lap | lmadsen: it was spaghetti when I started. It's taken me quite a while to get a general grasp of what the probs are, where, and why. |
| 20:39.11 | codefreeze-lap | file: yes, that's the common law of software. |
| 20:39.17 | lmadsen | Juggie: probably not a bad idea... if we knew what other providers were offering, then maybe we could provide a general approximation |
| 20:39.30 | lmadsen | codefreeze-lap: sorry, I didn't mean to imply you create spaghetti code :) |
| 20:39.37 | file | commercial software is commercial software, you take what they give you :) |
| 20:39.39 | lmadsen | I assumed it was awful when you started |
| 20:39.49 | lmadsen | sometimes I think we need to have the same type of policy |
| 20:39.55 | Juggie | lmadsen, exactally... it cant hurt to see the data given by other providers and use that to determine what is erquired. |
| 20:39.58 | lmadsen | THERES THAT P-WORD AGAIN :) |
| 20:39.59 | codefreeze-lap | Juggie: I've been sent some manuals for other systems. My leg-based is still pretty simple compared to some. |
| 20:40.02 | file | for this since it is open source and there are people easily accessible people actually ask you to... change... and make it fit their thing |
| 20:40.32 | codefreeze-lap | lmadsen: I can tangle spaghetti with the best of 'em, **murf brags*** |
| 20:40.45 | lmadsen | also true... give them the basic tools, and let them manipulate it for their environment. The problem with CDRs is that no matter what you provide, it will never fit someone elses system. |
| 20:40.54 | Juggie | but i'm a pretty firm believer that given all the data in its simplest form (per leg) you should be able to generate anything you need after the fact with wonderful database magic. |
| 20:40.56 | lmadsen | kisses codefreeze-lap's pinky ring |
| 20:40.57 | file | right! |
| 20:41.04 | file | so give up with that thought in mind |
| 20:41.06 | lmadsen | Juggie: totally agreed |
| 20:41.13 | lmadsen | file: lol |
| 20:41.23 | file | and go with the idea of making something that provides everything people could want, and have them interpret it |
| 20:41.40 | Juggie | which is what i think CEL should be. |
| 20:41.41 | lmadsen | that's why I like the idea of the simple CDR system |
| 20:42.02 | file | and I still think having direct backends to databases is rubbish, but that is personal |
| 20:42.03 | Juggie | or simple cdr, what ever you want to call it, |
| 20:42.18 | lmadsen | start with simple CDRs, and then augment that with CEL; or the other choice of leg-based, plus augmented with CEL. If you need anything beyond that outside of SQL statements, you're not trying hard enough. |
| 20:42.20 | Juggie | file, you suggest we go completly w/ odbc? or some other layer |
| 20:42.36 | lmadsen | file: what do you mean? like cdr_pgsql? |
| 20:42.51 | lmadsen | I'm totally in favour of an ODBC only system. |
| 20:42.55 | file | write out to text files and have a separate process take the text files and do whatever |
| 20:43.05 | file | database goes down, they still exist on the HD |
| 20:43.19 | file | database blocks for whatever reason, doesn't matter |
| 20:43.25 | codefreeze-lap | lol, someone I respect very much said that you instruct folks, and let them operate on their own... viva open source and DOCUMENTATION and SPECs. |
| 20:44.51 | Juggie | that was one thing i was trying to address when i was working on the cdr queue branch, which sadly died but none the less, if asterisk crashed we would of lost the queue with my implementation, so writing to text and then uploading into db would probally be the most ideal/simple solution. |
| 20:45.04 | codefreeze-lap | file: that's been proposed; but the level of sophistication in turning the journal into useful data is high enough that not many will attempt it. Without the backend to some extent, we'd be heavily criticised. |
| 20:45.36 | Juggie | codefreeze-lap, one thing that could be done is buffer at least any failed cdrs |
| 20:46.12 | Juggie | with a seperate non blocking thread for writing |
| 20:47.03 | codefreeze-lap | Well, my plan is this: the cel2cdr core will be used both inside and outside asterisk. Inside, it will collect event data and issue CDRs in real time. Externally, it will read the cel_custom text file and issue CDR data in batch mode. |
| 20:47.24 | lmadsen | couldn't you just write to both, and have a autoincrement value at the start of each CDR in the text file, then you could sync up in the DB if necessary... |
| 20:48.49 | codefreeze-lap | So, if you crash, you can recover every call right up to the crash, even if they weren't ended. Same for midnight-1st-of-month to midnight-end of month type billing apps. |
| 20:49.30 | codefreeze-lap | lmadsen: the journal in cel_custom format would be pretty useless syncing against. |
| 20:49.48 | codefreeze-lap | A tangled sequence of overlapping events, one at a time. |
| 20:50.34 | codefreeze-lap | A single channel lifetime could span thousands of events, most of which irrelevant |
| 20:51.04 | lmadsen | unfortunately I know very little about CEL... I just assume it allows me to insert custom CDRs based on events that I wish to trigger on |
| 20:52.06 | codefreeze-lap | lmadsen: it's just a list of single events, and data about the event, like channel, time, type, and some fields and info from the channel... including linkedID, etc. |
| 20:53.13 | codefreeze-lap | exactly what events you want to track, you can specify. |
| 20:53.47 | codefreeze-lap | So, a simple format like SimpleCDR would require very little tracking, absorbing less bandwidth. |
| 20:56.44 | codefreeze-lap | lmadsen: simple CDRs probably won't allow any mods; nothing to mod, except what extra data you want to record, like userfield. Leg Based will allow you split cdrs via the dialplan. |
| 20:57.47 | lmadsen | interesting... I need to read up on CEL because I'm pretty sure what I believe it to be, is not :) |
| 20:59.26 | codefreeze-lap | To implement higher level features, like CDR splitting, you simply have your dialplan issue a special event. It will go out with the channel data snapshot and be part of the event list. Your backend interprets and does what it needs to with that. |
| 21:01.06 | codefreeze-lap | As to policy, my CDR spec will be the policy. If anybody says the CDR's are wrong, we refer to the "standards doc", and either the code agrees with the spec or doesn't. If it does, the guy complaining gets to eat rocks for supper. |
| 21:02.54 | codefreeze-lap | (at least folks will get their daily mineral supplementation!) |
| 21:03.57 | codefreeze-lap | I still haven't named the project.... CDRng... CDRast... uh, that sounds bad... |
| 21:06.53 | codefreeze-lap | And, the guys who don't review the spec, don't get much to complain about... they might affect v2 of the document, and maybe a year later, the new implementation based on the v2 spec... |
| 21:07.33 | file | ideally you shouldn't have to redo this... for awhile |
| 21:08.05 | codefreeze-lap | They'll get to respect the "power of the doc" and the price of sleeping when it was written... |
| 21:08.44 | codefreeze-lap | file: yes, and public demand will most likely determine the frequency of versions.... might be we never have to update the spec... |
| 21:09.51 | codefreeze-lap | Excuse me, I have to go into the upper-40's temps and do a chore or two for a break, bbs! |
| 21:12.18 | file | codefreeze-lap: if the spec has the potential to be redone... I would consider that bad for what is to be done... |
| 21:17.50 | lmadsen | agreed with above points |
| 21:18.09 | file | unlike Mark you have the time to properly design and implement this |
| 21:18.32 | file | if you foresee that you are going to have to redo it to a new spec... something is wrong |
| 21:18.42 | lmadsen | plus community input |
| 21:18.48 | file | right |
| 21:31.18 | *** join/#asterisk-doc telecos (n=sergio@34.167.219.87.dynamic.jazztel.es) |
| 21:45.40 | codefreeze-lap | righto. That's why I'm working hard to make discussions as public as possible. Guys who throw in input now will definitely make a difference. I suspect that the CDR-leg i/f will pretty much supply all the folks who want detailed reporting. They'll have the freedom to generate their own legs from the dialplan. I don't think they could demand more from it structurally. The only thing they'll be wanting will be more fields, more data from the channels |
| 21:46.58 | codefreeze-lap | And even I say "no more fields", they could easily toss that kind of info into the userfield from the dialplan, and get it anyway. |
| 21:57.15 | lmadsen | well, we have adaptive odbc... would be quite easy to just add the new column to the database :) |
| 21:57.23 | lmadsen | then use CDR() |
| 21:57.49 | codefreeze-lap | Well, CDR will not be used. It'll be CHANNEL() all the way for this stuff. |
| 21:58.37 | lmadsen | gotcha... same idea though :) |
| 21:59.20 | codefreeze-lap | yes, you have it. same basic idea. My spec will document each chunk of data we'll record, and where/when/how it will end up in the CDR's generated. |
| 21:59.43 | codefreeze-lap | At least, that's the goal. |
| 22:05.27 | lmadsen | nice... well I'll try to be involved as much as I can on the design with you! |
| 22:05.47 | lmadsen | hopefully we can keep it simple enough for even myself to understand! |
| 22:14.10 | *** join/#asterisk-doc telecos (n=sergio@34.167.219.87.dynamic.jazztel.es) |
| 22:18.10 | codefreeze-lap | lmadsen: good to hear. You've got some experience, I'll be listening. |
| 22:20.34 | lmadsen | heh... I haven't done too much CDR stuff, but I think I have an idea of how it should work... and really, it should make sense... it shouldn't be overly complicated (ideally) |