[Home]

Summary:ASTERISK-26101: [patch] Bridge: Channel is not unheld in attended transfer
Reporter:Niclas Larsson (EdgeSystems)Labels:
Date Opened:2016-06-09 07:53:12Date Closed:2020-01-14 11:13:35.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Core/Bridging/bridge_basic
Versions:13.9.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian 7.10Attachments:( 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