[asterisk-bugs] [Asterisk 0018322]: Redirect two bridged channels to the same conference
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Nov 22 13:36:27 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18322
======================================================================
Reported By: nerbos
Assigned To: rmudgett
======================================================================
Project: Asterisk
Issue ID: 18322
Category: Applications/app_meetme
Reproducibility: sometimes
Severity: major
Priority: normal
Status: closed
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:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2010-11-17 09:26 CST
Last Modified: 2010-11-22 13:36 CST
======================================================================
Summary: Redirect two bridged channels to the same conference
Description:
Greetings,
OS: centOS 5.5
Libpri: 1.4.11.4
Dahdi: 2.4.0
Asterisk: 1.8.0
Situation, i have two channels bridged together and i want to pass both
channels to a conference room, so i decided to send a Redirect in the AMI
console:
Action: Redirect
Channel: CHANNEL_1
ExtraChannel: CHANNEL_2
Exten: 1001
ExtraExten: 1001
Context: my_conference
ExtraContext: my_conference
Priority: 1
ExtraPriority: 1
ActionID: XXXX
Sometimes one of the channels fails to stay in the conference, other times
both channels stay in conference (as expected). The AMI events are
different in the two cenarios (the order of the events), when it fails, the
channel that didn't get masquerade is the first to send the MeetMeJoin
event, proceeded by a MeetMeLeave. When it works the first MeetMeJoin is
send by the masquerade channel. I don't know if this order is related to
this issue, but i found it important to report.
Best regards.
P.S.: My conference context is pretty simple...
[my_conference]
exten => _X.,1,MeetMe(${EXTEN},dq)
exten => _X.,2,Hangup
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0018230 [regression] Redirect function (over co...
======================================================================
----------------------------------------------------------------------
(0129049) svnbot (reporter) - 2010-11-22 13:36
https://issues.asterisk.org/view.php?id=18322#c129049
----------------------------------------------------------------------
Repository: asterisk
Revision: 295866
_U branches/1.8/
U branches/1.8/apps/app_macro.c
U branches/1.8/include/asterisk/channel.h
U branches/1.8/include/asterisk/frame.h
U branches/1.8/main/channel.c
U branches/1.8/main/pbx.c
------------------------------------------------------------------------
r295866 | rmudgett | 2010-11-22 13:36:11 -0600 (Mon, 22 Nov 2010) | 60
lines
Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53
lines
Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r295790 | rmudgett | 2010-11-22 12:46:26 -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=295866
Issue History
Date Modified Username Field Change
======================================================================
2010-11-22 13:36 svnbot Checkin
2010-11-22 13:36 svnbot Note Added: 0129049
======================================================================
More information about the asterisk-bugs
mailing list