Summary: | ASTERISK-26101: [patch] Bridge: Channel is not unheld in attended transfer | ||
Reporter: | Niclas Larsson (EdgeSystems) | Labels: | |
Date Opened: | 2016-06-09 07:53:12 | Date Closed: | 2020-01-14 11:13:35.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Core/Bridging/bridge_basic |
Versions: | 13.9.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Debian 7.10 | Attachments: | ( 0) atxfer.patch ( 1) atxfer2.patch |
Description: | 1. A calls B
2. B starts a atxfer to C 3. A => moh, B => hold 4. C answers 5. A hung up 6. B and C is still talking (and the atxfer is aborted) but B is still on hold Shouldn't B be unholded as soon as the channel starts dialing or at least when C answers? The following patch solves the problem (when C answers) but I'm not quite sure if it's the right place/thing to do. Inline patch removed. | ||
Comments: | By: Asterisk Team (asteriskteam) 2016-06-09 07:53:12.864-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2016-06-10 06:00:36.588-0500 We can't accept patches unless they've been attached and marked as a code contribution. If you'd like to attach the one you made please do so. By: Niclas Larsson (EdgeSystems) 2016-06-10 07:34:09.349-0500 Done. One thing though, in {code} static enum attended_transfer_state double_checking_exit(struct attended_transfer_properties *props, enum attended_transfer_stimulus stimulus)` {code} there is {code} case STIMULUS_DTMF_ATXFER_SWAP: hold(props->transferer); bridge_move(props->target_bridge, props->transferee_bridge, props->transferer, NULL); unhold(props->transferer); return TRANSFER_CONSULTING; {code} which will cause the patch to unhold a second time. By: Niclas Larsson (EdgeSystems) 2016-06-10 08:00:23.773-0500 Unhold even earlier. By: Richard Mudgett (rmudgett) 2016-06-13 10:50:46.364-0500 Please attach a log of the situation. Off-hand I think this may be a misunderstanding of the hold message. When B initiates the atxfer, B puts A on hold. Since A hangs up and thus goes away before the transfer completes there is no need to unhold A. By: Asterisk Team (asteriskteam) 2016-06-27 12:00:00.902-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines |