[asterisk-bugs] [Asterisk 0017273]: atxfer *2 channel dahdi FXS no hangup

Tue Jan 18 12:17:10 CST 2011

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17273 
====================================================================== 
Reported By:                grecco
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17273
Category:                   Channels/chan_dahdi
Reproducibility:            have not tried
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.2.7-rc3 
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-05-01 17:06 CDT
Last Modified:              2011-01-18 12:17 CST
====================================================================== 
Summary:                    atxfer *2 channel dahdi FXS no hangup
Description: 
Attended transfer *2 (feature atxfer=*2), channel dahdi port FXS.

A call B
B aswered A
B *2 (atxfer) call C 
C rining (no aswer)
B hangup 

B it keeps calling, getting blocked

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018395 C should not receive request call again...
====================================================================== 

---------------------------------------------------------------------- 
 (0130634) svnbot (reporter) - 2011-01-18 12:17
 https://issues.asterisk.org/view.php?id=17273#c130634 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 302178

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r302178 | rmudgett | 2011-01-18 12:17:05 -0600 (Tue, 18 Jan 2011) | 109
lines

Merged revisions 302174 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r302174 | rmudgett | 2011-01-18 12:11:43 -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=302178 

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