Summary:	ASTERISK-00705: [patch] Cancel voicemail
Reporter:	barton (barton)	Labels:
Date Opened:	2003-12-25 22:42:08.000-0600	Date Closed:	2011-06-07 14:05:30
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_voicemail.c.diff
Description:	This patch adds 2 parameters to voicemail.conf: cancelext and cancelkey.  This could be used to handle the "0" key to immediately cancel and exit out of voicemail, and redirect the user to an operator.  In this case, the user would specify this in voicemail.conf: cancelext=0 cancelkey=0 In this instance, when the user presses "0" while the voicemail is recording, they will be redirected to priority 1 of extension "0" within the current context.
Comments:	By: Brian West (bkw918) 2003-12-25 23:03:57.000-0600 diff -u please By: barton (barton) 2003-12-26 00:15:53.000-0600 diff -u added By: Brian West (bkw918) 2003-12-26 11:50:18.000-0600 shouldn't this continue on the current exten next priority?  anyone else have input? By: barton (barton) 2003-12-26 13:10:53.000-0600 That's what happens when voicemail() is finished, such as when the caller presses '#'.  Allowing the user to specify a "cancelext" can redirect the caller elsewhere when the voicemail is actually canceled.  I didn't see a need for a "cancelpriority" parameter in this situation because "cancelext" can be configured with a GoTo if necessary. By: Brian West (bkw918) 2003-12-26 13:16:02.000-0600 no I mean current priority+1 on cancel. By: Brian West (bkw918) 2003-12-26 13:22:20.000-0600 Er.. priority+101 ... to keep with the other conventions in other apps in asterisk.  for this to make it into CVS it would have to keep to the standards. By: barton (barton) 2003-12-26 14:41:26.000-0600 That defeats the purpose of the patch.  The voicemail documentation states "If the requested mailbox does not exist, and there exists a priority n + 101, then that priority will be taken next".  This would be used, perhaps to tell the caller that there is a problem with the system because the mailbox does not exist.  The patch I provided gives a way for the caller to be redirected to a specified extension.  A scenario might be for the caller to reach the operator because he/she does not want to leave a voicemail, but instead needs to talk with someone right away.  In your case, the caller would press "0" (or whatever key specified by the "cancelkey" parameter) and they would be dropped to priority "n+101" where they would receive a message about a missing mailbox.  This would be inappropriate. It is situations such as these that make me believe that we should be able to handle return codes from applications in the dialplan instead of the simple boolean GoTo(n+1|n+101) scheme currently used.  A global variable set to the return code could be queried with a GotoIf statement. edited on: 12-26-03 14:53 By: Brian West (bkw918) 2003-12-26 21:20:17.000-0600 I can see where this would work in situations like this. "You have reached the office of Bugs Bunny... if you wish to speak with my receptionist please press 0 otherwise leave a message..." See why its a good idea... you option doesn't scale in a multi company asterisk environment.  The N+101 you talk about is when a mailbox doesn't even exist.  Thats something totally diffrent. By: Brian West (bkw918) 2003-12-26 21:20:42.000-0600 Or you can make it N+50 like app_enum does. By: barton (barton) 2003-12-27 14:07:14.000-0600 "You have reached the office of Bugs Bunny... if you wish to speak with my receptionist please press 0 otherwise leave a message...", Exactly.  The natural reaction to some people is to immediately hit '0' if they don't want to leave a voicemail. "you option doesn't scale in a multi company asterisk environment"... sure it does, if everyone is using the same "cancelkey", each person can handle their "cancelext" within their own voicemail context and have it do whatever they want it to do, or even nothing at all.  In fact, it would work the same way as the "N+50" scheme you're suggesting.  Is "N+50" a standard convention in other apps in Asterisk? By: Brian West (bkw918) 2003-12-27 14:19:55.000-0600 but if company A wants their cancel key going elsewhere then it doesn't scale. Locking people to one way of doing things isn't good.  Giving both options would be a good idea. app_enum does this:(so its N+51 mybad) Currently, the enumservices SIP, H323, IAX, IAX2 and TEL are recognized. A good SIP, H323, IAX or IAX2 entry will result in normal priority handling, whereas a good TEL entry will increase the priority by 51 (if existing). By: Brian West (bkw918) 2003-12-27 14:28:12.000-0600 Also look at your diff you remove 3 lines that are questionable. - get_date(date, sizeof(date)); - time(&start); and: - res = play_and_record(chan, NULL, fn, vmmaxmessage, fmt); + Can you comment on those? By: barton (barton) 2003-12-27 14:37:40.000-0600 Those lines are moved, not removed (look at the resulting source after the patch is applied) so that the date and time are stored before play_and_record() is called.  This must be done so that the "origdate" and "origtime" can be written in the "Message Information File".  The writing of the "Message Information File" is also delayed until after play_and_record() is finished so that some message-waiting indicators (BT101) will not falsely notify the user that a voicemail has been left if the user decides to cancel leaving the voicemail. By: barton (barton) 2003-12-27 14:45:25.000-0600 "but if company A wants their cancel key going elsewhere then it doesn't scale."  Sure it does.  I don't follow your logic.  It scales in the same way that your suggested N+51 does.  Instead of dropping the user to N+51 when the voicemail is canceled (where the cancellation is handled per-employee/per-company, whatever... based upon the specific context they are in), it drops the user to the specified "cancelext" instead.  Each person/company can have their own "cancelext" handler within the voicemail context.  One "cancelext" is not used by everyone, and it therefore does not lock people into one way of doing things. Because they are functionally equivalent, there's no need to "sweat the small stuff" here... if N+51 is currently in use by applications, then we should probably use that instead (although I still believe that handling return codes from applications, or jumping to a user-specified extension is much more flexible). :) By: Brian West (bkw918) 2003-12-27 15:10:28.000-0600 I was looking at it from the standpoint that all extension logic and routing should stay in the extensions.conf file.  Then again I maybe wrong. By: barton (barton) 2004-01-13 20:32:39.000-0600 The updated patch is a rewrite of the original patch that takes into account the ideas found in this bugnote.  An option is added to the VoiceMail application that allows the user to specify a cancel key.  The usage would be as such: VoiceMail([s|u|b|c[1-9*]]extension[@context]) For example: exten => s,1,Voicemail(uc0${ARG1}) where "c" is the cancel flag and "0" is the cancel key.  Pressing the cancel key will cancel VoiceMail() at anytime after the application has begun, including when the Busy or Unavailable messages are being played due to the "c" or "b" flag.  If the cancel key is pressed, and priority n+51 exists, then that priority will be taken next. The "cancelkey" and "cancelext" options used in the original patch have been completely removed from this patch. By: Brian West (bkw918) 2004-03-21 11:04:11.000-0600 We already have 0 to exit to exten => o in app_voicemail if this isn't what you are needing or talking about then let me know.