What I was referring to was call accounting software, which will break down reports by department, time of day, extension, trunk groups, cost analysis, etc. You pinpointed it well - "CDR data". I believe that is what I stated as well, define the cdr data, not the reports, or at least not a huge selection of reports, but maybe some basic ones as they have now.
If sipXecs provides a standard set of data, and some simple reporting, then end users can purchase their own call accounting software, or open source call accounting software, to do more extended reporting. When you get into CDR, there is a complete industry out there that deals with that data, and it can become quite advanced. For an example, law firms rely on call accounting to do their billing of time with customers. Would I propose the CDR from sipXecs for a law firm. Not a chance! The liabilities are too high for them and for me. However, I would recommend one of several solid call accounting platforms if the CDR data was reliable and they had build an interface to it. This is how most PBX's do it. They don't typically have their own Call Accounting programs. The call accounting programs have interfaces they write to the different PBX products on the market. SipXecs is a great product. But, do we really want it to be a pbx, key system, call recorder, acd, call accounting, console, sip client, and anything else available under the sun. Maybe, but you can't accomplish all of this, and accomplish it well, without a considerable amount of development time. It seems to me the community should understand some of these limitations and tailor their expectations accordingly. MY OPINION is that their time is better spent not creating call accounting systems and reports, but defining their data subset extremely well and concise so that call accounting applications can wrap their applications around that data set and provide the end user a much more robust and comprehensive call accounting system. http://en.wikipedia.org/wiki/Call_accounting a quick search - http://www.filebuzz.com/findsoftware/Open_Source_Call_Accounting/1.html From: Josh Patten [mailto:[email protected]] Sent: Sunday, January 24, 2010 11:12 PM To: Todd Hodgen Cc: 'sipXecs users' Subject: Re: [sipx-users] Simplify, Simplify, Simplify >From my perspective one of the reasons for the original request from Scott was to see what would help simplify both administrative and end user tasks. CDR seems to be a sore spot with a lot of those who responded. What industry is it that you speak of? It's not unheard of amongst other open source and recent commercial PBX's to have relatively straightforward CDR data. It is my understanding that sipX is intended to be an "easy to use" system that can be administered by those unfamiliar with the PBX's of yesteryear, such as network administrators who get telephony projects loaded on top of their existing workloads with razor thin budgets to work with, and as a consequence of that can't be entirely dedicated to telephony like the telephone administrators of the 90's. It is my understanding that sipX is a way for these network administrators to concentrate on more important things, like making sure the end users get the information they need, be it CDR or email, or even CDR in email. Less time spent generating CDR's for department heads is more time spent on better things. I am sure that a third party company could be employed to parse the data out every month or to write a parser, but it still involves more time and/or money spent on everyones part to get all the data gathered and parsed than just having the option to run reports in the user portal, or as an automated email sent to the appropriate parties at specified dates with easily understandable data (not necessarily extremely detailed). Supervisors are able to see ACD data for employees they manage in the user portal, how is CDR data any less important? Todd Hodgen wrote: IMO, CDR work should be limited to development of raw CDR data, that is consistent with what the rest of the industry creates for their data. With concise CDR being available, there is a plethora of companies out there that make software for creation of many different reports from good data. To spend time developing reports within this application, when it is merely re-inventing the wheel, seems like a waste of good talent. From: [email protected] [mailto:[email protected]] On Behalf Of Josh Patten Sent: Sunday, January 24, 2010 2:30 PM To: [email protected] Cc: sipXecs users Subject: Re: [sipx-users] Simplify, Simplify, Simplify Now you see why I had 21 in my original email. They just kept coming to me, and I had neglected to see the limit of 5 in the original post. I think you had all the same ones I listed as well. Also, did you see my detailed recommendation for CDR in an earlier post? I was hoping to get some feedback from other end users if that was a good idea or if there were better ones. [email protected] wrote: One more :) .5) Voicemail quota management. Ability to set a max size on a voicemail box and a max age on individual voicemail messages. On 1/24/2010 1:21 PM, [email protected] wrote: 1) 64 bit ISO install 2) Ability to automate and/or delegate CDRs. I either need to have a preset one emailed out to dept heads or give them the ability to log in and only see their employees data 3) PIN numbers for long distance authorization 4) Clean up CDR data. This has been said already. There is too much work to get them in a good format. 5) Better GUI based troubleshooting/diagnostics. 6) Sorry, had to add one more. Check box type option when user forwards to internal extension. This would let them select where it goes if nobody answers. Sometimes they want it to come back to their voicemail, sometimes they want it to go to the forward recipients voicemail. It would be nice for them to be able to accomplish this with a check box instead of explaining they need to ad 8XXX as a second forward if they want it to go to the other persons voicemail if nobody answers. **Not included because I was told it is in 4.2 already. Better tools for external SSL certs. Sent via BlackBerry from T-Mobile -----Original Message----- From: "Scott Lawrence" <mailto:[email protected]> <[email protected]> Date: Fri, 22 Jan 2010 16:23:34 To: sipXecs users <mailto:[email protected]> <[email protected]> Subject: [sipx-users] Simplify, Simplify, Simplify As we begin to home in on release 4.2, we're starting to formulate plans for what comes next... First, I want to reassure the community - Avaya is very much committed both to the SCS commercial product (see roadmap announcements made this week), and to leading, contributing to, and materially supporting the sipXecs open source project. There most assuredly will be versions beyond 4.2, and we're committed to making them better with every release. Which brings me to the Subject of this request for community input. One of the major strategic goals of the release after 4.2 is to make sipXecs simpler. Simpler to install, simpler to administer, simpler for end users to use. Nice goal, huh? Motherhood is good, Apple Pie is very good, and Simplicity is great - I'm glad we all agree :-) Now comes the challenging part - what is simplicity? We'd like to hear what the community thinks... Specifically, what are your top 5 suggestions for how to simplify sipXecs? For this thread, we are _not_ asking for what your favorite missing power telephony features are (we'll do some of those too) - we want to know how to make the features we've got easier to understand and use. What are the things that you have to jump through hoops to do (especially if you have to do them more than once)? What are the things you constantly have to explain to users? What are the things you know how to do but it's just a little irritating ever time you have to do them? Try to think back to your first experiences - what was hard before you knew what you were doing (newbies - this is your chance to jump in and contribute even before you know what you're doing!) ? This is not like those dumb Microsoft advertisements where one doofus after another takes credit for Windows 7 (really - would anyone actually want to take _credit_ for Windows?) - we really want to know. I'm going to suggest one more thing for this thread - that developers just read and not post. In particular, in this thread: don't explain that something our users think is hard is actually easy, or tell them why it's hard, or suggest how we might fix it, or chime in here and now with your ideas. We'll have our turns to process all this more actively later and elsewhere - this thread is about listening to our users pain. Hear, be inspired, and get motivated. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
