| Summary: | ASTERISK-11588: New AMI atxfer limited to digits only and ignores context and priority; looks like just wrapper on PlatDTMF | ||
| Reporter: | David Woolley (davidw) | Labels: | |
| Date Opened: | 2008-03-06 08:12:32.000-0600 | Date Closed: | 2008-10-09 18:44:44 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/ManagerInterface |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Based on code reading only, the implementation of the new "atxfer" (ASTERISK-1052585) AMI command appears to accept and validate context and priority parameters but then not use them. It last processes them before it has resolved the channel, so I don't believe they can have been recorded as a side effect of the validation. Also, compared with a SIP initiated attended transfer, and, probably, the original proposal, it is limited to extensions that can be represented with DTMF digits. Although I can't claim to understand Asterisk well enough to be sure yet, it looks to me that it will not allow transfers in situations where a SIP initiated transfer would be allowed. I'm also somewhat concerned that it may, unnecessarily force the media stream to go through Asterisk, although I'm not certain that wasn't a limitation of the original proposal, or of all attended transfer solutions. Conversely, I'm not sure that you can't have control frames only, provided DTMF doesn't have to be detected in the audio stream. Again these are areas where I'm still learning. I also wonder about the implications of DTMF for a media stream that doesn't carry audio, although that may be because I'm treating the word Tone too literally. My impression is that this new feature is just a wrapper around PlayDTMF, given that anyone using AMI really ought to know the codes to invoke an attended transfer. If it can't be done just using PlayDTMF, I feel that the correct solution, to providing the current limited capability, is to extend PlayDTMF so that it can be done that way. ****** ADDITIONAL INFORMATION ****** If possible, re-open ASTERISK-1052585 | ||
| Comments: | By: Mark Michelson (mmichelson) 2008-06-03 15:55:19 Hi, sorry about the lack of activity on this issue. The problem is that this has taken a back seat to many higher-priority issues and so I haven't gotten around to addressing this yet. It still will probably be a while before anything is done to address this, but I just wanted to reassure you that this issue is not being ignored. By: Digium Subversion (svnbot) 2008-10-09 18:44:41 Repository: asterisk Revision: 148160 U trunk/main/manager.c ------------------------------------------------------------------------ r148160 | mmichelson | 2008-10-09 18:44:41 -0500 (Thu, 09 Oct 2008) | 14 lines The priority was unnecessary for the manager atxfer, so it has been removed. Furthermore, now we actually use the Context argument passed to set the transfer context and don't error out if no context is specified. This addresses the actual problems outlined in issue 12158. Regarding the other points brought up, regarding the inability to not transfer to extensions which cannot be represented by DTMF, it is not enough of a constraint that it is worth attempting to rework the feature. (closes issue ASTERISK-11588) Reported by: davidw ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=148160 | ||