[asterisk-bugs] [Asterisk 0018395]: C should not receive request call again after C cancel if B blind transfer using atxfer call C

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


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18395 
====================================================================== 
Reported By:                shihchuan
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   18395
Category:                   Features
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.8.0 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
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-11-29 04:31 CST
Last Modified:              2011-01-18 12:11 CST
====================================================================== 
Summary:                    C should not receive request call again after C
cancel if B blind transfer using atxfer call C
Description: 
call limit of B is 2
1. A call B, B answered
2. B *97(atxfer) call C, C rining (no aswer)
3. B hangup 
4. C cancel 
5. B receive request call (It's ok)

call limit of B is 1
1. A call B, B answered
2. B *97(atxfer) call C, C rining (no aswer)
3. B hangup 
4. C cancel call
5. C receive request call again, C ringing (behavior isn't reasonable)
6. C cancel call again 
7. C receive request call again, C ringing (behavior isn't reasonable)

Because B reached call limit, C receive request call again.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0017273 atxfer *2 channel dahdi FXS no hangup
related to          0017999 Issues with DTMF triggered attended tra...
====================================================================== 

---------------------------------------------------------------------- 
 (0130629) svnbot (reporter) - 2011-01-18 12:11
 https://issues.asterisk.org/view.php?id=18395#c130629 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 302174

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

------------------------------------------------------------------------
r302174 | rmudgett | 2011-01-18 12:11:44 -0600 (Tue, 18 Jan 2011) | 102
lines

Merged revisions 302173 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r302173 | rmudgett | 2011-01-18 12:07:15 -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=302174 

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




More information about the asterisk-bugs mailing list