Summary:	ASTERISK-01512: [request] Improved Voicemail Notification options
Reporter:	rthrash (rthrash)	Labels:
Date Opened:	2004-05-01 12:23:19	Date Closed:	2011-06-07 14:05:02
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Voicemail notification could better emulate or surpass currently available commercial voicemail systems by adding the following features: 1) When reviewing messages, and the date/time/message-number stamp is playing, pressing "1" would skip the remainder of the "header" playback. This saves a considerable amount of time/frustration for people who need to check messages in a hurry, or when there are many messages to review such as when returning from a vacation or conference. The envelope can always be replayed by using the advanced options ("3") to replay the envelope for the message.   2) When you you call your own DID line or you are transferred to your extension, during your message playback pressing "*" could prompt you to enter your password. This would allow you to conveniently check your messages by calling your own telephone number. This option could be enabled/disabled globally via voicemail.conf. 3) Voicemail security could be augmented by optionally enforcing "password rules" such as requiring a mailbox password length, no repeating digit passwords ("1111", etc.), no password same as mailbox/extension number, etc. 4) When a new message is left in your mailbox, another option for notification is to have Asterisk call a person's cell phone:  a) If on a PRI, setting a context for voicemail notification would allow a company to set up a unique CID so that users know it is a new voicemail notification.  b) The system would try to reach the person X number of times, every Y minutes (configurable via mailbox options).  c) If a person wants to stop notification for particular message, they could answer and enter a certain code ("*7" or "*#" ? )  d) If the person wanted to turn off message notification for the remainder of a day, they could answer and enter a certain code ("*3" or "**#" ? )  e) All options should be able to be configured in the mailbox options menu, (including the cell phone number to call) via the "0" mailbox options menu. 5) Automatically expiring "vacation mode". This would allow a user to have a regular voicemail mode and an away mode, similar to time/day-based auto attendants. During vacation mode, all notifications would be turned off, actually allowing people to have a vacation!  a) An alternate extension/number could be set up for automatic duplication of all messages to that extension that are not marked private by the calling party. This would help maintain customer service levels and ensure that important issues don't fall through the cracks.  b) Turning this mode on prompts the user to automatically record their "vacation" message for that away time. This would could also be used for out of town business trips, conferences, etc.  c) The user would be prompted to then set the duration of their of their away time by entering the date/time of their expected return. After that date/time is reached, the person would not have to remember to switch back to regular operation mode, as the system would handle it automatically for them. No more "Your message is really old and needs to be updated..." messages in your mailbox! d) The person could further be prompted for an optional "out-of-town" notification number that would either take the place of or be used in addition to the cell phone notification number in part 4, above. The user would also be prompted for a time after which that number is active (allowing for travel time). 6) Urgent message mode. If a message is marked urgent from advanced options by the person leaving the message, it would bypasses all do-not-notify rules above.  a) The user would need to enter an "emergency/urgent extension" in their mailbox configuration that is different from their own extension. This could be a person's assistant, a customer service rep, etc. It should default to the receptionist extension (defined by default in voicemail.conf).  b) When a person leaves a voicemail message and marks it as urgent, the message is automatically copied to this backup extension.  c) If the person is on vacation mode, it copies the message both to the "backup extension" in option 4, above, as well as an "emergency/urgent extension". ****** ADDITIONAL INFORMATION ****** In my personal experience, the first and fourth items are very handy, although the fourth may potentially sounding as a nightmare at first. They stem from experience with a commercial Telekol voicemail system, and work great for sales reps who're frequently away from their desks, etc. I would think that parts three, five and six would be features that go above and beyond most currently available voicemail systems, and really make Asterisk look significantly superior to traditional commercial voicemail offerings. I just wish I knew C... a programmer, I am not. :(
Comments:	By: rthrash (rthrash) 2004-05-01 12:25:49 Can someone change the title to a more appropriate title, such as "Voicemail features to crush the competition" edited on: 05-01-04 11:25 By: twisted (twisted) 2004-05-01 14:03:20 Okay.. here goes nothing.. 1)  I agree with this, and it would be fairly easy to impliment. 2) This can be handled through extensions.conf.   See Ant Ex-Girlfriend logic in the wiki. It can be implimented in other ways, but it can already be handled through the dialplan.  msg me on irc for an example if i'm around. 3) Sounds good, and I'm not any kind of expert C programmer, but the logic to do this one sounds horrific.. 4) If your cellphone supports SMS messaging, or text messaging, asterisk already will send text messages to cellphones reporting a voicemail in your box.   5) This is a nice feature, and is standard on many voicemail systems.  I'm not sure what it would take to do this one, but it sounds like a good idea.. 6) Message priority is a good one, but i think this would require modifying the directory structure so that prioritized messages are are placed in a folder where they are read first. To do what you're asking, it would almost be better to re-write app_voicemail.c from scratch.   There are a few people who have been toying with this idea already...  who knows... ;) By: rthrash (rthrash) 2004-05-01 18:11:08 One idea and one clarification: Regarding 3: if C supports some form of regex or if the mailbox and proposed password values could be passed to a Perl or PHP routine, then this should be easy to implement. I could write the regex, even! Regarding 4: Here's an example of why this is so valuable (and you can't really appreciate it until you've experienced it, quite honestly!) Say you're a salesperson driving down the road and you get message notification to your cell phone. As is, you'd have to click through to scroll down to read your message, then dial in to get your message; it can be dicey, distracting and dangerous. At least more dangerous than just blindly answering a call, entering your password by feel and never taking your eyes off the road. This would be in addition to already-working pager notification. Different strokes for different folks, and certainly less button-pushing to get to the same end game! You could also disable notification permanently (for the remainder of the day, anyway) or temporarily as well to remove distractions or repeated interruptions with this feature, too. By: twisted (twisted) 2004-05-01 19:58:56 I understand where you're coming from on point 4 now.   I was under the impression that it was defeating the purpose of voicemail, considering you can configure * already to dial multiple channels, so why not just add a dial string for your cellphone as a next step from your office phone?  I think call forwarding could handle this quite well... and that could be done in the dialplan. By: rthrash (rthrash) 2004-05-02 11:28:02 That's a great idea to add, too! But I still want the ability to review messages and not being "forced" into taking a call, and hoping to keep all voicemail consolidated "at the office". Am I missing something here? By: twisted (twisted) 2004-05-02 11:49:56 No, I understand exactly where you're coming from.  In my system, i have all of my voicemail done on the server side, even with my cellphone connected, just by giving my cell a 15 second timeout - that way, it rings 3 times, along side the phones associated wtih my extension, and If i dont' answer it, it rolls into the voicemail app. By: twisted (twisted) 2004-05-02 11:52:39 However, we should think about starting a voicemail3 discucssion and getting a list of features for that, and I can see where you're coming from, and I'm not discounting this in any way as important.  Let's start making our prioritized lists of features we would like to see in an advanced voicemail package. By: rthrash (rthrash) 2004-05-02 14:40:59 Sounds like a plan to me. Out of curiosity, why write from scratch as voicemail3 vs add to voicemail 2? Granted, I've never looked at the code side one bit... There's some directory enhancements that could be rolled in too (see http://bugs.digium.com/bug_view_page.php?bug_id=0001524). By: twisted (twisted) 2004-05-02 19:39:51 Because voicemail2 has been hacked to death.  It has been great to us, and to continue to add features it's only going to get larger and more complicated to deal with.  If we want to keep on this discussion, we need to outline a new app for a possible replacement.  This is not only my concensus, but there are several of us who have discussed it.  Also, the directory features are handled by app_directory, and not app_voicemail. By: hwstar (hwstar) 2004-05-02 20:45:26 Twisted- I tend to agree. Not only will a new voicemail3 app allow a complete from-the-ground-up restructuring. As an added bonus, it will make it much easier to develop, test and debug because patches won't conflict against a live module (when bugs in vm2 are fixed). Steve. By: rthrash (rthrash) 2004-05-03 12:10:20 VM3 it is, then! What's the best way to go about moving this forward? By: hwstar (hwstar) 2004-05-03 13:39:07 Let's put together and share a text file outlining all of the features which VM3 will support. With this, we can then start asking architectural questions about the underlying code to support the feature set. By: Brian West (bkw918) 2004-05-05 00:31:27 Ok rthrash is going to start collecting stuff we would like to see in voicemail3 or so we have dubed the project.