|Summary:||ASTERISK-00106: Adding an option for double # transfers|
|Date Opened:||2003-08-16 05:15:27||Date Closed:||2011-06-07 14:05:16|
|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.