[asterisk-bugs] [Asterisk 0017999]: Issues with DTMF triggered attended transfers
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Jan 18 12:07:17 CST 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17999
======================================================================
Reported By: iskatel
Assigned To: rmudgett
======================================================================
Project: Asterisk
Issue ID: 17999
Category: Core/PBX
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Target Version: 1.6.2.17
Asterisk Version: SVN
JIRA: SWP-2246
Regression: No
Reviewboard Link: https://reviewboard.asterisk.org/r/1047/
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-09-16 05:52 CDT
Last Modified: 2011-01-18 12:07 CST
======================================================================
Summary: Issues with DTMF triggered attended transfers
Description:
Hello!
There are such two situation during attendant transfer usage
Situation https://issues.asterisk.org/view.php?id=1
1) A (8123364000) calls B (0011*102). B answers.
2) B using DTMF dial *2 (code in features.conf for attendant transfer).
3) A hears MOH. B dial number C (3364021)
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
5) A hangup. C still ringing until "atxfernoanswertimeout" expires.
Problem: When A and B hangup C still ringing.
Situation https://issues.asterisk.org/view.php?id=2
1) A (8123364000) calls B (0011*102). B answers.
2) B using DTMF dial *2 (code in features.conf for attendant transfer).
3) A hears MOH. B dial number C (3364021)
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) "atxfernoanswertimeout" expires. After this asterisk tries callback "B"
but do it using such form "SIP/0011*102" and generates INVITE with
RURI=sip:@"dest_ip" i.e. without any number in RURI.
Because of this SIP remote device cannot handle call.
Problem: There is no number in RURI when try callback to B.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0017009 Dialplan continues execution after tran...
related to 0017956 [patch] atxfer broken on 1.6.2.11
related to 0018395 C should not receive request call again...
related to 0017096 C keeps ringing when hanging A and B af...
related to 0016856 [regression] Blind transfers initiated ...
related to 0018379 attended transfer weird behaviour
======================================================================
----------------------------------------------------------------------
(0130623) svnbot (reporter) - 2011-01-18 12:07
https://issues.asterisk.org/view.php?id=17999#c130623
----------------------------------------------------------------------
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 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=302173
Issue History
Date Modified Username Field Change
======================================================================
2011-01-18 12:07 svnbot Checkin
2011-01-18 12:07 svnbot Note Added: 0130623
======================================================================
More information about the asterisk-bugs
mailing list