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-0600Date Closed:2008-10-09 18:44:44
Versions:Frequency of
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.


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