Summary:ASTERISK-00106: Adding an option for double # transfers
Reporter:iain (iain)Labels:
Date Opened:2003-08-16 05:15:27Date Closed:2011-06-07 14:05:16
Versions:Frequency of
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


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.