[asterisk-bugs] [Asterisk 0012158]: New AMI atxfer limited to digits only and ignores context and priority; looks like just wrapper on PlatDTMF

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=12158 
====================================================================== 
Reported By:                davidw
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12158
Category:                   Core/ManagerInterface
Reproducibility:            N/A
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 106236 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-06-2008 08:12 CST
Last Modified:              03-10-2008 08:57 CDT
====================================================================== 
Summary:                    New AMI atxfer limited to digits only and ignores
context and priority; looks like just wrapper on PlatDTMF
Description: 
Based on code reading only, the implementation of the new "atxfer"
(http://bugs.digium.com/view.php?id=0010585) 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.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-10-08 08:57  file           Status                   new => assigned     
03-10-08 08:57  file           Assigned To               => putnopvut       
======================================================================