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. |