[Home]

Summary:ASTERISK-15876: C keeps ringing when hanging A and B after blind transfer using atxfer
Reporter:gelo (gelo)Labels:
Date Opened:2010-03-26 04:35:32Date Closed:2011-01-18 12:17:08.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 17069.debug.log
( 1) sip-debug-blonde-xfer-KO.txt
Description:The scenario is as follows:

1. A calls B
2. B answers, presses *2 for atxfer
3. While C is ringing, B hangs up

At this point, A and C are connected, so if C answers the call, A and C speak without any problem.

But, if A hangs up while C is ringing, C keeps on ringing indefinitely

****** ADDITIONAL INFORMATION ******

I'm using attended transfers as blind transfers so that C gets B as CID, for billing purposes.
Comments:By: gelo (gelo) 2010-03-26 04:52:18

I forgot to point out that it's a SIP only scenario. Haven't tested if this happens also with other technologies.
By: Paul Belanger (pabelanger) 2010-03-26 09:35:40

Your bug report lacks information needed to investigate this issue, you will need to provide debugging output.  Please review the bug guidelines (http://www.asterisk.org/developers/bug-guidelines) for more information.
By: Leif Madsen (lmadsen) 2010-03-26 13:27:38

The term for this type of transfer is "blonde transfer".

As mentioned by pabelanger you'll need to follow the bug guidelines. You'll need at the very least a complete SIP console trace.
By: Francesco Romano (francesco_r) 2010-03-27 10:43:42

I can confirm this bug using only the Builtin Feature code (*2). Using the native sip atxfer between two hard phones, "blonde transfer" works well.
By: gelo (gelo) 2010-03-29 03:21:26

I did read the bug guidelines, but didn't upload a SIP trace, as I don't think it's a SIP problem

I've uploaded a console trace, as requested. Please let me know if you need anything else.

A = 1236 (10.1.3.15)

B = 1234 (10.1.3.16)

C = 1235 (10.1.2.16:5061)

Asterisk IP = 10.1.2.130
By: Paul Belanger (pabelanger) 2010-04-01 13:13:46

I can confirm this, I just tested it locally. I will try and upload a debug log shortly.


By: Paul Belanger (pabelanger) 2010-04-01 13:36:33

Attached debug log.

[Apr  1 18:28:15] DEBUG[30267] channel.c: Soft-Hanging up channel 'Local/3002@from-sip-1391,2'

Is when I manually hung up phone C.


By: Amilcar S Silvestre (amilcar) 2010-04-27 04:35:28

Any news on this? I think it's a blocker for 1.4.31.
By: Paul Belanger (pabelanger) 2010-04-27 08:56:41

I don't see this as a block for 1.4.31. The issue is in the queue and will get looked at when a developer resource becomes available.
By: grecco (grecco) 2010-07-06 15:36:10

Any fix?

Is there a patch?
By: Leif Madsen (lmadsen) 2010-07-06 17:34:00

Patches would be attached to this issue at the time they were developed.
By: grecco (grecco) 2010-08-24 14:43:47

Good afternoon!

Some forecast to fix the problem?

Grateful,
By: Stefan Schmidt (schmidts) 2010-08-25 13:26:29

have a look at the related issue 0017192 there is allready a review request which will fix the problem in issue 0017192. maybe this could help you too.
By: Digium Subversion (svnbot) 2011-01-18 12:04:40.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:17.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:45.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:06.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