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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
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:             2008-03-06 08:12 CST
Last Modified:              2008-10-09 18:44 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=10585) 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0093438) svnbot (reporter) - 2008-10-09 18:44
 http://bugs.digium.com/view.php?id=12158#c93438 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=12158)
Reported by: davidw


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=148160 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-09 18:44 svnbot         Checkin                                      
2008-10-09 18:44 svnbot         Note Added: 0093438                          
======================================================================