[Home]

Summary:ASTERISK-16041: atxfer *2 channel dahdi FXS no hangup
Reporter:grecco (grecco)Labels:
Date Opened:2010-05-01 17:06:20Date Closed:2011-01-18 12:17:10.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug.txt
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



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

Tested?

asterisk-1.4.30

asterisk-1.6.2.6

asterisk-1.6.2.7-rc3

Comments:By: Paul Belanger (pabelanger) 2010-05-03 09:29:27

We are lacking information here (see below).  Are all the phones DAHDI? We will need traces, debug output and dialplans.

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt

---
Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We\'d be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!
By: grecco (grecco) 2010-05-03 20:56:53

Comments:

I got the call, port FXO number 4:
==================================

[May  3 21:12:07] DEBUG[3079] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 4
[May  3 21:12:07] VERBOSE[3079] logger.c:   == Starting post polarity CID detection on channel 4
[May  3 21:12:07] DEBUG[3079] dsp.c: dsp busy pattern set to 0,0
[May  3 21:12:07] VERBOSE[3116] logger.c:     -- Starting simple switch on 'DAHDI/4-1'
[May  3 21:12:07] DEBUG[3116] chan_dahdi.c: Receiving DTMF cid on channel DAHDI/4-1
[May  3 21:12:07] DEBUG[3116] chan_dahdi.c: DTMF digit: A on DAHDI/4-1


Answered port 3 FXS:
====================

[May  3 21:12:14] DEBUG[3025] devicestate.c: Changing state for DAHDI/3 - state 2 (In use)
[May  3 21:12:14] VERBOSE[3116] logger.c:     -- DAHDI/3-1 answered DAHDI/4-1
[May  3 21:12:14] DEBUG[3073] app_queue.c: Device 'DAHDI/3' changed to state '2' (In use)

Transfer call * (atxfer)
========================

[May  3 21:12:17] DEBUG[3116] chan_dahdi.c: DTMF digit: * on DAHDI/3-1
[May  3 21:12:17] DTMF[3116] channel.c: DTMF end '*' received on DAHDI/3-1, duration 0 ms
[May  3 21:12:17] DTMF[3116] channel.c: DTMF begin emulation of '*' with duration 100 queued on DAHDI/3-1
[May  3 21:12:17] DEBUG[3116] channel.c: Got DTMF begin on channel (DAHDI/3-1)
[May  3 21:12:17] DEBUG[3116] chan_dahdi.c: Requested indication 20 on channel DAHDI/4-1
[May  3 21:12:17] DEBUG[3116] chan_dahdi.c: Requested indication 20 on channel DAHDI/3-1
[May  3 21:12:17] DEBUG[3116] channel.c: Bridge stops bridging channels DAHDI/4-1 and DAHDI/3-1
[May  3 21:12:17] DEBUG[3116] chan_dahdi.c: Requested indication 20 on channel DAHDI/4-1
[May  3 21:12:17] DEBUG[3116] chan_dahdi.c: Requested indication 20 on channel DAHDI/3-1


In the 2 ringing, I put the phone down (dahdi/3). No running the hangup of channel 3 (dahdi/3). Locking (dahdi/3) up the call by the channel 2 (Dahdi-2).

occurs in versions of Asterisk:

asterisk-1.4.30;
asterisk-1.4.31-rc2;
asterisk-1.6.2.6;
asterisk-1.6.2.7-rc3;

If needed, I can send more information.
By: Francesco Romano (francesco_r) 2010-05-04 10:41:44

I think that is the same bug of ASTERISK-1685096.
By: Paul Belanger (pabelanger) 2010-05-04 10:45:20

grecco: The debug information looks good, but I am having a hard time understanding the issue.

---
A call B
B answered A
B *2 (atxfer) call C
C ringing (no answer)
B hangup

B it keeps calling, getting blocked
---
I don't understand 'it keeps calling, getting blocked'. Are you saying when you hang up B, Asterisk is not detecting the hangup and C keeps ringing?
By: Paul Belanger (pabelanger) 2010-05-04 13:24:36

francesco_r: I believe so too, I just wanted to confirm with the reporter.
By: grecco (grecco) 2010-05-04 14:46:28

Exactly,

A call B
B answered A
B *2 (atxfer) call C
C ringing (no answer)
B hangup (I put on the hook),I am picking up the phone. I can hear the ringing (B ringing C).

Correct, disconnect B (free) and connect A call (ringing) C.

Thread C (no answer), call (ringing)  B.

Sorry, my English is google. I am Brazilian.
By: Paul Belanger (pabelanger) 2010-05-04 15:03:32

Going to close this bug as a duplicate.  Please follow along with ASTERISK-1685096.
By: Richard Mudgett (rmudgett) 2010-12-02 21:38:54.000-0600

Please follow issue ASTERISK-17040 as it has the same root cause as this issue.

Issue ASTERISK-15876 is not a duplicate of this issue.


By: Digium Subversion (svnbot) 2011-01-18 12:04:45.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:20.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:48.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:09.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