Summary: | ASTERISK-16972: Redirect two bridged channels to the same conference | ||
Reporter: | Nuno Borges (nerbos) | Labels: | |
Date Opened: | 2010-11-17 09:26:35.000-0600 | Date Closed: | 2010-11-22 13:42:14.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_meetme |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
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 | ||
Comments: | By: Digium Subversion (svnbot) 2010-11-22 12:46:44.000-0600 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 ASTERISK-15731 (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 ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295790 By: Digium Subversion (svnbot) 2010-11-22 13:28:37.000-0600 Repository: asterisk Revision: 295843 _U branches/1.6.2/ U branches/1.6.2/apps/app_macro.c U branches/1.6.2/include/asterisk/channel.h U branches/1.6.2/include/asterisk/frame.h U branches/1.6.2/main/channel.c U branches/1.6.2/main/pbx.c ------------------------------------------------------------------------ r295843 | rmudgett | 2010-11-22 13:28:27 -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 ASTERISK-15731 (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 ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295843 By: Digium Subversion (svnbot) 2010-11-22 13:36:27.000-0600 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 ASTERISK-15731 (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 ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295866 By: Digium Subversion (svnbot) 2010-11-22 13:42:14.000-0600 Repository: asterisk Revision: 295867 _U trunk/ U trunk/apps/app_macro.c U trunk/include/asterisk/channel.h U trunk/include/asterisk/frame.h U trunk/main/channel.c U trunk/main/pbx.c ------------------------------------------------------------------------ r295867 | rmudgett | 2010-11-22 13:42:03 -0600 (Mon, 22 Nov 2010) | 67 lines Merged revisions 295866 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r295866 | rmudgett | 2010-11-22 13:36:10 -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 ASTERISK-15731 (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 ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ................ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295867 |