[asterisk-bugs] [Asterisk 0018185]: Blind transfer failure, A calls B, B transfers to C
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Nov 22 12:46:34 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18185
======================================================================
Reported By: kwemheuer
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18185
Category: Channels/chan_sip/Transfers
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.8.0
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-10-22 04:43 CDT
Last Modified: 2010-11-22 12:46 CST
======================================================================
Summary: Blind transfer failure, A calls B, B transfers to C
Description:
The summary says it: Transfers are not working in one direction. In
detail:
I set up an asterisk system (version 1.8.0). While using a SIP only
environment I discovered a problem using blind transfer. The phones are
SNOM or Aastra and are using the SIP REFER Method.
For debugging purposes I stripped down the environment to a simple
dialplan with only three extensions. There are three phones (Snom)
registered to asterisk. I use release 1.8.0 from yesterday.
There are three extensions: 100, 150, and 180. There are three
SIP-Devices: phone1, phone2, and phone3. (See extensions.conf, sip.conf)
User on phone1 dials 150 (phone2). User on phone2 transfers the call to
phone3 (using blind transfer, SIP REFER Method). The calls fails (See debug
output in file failed.log)
The following scenario is working: User on phone1 dials 150 (phone2). User
on phone1 transfers the call to phone3 (using blind transfer, SIP REFER
Method). See debug output in file working.log.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0018192 Call dropped on SIP REFER in 1.8.0
related to 0018230 [regression] Redirect function (over co...
related to 0018299 Asterisk not send fax to fax extension
related to 0018254 Attended transfer failure
======================================================================
----------------------------------------------------------------------
(0129029) svnbot (reporter) - 2010-11-22 12:46
https://issues.asterisk.org/view.php?id=18185#c129029
----------------------------------------------------------------------
Repository: asterisk
Revision: 295790
U branches/1.4/apps/app_macro.c
U branches/1.4/include/asterisk/channel.h
U branches/1.4/include/asterisk/frame.h
U branches/1.4/main/channel.c
U branches/1.4/main/pbx.c
------------------------------------------------------------------------
r295790 | rmudgett | 2010-11-22 12:46:27 -0600 (Mon, 22 Nov 2010) | 46
lines
The channel redirect function (CLI or AMI) hangs up the call instead of
redirecting the call.
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue
https://issues.asterisk.org/view.php?id=16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue https://issues.asterisk.org/view.php?id=18171)
Reported by: SantaFox
(closes issue https://issues.asterisk.org/view.php?id=18185)
Reported by: kwemheuer
(closes issue https://issues.asterisk.org/view.php?id=18211)
Reported by: zahir_koradia
(closes issue https://issues.asterisk.org/view.php?id=18230)
Reported by: vmarrone
(closes issue https://issues.asterisk.org/view.php?id=18299)
Reported by: mbrevda
(closes issue https://issues.asterisk.org/view.php?id=18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=295790
Issue History
Date Modified Username Field Change
======================================================================
2010-11-22 12:46 svnbot Checkin
2010-11-22 12:46 svnbot Note Added: 0129029
======================================================================
More information about the asterisk-bugs
mailing list