[Home]

Summary:ASTERISK-17040: C should not receive request call again after C cancel if B blind transfer using atxfer call C
Reporter:aaa (shihchuan)Labels:
Date Opened:2010-11-29 04:31:00.000-0600Date Closed:2011-03-02 15:39:28.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) transfer_problem1.txt
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.
Comments:By: Richard Mudgett (rmudgett) 2010-12-02 21:53:01.000-0600

It is intended for Party B to be called back if Party C does not answer if atxferdropcall is no.  It is also intended to bounce back and forth between Party B and Party C for atxfercallbackretries times to try to get someone to take the Party A call.

However, the call linked to Party B is not completely hung up yet during the transfer.  This is why Party B has reached its call limit and is a bug.
By: Digium Subversion (svnbot) 2011-01-18 12:04:44.000-0600

Repository: asterisk
Revision: 302172

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r302172 | rmudgett | 2011-01-18 12:04:37 -0600 (Tue, 18 Jan 2011) | 88 lines

Issues with DTMF triggered attended transfers.

Issue ASTERISK-16684
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 ASTERISK-15876)

Problem: When A and B hangup, C is still ringing.

Issue ASTERISK-17040
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 ASTERISK-16041
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 ASTERISK-16041 and ASTERISK-17040 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 ASTERISK-16684)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246

(closes issue ASTERISK-15876)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192

(closes issue ASTERISK-17040)
Reported by: shihchuan
Tested by: rmudgett

(closes issue ASTERISK-16041)
Reported by: grecco
Tested by: rmudgett

Review: https://reviewboard.asterisk.org/r/1047/

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

http://svn.digium.com/view/asterisk?view=rev&revision=302172
By: Digium Subversion (svnbot) 2011-01-18 12:07:19.000-0600

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 ASTERISK-16684
 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 ASTERISK-15876)
 
 Problem: When A and B hangup, C is still ringing.
 
 Issue ASTERISK-17040
 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 ASTERISK-16041
 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 ASTERISK-16041 and ASTERISK-17040 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 ASTERISK-16684)
 Reported by: iskatel
 Tested by: rmudgett
 JIRA SWP-2246
 
 (closes issue ASTERISK-15876)
 Reported by: gelo
 Tested by: rmudgett
 JIRA SWP-1192
 
 (closes issue ASTERISK-17040)
 Reported by: shihchuan
 Tested by: rmudgett
 
 (closes issue ASTERISK-16041)
 Reported by: grecco
 Tested by: rmudgett
 
 Review: https://reviewboard.asterisk.org/r/1047/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=302173
By: Digium Subversion (svnbot) 2011-01-18 12:11:47.000-0600

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 ASTERISK-16684
   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 ASTERISK-15876)
   
   Problem: When A and B hangup, C is still ringing.
   
   Issue ASTERISK-17040
   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 ASTERISK-16041
   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 ASTERISK-16041 and ASTERISK-17040 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 ASTERISK-16684)
   Reported by: iskatel
   Tested by: rmudgett
   JIRA SWP-2246
   
   (closes issue ASTERISK-15876)
   Reported by: gelo
   Tested by: rmudgett
   JIRA SWP-1192
   
   (closes issue ASTERISK-17040)
   Reported by: shihchuan
   Tested by: rmudgett
   
   (closes issue ASTERISK-16041)
   Reported by: grecco
   Tested by: rmudgett
   
   Review: https://reviewboard.asterisk.org/r/1047/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=302174
By: Digium Subversion (svnbot) 2011-01-18 12:17:08.000-0600

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 ASTERISK-16684
     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 ASTERISK-15876)
     
     Problem: When A and B hangup, C is still ringing.
     
     Issue ASTERISK-17040
     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 ASTERISK-16041
     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 ASTERISK-16041 and ASTERISK-17040 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 ASTERISK-16684)
     Reported by: iskatel
     Tested by: rmudgett
     JIRA SWP-2246
     
     (closes issue ASTERISK-15876)
     Reported by: gelo
     Tested by: rmudgett
     JIRA SWP-1192
     
     (closes issue ASTERISK-17040)
     Reported by: shihchuan
     Tested by: rmudgett
     
     (closes issue ASTERISK-16041)
     Reported by: grecco
     Tested by: rmudgett
     
     Review: https://reviewboard.asterisk.org/r/1047/
   ........
 ................
................

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

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