[asterisk-bugs] [Asterisk 0017999]: Issues with DTMF triggered attended transfers

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Jan 18 12:07:16 CST 2011


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17999 
====================================================================== 
Reported By:                iskatel
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   17999
Category:                   Core/PBX
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Target Version:             1.6.2.17
Asterisk Version:           SVN 
JIRA:                       SWP-2246 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/1047/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-09-16 05:52 CDT
Last Modified:              2011-01-18 12:07 CST
====================================================================== 
Summary:                    Issues with DTMF triggered attended transfers
Description: 
Hello!

There are such two situation during attendant transfer usage
Situation https://issues.asterisk.org/view.php?id=1 
1) A (8123364000) calls B (0011*102). B answers.
2) B using DTMF dial *2 (code in features.conf for attendant transfer).
3) A hears MOH. B dial number C (3364021)
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing. 
5) A hangup. C still ringing until "atxfernoanswertimeout" expires.

Problem: When A and B hangup C still ringing. 

Situation https://issues.asterisk.org/view.php?id=2

1) A (8123364000) calls B (0011*102). B answers.
2) B using DTMF dial *2 (code in features.conf for attendant transfer).
3) A hears MOH. B dial number C (3364021)
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing. 
6) "atxfernoanswertimeout" expires. After this asterisk tries callback "B"
but do it using such form "SIP/0011*102" and generates INVITE with
RURI=sip:@"dest_ip" i.e. without any number in RURI.
Because of this SIP remote device cannot handle call.   

Problem: There is no number in RURI when try callback to B.  
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0017009 Dialplan continues execution after tran...
related to          0017956 [patch] atxfer broken on 1.6.2.11
related to          0018395 C should not receive request call again...
related to          0017096 C keeps ringing when hanging A and B af...
related to          0016856 [regression] Blind transfers initiated ...
related to          0018379 attended transfer weird behaviour
====================================================================== 

---------------------------------------------------------------------- 
 (0130623) svnbot (reporter) - 2011-01-18 12:07
 https://issues.asterisk.org/view.php?id=17999#c130623 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 302173

_U  branches/1.6.2/
U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r302173 | rmudgett | 2011-01-18 12:07:16 -0600 (Tue, 18 Jan 2011) | 95
lines

Merged revisions 302172 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88
lines
  
  Issues with DTMF triggered attended transfers.
  
  Issue https://issues.asterisk.org/view.php?id=17999
  1) A calls B. B answers.
  2) B using DTMF dial *2 (code in features.conf for attended transfer).
  3) A hears MOH. B dial number C
  4) C ringing. A hears MOH.
  5) B hangup. A still hears MOH. C ringing.
  6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
  For v1.4 C will ring forever until C answers the dead line. (Issue
https://issues.asterisk.org/view.php?id=17096)
  
  Problem: When A and B hangup, C is still ringing.
  
  Issue https://issues.asterisk.org/view.php?id=18395
  SIP call limit of B is 1
  1. A call B, B answered
  2. B *2(atxfer) call C
  3. B hangup, C ringing
  4. Timeout waiting for C to answer
  5. Recall to B fails because B has reached its call limit.
  
  Because B reached its call limit, it cannot do anything until the
transfer
  it started completes.
  
  Issue https://issues.asterisk.org/view.php?id=17273
  Same scenario as issue 18395 but party B is an FXS port.  Party B cannot
  do anything until the transfer it started completes.  If B goes back off
  hook before C answers, B hears ringback instead of the expected
dialtone.
  
  **********
  Note for the issue https://issues.asterisk.org/view.php?id=17273 and
https://issues.asterisk.org/view.php?id=18395 fix:
  
  DTMF attended transfer works within the channel bridge.  Unfortunately,
  when either party A or B in the channel bridge hangs up, that channel is
  not completely hung up until the transfer completes.  This is a real
  problem depending upon the channel technology involved.
  
  For chan_dahdi, the channel is crippled until the hangup is complete.
  Either the channel is not useable (analog) or the protocol disconnect
  messages are held up (PRI/BRI/SS7) and the media is not released.
  
  For chan_sip, a call limit of one is going to block that endpoint from
any
  further calls until the hangup is complete.
  
  For party A this is a minor problem.  The party A channel will only be
in
  this condition while party B is dialing and when party B and C are
  conferring.  The conversation between party B and C is expected to be a
  short one.  Party B is either asking a question of party C or announcing
  party A.  Also party A does not have much incentive to hangup at this
  point.
  
  For party B this can be a major problem during a blonde transfer.  (A
  blonde transfer is our term for an attended transfer that is converted
  into a blind transfer.  :)) Party B could be the operator.  When party B
  hangs up, he assumes that he is out of the original call entirely.  The
  party B channel will be in this condition while party C is ringing,
while
  attempting to recall party B, and while waiting between call attempts.
  
  WARNING:
  The ATXFER_NULL_TECH conditional is a hack to fix the problem.  It will
  replace the party B channel technology with a NULL channel driver to
  complete hanging up the party B channel technology.  The consequences of
  this code is that the 'h' extension will not be able to access any
channel
  technology specific information like SIP statistics for the call.
  
  ATXFER_NULL_TECH is not defined by default.
  **********
  
  (closes issue https://issues.asterisk.org/view.php?id=17999)
  Reported by: iskatel
  Tested by: rmudgett
  JIRA SWP-2246
  
  (closes issue https://issues.asterisk.org/view.php?id=17096)
  Reported by: gelo
  Tested by: rmudgett
  JIRA SWP-1192
  
  (closes issue https://issues.asterisk.org/view.php?id=18395)
  Reported by: shihchuan
  Tested by: rmudgett
  
  (closes issue https://issues.asterisk.org/view.php?id=17273)
  Reported by: grecco
  Tested by: rmudgett
  
  Review: https://reviewboard.asterisk.org/r/1047/
........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-18 12:07 svnbot         Checkin                                      
2011-01-18 12:07 svnbot         Note Added: 0130623                          
======================================================================




More information about the asterisk-bugs mailing list