Summary:	ASTERISK-20463: Atxfer manager command (and channel feature) can't transfer to an extension including '#'
Reporter:	Dade Brandon (dade)	Labels:
Date Opened:	2012-09-23 15:19:38	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Features
Versions:	10.1.3 10.7.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux, 3.2.0-29-generic, Asterisk 10.7.0 and 10.1.3	Attachments:
Description:	1) in app.c, ast_app_dbget: always breaks loop when receiving '#' (and doesn't append it to the dtmf string) 2) in features.c, builtin_atxfer: calls ast_app_dbget to retrieve transfer to extension 3) in manager.c, action_transfer queues dtmf frames to perform transfer Because of this, if in the manager interface, I supply Exten: ##971, then it's read as an empty extension Atxfer will not work on any extension that requires a # I'm sure this won't receive top priority (And I rewrote my extensions already, that are auto generated by my crm...) but I was looking for a long time in configs and docs, thinking that '#' being a terminatr was a config problem on my end Could the lack of support for extensions containing a '#' be added to the documentation? A solution could be to modify action_atxfer to set a flag indicating that dtmfs are being simulated, causing '#' to read in to the extension string, but I didn't opt to write a patch for that because I don't know if such a workaround for a relatively insignificant feature (atxfer) would meet Asterisk's code quality guidelines.  That solution doesn't work for a true dtmf initiated atxfer, though.  Can ast_app_dbget be rewritten to only stop at a '#' if it's sure that there's no possible matching extensions that could use this '#'?
Comments:	By: Birger "WIMPy" Harzenetter (wimpy) 2012-09-24 21:28:05.158-0500 I don't see why you think it would be no good for real feature transfers. They start executing the dialplan as soon as there's a match, without the need for a terminating #. So I think it should be fixed for all cases. I do however see a potential issue with dialing out on a SIP peer. That issue does however already exist in other circumstances.