Now that you ask, I'll elaborate a bit more.
1. There is often a need for department heads to compare their long
distance bill with individual callers within a department. Our long
distance provider uses PIN numbers on the telco side, so each
department has a specific PIN number and get a long distance bill based
on that PIN. It would be nice for department heads to be able to log
into the web portal and retrieve their departments CDR's (group based?)
for the billing period.
2. The current CDR, when used with park, MOH, directed call pickup,
etc. etc. is an absolute mess. It's almost impossible to get any useful
information out of it. One of the reasons for this is we use polycom
phones and an outbound SIP trunk to dial 4 digit to our Meridian Option
61c via DMS100 PRI so all of those numbers appear as external outbound
and inbound calls in the CDR. Perhaps a minumum number length threshold
when pulling CDR records for a report, or even better, perhaps a nested
call path within the detailed report, such as:
Step
|
From
|
To
|
Start
|
Total Duration
|
Duration
|
Action
|
Status
|
1
|
5551234567
|
4321
|
15-Jan-2010 9:01:15 AM
|
1 minute, 43 seconds |
|
Call Pickup by 4123
|
Completed
|
2
|
5551234567
|
4123
|
|
|
23 seconds
|
Placed On Hold
|
Success
|
3
|
5551234567
|
~~mh~
|
|
|
20 seconds
|
Retrieved From Hold
|
Success
|
4
|
5551234567
|
4123
|
|
|
15 seconds
|
Transfered to 84321
|
Success
|
5
|
5551234567
|
84321
|
|
|
45 seconds
|
Call ended by remote party
|
Success
|
1
|
4123
|
5553211236
|
15-Jan-2010 10:32:14 AM
|
5 minutes, 22 seconds
|
|
|
Completed
|
2
|
4123
|
5553211236
|
|
|
5 minutes, 22 seconds
|
Call ended by 4123
|
Success
|
1
|
5556344358
|
4987
|
15-Jan-2010 11:01:42 AM
|
1 minute, 10 seconds
|
|
No answer, sent to voicemail
|
Completed
|
2
|
5556344359
|
~~vm~4987
|
|
|
1 minute, 10 seconds
|
Call ended by remote party
|
Success
|
And, in addition, a simpler report for the department heads, preferably
sortable by inbound and outbound calls:
From
|
To
|
Start
|
Total Duration
|
Last Action
|
Status
|
5551234567
|
4321
|
15-Jan-2010 9:01:15 AM
|
1 minute, 43 seconds
|
Call ended by remote party
|
Success
|
4123
|
5553211236
|
15-Jan-2010 10:32:14 AM
|
5 minutes, 22 seconds
|
Call ended by 4123
|
Success
|
5556344359
|
4987
|
15-Jan-2010 11:01:42 AM
|
1 minute, 10 seconds
|
Call ended by remote party
|
Success
|
Right now, as I said, it's a bit of a jumbled mess and not really in a
usable state. I'm sure this could be done or at least improved upon.
Raymond Dans wrote:
Josh,
Noticed your request for
better CDRs/Reports. Can you be a bit more specific. A considerable
amount of new information has been added to the CDR records in 4.2 as
well as new/changes to reports. Is there something in particular about
a report that you'd like see?
Raymond
Dans |
Software
Engineer|
Avaya
| 3500
Carling Avenue|
Ottawa, Ontario
K2H-8E9|
Voice/Fax/Mobile: 613-763-3941/613-763-7742 |
[email protected]
Intelligent
Communications avaya.com
[ Please consider the environment before printing this email ]
Be ready for a mailing list flood :-P
Here are a few things, and I'm sure some if not most are already in
motion and some of them may not fall within your guideline, call me out
on them if they're out of the scope of your request:
- Advanced audiocodes gateway configurations, such as
manipulation tables.
- Better CDR's. Right now I'm having to get our on-staff
programmer to write me out a parser to sift through all the CDR records
to generate a comprehensive report.
- Voice notification of new voicemails, not just email. Some
people don't have data or SMS on their phones.
- Auto Attendant Dial by name directory is currently just bad,
namely due to the 10 second delay issue.
- make backup and restore a little more comprehensive, such as
making sure all SSL certs are in order.
- Wildcard SSL certificates.
- Bring back the remote call forwarding restriction, sometimes
there is a need to keep certain users from forwarding calls off-site.
- Hunt group pickup code shortcut. A speed dial has to be used
for hunt group pickup because users can't remember the entire *78XXXX
pickup code.
- Call pickup/hunt group pickup permissions. It is somewhat
unnerving that anyone can set up a presence monitor on any extension
they want to and intercept their calls.
- Allow different alarms to be sent to different email addresses
- (sipXconfig) Allow more than 20 phones/users to be displayed
at one time.
- For end users: allow a different phonebook in the web portal
than on the phone so the entire directory can be searched in the web
portal but only a small departmental subset will be seen on the phone.
- Better dial plans. The current ones are a bit watered down.
- Transferring calls to park requires three button presses on
Polycom handsets (transfer, blind, park button). Could this possibly be
whittled down?
- If a Jabra or Plantronics headset with EHS adapters is used
on a phone with BLF then every time a BLF button shows a monitored
extension to be ringing, the headset also rings. Polycom and Jabra have
basically ignored me on this. I am almost 100% positive this has to do
with the "alerting" state with enhanced BLF.
- I've had to write EFK's for Intercom, Group Page, Transfer To
Voicemail, and Blind Transfer on Polycom phones. Perhaps these could be
included by default and turned on/off at the group phone level?
- Allow for a pickup time shorter than 1 second for *78XXXX
call pickup. Users are used to the call immediately being picked up on
older systems. I have trained users to wait for the short "beep" sound
but sometimes they forget :-(
- Voicemail quotas so the packrats will get rid of voicemails
from 5 years ago or archive them to their computer
- 64 bit CentOS installation ISO.
- Polycom config overrides upload. It's frustrating after a
firmware update having annoyed users because their ringtone,
background, etc. got reset.
- Troubleshooting has got to become a bit easier. A scrolling
CLI would definitely help.
OK, that seems to be more than just a few. I'm sure there are more that
I'm not thinking about right now. I'm really glad to hear Avaya is
committed to the project.
Josh Patten
Assistant Network Administrator
Brazos County IT Dept.
(979) 361-4676
On 1/22/2010 3:23 PM, Scott Lawrence wrote:
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/
|
