Summary:	ASTERISK-00106: Adding an option for double # transfers
Reporter:	iain (iain)	Labels:
Date Opened:	2003-08-16 05:15:27	Date Closed:	2011-06-07 14:05:16
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) doublehash.patch
Description:	The # transfer option is not usable if the caller will be calling a remote IVR system that needs a # passed through eg to terminate digit entry.  The attached patch changes the default behaviour for SIP so that a single # is passed through to the remote system but two hashes in quick succession triggers a transfer ****** ADDITIONAL INFORMATION ****** Although only tested for SIP (specifically ATA186) this option  may be needed on other phones.  Ideally it needs to be associated with a system-wide or extension specific config variable.
Comments:	By: Mark Spencer (markster) 2003-08-16 12:01:15 How about the reverse behavior since, when transferring, you don't want anyone to hear the '#'.  How about pressing hash twice (i.e. transferring to an empty extension), passes a # down the line. By: iain (iain) 2003-08-16 14:21:31 It's elegant but it makes the behaviour a bit odd for users that aren't interested in the # transfer option - presumably there'd have to be a delay after # was pressed once to be sure aother wasn't in the pipeline? AFAIK my patch won't pass a # down the line if # is pressed twice - so the remote user shouldn't hear anything untoward By: Mark Spencer (markster) 2003-08-16 15:36:43 If they're not interested in the # transfer option, why would they put it in the dial command line?  There would not need to be any delay because '#' in transfer mode terminates the extension that you're transferring to. By: iain (iain) 2003-08-16 16:15:37 Good point.  However, there will be some cases eg with SIP phones where a user may have some phones that have a specific transfer button and some that don't (eg via an ATA186).  Having uniform handling of DTMF in either case seems like a good idea.  Otherwise users would have to adapt their behaviour depending on the phone. I don't quite follow the argument about there being no delay "because '#' in transfer mode terminates the extension that you're transferring to".  I'm assuming that, after the first # is pressed asterisk will start the transfer process and start saying "transfer" which will then be cut off by the second press of #  - seems a bit messy. By: Mark Spencer (markster) 2003-08-18 19:33:47 Not really, you cut it off generally when typing an extension anyway.  If they have a specific transfer button, why would you use the '#' transfer anyway?  It's clearly inferior. By: iain (iain) 2003-08-19 03:42:23 I think this is heading towards being a Pythonesque debate over personal preferences.  In a mixed environment those with the transfer key will of course use it but those with analogue phones need a transparent alternative. I think that the most transparent behaviour is for any single keypress on an analogue phone to be passed through to the remote system - whatever the key.  Transfer is an additional behaviour that is triggered by the special double # key sequence.  I think the alternative leaves analogue phones as a poor relation. By: Mark Spencer (markster) 2003-08-20 09:32:43 Okay, but lets visit reality for a moment.... 1) You are the first person *ever* to complain about the legitimate bug that # transfer affects your ability with IVR.  Even though there are *lots* of # transfer users out there who use this feature (typically on in-bound only calls where IVR would be extremely rare). 2) The proposed change would *break* the behavior that everyone who has heretofore used Asterisk has come to expect from the feature. 3) Double # for # transfer is highly un-intuitive. 4) The proposed solution makes a feature which is accessed by performing an action within a relatively tight time constraint.  I still see people who have problems managing "flash" correctly. 5) If the max delay between the first and second # is too long, then the # will be delayed going out the PSTN interface, and someone may type '#' twice thinking it didn't make it the first time. 6) If the delay is too short, it may be difficult for the user to get used to. All in all, I don't think this is a good idea.  If you want to be able to send it twice, I think double '#' as detected by the code which reads the extension is the way to go.  Send a patch if you like. By: iain (iain) 2003-08-20 10:31:48 Just read the list - I was specifically requested by others to post the patch because they thought it was a good idea and had encountered exactly the same problem. I really fon't want to continue this debate it's smashing my interest in asterisk to bits.